The DARPA HPCS program aims to drive improvements in all aspects of productivity, including performance, but also programmability, portability and system robustness. These goals are closely aligned with Cray's own goals and historical direction. Our HPCS initiative, called Cascade, exploits Cray's strengths in designing balanced, robust architectures that enable high performance and high productivity on challenging, capability-class HPC problems.
This class of problems is especially likely to produce breakthroughs that can be of great strategic, scientific and economic importance. Two of many current examples include the ITER (International Thermonuclear Experimental Reactor) project, which aims to tame plasma energy so it can later be used to produce almost limitless supplies of clean electricity; and the global IPCC (Intergovernmental Panel on Climate Change) collaboration, which is helping to predict the effects of global warming and model scenarios for mitigating these effects. Cray supercomputers are performing substantial portions of the computation for ITER and IPCC today.
Cascade also leverages Cray's decades of experience as a successful technology test bed in collaboration with the U.S. Government (recent examples: the Red Storm program for DOE and Sandia; the Cray X1E program for DoD).
Cascade Goal: Trans-Petaflop Sustained Speed on Challenging Applications
In the global pursuit of petaflop computing speed — the United States, Japan, China and France are all targeting this goal around the end of the decade — we can expect a progression of milestones. There will be the first peak petaflop, the first Linpack petaflop, the first sustained petaflop on “embarrassingly parallel” applications, and finally the first sustained petaflop on challenging applications. Cascade is designed to provide trans-petaflop speed on challenging applications, and if Cray is selected for Phase III of HPCS, we think Cascade will be the first to reach this important milestone.
Cray systems built with the same design philosophy were the first to break the sustained gigaflop (1989) and sustained teraflop (1998) barriers on full 64-bit applications. For ITER, IPCC and other key initiatives, our Cray XT3 MPP systems and Cray X1E scalable vector supercomputers are providing unprecedented results today by efficiently scaling performance on challenging single applications to thousands of processors at customer sites.
Achieving high performance, however, is only part of the productivity story. Today, supercomputing sites often spend more on software development than on hardware. Reducing the time needed to write, tune, debug and maintain HPC applications is therefore critically important.
The current de facto standard for writing HPC applications is MPI, the Message Passing Interface. Writing applications in MPI requires breaking up all the data and computation into a large number of discrete pieces, and then using library code to explicitly bundle up data and pass it between processors in messages whenever processors need to share data. It's a cumbersome affair that distracts scientists from their primary focus.
Once an application is written, it's generally a time-consuming process to debug and tune it. Traditional debugging models just don't scale well to thousands or tens of thousands of processors (try opening up 10,000 debugger windows, one for each thread!). Trying to figure out why your application isn't getting the performance you think it should is also exceedingly difficult at large scales. Traditional profiling and even sophisticated statistics-gathering may be insufficient to ascertain why the performance is lagging, much less how to change the code to improve it.
Perhaps the biggest drain on productivity, however, is the time spent trying to structure an application to fit the attributes of the target machine. If the machine is a cluster with limited interconnect bandwidth, for example, the programmer must carefully minimize communication, and make sure that any sparse data to be communicated is first bundled together into larger messages to reduce communication overheads. If the machine uses conventional microprocessors, care must be taken to maximize cache re-use and eliminate global memory references, which tend to stall the processor. In other words, if your machine looks like a hammer, then you'd better make all your codes look like nails! This can lead to “unnatural” algorithms and data structures, which significantly reduces programmer productivity.
The Cascade Approach
The Cascade project addresses each of the barriers to productivity identified in the previous section. We provide several high-productivity programming models that significantly ease the burden of parallel programming, and innovative debugging and performance tuning tools specifically designed for very large-scale computing. These all execute on a scalable, high-bandwidth system, with globally addressable memory and heterogeneous processing technologies providing fast serial execution, massive multithreading, vector processing and FPGA-based application acceleration. The hardware and software combine to support Cray's vision of “adaptive supercomputing”, where the system adapts to the application rather than requiring the programmer to adapt the application to the system.
The first step toward higher productivity is providing easier ways to program HPC machines. We of course support MPI for legacy purposes, but we provide several alternatives that are facilitated by the globally addressable memory. Two programming languages that have been gaining momentum in recent years are Unified Parallel C (UPC) and Coarray Fortran (CAF). These variants of C and Fortran allow programmers to reference memory on remote nodes as easily as referencing memory on the local node. Problems are still broken up into multiple pieces, but data sharing is much more natural, and communication overhead is much lower. UPC and CAF programs are simpler and easier to write than their MPI counterparts, and look much closer to the serial code that most programmers are familiar with.
We're also developing the Global View programming model that takes these advantages another giant step forward. Global View programs present a single, global view of the program's data structures, and begin with a single main thread. Parallel execution then spreads out dynamically as work becomes available. A typical reaction to a program written in the Global View style is, “Gee, I didn't realize that was parallel code!”
Cray is developing the Chapel high productivity language as part of our Cascade program. Chapel provides a number of high level data and work abstractions, including support for graphs, hash tables, sparse arrays, and iterators. A unique and powerful feature of Chapel is the ability to separate the specification of an algorithm from structural details of the computation, including data layouts, work decomposition and communication. This significantly simplifies the creation of the basic algorithms, and allows these structural components to be gradually tuned over time.
Cray's programming tools effort is centered around a few powerful concepts that reduce the complexity of working on highly scalable applications. The Cascade debugger solution will contain innovative features that focus on data rather than control, support application porting, and allow scaling commensurate with the application.
The Cascade performance analysis tools gather information using an extensive web of hardware performance counters and software introspection techniques. The tools analyze and synthesize performance data, presenting the user with insight, rather than statistics. The intent is to act as a parallel programming expert, providing high-level feedback on program behavior, and suggestions for program modifications to remove key bottlenecks or otherwise improve performance.
Cascade includes an integrated user environment (IDE), which allows the tools to seamlessly interoperate and provides various forms of context-specific help to the programmer. Of course, all of the tools users are familiar with in the Linux/AMD64 environment are also available, providing a comfortable environment for the occasional programmer, and those with commodity cluster backgrounds.
Balanced Hardware Design
Building a highly productive computing system requires special attention to hardware as well as software. The most crucial consideration is that of balance. It is far too easy to build an unbalanced machine, which may perform well on embarrassingly parallel applications, or achieve high Linpack numbers, but fail to perform well on challenging applications or diverse workloads.
A balanced hardware design complements processor flops with memory, network and I/O bandwidth, and provides architectural support for using all of the system resources efficiently. This is important not just for scalable performance, but also to improve programmability and breadth of applicability. Balanced systems also require fewer processors to scale to a given level of performance, reducing failure rates and administrative overhead.
A key challenge to achieving petaflop scale performance is providing adequate global system bandwidth. The Cascade program is attacking this problem on two fronts: signaling technology and network design. While bandwidth among chips on a board is important, the real issue is providing global bandwidth among tens of thousands of processors spread across dozens of compute cabinets. Our goal is to provide truly massive global bandwidth at an affordable cost.
The Cascade system architecture is designed to efficiently leverage the system's bandwidth. A key part of the design is a common, globally addressable memory across the whole machine. Direct global memory access allows very efficient, low-overhead communication. Accessing remote data is as simple as issuing a load or store instruction, rather than calling a library function to pass messages between processors. This also allows many outstanding references to be overlapped with each other and with ongoing computation. Imagine having to call library functions to access data in your local processor's memory. No one would stand for this, yet we are currently living with this restriction to access global memory on most HPC machines today!
Of course, providing shared global memory and high system bandwidth doesn't help if the processors are not highly latency tolerant. Microprocessors today simply aren't designed to tolerate the latencies in petascale systems (with good reason: the HPC market is small compared to the commercial and desktop markets for which these processors are designed). In addition, they generally don't have physical addresses large enough to address petabytes of memory, or address translation capabilities able to map large amounts of memory concurrently. This is why most HPC systems today fall back on a message passing model in which the processors don't have to deal with off-node data access.
Cascade builds upon the work that Cray pioneered with the Cray T3ETM massively parallel system in the late 1990s. We use the best-of-class microprocessor and surround it with custom communication technology that allows it to directly access global memory with very low overhead and at very high data rates. Hierarchical address translation allows the processors to access very large data sets without suffering from TLB faults.
AMD's Opteron will be the base processor for Cascade, building on our Opteron experience with today's Cray XT3 and Cray XD1 systems. In November 2005, Cray and AMD announced an agreement that extends our successful relationship through the end of the decade. Cray will continue to use AMD Opteron processors for the microprocessor-based supercomputer products we develop during this period. The two firms are also actively collaborating on Cray's Phase 3 proposal for the HPCS program.
Multiple Processing Technologies
While the AMD Opteron processors provide excellent performance on a wide variety of applications, they are not the best suited for all problems. There is a growing realization that, when it comes to high performance computing, one size does not fit all. This brings up another key aspect of the Cascade design: heterogeneous computing using custom processing technologies.
Recent developments in integrated circuit technology and processor microarchitecture have led to a significant reduction in the rate at which conventional processor performance has been improving. As an industry, we've wrung out most of the performance from deeper pipelining and more complex microarchitectures, and we're now facing wire delay and heat issues that are making it very difficult to speed up single processors. The result is that processor vendors are turning to multi-core processors, which further stresses processor-memory balance issues, and drives up the number of processors required to solve large problems.
This has renewed interest in specialized computing technologies that are able to extract more performance out of the transistors on a chip with less control overhead. Vector processing and field programmable gate arrays (FPGAs) are two promising technologies to do this. Both of these technologies allow higher processor performance, with lower power, on a subset of HPC applications, and reduce the number of processors required to solve a given problem.
Finding a way to better tolerate memory latencies is also of critical importance as system sizes continue to grow. On the most challenging applications, conventional processors may spend the majority of their time stalled, waiting for memory references to complete. Vector processors tolerate memory latency extremely well, and as a result, fit very comfortably into scalable machines.
Multithreading is a technology that allows a scalar processor to rapidly switch contexts, keeping multiple memory references in flight even if each individual thread can have only one. Microprocessor vendors are beginning to adopt multithreading to improve latency tolerance, but only at the modest levels required in desktops and servers (two to four threads per processor).
Cray has experience designing multithreaded processors with many more threads per processor. These processors are capable of tremendous speedups on applications that have abundant parallelism, but that cause conventional processors to stall due to pointer chasing or irregular, non-local memory reference patterns.
The ability for specialized processor technologies to speed up certain applications has led Cray, and others, to design custom computers specialized for certain types of workloads, and has led computing centers to buy multiple machines with different characteristics. Users then have to decide which machine to use to solve a particular problem. The Cascade design, on the other hand, will combine multiple computing technologies into a single system, allowing each to be applied when appropriate to accelerate a given problem.
The Cascade system will include pure scalar nodes, based on Opteron microprocessors, as well as nodes providing vector, massively multithreaded, and FPGA-based acceleration. In addition to providing multiple types of computing nodes, we are designing nodes that can adapt their mode of operation to the application.
Cray is taking a comprehensive approach to heterogeneous processing in our Cascade program. Multiple processing technologies share a common, globally addressable memory, with a very large global bandwidth. The user logs into a single system, and sees one global file system. When a program is compiled, the compiler analyzes the code to determine which processing technology best fits the code, and compiles the code accordingly. Then when the program is executed, scheduling software automatically deploys the code on the appropriate nodes. These capabilities all contribute to Cray's long-term vision of “adaptive supercomputing,” where the system adapts to the user's code, rather than requiring the programmer to adapt the application to the particular attributes of the system.
Adaptive supercomputing means that Cascade will optimize time-to-solution and user productivity by creating “glove fit” matches between the attributes of applications and the customizable menu of processor types within the Cray system. Heterogeneous processing systems will also be easier to program. Programmers will no longer need to restructure their code to avoid making global memory references, or worry about the small portion of their code that doesn't fully vectorize.
In a sense, a Cascade system will provide an HPC datacenter in a box, by replacing a collection of special purpose machines with a single system. But it is actually a more powerful concept, because of the common interconnect and global memory that the processors share. Increasingly, industrial and scientific users are building complex applications by coupling together different components that must communicate closely. Cascade will allow each of these components to run on the optimal processing technology within the same system, improving upon what could be done with a homogeneous system or a collection of separate systems. The Cascade compiler will allow us to perform the same optimizations to individual loop nests within a single program, transparently optimizing performance in a way that could not be done with a collection of individual machines.
Cray, like the other participants, is nearing the end of Phase II of the HPCS program. We've spent the past three years refining our plans for the Cascade system, and recently presented those plans to the DARPA review panel at the two-and-a-half day long Preliminary Design Review. We're working with our partners on the Phase III proposal now, and preparing for full-scale product development.
Because our corporate focus is solely on supercomputing, the Cascade program is central to our product roadmap going forward. Cascade will be implemented as a series of steps. We currently support varied computing needs with a set of individually architected machines. In 2007, our follow-on machines will be coupled together, creating a unified user environment and file system with the ability to launch applications on different processor types. The Cascade system, to be prototyped in 2010, will tightly integrate all the processing technologies into a single system and provide the adaptive software to make the underlying heterogeneous processing transparent to the user. We believe the Cascade design will provide a major improvement to productivity, maximizing performance while minimizing programmer effort, especially for the increasingly challenging problems (multi-physics, multi-scale) and mixed workloads of today and tomorrow.