Crisis in HPC Discussion - Jan Prins, UNC

Newsgroups: comp.parallel
Subject: Re: Crisis in HPC Workshop - Conclusions (Summary)
From: prins@cs.unc.edu (Jan Prins)
Date: 25 Oct 1995 15:38:06 GMT
Organization: The University of North Carolina at Chapel Hill

>In Article 12257, Preston Briggs  writes:
>>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