Programming language for hardware accelerators
Called “Exo,” the language is designed to help low-level performance engineers transform very simple programs that specify what they want to compute, into very complex programs that do the same thing as the specification, but much, much faster by using hardware accelerator chips – specialized devices that can run certain tasks orders of magnitude faster than CPUs. Such devices cannot be used out of the box: Software needs to efficiently use accelerators’ instructions to make it compatible with the entire application system, which translates to a lot of engineering work that then would have to be maintained for a new chip that a user is compiling code to, with any programming language.
Unlike other programming languages and compilers, say the researchers, Exo is built around a concept called “Exocompilation.”
“Traditionally, a lot of research has focused on automating the optimization process for the specific hardware,” says Yuka Ikarashi, a PhD student in electrical engineering and computer science and CSAIL affiliate who is a lead author on a new paper about Exo. “This is great for most programmers, but for performance engineers, the compiler gets in the way as often as it helps. Because the compiler’s optimizations are automatic, there’s no good way to fix it when it does the wrong thing and gives you 45 percent efficiency instead of 90 percent.”
With Exocompilation, say the researchers, the performance engineer is back in the driver’s seat. Responsibility for choosing which optimizations to apply, when, and in what order is externalized from the compiler, back to the performance engineer. This way, they don’t have to waste time fighting the compiler on the one hand, or doing everything manually on the other.
At the same time, Exo takes responsibility for ensuring that all of these optimizations are correct. As a result, the performance engineer can spend their time improving performance, rather than debugging the complex, optimized code.
“Exo language is a compiler that’s parameterized over the hardware it targets; the same compiler can adapt to many different hardware accelerators,” says Adrian Sampson, assistant professor in the Department of Computer Science at Cornell University. “Instead of writing a bunch of messy C++ code to compile for a new accelerator, Exo gives you an abstract, uniform way to write down the ‘shape’ of the hardware you want to target. Then you can reuse the existing Exo compiler to adapt to that new description instead of writing something entirely new from scratch.”
“The potential impact of work like this is enormous,” says Sampson. “If hardware innovators can stop worrying about the cost of developing new compilers for every new hardware idea, they can try out and ship more ideas. The industry could break its dependence on legacy hardware that succeeds only because of ecosystem lock-in and despite its inefficiency.”
The highest-performance computer chips made today, such as Google’s TPU, Apple’s Neural Engine, or NVIDIA’s Tensor Cores, power scientific computing and machine learning applications by accelerating something called “key sub-programs,” kernels, or high-performance computing (HPC) subroutines. For example, something called Basic Linear Algebra Subroutines (BLAS) is a “library” or collection of such subroutines, which are dedicated to linear algebra computations, and enable many machine learning tasks like neural networks, weather forecasts, cloud computation, and drug discovery. However, these new chips — which take hundreds of engineers to design — are only as good as these HPC software libraries allow.
Currently, though, this kind of performance optimization is still done by hand to ensure that every last cycle of computation on these chips gets used. HPC subroutines regularly run at 90 percent-plus of peak theoretical efficiency, and hardware engineers go to great lengths to add an extra five or 10 percent of speed to these theoretical peaks. So, if the software isn’t aggressively optimized, all of that hard work gets wasted — which is exactly what Exo helps avoid, say the researchers.
Another key part of Exocompilation is that performance engineers can describe the new chips they want to optimize for, without having to modify the compiler. Traditionally, the definition of the hardware interface is maintained by the compiler developers, but with most of these new accelerator chips, the hardware interface is proprietary. Companies have to maintain their own copy (fork) of a whole traditional compiler, modified to support their particular chip. This requires hiring teams of compiler developers in addition to the performance engineers.
“In Exo, we instead externalize the definition of hardware-specific backends from the exocompiler,” says Gilbert Bernstein, a postdoc at the University of California at Berkeley. “This gives us a better separation between Exo — which is an open-source project — and hardware-specific code — which is often proprietary. We’ve shown that we can use Exo to quickly write code that’s as performant as Intel’s hand-optimized Math Kernel Library. We’re actively working with engineers and researchers at several companies.”
The future of Exo, say the researchers, entails exploring a more productive scheduling meta-language, and expanding its semantics to support parallel programming models to apply it to even more accelerators, including GPUs. For more, see “Exocompilation for productive programming of hardware accelerators.”
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
