🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #3194

Re: R6000 vs BIT SPARC

#3194
From: John Mashey
Date: Wed, 29 Nov 1989 03:14
130 lines
7601 bytes
In article <1989Nov22.233508.20446@Neon.Stanford.EDU> rathmann@eclipse.Stanford.EDU (Peter K. Rathmann) writes:
>Ok, R6000 vs BIT SPARC is too early to call, but other comparisons
>might be even more interesting.  The R6000 based system was billed in
>the popular press as a mainframe, so does anyone have any numbers
>comparing it to more typical mainframes like the IBM 3090 or big
>Amdahl machines?

Please note: it's called an "Enterprise Server" rather than a mainframe;
the 6280 brochure doesn't ever say "mainframe", on purpose.
The claim is that the CPU performance is mainframe-uniprocessor class,
and that it's got pretty reasonable I/O.

According to a posting of Mike Taylor's a while back,
a few relevant numbers would be, for the fastest scalar mainframe for
which I have numbers:
			Amdahl 5990 CPU		RC6280
Cycle time		10ns			15ns (@67Mhz)
LLNL 64, Harmonic	11.9 MFlops		8.8 MFLOPS
LINPACK, 64, FORT	14.5 MFLOPS		10.3 MFLOPS
LINPACK, 32, FORT	16.8 MFLOPS		13.9 MFLOPS
Dhrystones (1.1) 	90Kish?			109K, -O3

Grossly, as far as I can tell:
	An Amdahl 5990 CPU is faster than a 5890 (for sure!) and
	faster than the fastest current IBM 3090 CPU, assuming all scalar
	stuff (no vector units).
@ 67.5Mhz, a 6280 CPU seems faster than a 5890 or 3090, but a little slower than
a 5990, at least on floating-point.  There is insufficient comparative
data to really know much on the integer side. (Dhrystone is also good
for S/370-bashing, not just VAX-bashing.) I suspect a 6280 might equal
a 5990 on the integer stuff, but more data is really needed.
One would have to see a lot more data to know a lot more, especially
given the different memory systems [the Amdahl brings joy to SRAM vendors:
up to 512MB of it...; the 6280's secondary cache is "only" 512KB.
This certainly will help the Amdahl's performance in huge multi-user
situations, although the 6280 has been designed to be pretty reasonable
for that purpose also (512KB of physical, 2-way set-associative cache
helps a lot).]

Of course, you can put 4 CPUs in the Amdahl box, whereas we've announced 1.

I think a 5990 CPU would be called about 60-65 VUPs (?; note that IBM-mips
and VUPs are different, so this corresponds to nothing they claim.)
A full 5990 box (according to a posting a while back) has a peak aggregate
I/O rate of 500 MB/sec, or about 2 MB/sec per VAX-mip, assuming
that each CPU is around 65 VUPs.  The RC6280's biggest I/O configuration
will allow 6 VME busses, for 33MB/sec peak aggregate rate, also
around 2-3 MB/sec per VUP (well, it looks more like 3, but I suspect that
a 5990 can get closer to its peak than we can, given the different memory
architectures.)

There is insufficient data in those numbers, given the completely
different architectures, to know much, except that the biggest announced
configurations sound like they have grossly have similar ratios of
I/O bandwidth to compute power.  The smallest 6280 has about .5 MB/sec per VUP.

>
>Extrapolating from the xfroot numbers indicates that the R6000 should
>be pretty competitive, at least for floating point.  Has anyone checked
>it for a business data processing mix of databases and COBOL?

It is specifically tuned to be good at such things; in particular, the
cache design is partially aimed at that issue.
>
>If the R6000 can compete with classic mainframes on their home ground,
>I might start believing this talk about killer micros.

Again, it's NOT a mainframe: it doesn't have the direct, immense connectivity
of a large mainframe.  It probably does have the connectivity of a small
mainframe, and (about) the CPU performance of the faster large
uniprocessors.

(The following is doing its best not to be a commercial, but it's hard :-)
Just to fix a misconception I've now seen several times, such machines are
NOT expected to put IBM or Amdahl out of business, and are NOT expected
to be one-for-one replacements for big mainframes.  No one in their right
mind would position this product that way.  If not that, then what are these
things (big Killer-Micros, not just MIPS-based ones) for:
	a) Upgrades from smaller micro-based systems, in either commercial
	or technical markets. (Again, there are fairly large numbers of
	UNIX micros in the commercial markets, not just technical ones.)

	b) Offload selected existing applications from mainframes, mostly
	to avoid upgrades at awkward times, or to survive budget pressure.
	For example, big OLTP things running under MVS aren't about to
	move any time soon to any of the fast micros ["any time soon" means
	"in the forseeable future"].  On the other hand, suppose you have
	a mainframe complex that's running:
		OLTP with IMS or DB2
		CAD number-crunching
		program development
	and it's out of steam.  You might be tempted to move some of the
	CAD off, and maybe some program development (many computer centers
	have done this for years anyway, but some applications were "stuck"
	on the mainframes for speed or size needs).  Thus, you would free up
	cycles for your OLTP work (which will probably never move).
	Also, maybe the the CAD department decides it could afford to have
	the comp center run a K.M. for them, for their dedicated use.
	"Avoiding upgrades at awkward times" : anybody who's spent any time
	in the mainframe business knows there are good times in product
	lifecycles to buy new things, and other times that are not so good.
	Sometimes, putting off a major upgrade for 6 months can save a lot of
	money.
	c) Suppose your company uses some relational database that runs on both
	mainframes and various UNIX systems, and you're implementing a new
	application based on it.  In some cases, a Killer Micro offers another
	point in the cost/performance space that may fit what you need,
	where a bunch of small micro-based systems just don't fit.

In general, if you look at the history of computing, new kinds of
computers have either siphoned off growth from older kinds, or opened
new markets, rather than engaging in direct 1-on-1 replacement battles.
A reasonably objective view of the K.M. machines for the commercial market
says:
	a) There are shops that will never, ever have them (not surprising,
	as there are shops that have only recently come to believe that
	companies like Amdahl, Tandem, or DEC are substantial enough to
	deal with.  Some haven't gotten that far...  for such places,
	companies like MIPS or even Sun simply don't exist...)
	Fotunately, many K.M.s will get sold thru other larger companies.
	b) Enough places simply want faster UNIX boxes, or if they can
	get mainframe CPU speeds from something whose cost/VUP is 10X better,
	and is fast enough to get the job done in time, will happily move
	selected applications off, or at least consider K.M. boxes as
	alternatives for growth.  
-- 
-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
Technical Details
Message-ID: <32343@winchester.mips.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!mips!mash
References: <1989Nov21.015953.13817@elroy.jpl.nasa.gov> <14900002@hpdml93.HP.COM> <1989Nov22.233508.20446@Neon.Stanford.EDU>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: R6000 vs BIT SPARC
Message-ID: <32343@winchester.mips.COM>
Date: 29 Nov 89 03:14:57 GMT
References: <1989Nov21.015953.13817@elroy.jpl.nasa.gov> <14900002@hpdml93.HP.COM> <1989Nov22.233508.20446@Neon.Stanford.EDU>
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 130