In the third of a series of guest posts on heterogeneous computing, James Reinders shares experiences surrounding the creation of ASCI Red and ties that system’s quadranscentennial anniversary to predictions about the heterogeneous future being ushered in by exaflops machines.

In 1997, ASCI Red appeared on the Top500 as the first teraflops machine in history. It held that spot for seven lists, a record that remains unbroken decades later. Using thousands of Intel microprocessors, it offered additional evidence that massively parallel machines based on “off the shelf” technology would dominate supercomputing of the future – a trend that was not universally endorsed in 1997. It was also not hard to find skeptics that claimed we would never need a petaflops of computing power, and many saw teraflops as only needed for military needs.

Twenty-five years later, exaflops machines offer evidence of trends that will dominate supercomputing of the future. Before I share my predictions of our future, I’ll reflect on how ASCI Red came to be.

ASCI Red

In December 1996, while the machine was still at Intel in Oregon and only three-fourths built, ASCI Red ran for the first time above the one-trillion-operations-per-second rate.

The full system featured 1.2 TB of memory and 9,298 processors (200 MHz Intel Pentium Pro processor boosted later with specially packaged 333 MHz Pentium II Xeon processors) in 104 cabinets. Not including cooling, the system consumed 850 kW of power.

People speak of ASCI Red supercomputer, operated at Sandia for nine years, with a well-deserved reverence. Sandia director Bill Camp said, in 2006, that ASCI Red had the best reliability of any supercomputer ever built.

Why ASCI Red?

Accelerated Strategic Computing Initiative (ASCI), was a ten-year program designed to move nuclear weapons design and maintenance from a test-based (underground explosions) to simulation-based approach (no more underground testing).

By developing reliable computational models for the processes involved over the whole life of nuclear weapons, the U.S. could comfortably live with a Comprehensive Nuclear-Test-Ban Treaty. DOE scientists estimated they needed 100 teraflops by the early 2000s.

Convex, Tombstones, and Execution of Strategies

To build a teraflops machine it was initially believed we would need to do that with a non-Intel processor. Clearly, the floating-point performance of the Pentium processor was insufficient.

In 1994, I visited Convex Computer Corporation to consider if we should use HP processors. Convex pushed HP designs to their limits including over-clocking (long before gamers made this popular). On the patio just outside of the Convex cafeteria, there are more than twenty names etched in cement including Chopp Computer, ETA Systems, and Multiflow. These were all companies that started alongside Convex in supercomputers and failed as businesses.

They explained that these were reminders of the need for more than a great strategy and smart people, you have to actually execute it successfully. Convex cofounder Bob Paluck was quoted in Bloomberg as saying “You’ve got to have a brilliant strategy, and you have to actually execute it. Otherwise, you become a tombstone.”

It fits perfectly with the Andy Grove philosophy drilled into us at Intel that “only the paranoid survive.”

Convex survived and was eventually acquired by HP. While we didn’t select HP parts, I never forgot that Convex graveyard.

Krazy Glew on comp.arch

Intel was the first company to have hardware (the 8087 in 1980) supporting the (then draft) IEEE FP standard. The Intel i860 used a VLIW design to power the #1 supercomputer in 1994, but x86 floating-point remained disappointing for HPC. As a frequent reader of comp.arch on usenet, I was intrigued when Andy “Krazy” Glew from Intel’s P6 wrote “Don’t count Intel out on floating-point” to a flame about Intel floating point being noncompetitive. Andy and I hit it off.

I became the first champion in the architecture study team for using the P6 design. The interest became much greater when the first P6 parts — now called the Intel Pentium Pro — came back and it became apparent we could have 200MHz parts under 40 watts, and that included an on-package L2. The power efficiency, compute density, and costs quickly made it the obvious choice with the entire architecture team.

Comet Shoemaker–Levy 9 and C++

For the most part, C++ had no following in HPC. C++ was not an ANSI or ISO standard (that came in 1998). A notable exception was a group at Sandia, the destination for ASCI Red.

The discovery of Comet Shoemaker–Levy 9 and the realization that it was likely to collide with Jupiter caused great excitement – a never before seen opportunity to observe two significant Solar System bodies collide.

