Unable to compile IcedTea with CACAO under Fedora 17

Peter B. Kessler Peter.B.Kessler at Oracle.COM
Tue Dec 18 13:58:51 PST 2012


You can combine printing the version stamp and running your program with, for example

    $ java -showversion HelloWorld
    java version "1.7.0_07"
    Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
    Java HotSpot(TM) Server VM (build 23.3-b01, mixed mode)

    Hello world!

I find that helps me not forget which JVM generated which output, e.g., in logged output.

			... peter

Robert Lougher wrote:
> On 18 December 2012 21:00, Robert Lougher <rob.lougher at gmail.com> wrote:
>> Hi Greg,
>>
>> On 18 December 2012 18:02, Greg Johnson <gregjo at yahoo.com> wrote:
>>> Under Debian, I have this:
>>> # java -version
>>> java version "1.6.0_18"
>>> OpenJDK Runtime Environment (IcedTea6 1.8.13) (6b18-1.8.13-0+squeeze1)
>>> OpenJDK Zero VM (build 14.0-b16, mixed mode)
>>>
>>> Under Fedora, I have this:
>>> # java -version
>>> java version "1.7.0_b147-icedtea"
>>> OpenJDK Runtime Environment (fedora-2.1.fc17.6-arm)
>>> OpenJDK Zero VM (build 22.0-b10, interpreted mode)
>>>
>>> Both are using Zero VM, but with different modes. Then I received this
>>> explanation from the Raspberry Pi forums:
>>> --------------------------------------
>>> The main reason why you see a magnitude difference in the Debian vs Fedora
>>> results really boils down to that there exist two variants of Zero.
>>>
>>> In Fedora you have installed OpenJDK Zero VM (build 22.0-b10, interpreted
>>> mode)
>>> This is using the C++ interpreter only.
>>>
>>> In Debian you have installed OpenJDK Zero VM (build 14.0-b16, mixed mode)
>>> The "mixed mode" version contains two addons, designed by Edward Nevill, on
>>> top of the generic Zero C++ interpreter, a rewritten interpreter main loop
>>> in ARM assembly this speeds up the jvm about a factor x3 this do benefit the
>>> Pi.
>>> The "mixed mode" also include a Thumb2 JIT that improves speed for ARMv7
>>> cores and later, the Pi could benefit from this JIT if it got rewritten from
>>> Thumb2 to target generic ARM or Thumb1 assembly.
>>> -----------------------------------------
>>>
>> Performance-wise JamVM is faster than the assembly interpreter but
>> slower than the Thumb2 JIT.  However this doesn't work on the Pi, so
>> JamVM should be faster than what you used on Debian (as long as it was
>> on the Pi).
>>
> 
> Some numbers (SciMark is far from my favourite but it runs quickly):
> 
> rob at terminus ~ $ java -version
> java version "1.7.0_07"
> OpenJDK Runtime Environment (IcedTea7 2.3.2) (7u7-2.3.2a-1+rpi1)
> OpenJDK Zero VM (build 22.0-b10, mixed mode)
> rob at terminus ~ $
> rob at terminus ~ $ java -jamvm -version
> java version "1.7.0_07"
> OpenJDK Runtime Environment (IcedTea7 2.3.2) (7u7-2.3.2a-1+rpi1)
> JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching)
> rob at terminus ~ $
> rob at terminus ~ $ java -jamvm -cp scimark2lib.jar jnt.scimark2.commandline
> 
> SciMark 2.0a
> 
> Composite Score: 5.5537918178428125
> FFT (1024): 3.5766089775997916
> SOR (100x100):   10.826562572167525
> Monte Carlo : 1.0230009994051166
> Sparse matmult (N=1000, nz=5000): 5.1887509149849
> LU (100x100): 7.154035625056732
> 
> java.vendor: Oracle Corporation
> java.version: 1.7.0_07
> os.arch: arm
> os.name: Linux
> os.version: 3.2.27+
> rob at terminus ~ $ java -cp scimark2lib.jar jnt.scimark2.commandline
> 
> SciMark 2.0a
> 
> Composite Score: 3.025386835322935
> FFT (1024): 1.769265203055126
> SOR (100x100):   6.539676672735603
> Monte Carlo : 0.627889791674138
> Sparse matmult (N=1000, nz=5000): 2.660431296672497
> LU (100x100): 3.5296712124773117
> 
> java.vendor: Oracle Corporation
> java.version: 1.7.0_07
> os.arch: arm
> os.name: Linux
> os.version: 3.2.27+
> rob at terminus ~ $
> 
>>> The Thumb2 info is out of my league. However, the disparity on performance
>>> was drastic, thus I searched out other avenues. Cacao was suggested, so I
>>> thought I'd try it out. Since it won't compile on 32bit x86, I have no hope
>>> of compiling it on ARM. I guess my search continues.... :-(  Stefan
>>> suggested JamVM as a possibility. Off I go. :-)



More information about the distro-pkg-dev mailing list