🚀 go-pugleaf

In article <30200001@gorgo.UUCP> bsteve@gorgo.UUCP writes:
>
>AARRRGGH...
>
>   There is NO implicitly direct relationship between MegaFlops and clock
>speed! Good grief people, what about consideration of the number of tics per
>MMU cycle and how this is affected by the need for waitstates at higher clock
>speeds? Does the architecture support stackable MMU's, and how might this
>affect memory cycle time and how do the cycle times differ amoung various
>addressing modes? Flops/Hz is just not a valid measurement of anything. This
>is particularly true in view of the fact that "Flops" varies wildly from
>benchmark to benchmark.
>
>   Steve Blasingame (Oklahoma City)
>   bsteve@eris.Berkeley.Edu
>   ihnp4!occrsh!gorgo!bsteve
>
>
>"We burn the tabonga with a might fire and yet it would not die..."
>				From: FROM HELL IT CAME

Jeeze Louise.  Of course there is a relationship between MegaFlops and
MHz.  What you get is Flops per cycle which is the inverse of cycles
per Flop; cycles per Flop is very interesting, just as cycles per
instruction is very interesting, and the inverse is equally interesting
if not quite as intuitive.  What the hell do the number of "tics per
MMU cycle," "stackable MMU's," and the variation of cycle time "amoung
[sic] various addressing modes" have to do with floating point?  What
the hell is a "stackable MMU;" and the last time I checked, cycle time
doesn't vary with addressing mode, even on the CISCiest of CISCs (ok,
AMD does have a 2900 clock chip which allows different cycle times to
be selected by microinstructions, but this thing is virtually never used
in the real world).  Flops/Hz does measure something; it may not be a
really good way to measure architectural efficiency, but not for any of
the reasons you submit.