WJP@VM.NRC.CA (Wayne Podaima) (10/30/90)
We have some unhappy observations re performance of Fortran programs under IRIX 3.3.1. The same program compiled under 3.3.1 runs about 5% slower than it did under 3.2.3 (same compiler options), using 1 cpu of a 4D/240S. The program is compute intensive - no paging, no disk I/O, double precision. Any ideas; anyone with similar results? We then tried the libfpe.a floating point exception handling library, expecting it to be still slower; well it ran 2% FASTER than the original 3.2.3 compiled version. What gives? Any comments appreciated, Wayne Podaima
bron@bronze.wpd.sgi.com (Bron Campbell Nelson) (10/31/90)
In article <90Oct29.145239est.57616@ugw.utcs.utoronto.ca>, WJP@VM.NRC.CA (Wayne Podaima) writes: > > We have some unhappy observations re performance of Fortran programs under > IRIX 3.3.1. The same program compiled under 3.3.1 runs about 5% slower > than it did under 3.2.3 (same compiler options), using 1 cpu of a 4D/240S. > The program is compute intensive - no paging, no disk I/O, double precision. > Any ideas; anyone with similar results? > > We then tried the libfpe.a floating point exception handling library, > expecting it to be still slower; well it ran 2% FASTER than the original > 3.2.3 compiled version. What gives? > I don't know about the first part, but I can comment on the second: in all likelyhood your program is getting a number of underflow exceptions (IEEE denormalized numbers). Denorms are *not* handled by the f.p. hardware, instead they are punted to an exception handler (which does the f.p. operation in software). In libfpe.a on the other hand, the default setting for underflow is to flush the value to zero, rather than to compute the denorm. Note that this setting is *not* IEEE compliant. The advantage is that zero is a value that the hardware can handle. You still take an exception when the value is first computed, but by flushing it to zero, you do not take further exceptions when that value is subsequently used. (Hummm ... I see someone might read that wrong .. the f.p. underflow "exception" is *not* an error, it is just an exceptional (unusual) event. Therefore it is dealt with by an exception handler, rather than by throwing hardware at the problem.) The numbers you report above seem to indicate you were spending 10%+ of your time dealing with denorm values, so you must have been getting a *lot* of them. -- Bron Campbell Nelson bron@sgi.com or possibly ..!ames!sgi!bron These statements are my own, not those of Silicon Graphics.
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (11/01/90)
....
>"exception" is *not* an error, it is just an exceptional (unusual)
Kahan (primary force behind the ieee 754 effort) has a nice slide on
this
exceptions are not errors. exceptions are not uncommon.
... repeated 50 times....
There are perfectly "normal" applications that do nearly all their
computation very close to zero (solving for deviations from an
expected value, for example) ....
Many vendors (Sun and MIPS included) exclude denomalized support from
the hw, and this causes a non-trival class of users to have severe
performance problems. Fortunately, most applications which compute
things close to zero are perfectly happy with flush to zero
arithmetic. Rather than having two librarys, a run-time is handy (in
my experience). On suns's that is call abrupt_underflow().
My point in posting is to not allow the spirit of Kahan to be
disturbed ... floating point exceptions are not exceptional events ...
we should have picked a name sans connotations of frequency.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043