🚀 go-pugleaf

In article <9106040308.AA20570@W20-575-91.MIT.EDU>, pshuang@ATHENA.MIT.EDU writes:
|> Reading this thread, I get the impression that several people feel that
|> IEEE compliance exacts a large toll in speed.  I do not doubt this, but
|> I was wondering if anyone had comparative statistics on the speed of
|> floating point operations when performed by an IEEE-compliant package
|> versus one which was not.  Of course, to be meaningful the data would
|> have to be for the same piece of hardware.
|> 

On the iPSC/860 (and the Delta Touchstone System) we provide an IEEE compliant
mode as default, and a non-IEEE mode, available via compilation/linking switches.

The non-IEEE mode forces denormals to 0.0 when they are encountered, and does
lossy division (loss of 3 ulps).  In addition, the routines in libm.a are
substituted with analogues that have been compiled in the non-IEEE mode.

Codes that encounter denormals, do division, or call the libm.a routines that
encounter denormals or do division, experience speedups.  Without citing codes or
exact numbers, I have seen speedups ranging from nothing to 500x.  It's very
application/dataset dependent.

Just anecdotal evidence, worth no more than the bits it's written with.  Note
that handling of denormals and division on the i860 are done in software, like
many other RISC implementations.

I don't speak for Intel - they don't pay me enough to do that.
-- 
Kirk Hays - NRA Life. [hays@ssd.intel.com]
"Good ideas become hardware, bad ideas stay in software." - who said that?