🚀 go-pugleaf

In article <1991Apr30.163153.18568@midway.uchicago.edu> rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) writes:
>> Comments on Cyber 205, page faults, etc.
>
>I suffered with a Cyber 205 for 6 or 7 years, and I know the machine
>from a scientific user's viewpoint.  For just about all fluids 
>codes, we found virtual memory to be essentially worthless.  For

Cray was quoted once as saying something like (paraphrase):

"If you don't have it (real memory) you can't fake it."

If you look at "Virtual Memory" as an attempt to fake real memory, then,
it won't work.  On the other hand, from the Operating System point
of view, "Memory Mapping" (another name for Virtual Memory) has 
tremendous benefits, particularly if you want even a modest interactive
load.  Otherwise, you either buy twice as much memory as you really need, or,
throw away half you CPU swapping big jobs against each other.  
To some extent, the benefit of virtual memory is invisible to the user.  
If the system has virtual memory, you can run interactively and still 
get very high utilization.  On the other hand, your particular job 
hasn't speeded up.  But, the user benefits due to more throughput/faster 
turnaround/etc.

>out of core codes, we had to manage I/O by hand, and about all
>virtual memory did for us was to enable us to create blocks of
>virtual storage that we could move things in and out of "by hand"

Well, I saw 205 jobs which used the memory mapping I/O functions to achieve
full channel utilization on 8 high speed channels.  I would say 
that I saw virtual memory create great benefits to individual jobs
through this technique (memory mapped files, combined with the "advise"
functions to tell the system what pages you expected to use).  You could
program really fast I/O on that system, and also get an immediate benefit
as soon as more memory was available to the job.

>vs. otherwise.  What made the Cyber a pain to program, and killed it
>vs. the Cray, was that (1) it had a long pipeline, hence a big hit
>for short vectors, which meant that codes had to be rewritten to
>use very long vectors, 

True, this was a big problem.  The benchmarks that ran on the ETA-10 showed
that the long vector startup was not necessary. The ETA-10 had better
instruction overlap with the same basic architecture.

(2) it couldn't execute vector instructions
>unless data was contiguous in memory, so for non-unit strides, you
>had to do scatter-gather.

Yes, this really was the Achilles Heel for this particular Architecture.

>The cache machines, like IBM, also have problems with non-unit
>strides, but I'm finding that using strip-mining, it is relatively
>easy to get around them, provided your algorithm has re-use of
>data.

I have only limited experience with the new, fast-only-in-cache, machines,
but I have to say that the code you need to get optimum performance is
even more non-intuitive than that for the older vector architecture machines.
Even worse, code which was previously optimal for vector machines, and which
was OK on a wide variety of other machines, is now pessimal for these machines.
Sigh...


  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                            #include <std.disclaimer>