Since the release of the first TOP500 list in June of 1993, the HPC community has been motivated by the competition to place high on that list. We’re now approaching the twentieth anniversary of the TOP500. In recent years, two additional lists have gained traction: the Green500 and the Graph 500. Would a few more lists be useful? Let’s take a look at a some options.

Two Decades of Lists

In June, at the International Supercomputing Conference in Hamburg, the TOP500 list will celebrate its twentieth anniversary. The first list was published in June of 1993 at the Supercomputing 93 Conference in Mannheim. The top 10 entries on that list are displayed below.

The peak performance of the top machine was just under 60 gigaflops. Eight of the top 10 machines were manufactured and sited in the United States, five of those by a now-defunct vendor.

Nostalgia aside, it is interesting to reflect on the impact that the TOP500 list has had, and continues to have, on HPC around the world. While some might argue that the list is too simplistic and fails to capture the true complexity of high performance computers, its beauty also lies in that simplicity. It provides a simple linear ranking of machines by their peak performance at number crunching, as measured by the LINPACK benchmark, in FLOPS (floating point operations per second). It has provided a race that everyone wants to win. Consequently, high placement on the TOP500 list has become a driver on HPC procurements and provides bragging rights and enhanced recruitment power to those at the top.

Green500 & Graph 500 Lists

As was discussed in a previous HPCwire article, the TOP500 List has also spawned at least a couple of additional lists: the Green500, introduced in November of 2007, and Graph 500, introduced in November of 2010. The previously unconstrained race to the top is being complemented by a new form of competition – one constrained by electrical power – and captured in the Green500 list. Here, the measure is energy efficiency and the metric is MFLOPS/watt. Also, data crunching has soared in importance and visibility and is arguably on par with number crunching. Data crunching performance, as measured by an evolving set of kernels from graph algorithms and a metric called TEPS (traversed edges per second), is documented in the Graph 500 list.

These new lists help expand our understanding of machine performance by adding a couple of additional dimensions. At the same time, each list preserves the beauty of the TOP500 list by providing a simple linear ranking. Each gives us a competition to be won. In this same spirit, perhaps we should consider putting a few more HPC dimensions into competitive play. To start the conversation, we’ll propose a few possibilities.

Footprint500

The most capable computers are very large. Housing them is expensive. So, we might want to create a “footprint” measure (actually system volume, but footprint sounds better). The footprint metric could be FLOPS/meter³. Given some agreement on what constitutes the measurable volume of a system, such a Footprint500 list should be relatively straightforward to construct.

For example, let’s make some rough estimates for the RIKEN K Computer, currently at the top of the TOP500 List. The entire K Computer system and all of its supporting equipment are spread across three floors and a basement in its home at the RIKEN Advanced Institute for Computational Science. If we consider only the room in which the computer cabinets are located, it has a floor area of about 3,000 m². The K Computer’s 864 cabinets sit on an areal footprint of 1,600 m². As the cabinets are a bit over 2m tall, this yields a volume of about 3,296 m³. The K Computer’s peak performance is 10,510 Teraflops. Thus, it delivers roughly 3.19 teraflops/m³. How does your favorite machine compare?

Faultless500

The reliability of high-end HPC machines is a significant issue. There are several ways to measure system reliability and this is an active topic of research. A common metric is the Mean Time Between Interrupt (MTBI). So, we’ll use this as a placeholder for whatever more precise metric the community of experts may converge on. MTBI can range as low as days or even just hours for our most capable machines. This is not a good situation and it is expected to get worse as systems grow into the exascale range. In order to highlight the issue and provide positive reinforcement to those who make strides in addressing it, we might create a Faultless500 list. To be fair to the larger, more capable, machines the MTBI metric could be replaced with something like a Mean FLOPS Between Interrupt (MFBI) one.

Motion500

Crunching numbers is fast and cheap, while moving data is slow and expensive. This is the mantra one hears these days. So, maybe we need a data motion metric and a Motion500 list. For example, something like bits/second/distance, where distance represents some set of predetermined traverses of a computing system’s memory space. If the traverses look significantly different for number and data crunching applications, then perhaps there should be two lists. Another approach might be that described by Allan Snavely, associate director of the San Diego Supercomputer Center, as data motion capacity: “Take the capacity of each level of the memory hierarchy in bytes and divide by the access time in cycles and sum this up.”

Satisfaction500

From the end user’s perspective, the time to job completion is very important. Obviously, not all application jobs look alike. For example, we’ve already observed that number and data crunching are claimed to be substantially different. Within each of these categories there is further significant differentiation. So while time to completion may be a good metric for end user satisfaction, there is no obvious simple measure, like LINPACK, to apply. Nonetheless, test suites comprised of collections of complete codes representative of those applications consuming the lion’s share of HPC resources can be assembled and used to measure time to completion for the Satisfaction500 list.

About a decade ago, the Department of Energy’s Office of Advanced Scientific Computing Research commissioned a first attempt at something one might see as similar in intent to a Satisfaction500 list. It was called the Applications Performance Matrix (see screenshot below). Its purpose was to provide “a rich source of information on the performance of high-performance computers applied to real science and engineering problems.”

It may have been an idea ahead of its time, as it seems to have disappeared from the web and only to have survived in presentations, like this one given by Bill Buzbee at the 2004 Salishan Conference.

While the Applications Performance Matrix used real applications codes to measure computer performance, a complementary approach has been taken by the HPC Challenge benchmark. This benchmark attempts to get a more holistic view of computer performance by using a suite of seven tests, presumably abstracted from the requirements of real applications.

What we suggest here is “biting the bullet” and running a suite of “full up” applications codes to completion, under pre-specified conditions, on a large collection of computers. With the emergence of a nascent OpenScience movement (see, for example, the Open Chemistry Project) and the imperatives for openness imposed by the centrality of science to public policy formation, perhaps a common set of real applications captured in open codes, to serve as candidates for such a suite, is now within reach.

List of Lists

If each of the above suggestions were implemented, we’d have seven distinct “500” lists available for analysis and decision making. While each list would contain its own collection of machines, presumably there would be reasonable overlap. In our earlier study of the TOP500, Green500 and Graph 500 lists we found this to be the case and, given an incentive to make the measurements, the intersection of the various lists would surely grow.

So, the ultimate list would be a list of all the lists. Given clear identification of machines, so that they could be unambiguously tracked across lists, the ListofLists500 might help us to better understand the character of various high performance computers, while preserving the linear rankings and competitions inherent in the individual lists. Also, if the ListofLists500 were refined enough and diligently maintained, it could serve as the basis for an HPC “configurator.”

Are any of these lists worth a try? Do you have suggestions for other lists? Let us know what you think.

About the author

Gary M. Johnson is the founder of Computational Science Solutions, LLC, whose mission is to develop, advocate, and implement solutions for the global computational science and engineering community.

Dr. Johnson specializes in management of high performance computing, applied mathematics, and computational science research activities; advocacy, development, and management of high performance computing centers; development of national science and technology policy; and creation of education and research programs in computational engineering and science.

He has worked in Academia, Industry and Government. He has held full professorships at Colorado State University and George Mason University, been a researcher at United Technologies Research Center, and worked for the Department of Defense, NASA, and the Department of Energy.

He is a graduate of the U.S. Air Force Academy; holds advanced degrees from Caltech and the von Karman Institute; and has a Ph.D. in applied sciences from the University of Brussels.