Re:Wrong Again (Score 1)

A 32-bit JVM can only address 4 GB of memory. Java has to do garbage collection. The longer you can defer garbage collection, the higher your benchmark score. With a 64-bit JVM addressing 96 GB of RAM, you can defer garbage collection for the length of the benchmark run.

Also, I would bet that when Sun runs SPECjbb using the 1.4 JVM (64-bit), they will produce 6800 results very similar to, and perhaps better than, the p680. Also, if you note at www.spec.org, a 24 CPU HP Superdome scored 146,825 on SPECjbb using a 32-bit JVM. When HP runs this with a 64-bit JVM, they will probably exceed 200,000, crushing both IBM and Sun.

In short, if you are using SPECjbb to estimate performance for a planned J2EE appserver, you would be an incompetent fool to use a 64-bit JVM run, unless you know your appserver used a 64-bit JVM, and most (if not all) do not.

Granted, I should have been more careful in looking at the JVMs. But consider this: the 8 and 12 way versions of the 680s without the 64-bit JVM (with JIT enabled, but I'd consider that part of the platform IBM provides for Java) outdo the 8 and 12 way E6800.

The difference isn't as dramatic, but observe that the iSeries 840, in its 12 and 24-way forms (32 bit JVM) outdoes the E6800. The processors are the same and the 12 way numbers for the 840 are lower than than of the 680. IBM's older-generation boxes admittedly lose to the E6800, but I claim that this is because the older AS400s and RS6Ks used the Power III back then (notice also that the numbers from the old AS400s are comparable to the old RS6Ks). This suggests two things: Sun's scaling from 12 to 24 isn't as efficient; although a 64-bit JVM helps, the RS64 IV at 600 Mhz as a platform simply outdoes the 750 Mhz US III. It's even scarier when you look at the numbers for the 750 Mhz RS64 IV (granted that they are with 64 bit JVMs).

And speaking of TPC benchmarks, what about TPC-H? IBM has a pretty decent 128 CPU SP2 result. However, the Sun 6800's CPUs are exactly twice as fast as the SP2's CPUs, and got exactly twice the performance per CPU, and both systems were running IBM's DB2 database.

I don't get the TPC-H complaints about IBM. I assume IBM hasn't published TPC-H stuff because it hasn't had an SP model (i.e. clusterable) until the 690. When the 690 turbo has been tested, I assumed that the numbers will be published. In the meantime, here's what I don't get. The 128 CPU SP cluster outdid an E10K (whose CPUs were running 25 Mhz faster) at a much higher cost efficiency (note however that the database sizes were different). And the SP outdid the E6800 box by a factor of 3. It did have to use 128 CPUs instead of 24, but consider: the price/performance ratios were nearly the same, so an IBM box that was "one-third" as powerful would have been equal in standing to an E6800 - or better, since most multi CPU things scale sub-linearly. But remember that the SP system was using 375 Mhz CPUs - the E6800 used 750 Mhz USIIIs. Imagine what a 690 Turbo would do here.

One final argument: IBM isn't cheating by clustering. If Sun's had a cluster that was good enough, it would have published the result. After all, it clustered 4 24-way E6500s for the TPC-C and it still just barely lost to a single 24-way S80 (precursor to the 680). With almost the highest numbers (except for an HP and Teradata box) IBM han't had reason to publish new TPC-H results. I bet now they will show fresh numbers.