extended precision hazards

[David Hough validgh business]

Jerome replied:

> Unfortunately, history has a chance to repeat itself.  By ignoring
> the performance issues of the vast number of platforms with extended
> extended registers or fused multiply-add operations, the Java spec
> invites nonconformance from vendors who choose not to suffer 1.5X
> to 10X performance degradation in numerical codes in order to match
> the results of less capable architectures.  At worst, that
> nonconformance will be as random and capricious as has the
> situation been with C.

History tends to repeat itself, but seldom exactly.   The difference between
Java and C in this respect - the noble or ignoble experiment - is that while
random and capricious numerical results have been considered "quality of
implementation" issues in C (and Fortran and C++ etc.) - legal and beyond
the pale of standardization, thus affording
compiler implementers and marketing scientists equal footing with numerical
analysts to argue the merits of their implementations - Java specifies 
numerical matters much more closely.

Thus "Java" implementations that produce
random and capricious results are not Java at all but rather something
superficially similar, spiritually akin to those hardware
arithmetic implementations that called themselves "IEEE 754" while using only the
least important part of that standard, the bit patterns in memory, while
not bothering with the more important parts concerning rounding and exception
handling.   Java licensees agree to conform to its language spec, although
some have been remiss.    There used to be a selection of interesting test
programs for difficult cases at 
	http://www.sun.com/workshop/java/jit/test_suite/index.html
but that seems to have disappeared.

It's a legitimate question whether Java in its present form
should be considered to be a general-purpose programming language, 
and thus potentially suitable for grand-challenge
supercomputer problems.    Some of the Java founders think so, while others
think Java should not be used in situations where portability is not important,
so that discussions like this one will not lead toward eliminating Java's
unique contribution toward portability.