Application developers looking for a foundational treatment of HPC programming need look no further than the 2010 text, Introduction to High Performance Computing for Scientists and Engineers, which describes the art of extracting maximum performance from modern processors and HPC platforms. Gerhard Wellein, who co-authored the book with colleague Georg Hager, has made a career of teaching HPC techniques to aspiring students in science and engineering programs.

Currently a professor at the Department for Computer Science at the University of Erlangen-Nuremberg, Wellein also heads the HPC group at the Erlangen Regional Computing Center (RRZE). Like many in HPC today, he came from a science background, in this case physics, and specifically solid state physics. Wellein holds a PhD in the subject from Germany's University of Bayreuth, and his interest in parallel and HPC programming stem from the intense computation demands of his original field of study.

At this June's International Supercomputing Conference (ISC'13) in Leipzig, Germany, Wellein will be delivering a keynote titled, Fooling the Masses with Performance Results: Old Classics & Some New Ideas. The presentation was inspired by David H. Bailey 1991 classic article Twelve Ways to Fool the Masses When Giving Performance Results on Parallel Computers, and is intended to follow the humorous tone of Bailey's original work.

HPCwire caught up with Wellein and asked him to preview some of the themes of his upcoming talk and expound on strategies for performance programming in the multicore era.

HPCwire: Multicore processors have been with us for more than a decade. In general, do you think programmers and programming has caught up to this computing paradigm?

Gerhard Wellein: Many software developers mainly focus on extendibility, flexibility and maintainability for their frameworks. Performance or better time to solution has not been an issue for them for two decades. Teaching in computer science still often ignores performance issues.

The same holds for parallelization – here the developers often hope that some other software layer – compiler or libraries – will do the job. However, people should become aware that improving time to solution, through hardware efficient code structures and parallelization, is not for free and often orthogonal to widely accepted concepts in modern programming languages and software engineering paradigms.

In a very provocative statement I would say that “abstraction is the natural enemy of performance.” To mitigate this problem, software developers need to understand the interaction of the different software layers, including compilers, with the basic hardware structures at least at a coarse level, and consider this relationship when designing and implementing the performance-critical path of the software.

HPCwire: In general, why is it so hard to extract peak performance from multicore processors?

Wellein: Modern multicore processors draw their performance from thread-level parallelism and data parallelism, that is, multiple cores and wide SIMD units per core. The programmer has to address both hardware features at the same time and needs optimize for them; otherwise he loses a substantial fraction of peak performance. If the compiler, for some reason, refuses to vectorize your single precision arithmetic code, you immediately lose almost 90 percent of the available peak performance on the latest Intel processors!

Then you need to do the job on your own. But who uses SIMD intrinsics or even programs assembly language? The same holds for multicore parallelization. Here load imbalances or dependencies can severely limit multicore efficiency from the start.

Moreover multicores have plenty of shared resources such as caches and memory interfaces which carry the risk of contention. One also should be aware that the maximum attainable performance always depends on the problem to be solved. Sparse matrix solvers working on irregular problems typically can only achieve a single digit fraction of peak performance, due to main memory bandwidth limitations. The architecture of modern multicores strongly favors problems which run from cache and have high spatial and temporal locality in their data access, which excludes large application areas from getting close to peak performance.
HPCwire: What kinds of tools and techniques for multicore programming are available that are not being commonly employed now?

Wellein: There is no lack of advanced tools. Often I have the impression that there are too many tools, frameworks and parallel programming models out there and many software developers get lost.

What is missing is a comprehensive understanding of the attainable performance for a give code or algorithm on a given hardware platform. Performance modeling is a structured process to analyze the interaction of hardware and software in order to predict the best performance levels both in serial and parallel applications. Comparing actual and predicted performance identifies inefficient code parts and opportunities for code optimization. Thus I feel that for time-critical applications, performance modeling should be integral part of the software development cycle.

HPCwire: If you had to pick one or two attributes of modern processors that hinders the ability of HPC developers to extract performance, what would it be?

Wellein: Performance improvements in multicores are driven mainly by two factors – SIMD and multicore parallelism – which need to be explicitly addressed by the programmer. The compiler alone will not do the job! In the good old days of the clock speed race, performance was boosted by the increasing processor frequency for free.

HPCwire: Is programming for performance different that programming for energy efficiency?

Wellein: No, this is just another side of the same medal. Programming for performance aims to reduce overall runtime. It may increase the power consumption mainly of the processor chip. But what counts at the end of the day is energy to solution, which is the product of both. All optimizations which substantially improve time to solution also reduce overall energy consumption.

What is even more interesting is that with a well optimized serial code you need fewer cores to saturate performance on the multicore chip. This now offers the interesting option to substantially reduce the clock speed of multicores or switch off cores completely! Some people may still complain that this makes your code less scalable on multicores. That is true but it improves energy efficiency and time to solution.

HPCwire: What do you think of the latest vector accelerators: GPUs and Intel's latest Xeon Phi line, or even the general-purpose DSPs from Texas Instruments? Is this a reasonable approach for vector computing or do you see this as an intermediate step to something else?

Wellein: Those approaches trade in hardware complexity for additional performance, thus shifting additional work load to the programmer. Application performance on those architectures is typically much more susceptible to programmer’s capability to write highly efficient code. At the “core” level they draw their performance from the same concepts as vector computers did, namely fine-grained data parallelism with a wide SIMD approach. The product of those two factors on an Intel Xeon Phi processor makes performance approximately 15 times higher than on a state-of-the art Xeon EP processor, making the accelerator even more sensitive to inefficient codes.

From classical vector computers they differ in the sense that accelerators are mainly optimized for FLOPS and not for FLOPS-to-byte ratios. This also becomes evident if you look at the hierarchical memory subsystems which do not provide the ease of use of the simple flat designs of vector computers.

Increasing fine-grained data parallelism in hardware may further boost the FLOPS of future accelerators, but will further decrease the FLOPS-to-byte ratios. Also non-SIMD parts in the codes may soon become severe bottlenecks – with greetings from Gene Amdahl!
HPCwire: Does the mass market for processors – generic servers, PCs, and now especially mobile devices – serve the needs of HPC? Do you think there is a reasonable cost/benefit for developing more specialized processors for this domain?

Wellein: The rapid development cycles and cost reductions of the mass markets have substantially fostered progress in computational science and engineering in the past decade. These achievements opened HPC capacities for the “masses” in science and engineering.

I do not feel that most of those users are today willing to pay a high price premium to develop specialized hardware solutions, which means for them to trade in capability for capacity. What is happening to the last vendor of specialized processors for supercomputing – NEC with its vector computing processors – is a good example. In recent years NEC lost many of their customers in the weather and climate community, one of the few communities that asked for specialized HPC solutions for a long time. The Lattice QCD community is still building specialized solutions, such as the QPACE project, but also gave up designing its own processors.

The requirements to an “optimal processor” differ substantially among the application communities and making specialized designs for each of them is economically unattractive for most of the users. They take what they get from the mass market vendors. As long as those deliver processors which provide a good compromise between “time to solution,” aka capability, and “throughput,” aka capacity, for most users, there is not enough pressure for large-scale investments in specialized HPC processors.

I do not feel comfortable with that trend because there is tendency to blame the application that it cannot make efficient use of those processors and one should adapt the solver or even the physical model to the processor! A provocative summary of this trend: “Seymour Cray built machines to solve problems. Today we look for problems which we can solve on the machines available!”