Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ames.arc.nasa.gov!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: Criteria for comparing RISC processors
Message-ID: <24953@ames.arc.nasa.gov>
Date: 4 May 89 15:59:35 GMT
References: <2368@ogccse.ogc.edu> <1464@cfa.cfa.harvard.EDU> <141@dg.dg.com> <18120@winchester.mips.COM> <144@dg.dg.com> <18316@winchester.mips.COM> <147@dg.dg.com> <18653@winchester.mips.COM> <102441@sun.Eng.Sun.COM> <157@dg.dg.com>
Sender: usenet@ames.arc.nasa.gov
Organization: NASA - Ames Research Center
Lines: 59

In article <157@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes:
>In article <102441@sun.Eng.Sun.COM> jek3@sun.UUCP (Joseph Kowalski) writes:
>>In article <18653@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>>>In article <147@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes:

>>>>produce code RIGHT NOW with performance (Mhz for Mhz) equal to the MIPS 

>Your point is well taken.  By saying "Mhz for Mhz," I was attempting to make
>sure that reasonable machines are being compared.  There is a penchant in

>Dollar for dollar comparisons don't apply when there is no overlap

Dollar for dollar comparisons are really the result of, not the input to,
the architectural question.  It depends too much on financial and marketing
considerations of the companies involved.  Know any companies which have
deliberately held back technology to avoid affecting current products?

>High end to high end suffers from the same problem:  one person's high

Actually, with a given technology this isn't too bad.  If you know that the
technology is the high end, that is, and not affected by marketing, as above

>Low end to low end is somewhat more fair.  In this space, the design

>$/MIP is the most fair since it more readily allows people to judge

Marketing affects this too much again...



Since this originally started as a discussion of a few "RISC" architectures
implemented in very similar technology, it seems to ME that "Mhz for Mhz"
isn't too bad a place to start.  How about a discussion of what instructions
get generated in the critical sections of your most favorite 5 benchmarks, and
why the branch strategy, address generation strategy, procedure call strategy,
and other relevant design choices end up producing fewer comparable
instruction cycles.

If you want to get into implementation issues, are there architectural reasons
why EVERYBODY can't do f.p. adds in two cycles?

Favorite benchmarks:

I like LINPACK to start: if you don't have the f.p. and memory performance
for good performance here, you can't solve my favorite problems.

Some version of SPICE:  a very commonly used code which is good 
for demonstrating branch and memory latency slowness.

...

Pick your favorites and do the comparisons, and show why
performance is, MHz for MHz, as good as MIPS.


  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117