Annotations accelerate
supercomputer programs
(page 3 of 4)
Exploring Orio's output
In one test, Norris and her colleagues used Orio on two systems: an Intel Xeon workstation and a Blue Gene/P supercomputer, both located at ANL. They let several optimizers, including ones that use optimization libraries, and Orio work on speeding up code for solving simple algebra problems.
The Orio-optimized code was consistently the fastest, in both sequential and parallel computing. In some cases, the Orio-enhanced code outperformed the others by factors of 4 to 6.
"Orio is able to generate many versions of the implementation," Norris says, "and our experience shows that the performance achieved is better than manually written implementations, including those that call highly optimized math libraries."
By testing Orio on two computers, Norris and Hartono showed the software works on different architectures. Beyond that, an optimizer also must find good solutions that work with a specific architecture. "With Orio, the Intel machine gives different optimized code than you get on the Blue Gene/P," Norris notes. "When you run Orio on different architectures, you are almost guaranteed to get different code because the memory hierarchies are different."
In addition, Norris and her colleagues have used Orio to work on codes that simulate fusion reactors and particle accelerators. "The core of this is a set of loops that iterate and update the discretized electric and magnetic fields," Norris says. "We create annotations for those sections and we have achieved some pretty good results with Orio."
In creating new versions of code for annotated sections, though, one must ask: How do you know that the optimized code produces the same answer as the original code?
"That is a very critical question," Gropp says. "Typically, when a developer optimizes code, it gets changed. The developer might compare the results of the original and 'optimized' code at that time, but then the code could get permanently changed, leaving nothing for future comparisons."
That is, new code could replace previous code and the programmer would move ahead &ndash assuming that the old and new code would produce the same answer under all circumstances.
"That new code, though, is probably more complicated," Gropp says, "and the compiler could make a mistake dealing with it or the new code might be 'buggy' in a way that is not obvious until some specific feature is used."
