Comments on "Proposal for Extension of Java(TM) Floating Point Semantics, Revision 1"

[Tim Lindholm]

Hi again Joe,

> Joe Darcy said re PEJFPS...

[More mail from you just in -- I hope we aren't leapfrogging too
many topics...]

[sketch of goals and extensions elided...]

> Programmers have different needs for different programs.  Sometimes
> bit-wise reproducibility is needed and warranted.  At other times, the
> speed of the program is more important than the exact answer computed.
> Existing Java semantics favor the former requirement over the latter.
> However, in addressing the speed issue, PEJFPS destroys a program's
> *predictability*.

Yes, when you're running widefp, but not when you're strictfp.  Wide
code doesn't give you predictability and performance.  But you have the
option of writing strict code where you've got predictability.

> For reasons both intrinsic and practical, Java has never lived up to
> its "write once, run anywhere" slogan.  Even single-threaded Java
> program are non-deterministic because the garbage collection algorithm
> determines the order finalize methods are called ([JLS] section 12.6).
> However, by specifying the sizes of primitive types and by giving
> precise rules for expression evaluation order, Java is much more
> predictable than other contemporary languages such as C and C++.  This
> increased predictability is the achievable fraction of "write once,
> run anywhere."  Therefore, by removing Java's predictability PEJFPS
> spoils an important feature of Java while contradicting previously
> espoused Java philosophy.

Again, the attempt is to not lose predictability irrevocably, but to
give the developer the choice of predictability or performance.  [I
think we need a moratorium on use of the phrase "to give the developer
a choice" in our industry.  You can no longer say it with a straight
face...]

[snip]

> How do you know what you are getting?
> -------------------------------------
> 
> PEJFPS adds various class fields (WIDEFP_MAX_EXPONENT,
> WIDEFP_MIN_EXPONENT, etc.) to indicate the range and precision of the
> formats that the VM uses in FP-wide contexts (PEJFPS section
> 20.9-20.10).  It is *permissible* for a VM to set these fields to
> indicate extended precision and then, in accordance with section 5.1.8,
> round every result to the corresponding base format (float or double).
> Therefore, the implementation can legally indicate extended precision
> is being used and then not actually use extended precision at all.

Yep.  However, I don't have a problem with that.  The proposal does not
intend that people should think of wide code as guaranteeing more
precision, just that it can be taken advantage of if that makes sense
to the implementation.

> Can assigning a float to a double overflow?
> -------------------------------------------
> 
> It is possible under PEJFPS for FP-wide contexts to promote float
> values to double extended and keep double values as double.
> Therefore, assigning a float to a double can overflow!  Even FORTRAN
> guarantees width(float) <= width(double).

I think you mean that float can be promoted to float-extended -- the
float and double-extended formats are independent.  But your conclusion
holds.  We didn't want to constrain things where IEEE 754 didn't force
us to.  We could further constrain the use of extended formats or the
parameters defining permitted formats if there's a good reason to do
that (suggestions?).

> What can a JIT do?
> ------------------

[code example showing wide doubles being calculated and printed over time]

> Assume the VM described above uses strict semantics when interpreting
> (to reuse an existing code base) and uses wide semantics when
> compiling, for better performance.  Therefore, the first five calls to
> dot could return NaN (strict interpreting) and the next five could
> return 1.0 (wide compiling).  The last call to dot could also return
> NaN since dot could have been evicted from the code cache.

I think your point is correct although your wording is misleading.  This
is not a question of alternating strict semantics with wide semantics.
Rather, the code is wide, period, and when interpreting the implementation
is not taking advantage of a double-extended format.  Wide code should
expect this kind of thing.  Strict code is guaranteed never to see it.

> Although Sun's Hotspot may always compile a method as soon as it is
> called, there are other JVM jits that could use different policies.

HotSpot doesn't compile as soon as it sees a method -- it typically runs
interpreted for a while, then may compile, then may deoptimize and run
interpreted again...  It probably flip-flops back and forth more than
any other commercial code generation technology.

[a code generator may not know what format to expect in a return value]

It is true that PEJFPS isn't maximally helpful to code generators here.
However, given Sun's various implementations this doesn't appear to be a
big issue.

