Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.arch Subject: Re: DeNorms (was Alignment on RS/6000) Message-ID: Date: 29 Nov 90 23:40:59 GMT References: <46866@apple.Apple.COM> <1990Nov28.154221.26355@Solbourne.COM> <46899@apple.Apple.COM> <1990Nov29.200543.15059@mozart.amd.com> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 29 In-reply-to: davec@nucleus.amd.com's message of 29 Nov 90 20:05:43 GMT 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?