For years Linpack has served as a reasonably useful benchmark for measuring the capability of supercomputers. That’s because high performance computing has traditionally been geared toward solving mathematically-intensive science problems, like 3D physics simulations. Applications in this domain are mostly an exercise in maximizing floating-point performance, and that’s what Linpack is designed to measure. But data-intensive applications are quickly emerging as a significant new class of HPC workloads. For this class of applications, a new kind of supercomputer, and a different way to assess them, will be required.

That is the impetus behind the Graph 500, a set of benchmarks that aim to measure the suitability of systems for data-intensive analytics applications. The nomenclature references graph algorithms, a core component of this class of applications. A Graph 500 group has been assembled to guide the development of these benchmarks, and has come up with a set of reference implementations. Over the past few months the group has been collecting submissions from organizations interested in benchmarking their systems.

The results of these submissions will be the first Graph 500 list, which will be announced at SC10 this year at a Bird of a Feather (BoF) session November 17. The BoF will be led by Sandia National Labs’ Richard Murphy, a computer architect at the lab, who has led some of the early work in getting the Graph 500 off the ground. We got the opportunity to ask Murphy to talk about the benchmarking effort in more detail and what it means for the HPC community.

HPCwire: To begin with, who is funding and supporting this effort?

Richard Murphy: The Graph 500 is a community effort led by Sandia. It has really been a grass-roots activity that began with an exciting dinner conversation at Supercomputing 2009. A core group of us recruited other professional colleagues, and the effort grew into an international steering committee of over 30 people. Each of the organizations represented has donated the time and expertise of the members of the steering committee.

DOE/NNSA has sponsored a small amount of administrative work in putting together putting together the list, helping to generate the reference implementations, etc., but is doing it as a community service. DARPA, NSF, and other agencies are also represented in the steering committee. Indiana University (IU) is providing computing service. IU, Georgia Tech and the University of Southern California Information Sciences Institute (USC/ISI) produced the reference implementations under contract to Sandia, which has been the major expense of the effort thus far.

Several organizations have contributed to refining the benchmarks, and provided technical expertise on deployment. Several of us chipped in a few dollars after the first dinner at SC09 to register the web site www.graph500.org.

HPCwire: So what exactly does the Graph 500 measure?

Murphy: Strictly speaking, the Graph 500 benchmark provides two computational kernels: first, the construction of an interesting large graph, and second a parallel search of that graph. We measure the execution time of those two pieces, ranked first by the size of the problem solved, then by the time.

More broadly, the goal of the Graph 500 benchmark is to measure the performance of a computer solving a large-scale “informatics” problem. We tend to use the term informatics in the US, but in Europe that’s all of computer science… its more broad than a knowledge discovery problem.

HPCwire: There are quite a few of HPC-type performance metrics out there already, including some that address the data-intensive problem space. What is the motivation behind this one?

Murphy: Most HPC-oriented benchmarks measure performance characteristics that are of traditional importance to the HPC community. While there are other very good data intensive benchmarks, including the DARPA HPCS SSCA#2 benchmark which also performs a graph problem, and more community benchmarks like the Terasort Benchmark for enterprise computing environments, our Graph 500 steering committee was trying to create a benchmark with two goals.

One is a sense of competition by creating a list-based ranking similar to the Top500, which has been tremendously successful at fostering platforms for the HPC community.

The other is a meaningful representation of future informatics applications, with a tie to a broad set of business areas. The hope was that this would be very difficult for conventional architectures, and help drive the community to computers that could better solve large-scale graph problems.

We specify a particular kind of graph because search results change dramatically depending on graph input, so it may be more precise to say that the Graph 500 benchmark is a parallel search over a proscribed graph. In fact, we’ve got six scales of problem — toy, mini, small, medium, large, and huge — and I doubt anybody will be able to solve the huge problem in the first list. We actually added the toy problem based on feedback that all the other scales were significantly challenging on some platforms.

HPCwire: What problem domain is this aimed at?

Murphy: We have identified five major areas in need of this kind of computational kernel: cybersecurity, medical informatics, data enrichment, social networks, and symbolic networks. Many of us on the steering committee believe that these kinds of problems have the potential to eclipse traditional physics-based HPC over the next decade.

Cybersecurity — large enterprises may create 15 billion log entries per day, and require a full table scan with end-to-end joins

