Compilers and More: Productivity and Compilers

By Michael Wolfe

July 27, 2007

Productivity is the new buzzword, and HPC now stands for High Productivity Computing; even HPCwire has adopted this moniker. Can we usefully define productivity? Several metrics have been proposed, most being difficult or impossible to use in any scientific way. The performance metric is typically results per time unit, like flops per second, or runs per day. A productivity metric has a different denominator, usually convertible into dollars (or other currency), such as programmer hours, total system cost, or total power usage.

For example, a simple (and useless) metric, let’s call it M1, is to measure the speedup gained for an application relative to the cost of attaining that speedup. Speedup is measured relative to some base time, and cost can be measured in dollars or hours (for programmer time). If we fix the target system, the hardware cost is constant; software development cost is sometimes normalized across different programmers by counting source lines of code (SLOC), which is coarse but defensible. Using SLOC favors higher level languages, which have shorter programs, though the performance may suffer. The metric M1 is defined as M1=Sp/SLOC where Sp is the speedup, and SLOC is the program length, estimating the programming effort. One study used this metric and indeed found that sequential MATLAB competes well with parallel C or Fortran; because the MATLAB program is shorter, the productivity metric is high, even though the absolute performance does not measure up to a parallel implementation. On the other hand, high-level parallel array languages like ZPL (http://www.cs.washington.edu/research/zpl) benefit both from low SLOC and high performance, and really shine using this metric.

One problem with M1 as a metric is that it implicitly assumes that you will run your program only once. If you run your program many times, it may be worthwhile to invest a great deal of additional effort for a comparatively small speedup; metric M1 will not show this to be beneficial, but the total time savings may change your mind.

Another problem with M1 is that it can show improved productivity even if the performance decreases. While it is true that most of our standard computing needs are not particularly sensitive to performance (think email), this is not the segment that HPC is intended to address. (If it is, someone let me know. I want out!) Even in the high performance world, we might be willing to accept small performance decreases if the development time and cost are significantly lower. However, rating a slow program as highly productive is counterproductive (pun intended).

Beyond Performance

Yet another problem with M1 is that it ignores additional considerations, such as debugging, portability, performance tuning, and longevity. These all fit into the productivity spectrum somewhere. Let’s discuss each briefly.

Debugging includes finding any programming errors as well as finding algorithmic problems. Interactive debuggers are common, but as we inexorably move into the world of parallel programming, these will have to scale to many simultaneously active threads. Right now the only commonly available scalable parallel debugger is Totalview, which sets the standard. Mature systems with available, supported debuggers are often preferable to a newer system where debugging is limited to print statements.

Portability concerns limit innovation. If we need portability across systems, we are unlikely to adopt or even experiment with a new programming language or library — unless or until it is widely available. Standard Fortran and C address the portability problems quite nicely, and C++ is also relatively portable. A common base library, such as MPI, however difficult to use, is at least widely available, and if necessary, we could port it ourselves.

Another aspect of portability is performance. When we restructure a program for high performance on one machine, we hope and expect the performance improves on other platforms. Programmers who worked on the vector machines in years past found that the effort to restructure their code for one vector machine did, in fact, deliver the corresponding high performance on other vector machines; the machine model was stable and easy to understand. MPI-based programs benefit from this; a parallel MPI program will run more or less as well in parallel on any reasonable MPI implementation.

Longevity concerns also limit innovation. We might be willing to adopt a new programming language, such as Unified Parallel C, for a current research project, but we are unlikely to use it for a product that we expect to live for a decade or more. Regardless of one’s feelings about UPC as a language, we are typically concerned that we will write a program today for which there will be no working compilers or support in ten years. I had the same problems with Java in its early years; programs that I built and used for months would suddenly stop building or working when we upgraded our Java installation.

Improving Productivity

We know what we really mean by high productivity, though it’s hard to quantify: we want to get high performance, but spend less to get it. Usually we mean spending less time in application development. If we go back 50 years, productivity is exactly what the original Fortran developers had in mind: delivering the same performance as machine language, with the lower program development cost of a higher level language. We would do well to be as successful as Fortran. There are no magic bullets here; someone has to do the work. There are four methods to improving productivity.

The first, and the one we’ve depended upon until now for improved performance (and hence productivity), is better hardware; faster processors improve performance. Hardware extraction of parallelism has long been promised (as has software parallelism extraction) and has been quite successful at the microarchitectural level (e.g., pipelined superscalar processors). But the gravy train here has slowed to a crawl. Hardware benefits are going to come with increased on-chip parallelism, not improved speed, and large scale multiprocessor parallelism is still the domain of the programmer.

The second (quite successful) method is faster algorithms. Sparse matrix solvers can be an order of magnitude more efficient than dense solvers when they apply, for instance. No hardware or software mechanism can correct an inappropriate or slow algorithm. Algorithm improvements are often portable across machine architectures and can be recoded in multiple languages, so the benefits are long-lived. So while new algorithm development is quite expensive, it can pay off handsomely.

The third method, often proposed and reinvented, is to use a high performance library for kernel operations. One such early library was STACKLIB, used on the Control Data 6600 and 7600 (ten points if you remember the etymology of the name). This library morphed over time into the BLAS, and now we have LINPACK and LAPACK. The hope is the vendor (or other highly motivated programmer) will optimize the library for each of your target architectures. If there are enough library users, the library author may have enough motivation to eke out the last drop of performance, and your productivity (and performance) increases. In the parallel computing domain, we have had SCALAPACK, and now we have RapidMind and (until recently) PeakStream. In these last two, the product is more than a library, it’s a mechanism for dynamic (run-time) code generation and optimization, something that was just recently an active field of research.

The upside of using a library is that when it works — when the library exists and is optimized on all your platforms — you preserve your programming investment and get high performance. One downside is that you now depend on the library vendor for your performance. At least with open source libraries you can tune the performance yourself if you have to, but then your productivity rating drops.

More importantly, the library interface becomes the vocabulary of a small language embedded in the source language. Your program is written in C or Fortran, but the computation kernel is written in the language of whatever library you use. When you restrict your program to that language, you get the performance you want. If you want to express something that isn’t available in that language, you have to recast it in that language, or work through the performance problems on your own. With the latest incarnations of object-oriented languages, the library interface looks more integrated with the language, complete with error-checking; but you still miss the performance indicators that vector compilers used to give (see below).

The fourth method is to use a better programming language; or, given a language, to use a better compiler. New languages are easy to propose, and we’ve all seen many of them over the decades; serious contenders are less common. Acceptance of a new language requires confidence in its performance, portability, and longevity. We often use High Performance Fortran as an example. It had limited applicability, but had some promise within its intended domain. It had portability, if only because major government contracts required an HPF compiler. However, when immature implementations did not deliver the expected performance, programmers quickly looked in other directions. Perhaps it could have been more successful with less initial hype, allowing more mature implementations and more general programming models to develop. We now see new parallel languages on the horizon, including the parallel CoArray extensions to Fortran (currently on the list for addition to Fortran 2008), Unified Parallel C, and the HPCS language proposals. Let’s see if they can avoid the pitfalls of HPF.

Compilers (or programming environments) also affect productivity. Early C compilers required users to identify variables that should be allocated to registers and encouraged pointer arithmetic instead of array references. Modern compilers can deliver the same performance without requiring programmers to think about these low-level details. Compilers that identify incorrect or questionable programming practice certainly improve productivity, but in the high performance world we should demand more. Vectorizing compilers in the 1970s and 1980s would give feedback about which inner loops would run in vector mode and which would not. Moreover, they were quite specific about what prevented vectorization, even down to identifying which variable in which subscript of which array reference in which statement caused the problem. This specificity had two effects: it would encourage the programmer to rewrite the offending loop, if it was important; and it trained the programmer how to write high performance code. Moreover, code that vectorized on one machine would likely vectorize on another, so the performance improvements were portable as well.

Learning from the vector compiler experience, we should demand that compilers and programming tools give useful, practical performance feedback. Unfortunately, while vectorization analysis is local to a loop and easy to explain, parallel communication analysis is global and can require interprocedural information.

One HPF pitfall that the HPCS languages must avoid is the ease with which one can write a slow program. In HPF, a single array assignment might be very efficient or very slow, and there’s no indication in the statement which is the case. A programmer must use detailed analysis of the array distributions and a knowledge of the compiler optimizations to determine this. MPI programs, as hard to understand as they may be, at least make the communication explicit. The HPCS language proposals to date have some of the same characteristics as HPF, and implementations will need to give performance hints to ensure that users can get the promised performance/productivity.

The key to a useful productivity metric is the ability to measure that we are improving the productivity of generating high performance programs. We may measure productivity as performance/cost, but we don’t get true high productivity by simply reducing the denominator faster than we reduce the numerator. We should want to reduce the denominator, the cost, while preserving or even increasing the performance.

—–

Michael Wolfe has developed compilers for over 30 years in both academia and industry, and is now a senior compiler engineer at The Portland Group, Inc. (www.pgroup.com), a wholly-owned subsidiary of STMicroelectronics, Inc. The opinions stated here are those of the author, and do not represent opinions of The Portland Group, Inc. or STMicroelectronics, Inc.

Subscribe to HPCwire's Weekly Update!

Be the most informed person in the room! Stay ahead of the tech trends with industy updates delivered to you every week!

Neural Networking Shows Promise in Earthquake Monitoring

February 21, 2018

A team of Harvard University and MIT researchers report their new neural networking method for monitoring earthquakes is more accurate and orders of magnitude faster than traditional approaches. Read more…

By John Russell

HPE Wins $57 Million DoD Supercomputing Contract

February 20, 2018

Hewlett Packard Enterprise (HPE) today revealed details of its massive $57 million HPC contract with the U.S. Department of Defense (DoD). The deal calls for HPE to provide the DoD High Performance Computing Modernizatio Read more…

By Tiffany Trader

Topological Quantum Superconductor Progress Reported

February 20, 2018

Overcoming sensitivity to decoherence is a persistent stumbling block in efforts to build effective quantum computers. Now, a group of researchers from Chalmers University of Technology (Sweden) report progress in devisi Read more…

By John Russell

HPE Extreme Performance Solutions

Safeguard Your HPC Environment with the World’s Most Secure Industry Standard Servers

Today’s organizations operate in an environment with ever-evolving threats, and in order to protect themselves they must continuously bolster their security strategy. Hewlett Packard Enterprise (HPE) and Intel® are addressing modern security challenges with the world’s most secure industry standard servers powered by the latest generation of Intel® Xeon® Scalable processors. Read more…

Fluid HPC: How Extreme-Scale Computing Should Respond to Meltdown and Spectre

February 15, 2018

The Meltdown and Spectre vulnerabilities are proving difficult to fix, and initial experiments suggest security patches will cause significant performance penalties to HPC applications. Even as these patches are rolled o Read more…

By Pete Beckman

Neural Networking Shows Promise in Earthquake Monitoring

February 21, 2018

A team of Harvard University and MIT researchers report their new neural networking method for monitoring earthquakes is more accurate and orders of magnitude faster than traditional approaches. Read more…

By John Russell

Fluid HPC: How Extreme-Scale Computing Should Respond to Meltdown and Spectre

February 15, 2018

The Meltdown and Spectre vulnerabilities are proving difficult to fix, and initial experiments suggest security patches will cause significant performance penal Read more…

By Pete Beckman

Brookhaven Ramps Up Computing for National Security Effort

February 14, 2018

Last week, Dan Coats, the director of Director of National Intelligence for the U.S., warned the Senate Intelligence Committee that Russia was likely to meddle in the 2018 mid-term U.S. elections, much as it stands accused of doing in the 2016 Presidential election. Read more…

By John Russell

AI Cloud Competition Heats Up: Google’s TPUs, Amazon Building AI Chip

February 12, 2018

Competition in the white hot AI (and public cloud) market pits Google against Amazon this week, with Google offering AI hardware on its cloud platform intended Read more…

By Doug Black

Russian Nuclear Engineers Caught Cryptomining on Lab Supercomputer

February 12, 2018

Nuclear scientists working at the All-Russian Research Institute of Experimental Physics (RFNC-VNIIEF) have been arrested for using lab supercomputing resources to mine crypto-currency, according to a report in Russia’s Interfax News Agency. Read more…

By Tiffany Trader

The Food Industry’s Next Journey — from Mars to Exascale

February 12, 2018

Global food producer and one of the world's leading chocolate companies Mars Inc. has a unique perspective on the impact that exascale computing will have on the food industry. Read more…

By Scott Gibson, Oak Ridge National Laboratory

Singularity HPC Container Start-Up – Sylabs – Emerges from Stealth

February 8, 2018

The driving force behind Singularity, the popular HPC container technology, is bringing the open source platform to the enterprise with the launch of a new vent Read more…

By George Leopold

Dell EMC Debuts PowerEdge Servers with AMD EPYC Chips

February 6, 2018

AMD notched another EPYC processor win today with Dell EMC’s introduction of three PowerEdge servers (R6415, R7415, and R7425) based on the EPYC 7000-series p Read more…

By John Russell

Inventor Claims to Have Solved Floating Point Error Problem

January 17, 2018

"The decades-old floating point error problem has been solved," proclaims a press release from inventor Alan Jorgensen. The computer scientist has filed for and Read more…

By Tiffany Trader

Japan Unveils Quantum Neural Network

November 22, 2017

The U.S. and China are leading the race toward productive quantum computing, but it's early enough that ultimate leadership is still something of an open questi Read more…

By Tiffany Trader

AMD Showcases Growing Portfolio of EPYC and Radeon-based Systems at SC17

November 13, 2017

AMD’s charge back into HPC and the datacenter is on full display at SC17. Having launched the EPYC processor line in June along with its MI25 GPU the focus he Read more…

By John Russell

Researchers Measure Impact of ‘Meltdown’ and ‘Spectre’ Patches on HPC Workloads

January 17, 2018

Computer scientists from the Center for Computational Research, State University of New York (SUNY), University at Buffalo have examined the effect of Meltdown Read more…

By Tiffany Trader

IBM Begins Power9 Rollout with Backing from DOE, Google

December 6, 2017

After over a year of buildup, IBM is unveiling its first Power9 system based on the same architecture as the Department of Energy CORAL supercomputers, Summit a Read more…

By Tiffany Trader

Nvidia Responds to Google TPU Benchmarking

April 10, 2017

Nvidia highlights strengths of its newest GPU silicon in response to Google's report on the performance and energy advantages of its custom tensor processor. Read more…

By Tiffany Trader

Fast Forward: Five HPC Predictions for 2018

December 21, 2017

What’s on your list of high (and low) lights for 2017? Volta 100’s arrival on the heels of the P100? Appearance, albeit late in the year, of IBM’s Power9? Read more…

By John Russell

Russian Nuclear Engineers Caught Cryptomining on Lab Supercomputer

February 12, 2018

Nuclear scientists working at the All-Russian Research Institute of Experimental Physics (RFNC-VNIIEF) have been arrested for using lab supercomputing resources to mine crypto-currency, according to a report in Russia’s Interfax News Agency. Read more…

By Tiffany Trader

Leading Solution Providers

Chip Flaws ‘Meltdown’ and ‘Spectre’ Loom Large

January 4, 2018

The HPC and wider tech community have been abuzz this week over the discovery of critical design flaws that impact virtually all contemporary microprocessors. T Read more…

By Tiffany Trader

Perspective: What Really Happened at SC17?

November 22, 2017

SC is over. Now comes the myriad of follow-ups. Inboxes are filled with templated emails from vendors and other exhibitors hoping to win a place in the post-SC thinking of booth visitors. Attendees of tutorials, workshops and other technical sessions will be inundated with requests for feedback. Read more…

By Andrew Jones

How Meltdown and Spectre Patches Will Affect HPC Workloads

January 10, 2018

There have been claims that the fixes for the Meltdown and Spectre security vulnerabilities, named the KPTI (aka KAISER) patches, are going to affect applicatio Read more…

By Rosemary Francis

GlobalFoundries, Ayar Labs Team Up to Commercialize Optical I/O

December 4, 2017

GlobalFoundries (GF) and Ayar Labs, a startup focused on using light, instead of electricity, to transfer data between chips, today announced they've entered in Read more…

By Tiffany Trader

Tensors Come of Age: Why the AI Revolution Will Help HPC

November 13, 2017

Thirty years ago, parallel computing was coming of age. A bitter battle began between stalwart vector computing supporters and advocates of various approaches to parallel computing. IBM skeptic Alan Karp, reacting to announcements of nCUBE’s 1024-microprocessor system and Thinking Machines’ 65,536-element array, made a public $100 wager that no one could get a parallel speedup of over 200 on real HPC workloads. Read more…

By John Gustafson & Lenore Mullin

Flipping the Flops and Reading the Top500 Tea Leaves

November 13, 2017

The 50th edition of the Top500 list, the biannual publication of the world’s fastest supercomputers based on public Linpack benchmarking results, was released Read more…

By Tiffany Trader

V100 Good but not Great on Select Deep Learning Aps, Says Xcelerit

November 27, 2017

Wringing optimum performance from hardware to accelerate deep learning applications is a challenge that often depends on the specific application in use. A benc Read more…

By John Russell

SC17: Singularity Preps Version 3.0, Nears 1M Containers Served Daily

November 1, 2017

Just a few months ago about half a million jobs were being run daily using Singularity containers, the LBNL-founded container platform intended for HPC. That wa Read more…

By John Russell

  • arrow
  • Click Here for More Headlines
  • arrow
Share This