> 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
-------------------------------------------------------------------------------
|