Subject: Re: FMA support in Java

From: Ronald F Boisvert <[email-masked]>
Date: Tue, 18 May 1999 11:58:38 -0400

-------- Original Message --------
Subject: Re: FMA support in Java
Date: Tue, 18 May 1999 11:53:43 -0400
From: Ronald F Boisvert <[email-masked]>
Organization: National Institute of Standards and Technology
To: Tim Lindholm <[email-masked]>
CC: [email-masked], [email-masked],[email-masked],
[email-masked],[email-masked], [email-masked], [email-masked],[email-masked],
[email-masked], [email-masked],[email-masked], [email-masked],
[email-masked],[email-masked], [email-masked]
References: <[email-masked]>

I am disappointed that there hasn't been any discussion of Marc's
FMA proposal.  We certainly had an animated discussion in Menlo
Park in March!

Here is my take: Marc's proposal is a very clear and precise
statement of the issues involved in admiting use of FMAs in Java.
He and Tim rightly placs this discussion in a larger context: there 
are other such performance enhancements that might, in time, be 
reasonable for inclusion in Java, and we should have a framework
for dealing with them rather than considering each one in an ad hoc
manner.

I support Marc's call for a third floating-point mode.  Having three
modes is the only way to satisfy the diverse requirements of Java
developers and users:

  strict   : results exactly reproducible; performance secondary
  default  : results highly reproducible (differences rare, minor
             and well characterized); performance good
  extended : results not reproducible (differences still well
             characterized, but can be significant); performance
             excellent

Strict mode allows very careful control in the relatively rare cases
when this is crucial.  Default mode gives good performance with only
rare differences; good for the average user.  Extended mode sacrifices
reproducibility to attain speed when high performance is critical.
The definitions of strict and default modes should be static over time,
with extended mode being used as a context for future enhancements.

Marc's call for three enhancements in extended mode seem to be a good
start.

(a) allow use of FMAs

    ... but tie them to explicit constructs in arithmetic expressions, and
        require their use either everywhere or nowhere.  One can still
        provide classes with FMA method calls for finer control.

(b) allow use of full 80-bit extended doubles on Intel processors

    ... but only for anonymous variables, and require their use either
        everywhere or nowhere

(c) allow promotion of float to double on machines where double is faster

    I'm not so sure of how wise this is.  There are some computations that
    I want to be in mixed mode.  These are somewhat rare occasions, though
    and I could require these be in default mode.  If this is done, then
    the consistent use requirement must be added.

I agree that associativity could also be added here, but that is a bigger
change that needs further discussion.

Also, I still think that it is important to allow JITs to have flags requiring
execution in strict mode to override the programmer who may have been too
generous in assigning loosened modes.

Ron