64-bit Linux Java Performance: SPECjbb2005

If you are not familiar with SPECJbb2005, please read our introduction to it here. SPECjbb2005 from SPEC (Standard Performance Evaluation Corporation) evaluates the performance of server side Java by emulating a three-tier client/server system with emphasis on the middle tier.

We tested with two JVMs:

  • SUN Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_02-b05, mixed mode)
  • BEA JRockit(R) (build R27.4.0-90 linux-x86_64, compiled mode)

We used the following optimizations:

  • Sun JVM: -Xms2g -Xmx2g -Xmn1g -Xss128K -XX:+AggressiveOpts -XX:+UseParallelOldGC -XX:+UseParallelGC
  • BEA JVM: -Xms1800m -Xmx1800m -Xns1500m -XXaggressive -XXlazyunlocking -Xgc:genpar -XXtlasize:min=4k,preferred=512k -XXcallprofiling

The BEA JVM uses memory more aggressively, making more use of the assigned memory. A heap size of 2GB would probably result in the JVM gobbling up too much memory, which could result in errors or poor performance on our 8GB system. That is why we lowered the JVM heap size from 2G to 1.8 G. We also applied slightly more aggressive tuning to the BEA JVM, as their customers are more interested in squeezing out the last bit of performance.

We also used four JVMs per system. The reason is that most IT departments emphasize consolidation today, and it is very rare that one JVM gets eight cores. We fully disclosed our testing methods here. However, note that you cannot compare the results below with our previous findings as we use newer JVMs now.

Below you can find the final score reported by SPECjbb2005, which is an average of the last four runs.


SPECjbb
2005 Sun 1.6.02

It took us hours, but we managed to complete one run of SPECjbb with faster 800MHz DDR. It shows with four JVMs that the memory subsystem on the Xeon systems is a clear bottleneck. It is also important to note that SPECjbb is one of the most sensitive benchmarks to memory bandwidth. If SPECjbb improves 6% when we use 800MHz ram instead of 667MHz, this is probably about the maximum boost the new Xeon will get from slightly faster 800MHz memory.

Let us see how the systems fare with the BEA JRockit JVM.


SPECjbb
2005 Bea JRockit 27.4

BEA uses some clever compression techniques to alleviate the pressure on the memory system. However, it is a bit funny to see how the hardware prefetching gets in the way. While it boosted performance by 14% in our zVisuel Kribi 3D, it is now slowing down the SPECjbb benchmark by 14%. When we disable it, the Xeon 5472 takes the lead.

The Xeon 3GHz looks like a sports car with his wheels deeply entrenched in the mud: the raw power keeps spinning on the lack of memory bandwidth. A 3GHz chip is hardly faster than a 2.33GHz chip, and here AMD's quad-core at 2GHz beats Xeon.

Software Rendering: zVisuel (32-bit Windows) MySQL and WinRAR
Comments Locked

43 Comments

View All Comments

  • Hans Maulwurf - Wednesday, November 28, 2007 - link

    Agreed, I have not seen an article as good as this one for years at Anandtech. And not for some time on other review sites as well.

    Thank you.
  • JohanAnandtech - Tuesday, November 27, 2007 - link

    Thanks people. This kind of articles take ridiculously amounts of time and I really appreciate that you let me know that you liked the article. It keeps us going. (and I mean that!)
  • magreen - Tuesday, November 27, 2007 - link

    Excellent article, thorough and with amazing depth and expertise. Keep up the great work AT!
  • Bluestealth - Tuesday, November 27, 2007 - link

    I agree, it was a very well done article. I can't wait to see how Intel's processors preform on Hyper... errr... Common System Interface (next year?). I believe that I will be buying AMD until that happens though for any servers.
  • Regs - Tuesday, November 27, 2007 - link

    Yeah, every time I see "Johan De Gelas" I have to read it.

    I like the added info on the Barc's L3 cache and the intro-factoid about the new architecture.

    I agree that the Barc's arrival is a year late and joined the party a little too shy. Integer performance will likely have to be addressed in the Bulldozer in 2-3 years. Which is 2-3 years too long. I would be really surprised if they can manage anything other than a die shrink for Shanghi with maybe more L3 cache and some tweaks for cache latency and SSE.

    Just seems like AMD took a nose dive in development for their processors in the past 3-4 years. After the K8 I would think they would be able to come up with something more innovative. Revolutionary should of never entered their heads and they should actually look down upon themselves for using such a word after 4 years.
  • jones377 - Tuesday, November 27, 2007 - link

    Any chance you could use the same tools to profile desktop applications as well in the future?
  • DigitalFreak - Tuesday, November 27, 2007 - link

    Three months or so since "launch", and you still can't get a server with AMD quad-core chips from any of the big 3 vendors (HP, Dell, IBM). AMD really screwed the pooch on this one.
  • jojo4u - Tuesday, November 27, 2007 - link

    Yuck, ugly GIF on the first page. Please use PNG because 256 colors are not enough for screenshots ;)
  • deathwombat - Saturday, December 1, 2007 - link

    In addition to being less ugly, PNG's higher compression would also make the file smaller (using less bandwidth), which I assume is what they were going for.
  • jkostans - Tuesday, November 27, 2007 - link

    Didn't even notice.

Log in

Don't have an account? Sign up now