Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!hp4nl!philapd!ssp1!roelof
From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom)
Newsgroups: comp.arch
Subject: Re: MIPS/MFLOPS ratio [long; here we go again; sorry]
Message-ID: <148@ssp1.idca.tds.philips.nl>
Date: 7 Jul 89 17:36:28 GMT
References: <596@megatek.UUCP> <112807@sun.Eng.Sun.COM> <22792@winchester.mips.COM>
Organization: Philips Telecommunication and Data Systems, The Netherlands
Lines: 83

In article <22792@winchester.mips.COM> mash@mips.COM (John Mashey) writes:

[Another view of the HOT CHIPS conference]

[A lengthy analysis of the verb tilt as in "tilting towards sparc" :-)] 
(Something tells me we've just witnessed the birth of a new expression 
as in so-and-so's showing a definite sparc tilt today :-) :-)

[Flames aimed at Keith Bierman designed to scorch Keith's toes.]

Since I'm the "fellow" who asked the question that prompted Keiths
posting that prompted your posting and since you were worried that Keiths
posting may have been overly biased and therefor may have unduly
influenced the General Public (me plus other interested readers)
the following:

[Another view]

Thanks, your extra DATA does provide more INSIGHT :-).
No seriously I mean it. Two heads are better than one and even more so if 
one of those two heads happens to be yours.

[lengthy analysis of the expression "tilting towards sparc" :-)]
I took Keiths remark to mean simple numerical superiority viz. more
sparc like implementations not derisory. Seeing MIPS track record
MIPS may indeed be smarter. Of course its not the individual folks
that are smarter but the organization itself. The way it lets various
software and hardware folks (concepts) interact. 
The way it lets the parts become a greater sum. Anybody with half an eye 
can see that MIPS is doing pioneering work in this area.
 
[Flames at Keith]
Of course Keith can take care of himself and God can take care of us all
but I think it is a little unfair to demand full data sheets from him because
he was kind enough to give a little info (and -his- insight) on the
proceedings. Rustling up that sort of info is obviously very time
consuming and Keith is already working long days (So how come you're
reading this Keith? :-)


But (as usual) you do bring up some good points particularly:


>The main reasons, I think, for the differences are:
>	1) The SPARC multi-cycle loads and stores, which is is not ISA,
>		but SYSTEM architecture and implementation.
>	2) The MIPS FPUs have lower cycle counts.
>	3) The compiler thing is an open question; I haven't looked at
>	much SPARC FP code lately, so I don't personally know.  Maybe
>	some UNBIASED third-parties would care to comment and give some DATA.
>

>and maybe thus offer a thesis that could be analyzed, if he

or anybody else!!!

>would do the following:
>	a) Gather all of the ACTUAL cycle counts of these various chips,
>	and put them in a table like the LSIL speaker showed, and post it here.
>	(This is data is clearly publicly available, I think.)
>	chips.  I think most of them overlap {add/sub/conv, mul/div/sqrt, and
>	load/store}, and I don't think any of them are pipelined, but I
>	could be wrong.
>	c) Give a terse, clear description of these chips in terms of which
>	ones are used in which currently-public SPARC systems, and dispel any

>credibility, I'd ask for the following DATA:
>	0) Talk about synchronizing the CPU and FPU at these speeds.
>	Do you have PLL's, or some other technique, or magic?
>	1) What are the access times of the SRAMs needed to
>	run at 30ns, 25ns, and 20ns cycle times? (Some of these parts
>	were claimed to scale to 50Mhz, so the 20ns is relevant.)

>	Which is better: 2-cycle + & 5-cycle *, or 3-cycle + & 4-cycle *?
>	On which kinds of benchmarks? why?
>	How much difference does it make in performance? in silicon space?

and of course my favourite :-)
>I.e., things that give DATA, and even better INSIGHT........
>
-- 
Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof@idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof