NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/super/1124

Internet Message Format | 1992-12-13 | 4.2 KB

Path: sparky!uunet!usc!sdd.hp.com!ux1.cso.uiuc.edu!roundup.crhc.uiuc.edu!roundup.crhc.uiuc.edu!anik
From: [e-mail] (Sadun Anik)
Newsgroups: comp.sys.super
Subject: Re: Precision requirements
Date: 13 Dec 92 02:06:43
Organization: Center for Reliable and High-Performance Computing
Lines: 60
Distribution: inet
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]>
NNTP-Posting-Host: polaris.crhc.uiuc.edu
In-reply-to: [e-mail]'s message of Fri, 11 Dec 1992 01:56:24 GMT

In article <[e-mail]> [e-mail] (Hugh LaMaster) writes:
>In article <[e-mail]>, [e-mail] (Eugene N. Miya) writes:
>|> In article <[e-mail]>
>|> [e-mail] (Dave Dodson) writes:
>|> >The oil industry consumes lots of supercomputer cycles doing seismic
>|> >analysis, and 32 bits is more than enough precision for that.  After
>|> >all, the seismic data has only 2 or 3 significant digits.  Using more
>|> >than 32 bits doesn't improve their ability to find oil.
>|> People think that if you double precision, all computations (adds, multiplies)
>|> double in time. They forget their long hand multiplications.  That's
>|> real estate.  Just another storage vs. time tradeoff.  Remember that you
>|> can gain insight by asking a person how many bits "single-precision" is.
>
>I don't know if this was discussed at SC '92, but at SC '91, several
>presentations mentioned that (please read carefully) 64 bits will not
>be enough for some (significant) algorithms when the problem *sizes* are
>scaled up to *TeraFLOPS* computing.  Therefore (please read carefully)
>microprocessor designs should now include some minimal support for
>128 bit FP so that the speed penalty is not enormous (full speed NOT
>required; 4:1 might be OK, 100:1 probably not).
>
>Why should today's MFLOPS-speed uP's worry about TeraFLOPS problems?
>Some of these micros are going to be used in MPP's.   This does not mean
>that we can expect (many) people to use (or need) 128 bit FP in
>their workstation-based computations.  But, generic uP's are becoming key
>components in some MPPs, and, as uP's approach GFLOPS speeds, people will
>have to worry about this.  [And, for the same reason, micros need 64 bit
>addressing, even though most workstations are not going to exceed a 1 GByte
>of physical memory for a few years.]

I don't follow the logic here. Since when MPP usage has been an
important factor in uP design? I wouldn't hold my breath to see 128
bit FP in a uP. It may happen in the future, but only when desktop
machine users require  it. As far as uP's are concerned x86
style FP operations should satisfy almost everybody. Ofcourse current
implemetation is microcoded but I expect to see a hardwired
add/multiply unit soon. x86 provides 80 bit "extended precision"
registers to handle 64 bit IEEE standard operations. Register to
register operations are 80 bits and some C compilers support this
precision. I don't think 80 bit operations are IEEE.

I don't think there is a good precision vs speed type tradeoff in a
pipelined FPU. If the hardware handles X bits per cycle, doing 2X
precision with pipelining would be pain. Think of all the flags and
exception detection for concurrently executing instructions. Designing
hardware to do this correctly can be harder than implementing 2X
precision for a scalar processor. When a 2X precision instruction is
provided in assembly language, you will end up executing it pretty
much on its own, with not much of pipelining. The bottom line is when
you have a pipeline unit you can either do 2X precision in about the
same time as X precision or much  slower. Ofcourse if you can get a
single cycle X precision FPU, then doubling your precision won't cost
too much (1:4 maybe). But still there is no "twice the precision half
the performance" type tradeoff for a generic uP.


--
Sadun Anik, U of Illinois at Urbana-Champaign
Center for Reliable and High-performance Computing
e-mail: [e-mail]