Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ames!pioneer.arc.nasa.gov!lamaster
From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: Computers for users not programmers
Message-ID: <1991Feb14.191020.3580@news.arc.nasa.gov>
Date: 14 Feb 91 19:10:20 GMT
References: <4772@mindlink.UUCP> <1991Feb13.180108.13480@eagle.lerc.nasa.gov> <2933@charon.cwi.nl> <1991Feb14.153747.26911@eagle.lerc.nasa.gov>
Sender: usenet@news.arc.nasa.gov (USENET Administration)
Reply-To: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster)
Organization: NASA Ames Res. Ctr. Mtn Vw CA 94035
Lines: 87

In article <1991Feb14.153747.26911@eagle.lerc.nasa.gov> xxremak@csduts1.UUCP (David A. Remaklus) writes:
>In article <2933@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>>In article <1991Feb13.180108.13480@eagle.lerc.nasa.gov> xxremak@csduts1.UUCP (David A. Remaklus) writes:
>> > >xxremak@csduts1.lerc.nasa.gov (David A. Remaklus) writes:
>(stuff deleted)
>While the CRAY is hardly RISC, I will concede that introduction of

Actually, the Cray-1/X/Y *are* RISC machines.  A little too RISC, in fact, 
since the lack of memory mapping hardware increases swapping overhead when
memory contention becomes a problem.  However, the architecture has a very 
simple instruction set, is a load/store machine, many operations take only one
cycle, can be heavily pipelined.  Just because it has a 512 Word Vector
Register set does not make it non-RISC.  Just think of it as a programmable
cache.  Kind of small, really - only 4 K Bytes.  The cost of swapping the vector
registers is a lot less than most people assume.  (For the record, the Cray-2
architecture *is* a little slower at context switching.  It isn't the same
architecture as the 1/X/Y... series).  Anyway, if RISC means anything at all,
surely the simple instruction set and load/store architecture of the Cray make
it a RISC machine.   I don't, by the way, equate RISC with good, decent, 
wholesomeness, as some do.

I note that a previous poster referred to another machine, the Cyber 205,
as non-RISC.  True - the vector instruction set was a very non-RISC memory-to-
memory design.  Just for the record, the *scalar* part of the 205 is a
RISC design.  For anyone who cares to remember :-)  I am still uncertain as to
whether a memory to memory vector processor is a *good idea* or a *bad idea*,
myself.  On the plus side, vector operations are good candidates for memory
to memory operations (think of all those array processors built that way.)
On the minus side, it complicates pipelining, although ETA seemed to finally
get that aspect under control on the (note: virtual memory) ETA-10... 
The Cray, with its vector register load/store design, is a RISC vector machine.
But, I digress.


>Now an architecture question.  It seems kind of silly to run certain
>utilities on a CRAY.  Even though it can execute a compile or grep or
>edit or etc. very fast, the vector unit sits idle for the time the
>processor spends performing these functions.  Probably worst of all is
>the interupt rate generated by some of these functions.  Especially since
>the CRAY has one of the worst process context switch times in the industry.

In fact, the Cray is decently fast at context switch times.  (A few years ago,
it had the record, but that is no longer true.  It isn't very cost effective,
in context-switches/sec/$, but it is fast.  Fast enough, that it isn't a factor
in a normal Cray workload.

>Is this a necessary evil in order to get effective use of a CRAY or
>wouldn't offloading this work to more 'appropriate' (the definition is
>left to the reader) platforms within that ellusive seamless environment
>be better?

The Cray is *very fast* at editing.  It isn't very *cost effective* at editing.
If that is all that you are buying a machine for.  However, consider that it 
*may* be more cost effective to, for example, change a few lines
of source code, than to copy it somewhere else, change it, and copy it back.  
In any case, it really doesn't matter!  Why?  I have looked at this on our Y-MP,
and so have others in theirs.  A *trivial* number of CPU cycles are expended 
in editing, in actual use.

How fast is the Cray at context switches?  I don't have a good program to
measure it on a fully loaded system during production time, but looking at 
"sar" on our machine during heavy interactive times, 
it appears that, through linear extrapolation, the Cray Y-MP can do
between 2000 and 3000 c-s's/sec/CPU.  Or, perhaps I should say *at least*,
because I don't have a good way to see how much kernel overhead is expended
doing various operations.  I can say, though, that the following problem is
much more significant:


Of more importance to Cray efficiency, doing its normal workload, is the 
lack of memory mapping hardware, which forces the kernel to do a lot of 
copying to fit new processes into memory, or to expand the size of existing 
processes.  It also forces the Cray to swap large memory processes much
more frequently than it should, based on memory availability.  This is 
particularly a problem during heavy interactive use.  

Not editing, mind you, which is a trivial overhead.  But, during "real"   :-) 
interactive supercomputing: e.g. interactive graphics output from a numerical 
simulation.  

The Cray needs an MMU!


  Hugh LaMaster, M/S 233-9,  UUCP:                ames!lamaster
  NASA Ames Research Center  Internet:            lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035    With Good Mailer:    lamaster@george.arc.nasa.gov 
  Phone:  415/604-6117