Since the first bug was eradicated from a Mark II system at Harvard in 1940s (an actual moth wedged in a relay, which drove the machine to a standstill) system exterminators have faced a constant spray of challenges. Nodes continue to reproduce, architectures alter, and application demands climb ever-higher walls.  

This all means it’s getting tougher for code exterminators to reproduce and track down the bugs across many thousands of cores. Further, many pre-petascale debuggers weren’t able to efficiently relay information about the health of the entire application, allowing a small portal to see one process at a time, despite the fact that hundreds were being debugged alongside.

Throw  coprocessors and accelerators into the mix and it seems there’s a perfect storm brewing for a total rethink in more efficient, scalable bug-zapping—especially with the spectre of exascale in the distance.

According to David Lecomber, co-founder and COO of HPC debugging company, Allinea, the scale and complexity of systems it’s been working with, including Titan and Blue Waters, required new approaches to tackle larger node counts. More pressing and complex, however, is the increased heterogeneity. For top-tier machines like these, he says, scale and core diversity are critical–but at the heart of all of their work is improving debugging speed. The company has targeted all of these areas as it’s worked alongside Oak Ridge National Lab, NCSA, and others aiming for extreme scale computing targets, refining its ability to show thousands of processes in one, full view for more effective bug stomping.

In the “moth-plucking” days of debugging, before visually-oriented, multi-process, scalable approaches, every single node in a cluster had to directly connect to where the user was sitting. Naturally, as node counts climbed, the workstations were quickly overloaded, meaning users could only handle at most several hundred or a thousand cores. Debugging was a necessary, clunky of evil—one that wouldn’t hold up to the demands of core counts in the hundreds of thousands, and even if it could keep up, it would slow to a crawl.

Lecomber touts his company’s role in reshaping that long-standing trend via Allinea’s DDT, which offered a UI that could paint the whole landscape of an application, letting users “visualize and compare 200,000 processes as simply as two.” Their work at massive scale recently started in earnest with Jaguar via their work with Oak Ridge, before wading into Blue Waters or battling the Titan. He claims that despite the scale, the speed was emphasized—to the point that Allinea could handle even higher node counts in anything we’re set to see soon. He said that the time to debug using the old node-connected approach was in the minutes, but they’ve been able to trim this process down to seconds.

During the company’s early work with Jaguar, and later Titan, Oak Ridge had a couple of problems, including limitations with the traditional printfs debugging approach to find bugs, followed by adding GPUs into the mix. Oak Ridge’s Tools Project Technical Officer, Joshua Ladd said that the ability to see every process in a parallel job allowed the lab to remove the debugging hassles and speed time to result.

And on the GPU front, the lab wanted researchers to take advantage of Titan’s accelerators but they needed more powerful tools that could attack those more complicated bugs. Further, Oak Ridge was able to harness DDT on Jaguar to debug an open source implementation of MPI at a half-million lines of code across a maximum of 225,000 cores.

Scale aside, as noted, the true challenges relate to the increasing heterogeneity of ever-larger systems. Lecomber said that a lot of work went on behind the scenes to get DDT primed for GPUs and coprocessors, and he expects such challenges are going to persist during the exascale climb. They’ve already done a great deal of work on accelerators and recently looked to address challenges on Xeon Phi, as detailed below.

Beyond new architectures, Allinea is focusing on combining advanced debugging and performance tools so users will be able to better visualize the performance of their applications. In other words, having a petascale machine isn’t incredibly useful if you can’t take advantage of that power—just as computing the fastest wrong answer won’t work either.

When it comes to exascale, and even petascale at this point, “the real gaps are in the tools area, the people writing applications for these large machines need to be able to do performance profiling in a similar way as they handle debugging—visually and with emphasis on speed,” he said. Their MPI profiler, called MAP, highlights lines of code that executed the slowest to demo what happened during the run in a format that will be familiar to those who already use DDT.

While we generally hear about HPC debuggers in the context of national labs, petascale systems are proliferating in the commercial spaces as well, necessitating enterprise-grade, extreme-scale extermination. Lecomber says that companies they work with, several of which are in the oil and gas and engineering arenas, are adopting similarly-sized systems that present mission-critical challenges. Simulating the performance and safety of an engine, for instance, can have devastating results if not done correctly or at best, can result in expensive runtime waste.

Aside from their academic affiliations and work in oil and gas and other key commercial areas, Allinea is working closely with the European Collaborative Research into Exascale Systemware, Tools and Applications (CRESTA) to identify what these future systems will look like and how tool vendors and application artists will need to rework their approaches. Lecomber says this also involves collaboration with system designers, processor-makers and other vendors to make sure the exascale research food chain is aligned.