From owner-riscy@pyramid.com  Tue Aug 10 09:14:27 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA26976; Tue, 10 Aug 93 09:14:27 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20819; Tue, 10 Aug 93 06:13:50 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08119; Tue, 10 Aug 93 06:12:37 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08112; Tue, 10 Aug 93 06:12:35 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20811; Tue, 10 Aug 93 06:13:38 -0700
Message-Id: <9308101313.AA20811@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA21525; Tue, 10 Aug 93 09:11:25 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Mips chips/performance
To: riscy@pyramid.com (Mips 3000)
Date: Tue, 10 Aug 1993 09:11:25 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1380      
Sender: owner-riscy@pyramid.com
Reply-To: 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? 

Speculation welcome.
-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok

 
From owner-riscy@pyramid.com  Tue Aug 10 10:19:11 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA29755; Tue, 10 Aug 93 10:19:11 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23696; Tue, 10 Aug 93 07:19:00 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11081; Tue, 10 Aug 93 07:16:38 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11074; Tue, 10 Aug 93 07:16:35 -0700
Received: from frisbee.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23682; Tue, 10 Aug 93 07:17:38 -0700
Received: from localhost by frisbee.cs.Colorado.EDU with SMTP id AA25613
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 10 Aug 1993 08:16:26 -0600
Message-Id: <199308101416.AA25613@frisbee.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: Mips chips/performance 
In-Reply-To: Your message of "Tue, 10 Aug 1993 09:11:25 CDT."
             <9308101313.AA20811@gossip.pyramid.com> 
Date: Tue, 10 Aug 1993 08:16:14 -0600
From: Drew Eckhardt <drew@frisbee.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: 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.
    
    
    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 t
   he
    mips 4000PC, and supposedly has longer pipelines, and less fp support.

Posibilities are 

- longer pipelines

- bigger on-chip cache

- different process, since it is a low power 3.3V part

- different 'C' compiler used for marketing purposes

- extern second level caches

    Is it possible it supports a second level cache? 

At the 4200's price, and the PC's price, I rather doubt that it has built in 
support for a second level cache.  

    Or it it just above a very
    important 1st level cache threshold that gives it twice the perfomance of t
   he
    4200 for this benchmark? (I.e. in real world not faster then the 4000PC)

Could be.
    
    Or was the 4200 paired with some custom memory subsystem that implemented
    a seperate cache controller for the 2nd level cache? 

Could be.
    
--------

 
From owner-riscy@pyramid.com  Wed Aug 11 03:45:40 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA14983; Wed, 11 Aug 93 03:45:40 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02922; Wed, 11 Aug 93 00:44:42 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00315; Wed, 11 Aug 93 00:43:18 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00308; Wed, 11 Aug 93 00:43:15 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02906; Wed, 11 Aug 93 00:44:16 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id IV25649; Wed, 11 Aug 1993 09:39:54 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA04346; Wed, 11 Aug 93 09:35:46 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA13392; Wed, 11 Aug 93 09:36:14 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 11 Aug 93 09:35:20 +0200
Message-Id: <9308110735.AA22202@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA22202; Wed, 11 Aug 93 09:35:20 +0200
To: riscy@pyramid.com
Subject: Re:  Mips chips/performance
Sender: owner-riscy@pyramid.com
Reply-To: 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
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Wed Aug 11 05:54:22 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18221; Wed, 11 Aug 93 05:54:22 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16010; Wed, 11 Aug 93 02:54:12 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15618; Wed, 11 Aug 93 02:52:40 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15611; Wed, 11 Aug 93 02:52:38 -0700
Received: from csunix.urc.kun.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15994; Wed, 11 Aug 93 02:53:34 -0700
Received: by csunix.urc.kun.nl (5.64/1.37)
	id AA01919; Wed, 11 Aug 93 11:45:44 +0200
From: ronald%csunix.urc.kun.nl@kunrc1.urc.kun.nl (Ronald Schalk)
Message-Id: <9308110945.AA01919@csunix.urc.kun.nl>
Subject: Re: Mips chips/performance
To: riscy@pyramid.com
Date: Wed, 11 Aug 1993 11:45:43 +0200 (CET)
In-Reply-To: <9308110735.AA22202@resi.waldorf-gmbh.de> from "Andreas Busse" at Aug 11, 93 09:35:20 am
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 3019      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

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

I guess by now we can close this discussion by voting for R4200.
Why:   1 This project started with the R3K andthe R4.2K is much faster,
         and this HAS FP-support. (No more discussion like 3051<->3081)

       2 It would make software easier, no FP-emulation needed :-)

       3 There are more important issues that have been put to the background
         e.g. ethernet,scsi,video,serial I/O, parallel ports, sound (?)

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

Yes, especially considering that the R3051 was first seriously considered.

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

YES, I guess that's important too.

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

Yes, it's important to drwaw the line somewhere, there's always something
bigger, better, faster, etc. But the main point is that the board has to
be affordabable. I guess the R4.2K gives us a viable alternative to the R3K.


Well closing off: 

Can we perform some kind of vote on the processor? Even though the 
pricing is not quite clear yet. I guess we can start talking again about 
the above mentioned issues??



Greetings Ronald

 ********************************************************************
 * ing. Ronald Schalk                                               *
 * sectie COOS                                                      *
 * Universitair Centrum Informatievoorziening (UCI)                 *
 * Katholieke Universiteit Nijmegen (KUN)                           *
 * e-mail : R.Schalk@uci.kun.nl   snailmail: Geert Grooteplein 41   *
 * tel.   : +31 80 617997                    6525 GA Nijmegen       *
 * fax   :  +31 80 617979                    Nederland              *
 ********************************************************************
 
 
From owner-riscy@pyramid.com  Wed Aug 11 05:58:42 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18332; Wed, 11 Aug 93 05:58:42 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16347; Wed, 11 Aug 93 02:58:34 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16122; Wed, 11 Aug 93 02:57:20 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16114; Wed, 11 Aug 93 02:57:18 -0700
Received: from bernina.ethz.ch 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16339; Wed, 11 Aug 93 02:58:23 -0700
Received: from neptune by bernina.ethz.ch with SMTP inbound id <25797-0@bernina.ethz.ch>; Wed, 11 Aug 1993 11:56:53 +0200
Message-Id: <9308110956.AA07164@neptune>
Received: from tau.inf.ethz.ch by neptune id AA07164; Wed, 11 Aug 93 11:56:48 +0200
To: riscy@pyramid.com
Subject: Re: Mips chips/performance 
In-Reply-To: Your message of "Wed, 11 Aug 93 11:45:43 +0100."
	     <9308110945.AA01919@csunix.urc.kun.nl> 
Date: Wed, 11 Aug 93 11:56:45 +0200
From: weingart@inf.ethz.ch
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

You write: 
Sie schreiben: 

> Can we perform some kind of vote on the processor? Even though the 
> pricing is not quite clear yet.

Sure.  I put in mine for either R4kPC, or R4200.

--Toby.
--------------------------------------------------------------
|Tobias Weingartner  |    PGP2.x Public Key available at     |
| +41'01'254'7205    |   'finger weingart@tau.inf.ethz.ch'   |
--------------------------------------------------------------
%SYSTEM-F-ANARCHISM, the operating system has been overthrown
 
