Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: comp.arch
Subject: Re: Why is SPARC so slow? [long, mo
Message-ID: <28200079@ccvaxa>
Date: 23 Dec 87 17:05:00 GMT
References: <1162@winchester.UUCP>
Lines: 27
Nf-ID: #R:winchester.UUCP:1162:ccvaxa:28200079:000:1372
Nf-From: ccvaxa.UUCP!aglew    Dec 23 11:05:00 1987


>If you are testing the performance of a specific system configuration (CPU,
>memory, disk, OS, etc, etc) fine, do so.  If you are addressing the 
>performance of the CPU/FPU/cache (which seems to be what is discussed in this
>group), don't use those benchmarks or at least try to factor out the 
>peripheral/OS/whatever differences.
>
>     	Randell Jesup			Lunge Software Development

I very much disagree - I/O system architecture should be just as much the 
topic of the comp.arch newsgroup as CPU and memory system architecture.
The problem, of course, is that there are more varieties of I/O systems.
Which is one of the best reasons for discussing them.

I do not mean to compare things like the Berkeley Fast File System 
with a CP/M disk layout. But, incidents like the report that BSD filesystem
performance can actually go down with a disk cache are appropriate
(smart SW/smart HW don't always mix). As is anything that talks about
faster I/O, since I/O is the bottleneck on too many systems.


Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
aglew@mycroft.gould.com    ihnp4!uiucdcs!ccvaxa!aglew    aglew@gswd-vms.arpa
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.