Newsgroups: comp.parallel
From: prins@cs.unc.edu (Jan Prins)
Subject: Re: Crisis in HPC Workshop - Conclusions (Summary)
Organization: The University of North Carolina at Chapel Hill
Date: 25 Oct 1995 15:38:06 GMT
Message-ID: <46llku$jjl@usenet.srv.cis.pitt.edu>

>Preston Briggs <preston@tera.com> 
>>mccalpin@UDel.Edu (John D McCalpin)
>
>>I am definitely *not* recommending add-on vector processors for
>>commodity cpus, but I am saying that fundamental changes in
>>architecture are needed to enable the machines to better tolerate
>>latency even to their own local memories.
>
>Sure.  But faster context switching, a la the Tera or some other
>multithreaded machine, lets each node do something useful while
>waiting on memory.  Communicating to another node or "communicating"
>to memory -- it's all the same thing.  Latency is a growing problem
>and the way around it is to context switch instead of waiting.
>Assuming, or course, you can context switch quickly -- May's point.

McCalpin's point goes further than latency hiding; for his benchmarks to
score well, the main memory must deliver data at close to the processor's
floating point computation rate.  I don't think any commercial
of-the-shelf microprocessor is capable of operating in this fashion.  Only
the large vector machines (Cray, NEC, Fujitsu, etc.) and the Tera machine
are designed with this principle in mind.

By the way, the vector machines ask you to perform operations on large
enough "chunks" of data (i.e. vectors) to amortize the memory reference
latency, so context switching is not the only way to hide latency.

--\-- Jan F. Prins                   mailto:prins@cs.unc.edu
  /   Dept. of Computer Science      http://www.cs.unc.edu/~prins
--\-- UNC Chapel Hill                tel:+1-919-962-1913

