🚀 go-pugleaf

In article <428@propress.com> pan@propress.com (Philip A. Naecker) writes:

>Case in point:  The R2000 chipset implemented on the R/120 (mentioned by others
>in this conversation) has, by all measures *excellent* scalar performance.  One
>would benchmark it at about 12-14 times a microVAX.  However, in real-world,
>doing-useful-work, not-just-simply-benchmarking situations, one finds that
>actual performance (i.e., performance in very simple routines with very simple
>algorithms doing simple floating point operations) is about 1/2 that expected.

Please be a little more specific, as this is contrary to large numbers
of people's experience with "doing-useful-work, not-just-simply-benchmarking"
situations.  Note: it is perfectly possible that one can encounter realistic
programs for which the performance is half of what is expected, on some
given class of benchmarks.  Is the statement above:
	a) The M/120 is really a 6-7X microVAX machine
	OR
	b) We've run some programs in which it is found to be a 6-7X
	uVAX machine.

Note that, as posted, this reads more like a) than b), so please say
more.


>Why?  Because memory bandwidth is *not* as good on a R2000 as it is on other
>machines, even machines with considerably "slower" processors.  There are
>several components to this, the most important being the cache implementation
>on an R/120.  Other implementations using the R2000/R3000/Rx000 chipsets might
>well do much better, but only with considerable effort and cost, both of which
>mean that those "better" implementations will begin to approach the price/
>performance of the "big" machines that you argue will be killed by the
>price/performance of commodity microprocessors.
The R2000 in an M/120 indeed has a very simple memory system.

The rest of the comments seem overstated to me: we just announced
a new machine (the RC3240), which is a CPU-board upgrade to an M/120,
uses an R3000, gains another 40-50% performance from the same old
memory boards, and costs the same as an M/120 did when it was announced.
If it had been desgined from scratch, it would be faster, with little or
no increase in cost.
PLEASE look at the data on the various machines built of such parts.
The one-word refill of the R2000 certainly slowed it down; the multi-word
refill & instruction-streaming on the R3000 certainly help improve the
kinds of programs that hurt an R2000, and the cost differences are really
pretty minimal.

In addition, if you look at R3000s in larger system designs,
I think it is hard to claim that these implementations are anywhere near
the price/performance (anywhere near as high price, that is) as those of
"big" machines, at least for CPU performance.
>
>I think you are to a degree correct, but one must always tailor such
>generalities with a dose of real-world applications.  I didn't, and I got bit
>to the tune of a fine bottle of wine. :-(

Anyway, we all agree on that: "your mileage may vary".  How about posting
something on the particular applications to generate some insight about
what these things are good for or not?
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086