Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.arch
Subject: Re: i860 MFLOP rate?
Message-ID: <1845@exodus.Eng.Sun.COM>
Date: 30 Oct 90 20:44:39 GMT
References: <9010291839.AA07178@lilac.berkeley.edu>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 34

rmbult01@ulkyvx.BITNET (Robert M. Bultman) writes:
>The i860 has been quoted as having a peak MFLOP rate of ~150
>MFLOPS.  (This is more of a guess.)  People writing in comp.arch
>have suggested that this is somewhat optimistic.

Note 1:  that is probably a peak "MOP" rate, not MFLOP rate.  The peak
figures are typcally 3 * OP * clock -- i.e., a 50 Mhz chip can go no
faster than 150 Million Operation Per Second.  In this situation, the
chip is performing the following mix of instructions per cycle:

1) 1 single-precision add
2) 1 single-precision multiply
3) 1 integer unit instruction (includes floating point fetches and
   stores)

In practice, all that people care about is FLOPS -- if you can issue
enough floating point loads and stores to keep the FPU happy, then
that's all that really matters.

Note 2: In theory, you can probably get pretty close to this, but in
the near term hand-coding is a must, and the going is very very slow.
Preston Briggs has opinions on this matter -- I quit worrying about
the problem some time ago.

The hard part about compilation is that your optimizer must realize
that the stages in the floating point pipeline are really registers,
and that it ought to use cached loads for certain operands, and
pipelined loads for other operands.  Since compilers typically don't
do this, you're stuck with (extrememly tedious) hand optimizations and
a lot of gray hair.  Fielding traps on this chip is also not good for
your mental health.

David Chase
Sun Microsystems