CTOForADay.com

The following results compare the Java Grande section 1 benchmark timings of Jenga, a PowerBook 400, to a PowerBook 667 ("Unk PB" or just "PB"), to an unspecified Acer system (it's in mail, somewhere.)

The important points are:

• For most tests, the PowerBook 400 is only .3 to .6x the performance of the PowerBook 667. That's more stark than I was expecting, but more than made up for by differences in on-chip cache, faster access to main memory during cache misses, and overal faster performance.
• In several tests, there are bizarre and strong differences in cost between the intel platform and the G4 systems under test. These scale, and are predictable: they reflect specific problems with the Mac implementation of the JVM, and are not a testament that Intel systems under test are somehow thousands of times faster at performing a given operation. Specifically:
  1. Casting of longs to doubles is bizarrely expensive in the Mac JVM. No good reason I can think of.
  2. Array creation looks frighteningly unoptimized, with allocations for 'aligned' values being cheaper than unaligned ones. This should be transparent, and the results of any of these allocation should result in aligned values.
  3. Exception:Throw test. God only knows.
  4. poor performance of Math:Random test, given what it is and does.
  5. Memory allocation is noticeably more expensive in the Create:Object examples. This is, again, a fundamental issue - and the 0.3x improvement of the PB to the Acer is almost guaranteed to be the 133MHz main memory bus over the 100MHz one.
  6. General poor performance of Math:*. Again, given that we've got more GP registers to work with, and the relative integer performance between the systems, the math numbers in specific cases are well out of line with expectations.
  7. Poor performance of Instance, InstanceOfAbstract - these are common tests that will have widespread impact on high level application performance.
  8. Poor performance of serial reading/writing - again, frighteningly bad sign for anyone doing a wide range of Java development, this just shouldn't happen.

I find it difficult to accept, given the otherwise relative performance of these systems, that these are anything other than fundamental problems with the VM implementation. Specifically:

• Memory allocation messiness; specifically with the way that the array tests show unusual, unoptimal allocation, whereby small allocations suffer greatly in performance.
• Behavior of fundamental instance/instance of abstract, as well as other key fundamental areas, suffers from huge performance degradation. Those places must be corrected in order for higher-level applications which make heavy use of that functionality to behave in predictable ways; just as allocation performance has an effect on all applications, so does instance validation and the cost of casting.
• Inexplicable, sudden drops in performance for what appear to be simple operations of casts on primitive types.
• Awful serialization performance. Tell me this is due to endian issues...