Re: An interesting quote on Java and C++

[dewar@merv.cs.nyu.edu (Robert Dewar)]

<<This is basically good, but it still bothers me that:

    type T is range 0..2_000_000_000;
    X, Y: T := T'Last;
    Z: T := (X + Y) / 2;

will typically behave differently on a 32-bit machine than on a 36-bit
machine.>>

True, this program fragment is non-deterministic, it may raise constraint
error, or it may give the right answer (no other possibilities are allowed).
The decision in Ada not to make such constraint checking canonical was
taken quite deliberately, on the grounds that it would have very significant
efficiency effects.

Since Java is interpreted anyway, at least in the original conception,
it has taken a more casual attitude to efficiency, and the fact that
arithmetic is canonical in Java, if taken seriously, would indeed have
very significant effects on efficiency.

For example, consider a more interesting example than Bob's one (since
there really aren't many 36-bit machines left in wide use).

   A,B,C : Float;
   ...
   A := A * B / C;

Let's assume we are talking IEEE short-form here (Java of course is a
complete catastrphone efficiency-wise on non-IEEE machines such as the
Dec Alpha (*) or the IBM mainframe), but let's not even worry about
that for a moment.

Instead consider the case where A*B is out of range of Float. If we insist
on canonical overflow in this situation, then we will badly harm efficiency
on the x86, which feels like doing all arithmetic in IEEE extended. Ada
quite deliberately in this case (by defining Float as an unconstrained type)
not only allows the intermediate value to overflow, but even the value stored
in A is allowed to be out of range if it is "correct".

Yes, this messes up the language a bit, and yes, this potentially causes
some portability problems, but we are willing to take these minor negatives
in return for a potentially VERY significant gain in efficiency of floating-
point.

Note incidentally that the requirement for IEEE floating-point arithmetic
is controversial, and is under active "discussion" by the ISO Java committee.

(*) thrown in deliberately! Most people, and certainly most DEC sales people,
would think of the DEC Alpha as an IEEE machine. However, the hardware
departs significantly from IEEE in the some areas, including the handling
of denormals, and if you want true IEEE semantics, then you get a huge
slowdown because of software fiddling.

In practice, poeple settle on the Alpha for this slight departure from
IEEE, just as they do on the SGI R10000, which "cheats" in a similar
manner (I should say that both instances of cheating are all about
trying to increase fpt efficiency in the normal case).

Now in languages with no fpt model (C, C++, Fortran, PL/1, Algol-68, Pascal,
Eiffel, ... it is a very long list), there is no problem, you can perfectly
well map to the expected efficient hardware execution mode on both these
machines.

Even in Ada, which has a very definite FPT model, this model has been
very carefuly chosen to balance maximum utility with the ability to
accomodate typical reasonabole floating-point systems, including both
these examples.

The decision in Java, if taken literally to follow IEEE precisely, is a
MAJOR problem on these two architectures, and in practice, the Java
implementations on such machines just ignore the fine points of the rules.

The decision to exactly follow IEEE rules by Sun was one of the following

a) deliberately taken on the grounds that sacrificing efficiency (by as
much as a decimal order of magnitude) was worth the guaranteed 100%
portability.

b) deliberately taken to give Sun a competitive advantage over other
work station manufacturers who don't implement IEEE 100%

c) casually taken without realizing the consequences

I do not know which of a) b) or c) applies.