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!

Advancing Modular Supercomputing with DEEP and DEEP-ER Architectures

February 24, 2017

Knowing that the jump to exascale will require novel architectural approaches capable of delivering dramatic efficiency and performance gains, researchers around the world are hard at work on next-generation HPC systems. Read more…

By Sean Thielen

Weekly Twitter Roundup (Feb. 23, 2017)

February 23, 2017

Here at HPCwire, we aim to keep the HPC community apprised of the most relevant and interesting news items that get tweeted throughout the week. Read more…

By Thomas Ayres

HPE Server Shows Low Latency on STAC-N1 Test

February 22, 2017

The performance of trade and match servers can be a critical differentiator for financial trading houses. Read more…

By John Russell

HPC Financial Update (Feb. 2017)

February 22, 2017

In this recurring feature, we’ll provide you with financial highlights from companies in the HPC industry. Check back in regularly for an updated list with the most pertinent fiscal information. Read more…

By Thomas Ayres

HPE Extreme Performance Solutions

O&G Companies Create Value with High Performance Remote Visualization

Today’s oil and gas (O&G) companies are striving to process datasets that have become not only tremendously large, but extremely complex. And the larger that data becomes, the harder it is to move and analyze it – particularly with a workforce that could be distributed between drilling sites, offshore rigs, and remote offices. Read more…

Rethinking HPC Platforms for ‘Second Gen’ Applications

February 22, 2017

Just what constitutes HPC and how best to support it is a keen topic currently. Read more…

By John Russell

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

IDC: Will the Real Exascale Race Please Stand Up?

February 21, 2017

So the exascale race is on. And lots of organizations are in the pack. Government announcements from the US, China, India, Japan, and the EU indicate that they are working hard to make it happen – some sooner, some later. Read more…

By Bob Sorensen, IDC

ExxonMobil, NCSA, Cray Scale Reservoir Simulation to 700,000+ Processors

February 17, 2017

In a scaling breakthrough for oil and gas discovery, ExxonMobil geoscientists report they have harnessed the power of 717,000 processors – the equivalent of 22,000 32-processor computers – to run complex oil and gas reservoir simulation models. Read more…

By Doug Black

Advancing Modular Supercomputing with DEEP and DEEP-ER Architectures

February 24, 2017

Knowing that the jump to exascale will require novel architectural approaches capable of delivering dramatic efficiency and performance gains, researchers around the world are hard at work on next-generation HPC systems. Read more…

By Sean Thielen

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

IDC: Will the Real Exascale Race Please Stand Up?

February 21, 2017

So the exascale race is on. And lots of organizations are in the pack. Government announcements from the US, China, India, Japan, and the EU indicate that they are working hard to make it happen – some sooner, some later. Read more…

By Bob Sorensen, IDC

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

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

Drug Developers Use Google Cloud HPC in the Fight Against ALS

February 16, 2017

Within the haystack of a lethal disease such as ALS (amyotrophic lateral sclerosis / Lou Gehrig’s Disease) there exists, somewhere, the needle that will pierce this therapy-resistant affliction. Read more…

By Doug Black

Azure Edges AWS in Linpack Benchmark Study

February 15, 2017

The “when will clouds be ready for HPC” question has ebbed and flowed for years. 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

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

US, China Vie for Supercomputing Supremacy

November 14, 2016

The 48th edition of the TOP500 list is fresh off the presses and while there is no new number one system, as previously teased by China, there are a number of notable entrants from the US and around the world and significant trends to report on. Read more…

By Tiffany Trader

Lighting up Aurora: Behind the Scenes at the Creation of the DOE’s Upcoming 200 Petaflops Supercomputer

December 1, 2016

In April 2015, U.S. Department of Energy Undersecretary Franklin Orr announced that Intel would be the prime contractor for Aurora: Read more…

By Jan Rowell

D-Wave SC16 Update: What’s Bo Ewald Saying These Days

November 18, 2016

Tucked in a back section of the SC16 exhibit hall, quantum computing pioneer D-Wave has been talking up its new 2000-qubit processor announced in September. Forget for a moment the criticism sometimes aimed at D-Wave. This small Canadian company has sold several machines including, for example, ones to Lockheed and NASA, and has worked with Google on mapping machine learning problems to quantum computing. In July Los Alamos National Laboratory took possession of a 1000-quibit D-Wave 2X system that LANL ordered a year ago around the time of SC15. Read more…

By John Russell

Enlisting Deep Learning in the War on Cancer

December 7, 2016

Sometime in Q2 2017 the first ‘results’ of the Joint Design of Advanced Computing Solutions for Cancer (JDACS4C) will become publicly available according to Rick Stevens. He leads one of three JDACS4C pilot projects pressing deep learning (DL) into service in the War on Cancer. Read more…

By John Russell

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

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

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

Leading Solution Providers

CPU Benchmarking: Haswell Versus POWER8

June 2, 2015

With OpenPOWER activity ramping up and IBM’s prominent role in the upcoming DOE machines Summit and Sierra, it’s a good time to look at how the IBM POWER CPU stacks up against the x86 Xeon Haswell CPU from Intel. Read more…

By Tiffany Trader

Nvidia Sees Bright Future for AI Supercomputing

November 23, 2016

Graphics chipmaker Nvidia made a strong showing at SC16 in Salt Lake City last week. Read more…

By Tiffany Trader

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

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

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

Dell Knights Landing Machine Sets New STAC Records

November 2, 2016

The Securities Technology Analysis Center, commonly known as STAC, has released a new report characterizing the performance of the Knight Landing-based Dell PowerEdge C6320p server on the STAC-A2 benchmarking suite, widely used by the financial services industry to test and evaluate computing platforms. The Dell machine has set new records for both the baseline Greeks benchmark and the large Greeks benchmark. Read more…

By Tiffany Trader

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

Intel and Trump Announce $7B for Fab 42 Targeting 7nm

February 8, 2017

In what may be an attempt by President Trump to reset his turbulent relationship with the high tech industry, he and Intel CEO Brian Krzanich today announced plans to invest more than $7 billion to complete Fab 42. Read more…

By John Russell

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