With each release of the Top500 list, more attention is directed at the relevancy of the ranking and the associated Linpack benchmark. As the HPC community expands, many vendors and users are openly questioning the significance of Linpack as a useful metric for determining supercomputer performance. In a recent HPCwire article, Stephen Wheat, Senior Director of Intel's High Performance Computing Platform Office, offered some of his ideas on this topic.

Recently, we got the opportunity to ask Doug Miles about his thoughts on the Top500. As the director of Advanced Compilers and Tools at STMicroelectronics, Doug has primary responsibility for managing The Portland Group Compiler Technology business unit. He has been involved in high performance technical computing since 1985 and has a unique perspective on the application side of HPC.

In this Q&A, Doug discusses the significance of the Linpack benchmark and what it actually measures in today's HPC systems.

HPCwire: Do you think the Top500 is useful for companies looking to evaluate the performance of HPC systems?

Miles: In the 1980s, the Linpack 100 benchmark was used to measure achievable compiled performance on supercomputers. Shared-memory parallel systems could auto-parallelize Linpack 100. Performance on this benchmark was widely regarded as a way to rank the world's fastest available vector-based or microprocessor-based computer systems.

In the late 80's and early 90's, it became popular to market so-called massively parallel systems based on theoretical peak performance. These theoretical peaks far exceeded achievable compiled performance. These massively parallel systems could not run Linpack 100, or any other benchmark that required automatic optimization by a compiler. However, continued efforts by vendors, and especially by the HPC user community, proved that MPPs could be used effectively as supercomputers. A revised benchmark was needed.

In 1993, a scalable version of Linpack called HPL was developed to measure the fastest computers in the world. It allowed comparisons of achievable compiled/library performance on all types of supercomputers, and quickly replaced Linpack 100 as the most widely quoted HPC benchmark.

While it is not ideal, the HPL benchmark is still useful in that it provides a real measure of achievable performance on an algorithm fundamental to HPC using a benchmark that is quick and easy to run and verify on any of the currently viable supercomputing platforms.

HPCwire: Does the Top500 still serve a useful purpose in measuring the performance capability of HPC systems?

Miles: By no means does HPL thoroughly characterize the performance capability of an HPC system. However, it is incrementally better than theoretical peak performance.

HPCwire: If those looking to acquire HPC systems don't look to the Top500 as a benchmark comparison, what would they use?

Miles: While neither Linpack 100 nor the HPL benchmark were or are sufficient as a comprehensive measure of overall capability of a supercomputer, two subtle and perhaps unintended changes occurred in the transition from Linpack 100 to HPL.

First, when scaled to a very large problem size, the HPL benchmark becomes almost entirely dependent on performance of the DGEMM matrix multiplication LAPACK library routine. The consequence of this dependence is that HPL essentially measures hand-coded matrix multiply performance. While this is relevant to certain application areas -- absolutely critical to some! -- it provides a narrow view of the overall capabilities of a supercomputer. And it is no measure whatsoever of the compile-and-go performance measured by Linpack 100, which demanded efficient auto-parallelization capability of both a system and the compiler, and did not allow any hand-coded assembly. This limitation has long been widely acknowledged.

Second, the Top500 list is a measure of the performance of computers actually owned by HPC end-users, whereas Linpack 100 was a measure of the performance of computers that could be delivered by HPC system builders. This change has resulted in a very unhealthy development. HPC customers, and even governments, measure prestige by rankings in the Top500 list. An organization's ranking in the Top500 list has become de-rigueur in any HPC center overview. The prestige of a high ranking has become so great that some purchase decisions appear to be influenced by a desire to achieve a high Top500 ranking when they should be influenced only by factors that maximize the amount and efficiency of the targeted workload achievable on the chosen system.

The keepers of the Top500 would do HPC a great service by using their influence to supplement the Top500 with a list that helps reverse these developments and provides a more comprehensive view of HPC capability at the same time. In particular, they could use a wider set of benchmarks, such as HPC Challenge or SPEC HPG to devise a ranking of the top 10 or 20 fastest "models" of computers available for purchase from HPC System builders, released concurrent with the Top500 every 6 months. This list would be much more valuable as a measure of the overall capabilities of currently available systems.

If a given HPC customer proposes to buy a system with a low (or non-existent) top 10 ranking in pursuit of a high Top500 ranking, presumably the right people holding the purse strings on those procurements will ask the right questions.

HPCwire: What is the biggest challenge today in really understanding the performance one can expect from a particular system?

Miles: Today, the multi-core issue is almost certainly the biggest challenge to understanding the kind of performance you can expect. As in the early days of Massively Parallel Processing, many observers seem to assume that two cores are twice as good as one, and four is twice as good as two. Some vendors advertise performance results based on throughput benchmarks that fit almost entirely in on-chip cache, with very fine print detailing the benchmarks used to measure multi-core performance improvements.

When multi-core CPUs become prevalent in HPC systems, end-users are likely to find that placing multiple MPI processes on a chip with no other changes to their code won't be very efficient for a lot of applications due to memory bandwidth constraints. CPU designers, system builders and compiler writers all need to work together toward systems that recognize this issue, and ensure maximally efficient use of the most precious and expensive HPC resource -- memory bandwidth. That is a key focus here at PGI right now.

-----

Doug Miles has been working in high performance technical computing, primarily from an applications perspective, since 1985.  He held various positions in math library development, applications engineering and technical marketing at Floating Point Systems from 1985 until 1993, when he joined The Portland Group (a.k.a. PGI). At PGI, Doug worked as a technical liaison between end-users and the compiler engineering team from 1993 until 2000, when The Portland Group was acquired by STMicroelectronics.  From 2000 through 2002, he was the engineering project manager on an ST-internal project to create a set of optimizing C/C++ compilers for STMicrolectronics' line of ST100 digital signal processors. In early 2003, Doug became the Director of Advanced Compilers and Tools at STMicroelectronics, and assumed primary responsibility for managing The Portland Group Compiler Technology business unit.