Subject: more on Java numerics

From: [email-masked] (David G. Hough at validgh)
Date: Thu, 20 Feb 97 14:19:10 PST

Persons interested in Coonen's comments on Java numerics may find more
discussion at

	http://www.validgh.com/java

which includes recent archives from the numeric-interest mailing list,
including responses from several of the creators of Java,
and information on that mailing list, and my own contribution in
troff, ascii, and postscript form.

---

From: "Russell L. Carter" <[email-masked]>
Date: Thu, 20 Feb 1997 16:45:49 -0700

> troff, ascii, and postscript form.

Perusing the file: http://www.validgh.com/java/java.numerics.ascii,
I extract the following two paragraphs:

>     In contrast, promoting machine-dependent programming would have to be
>considered an anti-goal of Java; that's what the "100% Pure Java" campaign is
>all about: assisting software producers in avoiding dependencies on particular
>machines.   Instead Java programs are intended to produce identical results on
>all supported machines.   One important reason for that goal is to facilitate
>validation of claimed Java implementations: all floating-point results should
>agree to the last bit. The alternative is most conventional languages like
>Fortran and C, in which hardware faults and compiler bugs sometimes masquerade
>as "roundoff differences" and conversely, roundoff differences are sometimes
>misclassified as hardware faults and compiler bugs, particularly with
>aggressively optimizing compilers.     Persons involved in intensive numerical
>work put up with these differences, and the costs associated with analyzing
>and correcting them, when their programs and problems demonstrate a high
>enough performance benefit.  In contrast, most Java programming is likely to
>be somewhat less numerically intensive, and the tradeoff is the other way:
>the cost of dealing with ultimately insignificant numerical differences
>doesn't justify the performance improvement available by tolerating them.
>
>     "If there is to be but one Java expression evaluation model, how should it
>be chosen?  The Java expression evaluation model is a simple one supported by
>most old and new computers used for floating-point computation: only single
>and double precision variables and registers exist, and floating-point
>instructions apply to only one or two input operands at a time.  No extra-
>precise accumulators or fused three-operand instructions may be employed. That
>model is supported in hardware or may be efficiently emulated on all current
>popular RISC workstations and CISC PC's.    It is true that x86-architecture
>PC's could sometimes provide faster and more accurate results by exploiting
>extended-precision accumulators, and PowerPC's could sometimes provide faster
>and more accurate results by exploiting fused multiply-add instructions, but
>the performance penalties for adhering to Java's model are not overwhelming
>and could be reduced further with a few modifications in the next revisions of
>those architectures.    In contrast, based on past experiences of compilers'
>routine misapplication of extended-precision registers and fused operations,
>there is plenty of reason to doubt that the benefits of those architectures
>would be readily achieved if they were mandated by Java, even if there were no
>performance degradation on machines which had not provided hardware support.

I would like to observe the following:

1. On x86, and especially for Pentium and Pentium Pro CPUs, the statement
   that "the performance penalty for adhering to Java's model are not
   overwhelming..." is inacurrate at best.  As David should well know it
   is the ability to keep intermediate results on the stack, along with
   judicious use of fxch that give these at best 1 result per cycle
   processors their rather surprising sustained floating point performance.
   Inducing an extra store/load at every floating point op will cause
   a minimum of a factor of 2 in sustained performance. It surely looks 	   
fortunate that Sun has the floating point architecture it does.
   And I might also observe that it is possible to buy several compilers
   that do The Right Thing for x86, and pgcc does not too bad for free.
   So I think that maybe David's concern for the competence of x86 compiler
   writers is misplaced, also.

2. As a practical matter the fused multiply operations on Power2 CPUs,
   and the extended precision registers found in x86, have had essentially
   NO discernable effect on the reproducible accuracy of nearly 
   all practical scientific calculations.
   In fact, I would go so far as to say that Java numerical results are
   going to differ across platforms a lot more from the immaturity of the
   output formatting code than from any adherence to individual CPU
   architectural enhancements.

Taking the long view, it is likely that Sun will find that the market will
settle these issues.  It's a nice try at hamstringing wintel/IBM, but
I don't think it will work.

Best regards,
Russell Carter