With machine learning and deep learning storming into the datacenter, the new challenge is optimizing infrastructure choices to support diverse ML and DL workflows. How many accelerators do you (really) need? Which interconnect scheme works best? How do various frameworks compare on different compute architectures? When can you choose less expensive CPUs and rely on the GPUs to do the magic? How different are the needs of training versus inferencing?

“There is no one server that does the job perfectly well,” said Ramesh Radhakrishnan, distinguished engineer, Dell EMC, to a packed session[I] at GTC last month. “You see a variety of servers used to execute these kinds of workloads.” Precisely to this point, a flurry of benchmarking tools is emerging to help make sense of ML/DL performance requirements and optimizations. There’s the Deep500 with grand ambitions but still very nascent and aimed mostly at very large scale systems. There are early movers – DeepBench, TF_CNN_Bench, and DAWNBench, for example – with typically narrower strengths and notable shortfalls. More recently, MLPerf has started emerging as popular tool that borrows from those coming before it.

MLPerf, a broader ML/DL benchmarking effort supported by industry and academia, is gaining a foothold at least for assessing training workloads. In his GTC session, Demystifying Deep Learning Infrastructure Choices Using MLPerf Benchmark Suite, Radhakrishnan took the audience on a test drive through MLPerf by presenting performance data from testing on four different systems (1-to-8 GPUs) with differing topologies He also offered comments about the other benchmarks and their contribution to progress so far.

Yes the GPUs profiled are all from Nvidia and the systems from Dell EMC – the occasion was GTC after all – but Radhakrishnan’s even-handed approach made for a solid primer. At HPCwire’s request, Nvidia agreed to make the link to Radhakrishnan’s streamed session public ahead of schedule and in time for inclusion in this article. It’s 44 minutes well-spent for those seeking a MLPerf overview. A few of the session highlights are covered here along with key slides from Radhakrishnan’s session.

Given the sudden rise of ML and DL it is perhaps not surprising that benchmarking tools have started sprouting. Each has value. “[Take] TF_CNN_Bench (TensorFlow convolutional neural network benchmark), for example,” said Radhakrishnan. “It’s very commonly used and people use it for different types of GPUs and it works well but is focused on a single domain, convolutional networks. If you are deploying a translation-based network that’s using RNN (recurrent neural networks), can you take the same observations that you made using a CNN (convolutional neural network) and assume the same thing for your other model? [No], there’s going to be differences. So you want to have a wide coverage on domains.”

DeepBench from Baidu does cover different domains. “It is primarily used for measuring the performance of the core operations that happen in your neural networks. [It has] CNN and RNN coverage [but] if you want to look at system level performance, this is not a tool for that. It doesn’t account for software frameworks, it doesn’t account for distributed training – you need the right set of tools for that,” noted Radhakrishnan.

Enter MLPerf. Early last year, “the folks that introduced DAWNBench from Stanford University worked with Google, Baidu, AMD, Intel and others to come up with MLPerf. This addressed a lot of shortcomings in previous benchmarks. It has coverage of different domains. In terms of metrics it borrows from DAWNBench, which uses execution time to [attain accuracy]. You are using Docker containers and producing all the information needed along with providing data sets so anyone can reproduce these [MLPerf] results,” said Radhakrishnan.

Importantly, emphasized Radhakrishnan, MLPerf has extensive support from industry and universities. At this writing more than 30 companies and roughly ten academic institutions are listed on the MLPerf website. This is key to culling out bias and driving MLPerf’s ability to make fair comparisons between systems or between two different ML/DL elements, according to Radhakrishnan. It also gives the organization “freedom to enable innovation to happen.”

So what is MLPerf? The organization describes it as, “A broad ML benchmark suite for measuring performance of ML software frameworks, ML hardware accelerators, and ML cloud platforms.” The current release, version 0.5, has five different domains: image classification, object detection, language translation, reinforcement learning, and recommendation. The MLPerf metric of choice – speedup – is the amount to time that it takes train a neural net model in these domains to state of the art target accuracy.

You can see the models used for each domain on the slide. Generally they represent state of the art models said Radhakrishnan – ResNet-50 used in image identification, is a deep (50 layer) residual neural network introduced in 2015. RNN GNMT (Google Neural Machine Translation, introduced in 2016) and Transformer (an NLP approach introduced in 2017) are likewise leading edge. One of MLPerf’s goals, said Radhakrishnan, is stay very current.