Astronomers and astrophysicists, with scant data to guide them, did not believe the effects of the collision would be visible from Earth. Sandia researchers, experts on high energy impacts, offered a different perspective. Computational simulations by Dave Crawford and Mark Boslough at Sandia, using C++ on an Intel Paragon supercomputer (#1 on the Top500 list at the time), predicted a visible plume rising above the rim of Jupiter. This public disagreement was carried by the media, notably CNN. In the end, the close correspondence between their predictions of a visible plume rising above the rim of Jupiter and the actual plume as observed by astronomers lent even more confidence to the accuracy of the Sandia simulation codes. What an awesome validation!

In a recent book “Impactful Times: Memories of 60 Years of Shock Wave Research at Sandia National Laboratories,” J. Michael McGlaun of Sandia related “We decided to write [c.1990] PCTH[1] in C++ rather than FORTRAN. We hoped to eliminate some coding errors using C++ features.” The results were “a version of PCTH working that demonstrated excellent parallel speedup” that also “demonstrated that we could eliminate many software defects in a carefully written C++ program.”

Sandia and comets helped fuel the interest that set the stage for C++ to really be a serious language on ASCI Red, in addition to the dominant FORTRAN and lesser used C.

Trends for the Future

In retrospect, most trends that would expand over the next twenty-five years were quite evident when you looked at what the needs were in 1997 and what results were coming out of groundbreaking work.

Those trends became even more evident during the life of ASCI Red. The spectacular comet simulations with C++ code was strong evidence of future directions (I can’t imagine writing an adaptive mesh code in Fortran no matter how much I love Fortran). While only defense uses were willing to pay for a teraflops machine, there were plenty of hints that would change including dual-use[2] work at Sandia. The insatiable appetite for performance drove the importance of standardizing message passing (MPI), and then the fattening of nodes with more and more computation at the node level which in turn fueled the need for node level standards (e.g., OpenMP). The topic of security has grown as well as the scope of usage has grown dramatically. Arguably, the least predictable trend was the giant leap in AI usefulness thanks to deep learning algorithms.

In brief, nine notable changes that went from small to big in the past twenty-five year are:

1. The rise in importance of C++.
2. The use of supercomputers for far more than military purposes.
3. Standardization of MPI.
4. Enormous growth of computational power at a node level (fat nodes).
5. Standardization of OpenMP to help with fat node programming.
6. Emergence of AI techniques as an important programming technique.
7. Floating point accelerators (most notably GPUs) to boost performance/watt and density.
8. Open source grew from occasional to ubiquitous.
9. Security has grown from a local concern to one with many surfaces to worry about.

What would our next list look like twenty-five years from now after exaflops systems appear. We already should know that the following nine are in our future:

1. More abstract programming – the rise in importance of Python, frameworks, and more and more abstractions to the point of inspiring thinking such as “No Code.”
2. More uses – supercomputers democratized even more especially as cloud vendors offer supercomputing for all – another vote for abstractions and “No Code”?
3. More programming attention for distributed computing – energized by higher performance interconnects.
4. Heterogeneous computing – fatter nodes get even more diverse thanks to many solutions from multiple vendors plus the mix-and-match that will happen with open chiplet interconnect standards (“new golden age for computer architecture”).
5. Multivendor multiarchitecture fat node programming – requires more open and performance portable solutions.
6. Algorithms matter – emergence of more AI techniques (not just deep learning) as important.
7. Multivendor heterogeneous capabilities to boost performance/watt and density – made more prevalent thanks to open chiplet interconnect standards.
8. Open – continues to expand to support more competition in everything.
9. Security – bigger machines, more simultaneous users, and wide availability make this an ever-growing topic of concern.

Unlike ASCI Red, our heterogeneous future will be multivendor, and multiarchitecture because competition is only growing in this “new golden age for computer architecture.”

Additionally, diversity in hardware demands that performance portability will be critical to the future. When systems were CPU-only, performance portability came about because each generation of CPUs sought to be uniformly better than the CPUs that came before. Every CPU tried to be general purpose. In a heterogeneous world, where specialization is needed for lower power and higher densities, non-CPU compute devices are no longer trying to be general purpose. Any rush to standardize in order to lock in the architectures of today will only serve to undermine the credibility of such a standard.

These nine trends demand we support more variety in hardware and applications, while making it more approachable, faster, and better.

And, unlike in 1997, we need to do it in far more than just Fortran (formerly known as FORTRAN).

“No code” is sounding better and better all the time. Dream on.

[1] PCTH stands for Parallel CTH, CTH stands for CSQ to the Three Halves, CSQ stands for CHARTD Squared, CHARTD stands for Coupled Hydrodynamics And Radiation Transport Diffusion). Learn more about CTH at https://www.sandia.gov/cth/.

[2] Dual-use technologies refer to technologies with both military utility and commercial potential.

About the Author

James Reinders believes the full benefits of the evolution to full heterogeneous computing will be best realized with an open, multivendor, multiarchitecture approach. Reinders rejoined Intel a year ago, specifically because he believes Intel can meaningfully help realize this open future. Reinders is an author (or co-author and/or editor) of ten technical books related to parallel programming; his latest book is about SYCL (it can be freely downloaded here). 

Other articles in this series

Solving Heterogeneous Programming Challenges with SYCL

Why SYCL: Elephants in the SYCL Room