> On the x86, distinguishing between double and double extended at
> compile time is less important since the floating point registers
> promote all values to double extended anyway.  However, on
> architectures that have orthogonal support for different floating
> point formats (separate instructions for each format, fewer registers
> for wider formats), knowing the width of the return value is important.

The implementor of a code generator a machine with such orthogonal
support is under no obligation to exploit extended formats and may not
want to if on the balance keeping track of this information is too
onerous.  Are there some architectures with such support where there is
no reasonable answer?

> A related problem arises for register spilling; namely, at what width
> do values get written to memory.  On recent x86 processors, it is
> faster to spill 64 bit double values than to spill 80 bit double
> extended values (the 64 bit spill instruction has lower latency even
> ignoring reduced memory traffic).  Therefore, the speed goals of
> PEJFPS temp a VM implementor to unpredictable spill to memory double
> values instead of double extended, breaking referential transparency
> of expressions and reintroducing precision anomalies found on the Sun
> III compilers.

Such rounding on spilling is permitted, and was requested by compiler
writers.  Implementations are permitted to make and advertise stronger
guarantees.

> No extended format arrays
> -------------------------
> 
> The loss of storage equivalence between variables and array elements
> precludes employing the Java programming idiom of using a one-element
> array to pass an extended floating point value by reference (see
> http://www.afu.com/javafaq.html section 6, question 21).
> 
> Additionally, allowing extended precision arrays would be useful in
> solving certain linear algebra problems.

The proposal doesn't support this idiom.  We just didn't see how to
widen values in arrays or instances given the time we had and the other
constraints.

> Miscellaneous problems
> ----------------------
> 
> At variance with both IEEE 754 and the current Java specification,
> PEJFPS does not require subnormal support in widefp methods (p. 30).
> Therefore, widefp variables might be able to represent *fewer*
> floating point values than corresponding strictfp variables.

Sorry, I don't understand the p. 30 reference, so I'm not sure I
understand the point.

> PEJFPS apparently does not allow fused mac to be used.  Therefore,
> PEJFPS ameliorates Java's performance implications on the x86 but not
> the PowerPC.

Has been discussed in email since yours came out -- ignoring it here.

> Having widefp be the default can break existing Java programs that
> rely on Java's strict floating point semantics (admittedly such
> programs are in the minority).

It's possible, but on investigation we don't think this will have a
large impact.  As you suggest, not many programs are likely to rely on
the currently-defined floating point semantics.  Given the track
record of implementations on x86, where few if any implemented the spec
correctly, people who depended on code working across platforms or
implementations were likely to have been frustrated or would be in the
future.  Should testing be improved in order to catch this spec
nonconformance and satisfy the few who depend on spec details, everyone
depending on floating-point code on x86 would take a big performance hit.

Those who were only targeting platforms on which it was easy to
implement the spec, and who relied on it, will probably still have
working code on those platforms without even having to make it
strictfp.  Such platforms probably won't use extended formats.  (Of
course if they require strict floating point they should still transition
to strictfp modifiers to ensure their code will work on other platforms.
But the transition needs not be abrupt...)

> PEJFPS lacks any mention of library support.  For example, can
> extended format values be printed out and read in?

True, it lacks mention.  We did not intend for PEJFPS to change library
support, except for the addition of the six variables in Float and
Double you'd noted earlier.  We are considering follow-on changes to
java.lang.Math or creation of a looser math library.  Extended format
values (that is, values that cannot be expressed in the non-extended
format) cannot be read in or printed out using the existing APIs.

[Another way]

I don't necessarily have any problems with these proposals, but have to
point out that there would be no way we could have introduced new types
or expression evaluation policies into 1.2 in the time that was
available.  That means we'd be committed to leaving things as they
were for an undefined time, or would have had to take a big performance
hit on x86 to hold people to the spec.

There are also at least some aspects that would have been pushed back on by
licensees, e.g.

> Alternatively, the current practice of storing after every floating
> point operation can be canonized (this retains a very minor double
> rounding on underflow discrepancy and carries some performance
> degradation).

Thanks for all the thought you're putting into this...

> -Joe Darcy
> darcyacs.berkeley.edu

-- Tim