Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!zaphod!uakari.primate.wisc.edu!sdd.hp.com!hplabs!hpda!hpcupt1!rtaheri
From: rtaheri@hpcupt1.cup.hp.com (Reza Taheri)
Newsgroups: comp.arch
Subject: Re: Re: IBM RS6000
Message-ID: <3830014@hpcupt1.cup.hp.com>
Date: 14 Jan 91 17:52:47 GMT
References: <1991Jan10.214122.9506@news.arc.nasa.gov>
Organization: Hewlett Packard, Cupertino
Lines: 29

> 1)   The machines are as fast as other micros on scalar code, and a lot faster
>      on vector code (other things being equal: clock speed, cache, etc. etc).
>      Many of the codes here *are* vectorizable.
> 
> 2)   The machine is very, very bad at context switches.  So bad, that response
>      time becomes terrible with *one* CPU bound background process running.
> 
> Again, this is *hearsay*.  But, I am particularly curious if anyone has any
> insight on 2) above.  Is it as bad as these various sources have reported?
> Does anyone have any numbers on the cost of a context switch?  Is it a
> function of process size, or ...whatever?

    My experience confirms this.  The Dhrystones/SPEC numbers for the
520 scream, but the TPC-B numbers and a multi-user, program development
benchmark (similar to the proposed SDET of SPEC 2.0) I ran put it in
the same class as machines with a fraction of its SPEC 1.0 rating.

    My guess is that this is due to a number of factors rather than a
single one.  IBM set out to design a fast workstation not a multi-user
computer, these machines have very small caches and TLBs for their clock
rate.  This brings about two points: 1) RIOS machines are marketed as
worksations AND as workstation servers.  A good server needs to be
a fast multi-tasking computer.  How good are the RIOS machines as
servers?  And 2) Are there any obstacles in simply increasing cache
and TLB sizes and making context switches faster; i.e. is the slowness
of multi-user performance in the architectute or in the implementation?

Reza Taheri
rtaheri@hpperf1.cup.hp.com