AMD's 3rd generation Opteron versus Intel's 45nm Xeon: a closer lookby Johan De Gelas on November 27, 2007 6:00 AM EST
- Posted in
- IT Computing
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.
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.
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.
Post Your CommentPlease log in or sign up to comment.
View All Comments
aeternitas - Thursday, December 13, 2007 - linkThen why are you here? Details is what technology is about!
I for one have a pet peeve with tech sites that use the wrong formats in their stories. Slightly damages credibility. Not to say this is a big deal in this case, though .gif is pretty much dead, unless you use an old browser on old tech, but then why would you be reading this story?
Look on the bright side, at least this isnt a Codec vs. Codec story, where the author uses jpgs for such color-limited screenshots.
SonicIce - Tuesday, November 27, 2007 - linkI think the color depth was decreased alot more than 8 bit. That image only has 33 unique colors in it. Something went wrong with the dithering maybe? 256 is usually more than enough.
Justin Case - Friday, November 30, 2007 - linkWho cares? The only part that suffers is the gradient at the top, all the relevant information is there, and this file is about half the size of what a PNG would be.