Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!WATSON.IBM.COM!jbs
From: jbs@WATSON.IBM.COM
Newsgroups: comp.arch
Subject: IEEE arithmetic
Message-ID: <9106120131.AA20868@ucbvax.Berkeley.EDU>
Date: 12 Jun 91 00:58:09 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 29


         David Hough writes:
Part of the problem is that the benchmark programs in use measure only
common cases.  Various versions of the Linpack benchmark all have in common
that the data is taken from a uniform random distribution, producing problems
of very good condition.   So the worst possible linear
equation solver algorithm running on the dirtiest possible floating-point
hardware should be able to produce a reasonably small residual, even for
input problems of very large dimension.

         This is untrue.  Consider pivoting on the column element of
smallest magnitude while using IEEE single precision.  I don't believe
n has to be very large before you are in big trouble.
         David Hough writes:
Such problems may actually correspond to some realistic applications, but many
other realistic applications
tend at times to get data that is much closer to the boundaries of
reliable performance.   This means that the same algorithms and input data
will fail on some computer systems and not on others.   In consequence
benchmark suites that are developed by consortia of manufacturers
proceeding largely by consensus, such as SPEC, will tend to exclude
applications, however realistic, for which results of comparable quality
can't be obtained by all the members' systems.

         If you know of a single realistic application where the diff-
erence between 64 bit IEEE rounded to nearest and 64 bit IEEE chopped
to zero makes a significant difference in the maximum performance ob-
tainable I would like to see it.
                       James B. Shearer