“It’s a very agile development model. There were actually seven or eight domains initially considered; these five made it [into the spec], but you can definitely see more domains being added and those models being refreshed based on what’s current and state of the art,” he said. “MLPerf is definitely a needed tool today and [we’re] really excited about looking to see how it changes over times and expands and adds domains as. It covers training now but I think they are really close to releasing the inference workload as well.”

The first MLPerf published results were in December. Nvidia, no surprise, trumpeted its strong performance. (See HPCwire article, Nvidia Leads Alpha MLPerf Benchmarking Round.) Radhakrishnan suggested those results didn’t have enough data points to examine some of the questions Dell EMC and colleagues at the University of Texas (College of Engineering) were interested in. His slide deck, which will be available soon, is good way to get a fast overview of the exercise.

“What we did in our work is actually run MLPerf against a wide range of platforms, GPU platforms, starting from a workstation with a single CPU and two GPUs, all the way to [a server with] eight GPUs. We decided to do a whole suite of tests ranging across scaling, comparing different GPU models, and looking at interconnect technologies whether it is PCIe or NVLink to help answer some of those questions,” he said.

Shown below is a kind of summary slide showing system performance based on number of GPUs used. The MLPerf score is how much faster the system executes compared to the MLPerf reference “which in this case is a single P100 instance and that P100 is not very well optimized either,” said Radhakrishnan. The smallest machine, based on Quadro GV100, scored 14.

“The score of 14 means this two-GPU platform ran 14 times faster than one P100.  However you should not make the assumption you are going to see that speed difference between P100s and GV100s every time. What this lets you do is you can actually calculate, because now that your baseline is the same, you can make the assumption that an eight-GPU platform performs four time more efficiently than my two-GPU platform. So you can make assumptions on scale. We are seeing some of the benchmarks scale linearly, so something like SSD (single shot multi-box detector) and other image classifications, get really good speed up going from two-to-four-to-eight GPUs. Some of the other benchmarks, recommendation and translation, don’t see that same efficiency and scale,” he said.

The tasks/features outlined in orange in the slide below are the areas benchmarked by Dell EMC.

“One question which always comes up is which framework should I use. Since there is so much information on Tensorflow from Google and Mxnet from Nvidia, we took those two submissions (from the initial MLPerf 0.20 run) and recreated those runs. We did this on a four-GPU NVLink platform, and plotted accuracy against time. Mxnet actually completed the target accuracy in about 245 min whereas TensorFlow took about 265 minutes. One of the reasons they are so close to each other is they take advantage of the Nvidia cuDNN library. In this case we actually looked at the GPU kernels that were being implemented and found that here were eight kernels called by both of these frameworks, they were exactly the same kernels, and they account for about 40 percent on average, of the execution time,” said Radhakrishnan.

For the purposes of his presentation, Radhakrishnan introduced two hypothetical characters Dave, a data scientist concerned only with performance, and Sally, a datacenter infrastructure manager concerned with cost, efficiency, and satisfying diverse constituencies. He discussed how their needs differ and how MLPerf can inform both.

“I showed Dave these results and he said “are you sure your Mxnet is optimized and running properly because I thought tensor flow was slower?” He was right in one way. Because this part of the submission that was done used TensorFlow version 1.12 [which] introduced XLA compiling. What XLA compiling does is basically does tensor fusion where it takes the graph and optimizes some of the optimized kernels that for your particular infrastructure, right, or your GPUs. So when we ran the same run without XLA compiler enabled, it actually took almost 200 minutes longer. One key takeaway is to make sure you are using the right optimizations, so no matter what you have underneath. If you aren’t taking advantage a compiling or using the right options you are going to leave a lot of performance on the table,” said Radhakrishnan.

One interesting result was the dramatic impact being able to use mixed precision during training. Radhakrishnan’s team looked Tesla V100-PCIe performance when used in precision and mixed precision modes.

“With Volta you get the capability of using mixed precision training. What this means is it uses a technique where it combines half-precision floating point and single-precision in order to improve performance and keep the same accuracy you get in your single precision frame. In addition to memory savings, you are also using dedicated hardware on V100s to do 4×4 matrix multiplies. However, there are some coding changes involved to take advantage of this,” noted Radhakrishnan.

