Is Sun's Sparc more equal than others on Java performance?

While Sun promotes Java as an 'open' language, able to run on any platform, a respected consultant has pointed out that Java's handling of floating-point issues has serious implications for anyone trying to use it on either PowerPC or Intel platforms. He concludes that that Java 'as currently specified is not architecture-neutral.'

What exactly does the term "open" mean when it's used with Java?

Floating-point consultant Jerome Coonen claims Java runs better on SPARC than on PC architectures. Does Java, inadvertently or otherwise, favor some platforms over others?

I have taken Sun Microsystems at its word that Java is platform-neutral. To me, that means Java bytecode crosses the network to do its work anywhere there is a Java Virtual Machine capable of receiving it. But Coonen's paper, "A Note on Java Numerics," casts doubt on Java's strict neutrality.

Coonen is a consultant on floating-point issues for Apple, Microsoft, SunSoft and Exponential Technology. For 10 years, he battled inside Apple for a correct IEEE implementation of floating-point operations on the Macintosh. His stance stemmed from his work with University of California at Berkeley mathematics professor W. Kahan on the IEEE floating-point standard. Kahan won the Association for Computing Machinery's Turing Award for his IEEE work, so his former student is unlikely to take it lightly.

Coonen inspected how Java handles floating-point operations on different platforms. Floating-point numbers are used in big scientific calculations that require, after a certain number of digits, that a number be rounded off and a decimal point inserted. Coonen concluded that Java "as currently specified is not architecture-neutral."

Java, Coonen writes, handles floating-point issues efficiently on Sun's SPARC and Silicon Graphics' RISC microprocessors. But Java on the PowerPC "has doubled the number of instructions ... and forced one gratuitous rounding [off]." When it comes to some Pentium systems, Coonen writes, Java "is nearly doubling the memory traffic and increasing the instruction count by half. This is not what the designers of the [Intel] x86 floating-point unit had in mind."

Coonen continues, "The examples show that Pentium and PowerPC users pay twice: less accurate results because of imposed intermediate operations, and lower performance due to time wasted on the unwanted operations."

If Coonen is correct, that isn't what we expect from a platform-neutral language. I've asked Sun for a response to his comments, and I'm sure I'll get one. Coonen ventures the idea that Sun was seeking to get uniformity of results across platforms. Coonen scoffs at the idea of uniformity in the name of portability. What he wants is strict numerical accuracy.

Coonen asserts that each hardware platform should get its own best chance to come up with the exact answer. Sun should follow the IEEE standard more precisely for each platform. Its existing approach means that some results will be off more than they have to be, even though they may be in cross-platform agreement.

This may seem like a trivial issue. For most of us, results won't differ enough to worry about. Also, mathematicians may disagree on the best way to execute floating-point operations.

But the high and mighty have pooh-poohed the floating-point issue before. Remember how Intel said the Pentium fault wasn't worth worrying about? Just one in 9 billion possible calculations would yield a bad result, Intel said at first. (This turned out not to be the case.)

So until we get that fuller explanation, I have to conclude that Java has been optimised for SPARC at the expense of PC users. And I'd like to know if Java is an "open" language or merely a cross-platform one, with some platforms more equal than others?

(Babcock is Computerworld US's technical editor. His Internet address is

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Show Comments