Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!oliveb!sun!chiba!khb
From: khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering)
Newsgroups: comp.arch
Subject: Re: MIPS supports 80- & 128-bit floats.
Message-ID: <83596@sun.uucp>
Date: 4 Jan 89 03:36:02 GMT
References: <10452@obiwan.mips.COM> <325@loligo.fsu.edu> <13142@cup.portal.com> <345@loligo.fsu.edu>
Sender: news@sun.uucp
Reply-To: khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering)
Organization: Sun Microsystems, Mountain View
Lines: 27

In article <345@loligo.fsu.edu> mccalpin@loligo.cc.fsu.edu (John McCalpin) writes:

>I think that The IEEE standard is a very good choice in a new design.
>It has the advantage of being vendor-independent, and is much more
>reliable than most other floating-point formats.  It is rather expensive
>to do correctly, and this often translates into slower speed at a fixed
>price.  But for a multi-million dollar machine, the incremental cost of
>getting the same speed with the IEEE format should not be prohibitive.

Gradual underflow and divide are sticking points for very high (cost
is no object performance). They are both worth having (GU especially
for 32-bit machines) but they will cause the biggest "baddest"
machines to be slower.

Seymour's machines do very low quality divides, but they are very
fast. If speed is the name of the game (and in supercomputing it has
been) then a non-ieee divide is a fact of life.

Until reccently I was on the other side (user side) and as a provider
of scientific software (kalman filtering)  I much prefered to limit my
concerns to the algorithm being designed, and/or the problem being
solved. Bad arithmetic looks just like certain types of mismodelling,
poor obserability, etc. Good arithmetic is worth having. Missing the
target is much worse than having to sweat to make the code run fast enough.

Keith H. Bierman
It's Not My Fault ---- I Voted for Bill & Opus