Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!ritcv!cci632!rb
From: rb@cci632.UUCP (Rex Ballard)
Newsgroups: net.arch
Subject: Re: Floating point performance
Message-ID: <562@cci632.UUCP>
Date: Wed, 22-Oct-86 09:42:49 EDT
Article-I.D.: cci632.562
Posted: Wed Oct 22 09:42:49 1986
Date-Received: Wed, 22-Oct-86 22:53:07 EDT
References: <340@euroies.UUCP> <1989@videovax.UUCP> <722@mips.UUCP> <8184@sun.uucp> <8575@lanl.ARPA> <3153@h.cc.purdue.edu>
Reply-To: rb@ccird2.UUCP (Rex Ballard)
Organization: CCI, Rochester Development, Rochester, NY
Lines: 27
Summary: Cycles/flop.

In article <3153@h.cc.purdue.edu> ags@h.cc.purdue.edu.UUCP (Dave Seaman) writes:
>In article <8575@lanl.ARPA> jlg@a.UUCP (Jim Giles) writes:
>>In article <8184@sun.uucp> dgh@sun.UUCP writes:
>>>                            Mflops Per MHz
>	"Floating point operations per cycle"
>
>after cancelling the "millions of ... per second" from numerator and
>denominator.
>
>I'm not claiming that this is a particularly useful measure, but that's
>what it means.

Sounds to me like what is really wanted is cycles/flop average.
This does give an indication of micro-code efficiency of the
archetecture used, based on average, rather than advertized
figures.

Obviously the more cycles/flop, the less inherantly efficient
the chip archetecture is.  By figuring these values using
whetstones or similar benchmarks, additional "off-chip" factors
such as set up overhead for the FPU calls are correctly included.

This sounds like an interesting measure of CPU/FPU archetecture
in the broader sense of the word.

>Dave Seaman	  					
>ags@h.cc.purdue.edu