More results and comments about gradual underflow

[Nelson H. F. Beebe]

Keith Bierman  <Keith.BiermanaEng.Sun.COM> writes:

>> That is, if benchmarks don't include such things,
>> designers will make them run slower.
>>
>> Benchmarks shouldn't be purely a measure of flat out speed.

I should have been clearer about what I meant: when comparing
performance of two machines, one should be doing so on equal footing.

In particular, no one would expect a completely-software
implementation of floating-point performance (e.g., Jerome Coonan's
Standard Apple Numeric Environment (SANE)) to be usefully compared to
a pure hardware floating-point implementation.

What many users often don't realize is that IEEE 754 is just an
architecture specification, and it makes no requirements on which
parts are done in software, and which in hardware.  Commercially
significant systems exist which have had IEEE 754 in pure software,
and in pure hardware, and in a mixture of the two.  Thus, most users
are unaware that some kinds of numbers are handled more slowly than
others on several current architectures.

By all means, let us have SEPARATE benchmarks, like the one Vaughn
Pratt posted today, that help to expose these implementation
differences, but let's not contaminate other suites (LINPACK, LAPACK,
SPEC, ...) with imbalances from hardware vs software implementations.

On the results that we have posted today for Vaughn's nice little
benchmark, each system with software handling of gradual underflow has
been characterized by large amounts of system (as opposed to user) CPU
time.

However, this need not always be the case: I have seen architectures
in the past that handled unimplemented-instruction interrupts and
floating-point exceptions by run-time patching of the executable image
to replace an expensive interrupt-generating instruction by a cheaper
function call to run-time library code, thereby avoiding a
kernel<-->user context switch on subsequent executions of the problem
instruction.  On such systems, most of the time might register as
user, rather than system, time, hiding the fact that software
emulation was still involved.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- Center for Scientific Computing       FAX: +1 801 585 1640, +1 801 581 4148 -
- University of Utah                    Internet e-mail: beebeamath.utah.edu  -
- Department of Mathematics, 322 INSCC                   beebeaacm.org        -
- 155 S 1400 E RM 233                                    beebeaieee.org       -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe  -
-------------------------------------------------------------------------------