Medical Informatics — 50 million patient records, with 20 to 200 records per patient, resulting in billions of individual pieces of information all of which need entity resolution… which records belong to me, you, somebody else, etc.

Data Enrichment — often petascale data sets, a straight forward example being maritime domain awareness with hundreds of millions of individual transponders, tens of thousands of ships, and tens of millions of pieces of individual bulk cargo. These problems also have a lot of different types of input data.

Social Networks — almost unbounded; one example is Facebook.

Symbolic Networks — often petabytes in size, a good example is the human cortex with 25 billion neurons and approximately 7,000 connections each.

As we’ve begun to think about these large data problems, one thing is clear: they are very different from physics problems. Our steering committee has representation from LexisNexis, who as a data company deals with many of these types of data sets as a core part of their business. We’ve also got representation from many of the major computer companies, who see this as an emerging challenge area.

Unlike a typical computation-oriented application, this kind of analysis is often dominated by searching through a large, sparse data set with very simple computational operations. To use the human brain example, each neuron probably only has 50-degrees of freedom or so — 5 or 6 bits of information — but that information is propagated to thousands of additional neurons in a structure with 25 billion neurons overall. A typical 3D physics application, more typified by the TOP500, in the simplest sense communicates along the faces of a cube, which from a data movement standpoint is much easier.

Finally, we hope this will be useful to computer companies. The DARPA Exascale Report concludes that moving data around — not simple computations — will be the dominant energy problem on an exascale machine. Part of the goal of the Graph 500 list is to point out that in addition to the technology making data movement “more expensive”, any shift in the application base from physics to large-scale data problems is likely to further increase the application requirements for data movement. In short, we’re going to have to rethink how we build computers to solve these problems, and the Graph 500 is meant as an early stake in the ground for these application requirements.

HPCwire: Are there specific system architectural features that are especially suited to these types of applications?

Murphy: Performance for these applications is dominated by the ability of the machine to sustain a large number of small, nearly random remote data accesses across its memory system and interconnect, the parallelism available in the machine — more than the performance of a single instruction stream — and the ability for fine-grained synchronization. In some sense, very different requirements from a machine performing a Linpack calculation. In fact, there’s very little compute, other than pointer math and simple comparisons, in this class of applications in general.

HPCwire: Are there any system requirements for a submission? Along those lines, do you expect to attract non-traditional platforms — those that wouldn’t necessarily show up on a TOP500 list?

Murphy: Any system capable of solving the problem is encouraged to compete, and I expect that this ranking may at times look very different from the TOP500 list. Cloud architectures will almost certainly dominate a major chunk of part of the list, and we may find that some exotic architectures dominate the top. I’m curious to see who submits the first time around. The goal in all this is to solve the problem, not require a particular way to solve it. We have released two reference implementations of the benchmark, and hope to have a good cloud reference implementation in the near future.

The only requirements are in the specification we also released, meaning that people are encouraged to target custom environments. We will also happily redistribute custom implementation as reference codes should organizations wish to contribute them.

HPCwire: Do you intend to fold the Graph 500 into any existing benchmark suite?

Murphy: We had a goal this year of producing a very small version of the benchmark for the consideration of the SPEC committee, but missed the deadline. Several of our industry representatives are part of the SPEC committee and will help us create a submission for their consideration the next time the opportunity comes up. We’d very much like to have the benchmark prove its utility. One of the tremendous successes of Linpack in the early days was that Linpack performance corresponded to real application performance for some critical codes. We believe that the Graph 500 benchmark will evolve to demonstrate performance on key codes related to the five business areas listed above.

HPCwire: How do you see the Graph 500 evolving?

Murphy: The Graph 500 steering committee is working to make the tie between data sets in the business areas listed above and the artificial benchmark graphs we generate stronger, which is part of what LexisNexis is helping us to do.

Additionally, we believe there are three key computational kernels: search, the kernel we released this year; optimization, a single source shortest path; and edge oriented, a maximal independent set. We’ve started with one this year to gain some experience in the benchmarking process, and to generate community feedback as we revise the benchmarking process. We envision the first several years of the Graph 500 as a learning process in applications and performance measurement, and plan to release the additional kernels over time.

There are some very difficult questions with those kernels. For example, the edge-oriented kernel we identified is important but amenable to randomized algorithms, and we want to prevent “gaming the benchmark.”

We’re also eager to evolve in the face of community needs. We may have missed an important business area or kernel, and we expect the benchmark to evolve with the application base.