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!

Musk’s Latest Startup Eyes Brain-Computer Links

April 21, 2017

Elon Musk, the auto and space entrepreneur and severe critic of artificial intelligence, is forming a new venture that reportedly will seek to develop an interface between the human brain and computers. Read more…

By George Leopold

MIT Mathematician Spins Up 220,000-Core Google Compute Cluster

April 21, 2017

On Thursday, Google announced that MIT math professor and computational number theorist Andrew V. Sutherland had set a record for the largest Google Compute Engine (GCE) job. Sutherland ran the massive mathematics workload on 220,000 GCE cores using preemptible virtual machine instances. Read more…

By Tiffany Trader

NERSC Cori Shows the World How Many-Cores for the Masses Works

April 21, 2017

As its mission, the high performance computing center for the U.S. Department of Energy Office of Science, NERSC (the National Energy Research Supercomputer Center), supports a broad spectrum of forefront scientific research across diverse areas that includes climate, material science, chemistry, fusion energy, high-energy physics and many others. Read more…

By Rob Farber

Nvidia P100 Shows 1.3-2.3x Speedup Over K80 GPU on Financial Apps

April 20, 2017

When it comes to the true performance of the latest silicon, every end user knows that the best processor is the one that works best for their application. Read more…

By Tiffany Trader

HPE Extreme Performance Solutions

HPC-Driven Weather Simulations Improving Forecasting Capabilities

In September of 1938, a massive hurricane traversed the Atlantic Ocean and made landfall in New England. Due to inadequate and incorrect forecasting, the storm struck farther north and with greater intensity than had been predicted, leaving residents and authorities with virtually no warning or time to properly prepare. Read more…

Quantum Adds Global Smarts to StorNext File System

April 20, 2017

Companies that use Quantum’s StorNext platform to store massive amounts of data this week got a glimpse of new storage capabilities that should make it easier to access their data horde from anywhere in the world. Read more…

By Alex Woodie

Scaling an HPC Career in Nepal Can Be a Steep Climb

April 20, 2017

Umesh Upadhyaya works as an IT Associate at the International Centre for Integrated Mountain Development (ICIMOD) in Nepal, which supports the country’s one and only HPC facility. He is directly involved in an initiative that focuses on climate change and atmosphere modeling Read more…

By Nages Sieslack

Hyperion (IDC) Paints a Bullish Picture of HPC Future

April 20, 2017

Hyperion Research – formerly IDC’s HPC group – yesterday painted a fascinating and complicated portrait of the HPC community’s health and prospects at the HPC User Forum held in Albuquerque, NM. HPC sales are up and growing ($22 billion, all HPC segments, 2016). Read more…

By John Russell

Intel Open Sources All Lustre Work, Brent Gorda Exits

April 19, 2017

In a letter to the Lustre community posted on the Intel website, Vice President of Intel's Data Center Group Trish Damkroger writes that effective immediately the company will be contributing all Lustre development to the open source community. Damkroger also announced that Brent Gorda, General Manager, High Performance Data Division at Intel is leaving the company. Read more…

By Tiffany Trader

NERSC Cori Shows the World How Many-Cores for the Masses Works

April 21, 2017

As its mission, the high performance computing center for the U.S. Department of Energy Office of Science, NERSC (the National Energy Research Supercomputer Center), supports a broad spectrum of forefront scientific research across diverse areas that includes climate, material science, chemistry, fusion energy, high-energy physics and many others. Read more…

By Rob Farber

Hyperion (IDC) Paints a Bullish Picture of HPC Future

April 20, 2017

Hyperion Research – formerly IDC’s HPC group – yesterday painted a fascinating and complicated portrait of the HPC community’s health and prospects at the HPC User Forum held in Albuquerque, NM. HPC sales are up and growing ($22 billion, all HPC segments, 2016). Read more…

By John Russell

Knights Landing Processor with Omni-Path Makes Cloud Debut

April 18, 2017

HPC cloud specialist Rescale is partnering with Intel and HPC resource provider R Systems to offer first-ever cloud access to Xeon Phi "Knights Landing" processors. The infrastructure is based on the 68-core Intel Knights Landing processor with integrated Omni-Path fabric (the 7250F Xeon Phi). Read more…

By Tiffany Trader

CERN openlab Explores New CPU/FPGA Processing Solutions

April 14, 2017

Through a CERN openlab project known as the ‘High-Throughput Computing Collaboration,’ researchers are investigating the use of various Intel technologies in data filtering and data acquisition systems. Read more…

By Linda Barney

DOE Supercomputer Achieves Record 45-Qubit Quantum Simulation

April 13, 2017

In order to simulate larger and larger quantum systems and usher in an age of “quantum supremacy,” researchers are stretching the limits of today’s most advanced supercomputers. Read more…

By Tiffany Trader

Penguin Takes a Run at the Big Cloud Providers

April 12, 2017

HPC specialist Penguin Computing recently re-ran benchmarks from a study of its larger brethren and says the results show its ‘public cloud’ – Penguin on Demand (POD) – is among the leaders in cost and performance. Read more…

By John Russell

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

