This paper analyzes two memory hot spot problems associated with massively parallel MIMD computers.The jirst is the memory stride problem, which is similar to stride problems found in existing supercomputers.Pseudo-random interleaving, as proposed by Norton and Melton, is the preferred solution.The second hot spot problem occurs in designs that use two separate memory accesses to lock and unlock critical sections (split transaction) and employ a jirst comeljirst serve queuing mechanism for shared memory locations.A bistabilip in throughput brought about by these conditions is analyzed and experimentally demonstrated.Simple equations are presented which predict the throughput at a critical section of code as a function of the number of applied threads.These equations also express the maximum number of threads that can safely be applied without the possibility of stalling.

This paper describes an application implemented on a simulated machine called Horizon. One purpose of this study is to investigate some of the features of a possible future machine (or class of machines) with a view toward deciding, early on in the research cycle, where problems may come up, what features should be added or strengthened, and what proposed features seem to be unnecessary. Another purpose is to learn more about how to program, instrument and debug a shared memory, massively parallel MIMD computer, and to begin to answer some of the questions: What tools does a programmer need to debug this type of machine? How can a programmer know if the machine is performing well? How can bottlenecks be identified? How can the massive amount of instrumentation information be condensed and presented to a user in a way that makes sense?

Horizon is a shared-memory multiple-instruction-stream-multiple-data-stream architecture currently under study. The performance of one Horizon processing element (PE) is quantified by user operations per instruction, the instructions per tick, and the basic clock rate. Assuming there is sufficient parallelism within a problem, the performance of one PE is multiplied by the number of PEs contained in the Horizon system. For a 256-PE Horizon the expected sustained performance is on the order of 50 billion user operations per second for problems with sustained parallelism of 8000 to 12000 instruction streams.>