Superconducting Technology Assessment - nitrd

Software Considerations
Program execution models are implemented in both hardware and software. To effectively evaluate a novel system
architecture, it is necessary to map applications onto the execution model and develop an understanding of how
the software runtime system would be implemented. If applications cannot be expected to exhibit high performance
on the execution model, there is little point in attempting to build a supercomputer that would implement the model.
Software has been—and continues to be—a stumbling block for high-end computing. Developers have had to
cope with SPMD (a program is replicated across a set of nodes, each of which processes its own data interspersed
with data transfers between nodes) execution models that force them to explicitly deal with inter-processor
communications and the distribution of data to processing nodes. Distributed memory systems have required
message passing between nodes; shared memory systems have required explicit synchronization to control access
to shared memory. Either way, it may take as much time to develop and test the communications infrastructure as
it does to develop and test the core processing logic in an application.
In order to lessen the pain of communications programming in parallel applications, the communications APIs hide
knowledge of the underlying hardware topology from applications. While this does contribute to ease of programming,
it also effectively prevents the application developer from constructing an optimal mapping of the application to
the underlying hardware. This is unfortunate, given the fact that bandwidth is limited, and that both bandwidth
utilization and message latencies are strongly affected by the mapping of the application to the hardware.
New approaches to software tools and programming models are needed to take advantage of the execution models
developed for RSFQ-based supercomputers. Further, these tools are best developed in parallel with the hardware
and system architectures to provide feedback during that development. This approach reduces the risks associated
with systems that are both innovative and costly.
The Tera (now Cray, Inc.) MTA provided and excellent example of this approach. By directly supporting multiple
threads per processor in hardware, threads became a ubiquitous feature of the programming model, and
synchronization (the MTA is a logically shared-memory architecture) was necessarily supported at the hardware
level. Since these features were ubiquitous, they were supported by the compilers and other elements of the
development tool chain. The compiler support was good enough that developers could provide “hints” to the
compiler for tuning parallel applications instead of having to develop (possibly inefficient) communications
infrastructures for their applications.
165