Date: Thu, 11 Dec 1997 11:14:48 -0700 From: "Russell L. Carter" <rcarter@consys.com> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-current@freebsd.org Subject: Re: xlock: caught signal 8 while running galaxy mode. Message-ID: <199712111814.LAA06477@dnstoo.consys.com> In-Reply-To: Your message of "Fri, 12 Dec 1997 03:59:07 %2B1100." <199712111659.DAA16579@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Referring to stuff I wrote so long ago I'd almost forgotten :-), Bruce observes: }The C9x draft specifies pure behaviour. Values must be independent }of whether they are represented in a (wide) register or in memory or }calculated at compile time. In particular, implicit spills must not }change the value. Explicit stores and loads must round to the precision }of the storage type. In particular, casts and assignments must perform }their specified conversion. Yes, and the implications for conforming x86 fp performance are large. Whereas the implications for non-conforming fp accuracy is insignificant at worst, and at best a useless exercise in trying to prostitute numerical mathematics to meet the requirements for a branding campaign, the value of same which is now getting resolved in court. } David Goldberg } Differences Among IEEE 754 Implementations } http://www.validgh.com/goldberg/addendum.html } 1997-10-26 } }>[lots deleted] } }>My original statement said there are "counterexamples" }>to the general rule that more accuracy is better for }>application codes. After a lot of thought and rereading }>of papers in my archive I can think of only two, }>very tiny, classes of codes that 53 bit precision }>benefits more than 64bit precision (given identical }>compuation costs). Those are test programs with bugs, }>like paranoia, and iterative algorithms that require }>a bit of noise to be coaxed to converge. Are there }>more? At any rate, "counterexamples" was much too }>charitable. } }These are probably the main examples. Goldberg gives some }interesting ones. And a numerical mathematician parses his argument as follows: 1. A numerical algorithm was devised for a particular floating point arithmetic. 2. Said algorithm fails on extended precision fp systems (such as x86) 3. => (therefore), the numerical mathematician should use a different algorithm on extended precision fp systems (such as x86). Which is different from a product based view that would have every algorithm behave the same on all possible architectures, and damn all other consequences... Now I'll let Goldberg (as apparently interpreted by David Hough) restate my issue for me: (quote taken from above reference) +Neither should these remarks suggest that all single/double systems +deliver identical numerical results. Diverse systems differ in +features not covered or anticipated by IEEE 754: math libraries contain +different implementations of the elementary functions, +not all systems provide correctly rounded binary/decimal conversions +throughout the range of each format they support, and +some processors provide a primitive operation to multiply two numbers +and add a third with just one rounding at the end. (This +operation, called a fused multiply-add, can foil the splitting +process of Theorem 6, yet it can also be used in a non-portable way +to perform multiple precision multiplication without the need for splitting.) +These factors contribute to produce different results from +one machine to another, too, though they are far less insidious than +indiscriminate and gratuitous use of extended precision. The upshot (restated from the last go around) is as long as we have runtime access to the fp rounding and extended precision modes, *and* the mods to make default fp behaviour do not significantly slow down the system (by less than 1% say) then uniform behaviour is ok. That's not what a "100% Pure" implementation of java (on x86) would imply. It would fail miserably both requirements. Anyway, I hope I'm not sounding too rancorous here, because I sure don't feel that way, and I appreciate the care with which you've worked on these issues, Bruce. Regards, Russell (for those who are interested but not familiar with the some of the background issues, long discussions over this stuff have been held for years on the numeric-interest and for a little while java-for-cse lists. And a quick perusal of David Hough's site shows an even worse anti x86 bias then I recalled (some nice reengineering of history there); interesting, since Kahan happens to disagree with most of the cross-platform assertions, c.f. 1997 SIAM General Meeting talk(#) (Hough was a student of Kahan...) aren't mathematicians fun ;-)) (#) http://nextra.msri.org/lecturenotes/97/SIAM/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712111814.LAA06477>