Multitude of JVM - misinterpreted ;)

Quicksearch

Disclaimer

The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.

Navigation

< Garden | Different perspective. >

Multitude of JVM - misinterpreted ;)

Monday, July 12. 2010

TPM is bragging about the SPECjbb2005 performance of the p7 system. Interestingly he is talking about the nonsensical benchmark again: Multiple JVMs per system with 32 bit. As i wrote before: When you want a cluster, buy a cluster and don't build one for an embarrassingly parallel problem in a box. I think, that the only relevant test today is 1 JVM/64-bit today. By the way: Those multitude of JVMs/32-bit doesn't use the real advantage of the big machines (large heaps for you application), however it's the only chance those SGI systems or extremly-NUMA systems can compete with larger SMP systems, because of the vastly reduced interconnect usage (which is quite useful to avoid the long arm of Amdahl's law)

Posted by Joerg Moellenkamp in English, On Benchmarketing, Solaris, Sun/Oracle at 08:24 | Comments (8) | Trackbacks (0)

View as PDF: This entry | This month | Full blog

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Partitioning an application into multiple 32 Bit JVMs is still a real world use case - unfortunately.

For example, in IBM WebSphere 6 (still the dominant version in large companies), there's not even support for 64 Bit VMs on Solaris Sparc. It's the Sun VM, all right, but you cannot replace it, because IBM requires the IBM customized version of the Sun VM (I think the ORB is one of the things that's different).

#1 Arnd Beißner on 2010-07-12 10:35 (Reply)

If one's workload is amenable to a 32-bit runtime environment, on all common and current processors running in 32-bit mode is faster than 64-bit mode. Seems like it's just good sense to retain that 3-7% performance rather than throw it away pointlessly.

#2 xysmith on 2010-07-12 17:48 (Reply)

Maybe, just maybe, when you need just bunch of 32-bit JVMs, each used with single CPU... you can use two dozens of PCs instead of a large SMP box?

#2.1 Maciek on 2010-07-14 10:41 (Reply)

I agree with Arnd. Another real world use case: Applications that do not scale with the number of cores. You get a log better performance by running a hand full of them in parallel for the same job on a multicore-system instead of running one big appserver instance. BTST - a lot...

#3 websphere_guy on 2010-07-12 18:42 (Reply)

For the moment you can only blame SPEC organization. The specification of SPECjbb2005 benchmark for now is that the overall result matters.
I agree with xysmith. If IBM runs the same on sigle JVM 64-bit, the score will be about 5% lower. Still a disaster for SPARC servers... we cannot do much about it. SPARCs are currently the slowest cores on market.

#4 John on 2010-07-12 22:34 (Reply)

I assume it would be much slower than just the 5%. 5% is just the mininum impact for 64-bitness without compressed OOPs.

The impact of factoring out the interconnect between the procs is much larger. Running SPECjbb2005 in a single JVM on larger system would give interesting insights to the efficiency of the interconnect. Unfortunately there isn't such a result.

#4.1 Joerg M. (Homepage) on 2010-07-12 22:40 (Reply)

TPM seemed to get a particular fact incorrect in the story:
http://www.itjungle.com/tfh/tfh071210-story02.html
"Oracle's T5440, a four-socket box using the Sparc T2+ processor running at 1.6 GHz and sporting eight cores and 32 threads per chip"

If I remember correctly, the T5440 is using the SPARC T2+ processor sporting 64 threads per chip.
http://en.wikipedia.org/wiki/UltraSPARC_T2

No where to comment, unnfortunately...

I am looking forward to the T3 being released, however!!!

#5 David (Homepage) on 2010-07-13 00:43 (Reply)

I stopped to expect factual correctness about Sun from TPM ... so i'm just writing about the fundamental problems ...

#5.1 Joerg Moellenkamp (Homepage) on 2010-07-13 09:05 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	E-Mail addresses will not be displayed and will only be used for E-Mail notifications. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: Standard emoticons like :-) and ;-) are converted to images. Enclosing asterisks marks text as bold (word), underscore are made via _word_.
	Remember Information? Subscribe to this entry