HPC and the Colocation Datacenter – a Bridge Too Far?

April 7, 2017

A more standardised HPC platform approach is making the running of HPC projects within increasing financial reach. Read more…

By Clive Longbottom, Quocirca

Google Pulls Back the Covers on Its First Machine Learning Chip

April 6, 2017

This week Google released a report detailing the design and performance characteristics of the Tensor Processing Unit (TPU), its custom ASIC for the inference phase of neural networks (NN). Read more…

By Tiffany Trader

Quantum Bits: D-Wave and VW; Google Quantum Lab; IBM Expands Access

March 21, 2017

For a technology that’s usually characterized as far off and in a distant galaxy, quantum computing has been steadily picking up steam. Read more…

By John Russell

Trump Budget Targets NIH, DOE, and EPA; No Mention of NSF

March 16, 2017

President Trump’s proposed U.S. fiscal 2018 budget issued today sharply cuts science spending while bolstering military spending as he promised during the campaign. Read more…

By John Russell

HPC Compiler Company PathScale Seeks Life Raft

March 23, 2017

HPCwire has learned that HPC compiler company PathScale has fallen on difficult times and is asking the community for help or actively seeking a buyer for its assets. 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

For IBM/OpenPOWER: Success in 2017 = (Volume) Sales

January 11, 2017

To a large degree IBM and the OpenPOWER Foundation have done what they said they would – assembling a substantial and growing ecosystem and bringing Power-based products to market, all in about three years. Read more…

By John Russell

CPU-based Visualization Positions for Exascale Supercomputing

March 16, 2017

In this contributed perspective piece, Intel’s Jim Jeffers makes the case that CPU-based visualization is now widely adopted and as such is no longer a contrarian view, but is rather an exascale requirement. Read more…

By Jim Jeffers, Principal Engineer and Engineering Leader, Intel

TSUBAME3.0 Points to Future HPE Pascal-NVLink-OPA Server

February 17, 2017

Since our initial coverage of the TSUBAME3.0 supercomputer yesterday, more details have come to light on this innovative project. Of particular interest is a new board design for NVLink-equipped Pascal P100 GPUs that will create another entrant to the space currently occupied by Nvidia's DGX-1 system, IBM's "Minsky" platform and the Supermicro SuperServer (1028GQ-TXR). Read more…

By Tiffany Trader

Leading Solution Providers

Tokyo Tech’s TSUBAME3.0 Will Be First HPE-SGI Super

February 16, 2017

In a press event Friday afternoon local time in Japan, Tokyo Institute of Technology (Tokyo Tech) announced its plans for the TSUBAME3.0 supercomputer, which will be Japan’s “fastest AI supercomputer,” Read more…

By Tiffany Trader

IBM Wants to be “Red Hat” of Deep Learning

January 26, 2017

IBM today announced the addition of TensorFlow and Chainer deep learning frameworks to its PowerAI suite of deep learning tools, which already includes popular offerings such as Caffe, Theano, and Torch. Read more…

By John Russell

Is Liquid Cooling Ready to Go Mainstream?

February 13, 2017

Lost in the frenzy of SC16 was a substantial rise in the number of vendors showing server oriented liquid cooling technologies. Three decades ago liquid cooling was pretty much the exclusive realm of the Cray-2 and IBM mainframe class products. That’s changing. We are now seeing an emergence of x86 class server products with exotic plumbing technology ranging from Direct-to-Chip to servers and storage completely immersed in a dielectric fluid. Read more…

By Steve Campbell

BioTeam’s Berman Charts 2017 HPC Trends in Life Sciences

January 4, 2017

Twenty years ago high performance computing was nearly absent from life sciences. Today it’s used throughout life sciences and biomedical research. Genomics and the data deluge from modern lab instruments are the main drivers, but so is the longer-term desire to perform predictive simulation in support of Precision Medicine (PM). There’s even a specialized life sciences supercomputer, ‘Anton’ from D.E. Shaw Research, and the Pittsburgh Supercomputing Center is standing up its second Anton 2 and actively soliciting project proposals. There’s a lot going on. Read more…

By John Russell

HPC Startup Advances Auto-Parallelization’s Promise

January 23, 2017

The shift from single core to multicore hardware has made finding parallelism in codes more important than ever, but that hasn’t made the task of parallel programming any easier. Read more…

By Tiffany Trader

HPC Technique Propels Deep Learning at Scale

February 21, 2017

Researchers from Baidu’s Silicon Valley AI Lab (SVAIL) have adapted a well-known HPC communication technique to boost the speed and scale of their neural network training and now they are sharing their implementation with the larger deep learning community. Read more…

By Tiffany Trader

US Supercomputing Leaders Tackle the China Question

March 15, 2017

Joint DOE-NSA report responds to the increased global pressures impacting the competitiveness of U.S. supercomputing. Read more…

By Tiffany Trader

IDG to Be Bought by Chinese Investors; IDC to Spin Out HPC Group

January 19, 2017

US-based publishing and investment firm International Data Group, Inc. (IDG) will be acquired by a pair of Chinese investors, China Oceanwide Holdings Group Co., Ltd. Read more…

By Tiffany Trader

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