How do you know if an HPC system, particularly a larger-scale system, is well-suited for deep learning workloads? Today, that’s not an easy question to answer in the sense there is no widely agreed-upon benchmark or reference architecture for comparing DL performance across systems. A group of researchers led by Tal Ben-Nun and Torsten Hoefler of ETH Zurich has set out to develop Deep500 – a benchmarking suite, reference architecture, and, yes, contest – to provide a meaningful assessment tool for deep learning capabilities on HPC platforms.

“We would like the community to establish good benchmarking practice for large-scale deep learning scientific computing workloads, while still taking the correctness of the end result (i.e., accuracy and generalization) into account,” Hoefler told HPCwire recently. “That is why we created Deep500. This benchmark should be insightful to HPC researchers and supercomputer vendors, but also to the users in computational science who use deep learning as an inference tool. We should thus avoid common pitfalls that accompany measuring performance alone.”

Hoefler and Ben-Nun have set up Deep500.org and organized a well-attended Deep500 BOF at SC18, which featured an expert panel, and served as further outreach to the HPC community. How quickly Deep500 will take shape is uncertain. The researchers are working with other prominent researchers from academia and industry; for example Satoshi Matsuoka, director of Riken Center for Computational Science, and Pradeep Dubey, Intel Fellow and director of Intel’s Parallel Computing Lab, were among the panelists.

Their idea is to create a useful tool not just a vanity trophy. That message came through in force when Matsuoka described in some detail the struggle his group faced in developing procurement criteria for Japan’s AI Bridging Cloud Infrastructure (ABCI) which is intended specifically to handle artificial intelligence workloads. (ABCI was number seven on the most recent Top500).

“If you ever procure a machine, the benchmark will have to be very precise, because if there is any wiggle room, people will cheat. I’m not blaming anyone. People will improvise. Find loopholes. This has always been an issue with benchmarks,” said Matsuoka at the BOF.

“The immediate next step in Deep500,” Ben-Nun told HPCwire, “is to construct a meta-review of how deep learning is used by the scientific community, so that the workload types and their properties are clear. We are organizing a monthly meeting with leading researchers and interested parties from the industry. The meetings are open and posted on the Deep500 website (https://www.deep500.org/). Following that, the next step is to establish a steering committee for the benchmark. It is imperative that we fix the ranking and metrics of the benchmark, as the community is undecided right now on several aspects of this benchmark. We intend to make considerable progress this year, reconvene at SC19.”

Ben-Nun and Hoefler suggest the HPC community response to the Deep500 concept has been positive; there is, they say, widespread recognition of the need for such a benchmark, but there are also significant challenges and differing views on how to solve them. Here are their thoughts on four prominent issues provided to HPCwire recently by email:

• Appropriate Datasets. “First, public deep learning datasets originate from fields such as computer vision, and as an HPC community we must establish datasets that are relevant to scientific computing, including data types and dimensions. Second, image and speech processing datasets are fixed, which makes deep learning a strongly scaling problem and thus inherently limit a supercomputing benchmark, as well as fosters specialization of techniques to specific datasets. Therefore, we need to consider synthetically-generated, relevant datasets as well.”
• Metrics. “As for metrics, there have been several opinions on the matter: is throughput the main ranking criterion, or is test accuracy and overall time-to-solution important? We are open to input from the community, and encourage anyone who is interested to join the meetings.”
• Allowable Methods. “The next open question is the algorithms and methods we allow the competitors to use. This is especially important, since many of the recent advances in distributed deep learning relate to modifying the original synchronous SGD algorithm. Approaches such as gradient quantization, asynchrony, and sparsification currently dominate the field, as the robustness of deep learning still yields satisfactory results. Openness to different methods is important, but as traditional benchmarks measure hardware, they usually leave little room for changing the algorithm itself. To cope with this landscape it is important to know what kind of learning strategies are important for scientific computing and are used for learning at scale.”
• Verification. “Last but not least is the issue of verification. How do we ensure that a result of the benchmark is correct? As opposed to HPL, HPCG, and Graph500, where the result is known, deep learning problems define loss functions and accuracy metrics, whose values vary due to the problem definition (stochasticity, datasets) and applied techniques. As evident in conferences such as NeurIPS (formerly NIPS), reproducibility is very important to the ML community, and we would like to guarantee it in Deep500.”

There are, of course, many (old and new) tests and datasets being used ad hoc to assess machine learning and deep learning capabilities of systems. Most are fairly narrow. One new effort – the MLPerf benchmark suite for assessing training and inference performance introduced last May – has attracted considerable support and recently released its first round of results (see HPCwire article, Nvidia Leads Alpha MLPerf Benchmarking Round.)

As you might expect the BOF conversation was wide-ranging; it covered everything from why such a benchmark is needed, what attributes it should encompass, to strategies for combating inevitable efforts to “beat” the test.

When Matsuoka suggested the new benchmark “should measure through-put and not time-to-solution” an audience member quickly challenged that idea; he recalled an earlier effort focused on throughput “but time-to-solution was so bad that everyone dropped it,” and added that the clever use of cache allowed cheating throughput. Matsuoka agreed but emphasized modern benchmarks need to be scalable for use on different size machines which can influence time to solution.

Clearly much work remains. Regardless, Deep500 efforts are forging ahead. Hoefler, Ben-Nun, and colleagues plan to post a new paper – A Modular Benchmarking Infrastructure for High-Performance and Reproducible Deep Learning – quite soon (Jan. or Feb.) on arXiv, and they whetted the BOF audience appetite with the slide below.

Along with Hoefler and Ben-Nun, panelists included: Dubey; Todd Gamblin (Center for Applied Scientific Computing, Lawrence Livermore National Lab); Tom Gibbs (Nvidia); Thorsten Kurth (National Energy Research Scientific Computing Center, LBNL); Matsuoka; and Jidong Zhai (Tsinghua University). A few of the brief BOF presentations re available on the Deep500 website.

Much of the conversation covered familiar ground but all of it was fascinating. Besides discussion of what a new benchmark should include there were a few snapshots of current DL practices and expectation based on a literature search and a fairly recent NERSC’s ML user survey. Presented below are a few slides from BOF panelists (click on slides to enlarge).

CURRENT DL TRENDS FROM BEN-NUN/HOEFLER
Ben-Nun and Hoefler presented a few snapshots from their literature review – “more than 100 papers” – of DL practices. Perhaps not surprisingly, the GPU use jumped dramatically in the past few years and now dominate. You may also find their paper, Demystifying Parallel and Distributed Deep Learning: An In-Depth Concurrency Analysis, of interest. Below are three of their slides.

NERSC ML USER SURVEY
Kurth of reviewed results of NERSC’s ML user survey which shows and interesting mix of tools being used with most models still run on relatively few CPUs/GPUs. He emphasized the importance of using open exchange formats to accommodate the rapidly changing/evolving ML framework landscape. Here are three of Kurth’s slides.

WHAT’S NEEDED IN DL BENCHMARK – INTEL
Intel’s Dubey emphasized the need for developing a benchmark that scales well, includes TCO, and can act as a proxy for “real-world, forward-looking” applications. Below are four of his slides.