As is shown in the slide below, it is worth the effort. Here improvements of roughly 150 percent to 330 percent were achieved. “A Resnet-50 job on an eight-GPU system that runs in about ten minutes if you take advantage of mixed precision; if you don’t it take advantage of it, [it takes] close to 500 minutes. After I prepared this slide yesterday, Jensen Huang (Nvidia CEO) announced you are getting this with practically just one or two lines change in your code. There’s an API exposed and once you enable that, it does different things you are supposed to do to make sure you still maintain the same accuracy,” said Radhakrishnan.

Radhakrishnan presented results from four different interconnect schemes including use of NVLink with GPUs using SXM2 form factor (permits high clock rate), use of PCIe switches, and PCIe standalone. Radhakrishnan noted the last arrangement (scheme on far right of slide) allows users to take a container “pin it to a CPU and then use a GPU” and that this provides the best CPU-to-GPU bandwidth and that’s useful for some applications though he didn’t specify examples.

“If you look at how machine learning performs across all of these designs. If you look at translation benchmarks you see that improves performance by anywhere from 40-to-50 percent and when you look at it in terms of minutes, that’s 20 minutes and 30 minutes. It is a sizeable improvement when you actually look at the percentage. There’s [also] improvement for MaskRCNN. When it comes image classification, you are seeing that the peer-to-peer capability provided by the PCIe switch makes a difference; you actually get difference between that platform and the two where you cannot do peer-to-peer.

“So system design does matter and as an infrastructure provider you definitely want to make sure to assign the tasks that are doing a lot of GPU-to-GPU communication, to the right platform. If you had a mix of platforms in your datacenter, if you have workloads that are actually doing a lot of peer-to-peer like translation benchmark, you want to make sure they get queued up on your NVLink platforms. For some of the other benchmarks, the differences that you get are not that significant,” said Radhakrishnan 

The bottom line, according to Radhakrishnan, is MLPerf provides a needed tool for assessing infrastructure choices as well as ML choices. “Use the tools to monitor and actually figure out how many GPUs you need [because] throwing as many GPUs as you can at the problem does not result in a linear increase in your performance. There are some workloads in which you can definitely see improvement and there are others where you are better off running at one or two GPUs,” he said.

The same is true for interconnect. “We looked at what NVLink brings to the table. For a two GPU system there are a couple of benchmarks for which NVLink did not make a difference,” he said but noted on larger systems NVLink can be critical when performance is your top priority although even there performance can vary by the model used.

There’s quite a bit more in Radhakrishnan’s presentation, including for example deeper dives into CPU utilization – it turns out TensorFlow is a CPU hog – and GPU utilization. It will be interesting to watch MLPerf’s development and how widely adopted it becomes.

Slide source: GTC2019

Link to Radhakrishnan’s GTC streamed (slides and audio) session: https://on-demand.gputechconf.com/gtc/2019/video/_/s9553-demystifying-deep-learning-infrastructure-choices-using-mlperf-benchmark-suite/

[i]Demystifying Deep Learning Infrastructure Choices Using MLPerf Benchmark Suite

Abstract: We’ll describe a new benchmark suite proposed by the Deep Learning community for machine learning workloads. We’ll present a quantitative analysis of an early version (0.5) of benchmark known as MLPerf and explain performance impact of NVIDIA GPU architecture across a range of DL applications. This work includes evaluating MLPerf performance on Turing, Volta, and Pascal to demonstrate the performance impact of NVIDIA GPU architecture across a range of DL applications. We’ll evaluate the impact of system-level technologies — Nvlink vs. PCIe topology — using server- and workstation-class platforms to show how system architecture impacts DL training workloads. We also plan to discuss our work to characterize MLPerf benchmark performance using profiling tools (GPU, CPU, memory & I/O), our hyperparameter tuning study (batch size, learning rate, SGD optimizer) on MLPerf performance, and map real world application use cases to MLPerf suite and how to quantify results for specific DL practitioner use cases. https://gputechconf2019.smarteventscloud.com/connect/sessionDetail.ww?SESSION_ID=263091