The decision to start including work related items in my blog certainly had a dramatic impact.
Hopefully I’m not a one hit wonder and will never say anthing relevant (or at least link worthy) again. I remain open to suggestions for content, so if you have questions you think I might be able to answer contact information is available on my About page.
The spike was generated by my posting about 64bit java performance, and this post is a follow up to provide a bit more data on some areas I touched on.
There is some more data on the Sun JDK implementation on the HotSpot wiki. Based on the recent publish of some SpecJBB2005 results, it seems there is (or will be) a supported version of compressed pointers from Sun.
Of course, the careful observer may noticed that the results are from an x86 based platform. Does compressed pointer technology only matter on x86 based platforms? In my original posting I focused on the x86-64 architecture and the benefits (and pitfalls) it brought to applications. In brief, by moving to 64bits the gain was both bigger and more registers. If we look at Sparc or POWER CPUs – these were both created with an eye on 64bit implementations, and thus the move to 64bits had less of an impact on the instruction set or register width. This means that for these systems, 64bit support results in more data (due to pointer size doubling) to move without any real benefit in terms of instruction set (read: code optimization).
Currently I believe Sun has only implemented their compressed pointer solution on x86-64 systems. There is no strong technical reason preventing it from being done on a Sparc system, but as I pointed out above the benefit may be harder to realize. The IBM Java6 JDK supports compressed pointers on POWER (AIX/Linux) and there is a measurable improvement on memory intensive benchmarks. IBM also supports this feature on zSeries (yup, the mainframe) and the following graph shows how the 64bit environment nearly matches the performance of the 31bit environment under Linux.
The -Xlp option is used to configure the IBM JDK to use ‘large pages’ to allocate the heap. The details about large page support I’ll save for a future posting.
So while most of the excitement around Java performance on 64bit systems is focused on x86-64, it is worth considering on other architectures. I believe this will become more important as java applications continue to grow and start hitting the limits of the 32bit address space, forcing a move to 64bit.
Is IBM’s 64bit java available for Linux x86? If so, it’s sure not easy to find-
was able to download the 32bit version of java6, but do not see a 64bit version in the same place.
Several years ago IBM’s java was the fast one for numeric work, but Sun’s java6
(64bit) is a fair amount faster than the 32bit Java6 (either IBM’s or Sun’s)
on the Scimark benchmark.
IBM’s Java JDK for Linux is actually quite easy to find. The google search is: http://www.google.ca/search?q=linux+ibm+jdk+download
Which should turn up the following link: http://www.ibm.com/developerworks/java/jdk/linux/download.html
You want to download “Java SE Version 6” for the platform called “64-bit AMD/Opteron/EM64T” to get a JDK that runs on a 64bit x86 Linux with support for compressed references.
As for Scimark – this benchmark doesn’t have the same recognition as those that are hosted by http://www.spec.org/. However, looking at the Scimark results here http://math.nist.gov/cgi-bin/ScimarkSummary you will see that the top results are Sun based numbers, but a more careful look shows a nearly 1:1 correlation between CPU frequency and the score.
The Scimark results attributed to the IBM JDK don’t look “way slower” than those posted by the Sun JDK. Today the results ranked 4th and 5th compare the IBM and Sun JDK both on 3.0GHz CPUs and they are neck and neck.