Subject: Numerics Working Group report

From: [email-masked]
Date: Tue, 8 Sep 1998 19:59:38 -0400

Hello,

I have some comments on the "Report of the Numerics Working Group":

Preface: The proposal explicitly mentions the goal to allow better
execution speed on both the x86 and PowerPC. I think it would be both more
accurate and more diplomatic to say that the proposal aims to allow better
execution speed on current CPUs.

ISSUE 3: The notation "<-" is used for assignment operation. Note that "a
<- b" is the legal Java expression "a less than negative b". I propose
using ":=" for assignment.

Still in ISSUE 3, it says that "... expression of the form a+b is merely
syntactic sugar for sum(a,b) ..." This is a bit unclear. Which "sum"? From
the class of "a"? From the class of "b"? Maybe it would be better to say
"a.plus(b)", as it is unambiguous.

ISSUE 4: In two places, blocking is implied as being an "answer-changing
optimization". Please note that blocking by itself does not need to change
the order in which operations are performed in a computing a particular
value. Blocking of matrix-multiply does not require associativity, for
example. It is typically the restructuring of reduction operations that
requires associativity.

Still in ISSUE 4, during the discussion of "associativefp" declaration: It
is mentioned that "associativefp" relaxes the precise exception model. Note
that this is a very dangerous thing to do, since exceptions in Java are
perfectly legal! The following code correctly compute the dot product of
two vectors, but it relies on precise exceptions:

double s = 0;
try {
  for (int i=0;true;i++) {
    s += a[i]*b[i];
  }
} catch (ArrayIndexOutOfBounds bounds) {
}

This code may look strange to Fortran programmers, but it is simply another
programming style. It is being advocated by some authors. Relaxing the
exception model would deny optimization of programs following this style. A
user attempting "associativefp" on this could get wrong results. Note that
there are effective ways to deal with optimizations in the precise
exception model (versioning, speculation, etc) and therefore I do not see a
need to relax it.

ISSUE 5: I believe that the multidimensional array classes can be extended
to include all of Java primitive types, as well as complex entries and
Object. Also, it is conceptually good to have zero-dimensional arrays. It
is a mechanism to get a reference to a single element.

Still in ISSUE 5, it is mentioned several times that the layout of the
array should be known. We may be painting ourselves into a corner here. We
could provide a mechanism that allows the user to specify a "preferred
access mode" to the array, which could help the compiler to select a
layout. We should not make the layout visible in any way, as it may have
negative implications in our ability to later deploy better
implementations.

Jose E. Moreira
IBM Thomas J. Watson Research Center
Yorktown Heights, NY 10598-0218
[email-masked]

---

From: "Joseph D. Darcy" <[email-masked]>
Date: Tue, 8 Sep 1998 21:32:04 -0700 (PDT)

>  Jose E. Moreira comments on the "Report of the Numerics Working Group":

> execution speed on current CPUs.

I think it is more forthright as it is currently.  The changes in
default semantics address issues on the x86 and PowerPC (or slightly
more generally, any machine with a fused mac).  The SPARC is not
affected by the changes in default semantics.

> using ":=" for assignment.

":=" is also used in Pascal, so there is precedent for ":=" as an
assignment operator.

> "a.plus(b)", as it is unambiguous.

Exactly how overloaded operators should be resolved is an interesting
issue; for software engineering purposes it is useful to be able to
call the method from either the class of "a" or the class of "b" (as
long as there is no ambiguity).

> perfectly legal!

Exceptions are also perfectly legal in Ada and Ada has an imprecise
exception model.

> The following code correctly compute the dot product of

If s is returned (or otherwise used) then yes, the exception has to be
precise.  But, if s is not used, the exception does not have to be
precise, that is, the values stored in i and s do not have to
correspond to the expected execution of the loop.  However, is the dot
product of two vectors meaningful if the vectors have differing
lengths, in other words would the value of s be used?

> exception model would deny optimization of programs following this
> style.

Precise exceptions also deny certain optimizations.  If the value of
"i" is visible outside of the loop, the compiler must insert code to
maintain the appearance of "i."  Such a requirement complicates
optimizations like induction variable elimination.

A precise exception model is easy to explain and understand.

>  Note that

As far as I know, the techniques to deal with precise exceptions are
akin to the techniques used to debug optimized code.  How much
overhead is involved with maintaining the versioning and speculation
information?

-Joe Darcy
[email-masked]