From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f3f9104dada53163 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: An interesting quote on Java and C++ Date: 1997/09/20 Message-ID: #1/1 X-Deja-AN: 274107031 References: <5ujjvq$t4s@drn.zippo.com> <34218E68.63D5@gsg.eds.com> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-09-20T00:00:00+00:00 List-Id: <> 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.