riscy
[Top] [All Lists]

Re: Mips chips/performance

To: riscy@pyramid.com
Subject: Re: Mips chips/performance
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 11 Aug 93 09:35:20 +0200
Reply-to: riscy@pyramid.com
Sender: owner-riscy@pyramid.com
> Here's a little performance table:
>       SpecINT Spec FP92       Mhz     Cache
> Mips 3000     27.3    29.3    40      0+128k      Dec 5240 numbers
> 486/66        32      16      33/66   8k          Intel announcement*
> 4000PC        35      34      50/100  8k+8k       Sgi periodic chart
> 4200          55      30      40/80   8k+16k?     Nec Broshure (no details)*
> 4000SC        60      58      50/100  8k+8k+1MB   SGI periodic chart
> Powerpc       60+     80+     66      32k         Motorolla ad *
> Pentium       64.5    56.9    66      8k+8k       Intel announcement * 
> R4400SC       97      88      75/150  16k+16k+1MB SGI periodic chart.
> 
> * = Spec numbers are probably obtained using an unmentioned 2nd level cache.
> 
> IMHO anything at the 4200 performance level or above looks great to me.
> 
> Question is how does the 4200 get it's speed?  It running 20% slower then the
> mips 4000PC, and supposedly has longer pipelines, and less fp support.
> 
> Is it possible it supports a second level cache? Or it it just above a very
> important 1st level cache threshold that gives it twice the perfomance of the
> 4200 for this benchmark? (I.e. in real world not faster then the 4000PC)
> 
> Or was the 4200 paired with some custom memory subsystem that implemented
> a seperate cache controller for the 2nd level cache? 

1. The specs for the R4200 are probably *estimates*. I'm sure they are
   a bit too high, but not much. The speed of the R4200 must be in
   between a R3000/40 and a R4000PC/50, simply because
   - it has 10 MHz clock less than the R4000PC/50 and
   - it has 64bit wide bus and logic, which makes it faster than a R3000/40.

2. The FP92 specs of the R4200 are so good because most floating point
   instructions have the same execution time as a real R4000 FPU has,
   only MUL and DIV are slower.

3. The pipeline is the same as a R3000 has. No reason to be slower
   than a R3000.

4. The R4200 has a larger primary cache (16k I + 8k D) than the R4000
   (8k I + 8k D). I mentioned already that the MIPS R4000 machine I
   am working on is sometimes 3 (!!) times slower than the R3000 machine
   with 32+32k cache we have here too.
   Although I don't believe that those 8k more speeds up the R4200
   by nearly factor 2 (in comparison to the R4000PC), I'm sure that
   the larger I cache results in a noticeable sustained speed up.

5. The R4200 ***DOES NOT*** support 2nd level cache. The Blockdiagram
   of ARCset shows no 2nd level cache, and there's ***NO SUPPORT*** at all.

The latter point should be one reason more to stop that 2nd level cache
discussion. If we are going to use the ARCset, we won't have 2nd level
cache. This is a fact unless someone finds an application around the R4200
or Orion *with* 2nd level cache support.
I'm not interested to spend any time to make an SC thing out of a PC CPU.
Of course, 2nd level cache would speed up the thing, but I thought that
we agreed to use an existing design to speed up development. That means
that we would use the ARCset design primarily *as is*, perhaps with
little changes in the I/O area. Integrating 2nd level cache in a design
which is not intended for that is probably no good idea.

Finally, I simply don't understand why this discussion came up.
I thought our goal was to design and produce a board with very good
price/performance relation. Although the price of the ARCset isn't
clear at the moment (which is not my or our fault, but NEC's) it seems
that this is what we are looking for. It offers more speed than
a R3081 solution probably for only few $s more.

If you all insist on a 2nd level cache design, we should forget
about the ARCset. That means in turn that we should forget about
having a design within the next 12 months. I'm not sure what then
happens to the group...

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 

<Prev in Thread] Current Thread [Next in Thread>