Path: utzoo!attcan!uunet!mstan!amull From: amull@Morgan.COM (Andrew P. Mullhaupt) Newsgroups: comp.arch Subject: Re: Why FP at all? (was: Re: Killer Micro II) Summary: Nay, nay, a thousand times nay. Message-ID: <1632@lhr.Morgan.COM> Date: 5 Sep 90 14:26:13 GMT References: <527@llnl.LLNL.GOV> <603@array.UUCP> <2482@l.cc.purdue.edu> Organization: Morgan Stanley & Co. NY, NY Lines: 65 In article , stephen@estragon.uchicago.edu (Stephen P Spackman) writes: > Please excuse the quasi-flamage.... > > Am I really dense, or have I completely missed the point? Why are we > burning silicon on floating point arithmetic when we could have fast > 128-bit INTEGER arithmetic? Why do all the great arguments for RISC > suddenly evaporate when FP looms? I can only answer your second question. > Seems to me that 90% of the floating point code I've seen had a > dynamic range that was low *and potentially known to the compiler*; it It would seem you haven't seen much code for scientific computation, or many subroutine libraries. If I compile say, and inner product subroutine am I then supposed to go around remembering what scaling is appropriate and what length vectors it can handle? > could have been directly compiled into scaled integers. Of what's > left, much was pretty weird stuff with unpredictable behaviour and the > exponent in fixed format FP was not big ENOUGH and maybe it should > have been broken out into a separately specifiable (and independently > computed) exponent ([int, long]float, you see). Ok, _you_ might consider Linpack pretty weird stuff but I think this would put you in a decided minority. > Ok, so we can do the full analysis; maybe there're a couple of > normalisation-shifts that deserve instructions, but I am *so tired* of > having the silicon on my PC and my workstation wasted on floating > point when all I want is Emacs and Unix and X to be tolerably fast > (which on a Sparc they aren't). Sniff. I keep my emacs and X on a Sun 3 where they belong. The RISC machines have better things to do than message passing. > Of course, I'm not into weather-prediction. Then again, I only ever > met one programmer who was. NCAR is actually a large place. Weather prediction is a billion dollar problem. Damage due to severe storms, floods, droughts is usually in the billions _every_ year. Our best attempts in this regard still fall short, but you can't argue that they're not worth it. It may be possible to predict El Nino, (that's what my old Ph.D. advisor is into these days...) and there is a lot of California exposed to this one. Naturally, a billion dollar problem can justify quite a few programmers. > Somehow it seems to me that we are being led by the nose by marketing > types and the ghosts of languages past. There are a lot of ghosts put into the market, mostly by marketing types. When we buy a machine, we find out if it can run our proprietary software, and if so, how fast. Floating performance is a big piece of the picture, along with our need for massive I/O throughput and our evaluation of the operating system. Sure, we need good integer performance, but we're not even remotely likely to consider replacing floating point with fixed arithmetic. It's a bad trade off for us on any of the present machines. Later, Andrew Mullhaupt Disclaimer: opinions expressed here are my own.