>
> Personally, I'd be interested to see info about non-Blackdown free
> JVMs. We don't hear too much about them on this list. That would
> have been an interesting comparison.
>
I ran the JVMSpec98 benchmarks from the cmdline to see how Kaffe
measures up against other JVMs.
Here's the estimates I got; they're all in seconds, lower is better:
compress jess db javac mpegaudio mtrt jack
ibmjdk 32.13 52.48 64.59 62.41 26.61 37.39 32.13
msjvm 33.90 51.40 129.00 84.50 41.00 24.90 65.10
sun1.1.8 32.50 35.10 108.00 117.00 30.30 58.40 42.20
jdk1.2 76.41 69.32 158.47 111.12 60.66 62.10 83.15
Kaffe/jit3 47.54 104.33 98.49 111.99 91.44 115.31 142.26
tya15 123.08 90.00 125.09 158.01 126.15 131.40 69.57
Kaffe/jit2 103.80 130.07 132.95 171.29 175.49 159.69 265.76
These were run from the cmdline with a -mx64M setting, and not from
the spec harness. Consequently, I am unable to claim that these numbers
represent Spec numbers. Let's consider them rough estimates, please.
They're nothing more. The numbers above are the averages of running
the benchmarks 2-4 times (via -m2 -M4), without regard to outliers etc.
(though there weren't any.)
The JVMs involved were:
ibmjdk: IBM JDK 1.1.8 with native threads running under RH 6.0
jdk1.2: Blackdown 1.2 with sunwjit and green threads running under RH 5.2
Kaffe/jit2: Kaffe with the old jit (the one that's in 1.0b4) under RH 5.2
Kaffe/jit3: The current Kaffe which will be released as 1.0b5 shortly.
msjvm: Microsoft 1.1 JVM running under Windows 98.
sun1.1.8: Sun's 1.1.8 JVM running under Windows 98 (uses Symantec JIT)
tya15: Blackdown JDK 1.1.7a with newest TYA jit (1.5) under RH 5.2
Everything was run on identical hardware, a dual proc PII/350.
Note the obvious caveats: we have not only different versions of JVMs
involved, but even different OSes. ibmjdk's number are particularly
inaccurate because I didn't turn off the second CPU; I saw a CPU
utilization from 100%-112% for two benchmarks, javac and mtrt, which
by the way is impressive by itself and in javac's case most likely
indicates parallel asynchronous gc. But it puts ibm's javac number
somewhat in perspective.
In addition, while I'm confident about the memory settings for the
Linux versions, I'm unsure about the settings for Microsoft's JVM.
Note that these benchmarks all generate a tremendous amount of garbage
and a JVM's performance on these benchmarks is greatly influenced by
the amount of memory available as well as the performance of its
allocator/garbage collector.
Let me repeat it again: these are ballpark numbers; any detailed
conclusions you might want to draw are inadmissible.
I should maybe add a comment about the kaffe numbers. Tim Wilkinson
wrote and integrated a faster JIT ("jit3") during this summer. This
has led to a good speedup, allowing kaffe to surpass the 1.1.7/TYA 1.5
combo for all but two benchmarks. JIT3 is available for x86, mips, m68k,
and StrongARM, it's not available for sparc and alpha at this point.
Sparc is jit2, and alpha is interpreter-only currently.
It is also interesting to note how some benchmarks are dominated by a
single aspect of a JVM. jack, for instance, throws numerous exceptions.
A JVM's jack performance is strongly influenced by the speed with which
it dispatches exceptions. Switching Kaffe's exception mechanism
to use a hashtable instead of linear search to find exception handlers, for
instance, yielded a speedup from 238 seconds to the 142 seconds.
- Godmar
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
