joel@kaprap.Solbourne.COM (Joel Boney) (11/28/90)
In article <46866@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes: >[] >>In article <13342@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes: >> >>This is probably true for NaN's and Infinities, but Denorms occur all the >>time. printf() often generates them when dealing with floats, and the >>math library routines do also. > >I still don't understand the assertion that Denorms occur all the time. >Just because printf() knows how to handle them doesn't mean that it >happens very often. Likewise the math routines. What is your evidence >than it happens "often" (whatever that means- 1% is incredibly often by >my definition in this case) Statistically denormalized numbers almost never occur (surely less than 1%). That doesn't mean they are not useful. They make writing robust floating point codes much easier. However, if your algorithm is producing lots of denorms then it probably is time to reconsider your algorithm. The library routines may generate intermediate denorms from time to time, but good library routines will not generate very many. It is fine (and certainly in the spirit of the IEEE standard) to implement some rare functions such as generating and computing with denorms via a combination of hardware and software. Most of the RISC vendors do this now and the performance degradation is not noticeable for any normal codes (SPECmarks for example). I would much rather the chip implementators use their silicon for things like more cache than for handling things like denorms in hardware.
baum@Apple.COM (Allen J. Baum) (11/29/90)
[] >In article <1990Nov28.154221.26355@Solbourne.COM> joel@kaprap.Solbourne.COM (Joel Boney) writes: >Statistically denormalized numbers almost never occur (surely less than 1%). >That doesn't mean they are not useful. They make writing robust floating >point codes much easier. However, if your algorithm is producing lots of >denorms then it probably is time to reconsider your algorithm..... > >It is fine (and certainly in the spirit of the IEEE standard) to implement >some rare functions such as generating and computing with denorms via >a combination of hardware and software.... Well, this is what I wanted to hear. What I heard before was that some machine was horribly slow because it trapped denorms and handled them in software. Since I was under the impression that denorms were rare, I didn't understand why that should be. I did get one explanation from lucier@math.purdue.edu who said that using spectral methods to compute solutions of time-dependent PDEs with very smooth solutions (most of the time) then you can have tons of denorms (50% or more) in the fourier coefficients of the solution. This is the first concrete example I've heard, for real problems. He went on to say that often you can just flush to zero in these cases. -- baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum
davec@nucleus.amd.com (Dave Christie) (11/30/90)
In article <46899@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes: [regarding the frequency of IEEE denorms in the real world] > I did get one explanation from > lucier@math.purdue.edu who said that using spectral methods to >compute solutions of time-dependent PDEs with very smooth solutions >(most of the time) then you can have tons of denorms (50% or more) in >the fourier coefficients of the solution. This is the first concrete >example I've heard, for real problems. He went on to say that often you can >just flush to zero in these cases. For another real-world example, I once dealt with a flight simulation benchmark (for commercial flight simulators, not gameware) that really bogged down on a MIPS (denorms handled by software) relative to CDC machines (denorms in CDC FP format == 0). As you can imagine, flight simulation constantly deals with very small rotations in three dimensions. A niche application, but certainly real-world. I don't really know whether denorm values are actually necessary for this application, though... ------------------------- Dave Christie My opinions only.
meissner@osf.org (Michael Meissner) (11/30/90)
In article <1990Nov29.200543.15059@mozart.amd.com> davec@nucleus.amd.com (Dave Christie) writes: | > I did get one explanation from | > lucier@math.purdue.edu who said that using spectral methods to | >compute solutions of time-dependent PDEs with very smooth solutions | >(most of the time) then you can have tons of denorms (50% or more) in | >the fourier coefficients of the solution. This is the first concrete | >example I've heard, for real problems. He went on to say that often you can | >just flush to zero in these cases. | | For another real-world example, I once dealt with a flight simulation | benchmark (for commercial flight simulators, not gameware) that really | bogged down on a MIPS (denorms handled by software) relative to CDC | machines (denorms in CDC FP format == 0). As you can imagine, | flight simulation constantly deals with very small rotations in three | dimensions. A niche application, but certainly real-world. | I don't really know whether denorm values are actually necessary | for this application, though... Hmm, maybe that explains why the 486 does most (all?) of the denorm handling in hardware rather than software like the 386 does. I guess it's possible that it makes Microsoft Flight Simulator faster (no smiley). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?