Thread View: net.arch
3 messages
3 total messages
Started by Ray Curry
Wed, 08 Oct 1986 20:53
re:Floating point performance
Author: Ray Curry
Date: Wed, 08 Oct 1986 20:53
Date: Wed, 08 Oct 1986 20:53
50 lines
3063 bytes
3063 bytes
>Path: nsc!pyramid!decwrl!decvax!ucbvax!ucbcad!nike!lll-crg!seismo!mcvax!euroies!shepherd >From: shepherd@euroies.UUCP (Roger Shepherd) >Newsgroups: net.arch >Subject: Floating point performance >Message-ID: <340@euroies.UUCP> >dislikes the NS 32310 (four chips); they seem to give the >same MFLOP rating. (Does anyone have Whetstone figures for >these two?) >Comparisons against Weiteks (or whatever) are also somewhat >suspect. To use their peak data rate you have to use them in >pipelined mode, their scalar mode tends to be somewhat slower -- >Roger Shepherd >INMOS Limited, 1000 Aztec West, Almondsbury, Bristol, BS12 4SQ, GB >USENET: ...!euroies!shepherd >PHONE: +44 454 616616 Just by coincidence, I have been running some floating point benchmarks on NS32081 floating point processor and thought I needed to respond with some more up to date numbers. I ran the single precision Whetstone on the NS32032 and NS32081 at 10MHz on the DB32000 board, and the NS32332 and NS32081 at 15 MHz on the DB332 board. I don't know where the posted 32032-32081 number came from but I measure better even using our older compiliers. Our new compilers show marked improvement. 32032-32081 (10MHz) 189 Kwhets (old compiler) 32032-32081 (10MHz) 390 Kwhets (new compiler) 32332-32081 (15MHz) 728 Kwhets (new compiler) I used the 32332-32081 numbers to generate instruction counts to project worst case performance for the NS32310 and the NS32381, worst case being using the identical math routines and minimizing the pipelining of the 32310. These project performance for the 32332-32381 (15MHz) at approx- imately 1100-1200 KWhets and 32332-32310 (15MHz) at 1500-1600 KWhets. Since both the 32310 and 32381 will have new instructions that will impact the math libraries, the real performance could be higher. Just for interest, preliminary analysis is saying pipelining should improve performance at least 15% overall (30% for the floating point portion of the instruction mix). I would like to add my own question to the value of benchmarks. That is what do the people on the net feel about transcendental functions? The Whetstone seems to me to place more emphasis on them than real life. One of the reasons for not including them directly in the 32081 was that it was felt that implementing them in math routines instead of hardware was more cost effective. Is this true or are transcendentals important enough for the increased cost of implementing them in hardware?
re:Floating point performance
Author: Henry Spencer
Date: Thu, 09 Oct 1986 21:40
Date: Thu, 09 Oct 1986 21:40
19 lines
1668 bytes
1668 bytes
> ...what do the people on the net feel about transcendental functions?
> The Whetstone seems to me to place more emphasis on them than real life.
> One of the reasons for not including them directly in the 32081 was that
> it was felt that implementing them in math routines instead of hardware
> was more cost effective. Is this true or are transcendentals important
> enough for the increased cost of implementing them in hardware?
Personally, while I strongly suspect that a software implementation is
more cost-effective than doing them in hardware, putting them on-chip
strikes me as a marvellous way of getting them right once and for all
and encouraging everyone to use the done-right version. (This does assume,
of course, that the chip-maker spends the necessary money to *get* them
right, which requires high-paid specialists and a lot of work.) One
could get much the same effect with a bare-bones arithmetic chip and a
ROM chip containing the math routines, except that ROMs are too easy to
copy and you'd never recover the investment needed to do a good job.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
re:Floating point performance
Author: aglew
Date: Wed, 15 Oct 1986 14:59
Date: Wed, 15 Oct 1986 14:59
21 lines
1613 bytes
1613 bytes
>> The final column gives some feel for how effective these >> processor/co-processor (just processor for the T414) >> combinations are at turning MFLOPS into usable floating >> point performance. > >As one who has looked at the relative merits of various processors >and coprocessors before making a selection, I am not at all concerned >about "how effective [a] processor/co-processor combination[] [is] at >turning MFLOPS into usable floating point performance." The bottom >line for an application is closely tied to the numbers in the "kWhets" >column. The real question is, "How fast will it run my application?" > > Steve Rice Well, not only that, but perhaps also "How much will it cost to run my application?" Users don't care how effective an architecture is, they only care what the final result is. People interested in design, however, may be interested in the ratios, since a low performance product with good figures of merit may show an approach that should be turned into a high performance product.
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads