Compilers and More: Parallel Programming Made Easy?

By Michael Wolfe

September 2, 2008

Look at all the current research projects aimed at exactly that: making parallel programming easy!

The NESL language aims to “make parallel programming easy and portable.” More precisely, its goal is to allow programmers “to write parallel code as concisely and clearly as sequential code, while achieving close to peak performance.”

Microsoft’s Parallel Computing Platform team aims to provide a runtime that provides support for parallelism, models, libraries and tools that “make it easy for developers to construct correct, efficient, maintainable and scalable parallel programs.”

The CxC (C by C) language has one-sided communication operations, “which makes parallel programming easy and efficient.”

My alma mater, the University of Illinois, has a new Universal Parallel Computing Research Center, whose goal is simply “Making parallel programming easy.” Marc Snir, the Computer Science Department head, said the goal for this effort is to “make ‘parallel programming’ synonymous with ‘programming’.”

The Parallel Computing Lab at the University of California at Berkeley has adopted the goal to “make it easy to write correct programs that run efficiently on manycore systems, and which scale as the number of cores doubles every two years.”

Intel’s Threaded Building Blocks (TBB) extends C++ for parallelism in an easy to use and efficient manner.

Tim Mattson (Intel) points out that in “our quest to find that perfect language to make parallel programming easy,” we have come up with an alarming array of parallel programming choices: MPI, OpenMP, Ct, HPF, TBB, Erlang, Shmem, Portals, ZPL, BSP, CHARM++, Cilk, Co-array Fortran, PVM, Pthreads, Windows threads, Tstreams, GA, Java, UPC, Titanium, Parlog, NESL, Split-C, and on and on.

Tim and I are colleagues on the OpenMP Language committee, which recently finalized the OpenMP 3.0 standard. OpenMP’s mission is to define a “portable, scalable model that gives shared-memory parallel programmers a simple and flexible interface for developing parallel applications for platforms ranging from the desktop to the supercomputer.” Is simple even easier than easy?

Every time I see someone claiming they’ve come up with a method to make parallel programming easy, I can’t take them seriously. First, “making parallel programming easy” must be harder than “making programming easy,” and I don’t think we’ve reached that first milestone yet. Yes, I can (and do) knock off quick programs to search or compute something simple, but then I can knock off a quick project to build a bridge over the seasonal stream in our backyard, too. I wouldn’t trust that bridge to freeway traffic, and I wouldn’t trust that quick program to solve anyone else’s problem, either.

All this is folly. I agree with Andrew Tanenbaum, quoted at the June 2008 Usenix conference: “Sequential programming is really hard, and parallel programming is a step beyond that.” Yes, programming is really hard. Look at the programming effort it takes to produce a well-supported world-class application. If it were easy, Microsoft wouldn’t need legions of programmers to develop and support its software. If sequential programming were a solved problem, we wouldn’t have the relatively recent introductions of new and successful languages, such as Java, and C#.

Consider any software development project. Typically it begins with discussion of interfaces (with other software, with data, with users), standards (programming language, operating system, formats), and requirements (functionality and performance). Often, a prototype implementation is developed and tested. One of the tests will involve performance, especially at the limits of the expected input. If the performance is satisfactory, no further tuning is necessary. If not, the team will look at alternative implementations, different algorithms, data structures, shortcuts, etc.; one of the schemes will be to use more parallelism.

In fact, the ONLY reason to consider parallelism is for better performance. Parallelism by itself doesn’t deliver any new features or functionality; it may allow you to deliver new functionality because of improved performance, but the parallelism itself didn’t create the functionality. Most of the programs I write don’t need parallelism because they don’t take long enough to matter. Only those with large datasets or lots of computation are even candidates. I’d be wasting my time and my employer’s resources adding complexity to my program in order to use parallelism that I don’t need.

Moreover, parallelism does not equate to performance. The focus needs to be not on parallelism, but on performance, where parallelism is one of the tools to get it.

Time and again we hear advocates claiming that if you just use their compiler, language, library, tool, methodology, etc., they will guarantee good performance now and forevermore. Yet each time around, the methods are limited to the technology of the day. Let’s look at an example algorithm, matrix multiplication:

   for i in 1:n
     for j in 1:n
       for k in 1:n
         c(i,j) = c(i,j) + a(i,k)*b(k,j)

Early compilers were tuned to optimize just such programs. As pipelined functional units were introduced, libraries were written to replace the inner kernel loops, such as STACKLIB and the BLAS; we could write this loop using a DAXPY call:

   for j in 1:n
     for k in 1:n
       daxpy( n, b(k,j), a(1,k), 1, c(1,j), 1 )
       ! equivalent to:
       ! for i in 1:n
       !   c(i,j) = c(i,j) + b(k,j)*a(i,k)

The library routines were rewritten in vector mode in the 1970s. However, it was soon realized that you could achieve even higher vector performance, called supervector performance, if you optimized the inner two loops to take advantage of vector register locality. Thus came the level-2 BLAS, implementing matrix-vector operations. Matrix multiplication turned into a loop around a DGEMV call:

   for j in 1:n
     dgemv( ‘n’, n, n, 1.0, a(1,1), n, b(1,j), n, 1.0, c(1,j), 1 )
     ! equivalent to:
     ! for k in 1:n
     !   for i in 1:n
     !     c(i,j) = 1.0*c(i,j) + 1.0*b(k,j)*a(i,k)

This was sufficient until the microprocessor revolution, where cache behavior dominated the processor performance. We then were given the level-3 BLAS, implementing matrix multiplication in a single call to DGEMM, which could then be appropriately tiled, unrolled, vectorized, and optimized for each machine. Now we’re in the multicore or manycore era, and who knows where it will lead in the next decade or two? Given how well we’ve predicted what the machines of the future will look like, can we design the universal programming model today?

One aspect of computer science is algorithm analysis, studying the computational and memory requirements of an algorithm. We learn how to reverse a linked list in linear time and constant space. We learn about the differences between bubble sort (O(N^3)), quicksort (O(N log N) on average, easily parallelizable) and heapsort (O(N log N) worst case, and my personal favorite). We learn to pay attention to the hidden constants in the big-O notation, since the constant factor can dominate the computation cost for reasonable inputs; thus, O(N^3) is almost always worse than O(N^2), but O(N log N) with a small constant may be better than O(N) with a big constant, for the expected cases.

For instance, in compilers, no one ever uses the linear time algorithm for computing dominators, because the constant factor is too big. We learn that the analysis usually translates directly to the actual performance. And we learn tricks, like hash table lookup, to work around difficult performance problems. None of this depends on the particular programming language or processor; the von Neumann model has served us well.

Algorithm analysis for parallel computing studies parallelism models, such as Bulk Synchronous Parallel (BSP), Communicating Sequential Processes (CSP), Data-Flow, and so on. These models make assumptions about the cost (or lack thereof) for synchronization and communication. Until we have machines that implement these models more closely, we need to take into account the cost of the virtualization as well. It doesn’t matter how efficient an algorithm is in some abstract machine model if the implementation of the abstract model is itself expensive.

The current “parallelism crisis” can only be resolved by three things. First, we need to develop and, more importantly, teach a range of parallel algorithms. When we teach sorting, we take into account in-core vs. out-of-core, the cost of doing a comparison, and the cost of copying the data versus using indices. Different sort algorithms work better with different dataset characteristics. Similarly, we must teach a range of parallel algorithms, so a programmer knows what dataset and system characteristics will affect the performance, and hence the choice of algorithm.

Second, we need to expand algorithm analysis to include different parallelism styles. It’s not enough to focus on just the BSP or SIMD or any other model; we must understand several models and how they map onto the target systems. We’ve become lazy; the sequential von Neumann model has been sufficiently universal that we think we can use a single model to cover all computing. Yes, this sounds like work, and it sounds like we’re going to have to think for a living.

Finally, we need to learn how to analyze and tune actual parallel programs. Sequential performance tuning has largely been reduced to (at most) profiling to find the computationally-intensive region of code, and either choosing a more efficient algorithm, choosing a different set of compiler flags or different compiler, or using a canned library routine. Advanced analysis may consider cache bandwidth and interference or operating system jitter. Parallel performance analysis is subject to many more pitfalls. Threads or processes may be delayed due to synchronization or communication delays; shared cache usage may cause additional interference; NUMA memory accesses may require more careful attention to memory allocation strategies. Program analysis tools can help here.

Stanford’s Computer Science Department Chair, Bill Dally, is quoted as saying “parallel programming is perhaps the largest problem in computer science today and is the major obstacle to the continued scaling of computing performance that has fueled the computing industry, and several related industries, for the last 40 years.” David Patterson, former ACM president and head of the Parallel Computing Laboratory at Cal Berkeley, said that “in order for parallelism to succeed, it has to result in better productivity, efficiency, and accuracy.”

Parallel processing is an obstacle, but then so is sequential processing. Parallel computing can result in better productivity, efficiency, and accuracy in the scientific process overall, but it’s silly to think that it will result in better productivity and efficiency in the programming process itself. The best we can hope for is to make parallel programming not much harder than sequential programming. Dally himself is giving a keynote speech at the International Conference on Parallel Processing in Portland in September titled “Streams: Parallel Programming Made Simple.” There’s that simple word yet again.

That’s not to say there aren’t problems to be solved. There are, and parallel programming is going to continue to be a problem. However, unlike the doomsayers and the simplifiers, I think these are hard problems, but not impossible. We solve hard problems every day. We’ve already developed several successful, widely-used parallel programming paradigms, including MPI and OpenMP. They may not be perfect, universal models, but we should learn what worked. And we have as much to learn from proposed models that did not succeed or survive, such as High Performance Fortran.

And, frankly, I have confidence in the applications programmer’s ability to develop algorithms and approaches to using parallelism. Apparently, many in the computer science community do not.

—–

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!

Graphcore Readies Launch of 16nm Colossus-IPU Chip

July 20, 2017

A second $30 million funding round for U.K. AI chip developer Graphcore sets up the company to go to market with its “intelligent processing unit” (IPU) in 2017 with scale-up production for enterprise datacenters and Read more…

By Tiffany Trader

Fine-Tuning Severe Hail Forecasting with Machine Learning

July 20, 2017

Depending on whether you’ve been caught outside during a severe hail storm, the sight of greenish tinted clouds on the horizon may cause serious knots in the pit of your stomach, or at least give you pause. There’s g Read more…

By Sean Thielen

Trinity Supercomputer’s Haswell and KNL Partitions Are Merged

July 19, 2017

Trinity supercomputer’s two partitions – one based on Intel Xeon Haswell processors and the other on Xeon Phi Knights Landing – have been fully integrated are now available for use on classified work in the Nationa Read more…

By HPCwire Staff

Fujitsu Continues HPC, AI Push

July 19, 2017

Summer is well under way, but the so-called summertime slowdown, linked with hot temperatures and longer vacations, does not seem to have impacted Fujitsu's output. The Japanese multinational has made a raft of HPC and A Read more…

By Tiffany Trader

HPE Extreme Performance Solutions

HPE Servers Deliver High Performance Remote Visualization

Whether generating seismic simulations, locating new productive oil reservoirs, or constructing complex models of the earth’s subsurface, energy, oil, and gas (EO&G) is a highly data-driven industry. Read more…

Researchers Use DNA to Store and Retrieve Digital Movie

July 18, 2017

From abacus to pencil and paper to semiconductor chips, the technology of computing has always been an ever-changing target. The human brain is probably the computer we use most (hopefully) and understand least. This mon Read more…

By John Russell

The Exascale FY18 Budget – The Next Step

July 17, 2017

On July 12, 2017, the U.S. federal budget for its Exascale Computing Initiative (ECI) took its next step forward. On that day, the full Appropriations Committee of the House of Representatives voted to accept the recomme Read more…

By Alex R. Larzelere

Summer Reading: IEEE Spectrum’s Chip Hall of Fame

July 17, 2017

Take a trip down memory lane – the Mostek MK4096 4-kilobit DRAM, for instance. Perhaps processors are more to your liking. Remember the Sh-Boom processor (1988), created by Russell Fish and Chuck Moore, and named after Read more…

By John Russell

Women in HPC Luncheon Shines Light on Female-Friendly Hiring Practices

July 13, 2017

The second annual Women in HPC luncheon was held on June 20, 2017, during the International Supercomputing Conference in Frankfurt, Germany. The luncheon provides participants the opportunity to network with industry lea Read more…

By Tiffany Trader

Graphcore Readies Launch of 16nm Colossus-IPU Chip

July 20, 2017

A second $30 million funding round for U.K. AI chip developer Graphcore sets up the company to go to market with its “intelligent processing unit” (IPU) in Read more…

By Tiffany Trader

Fine-Tuning Severe Hail Forecasting with Machine Learning

July 20, 2017

Depending on whether you’ve been caught outside during a severe hail storm, the sight of greenish tinted clouds on the horizon may cause serious knots in the Read more…

By Sean Thielen

Fujitsu Continues HPC, AI Push

July 19, 2017

Summer is well under way, but the so-called summertime slowdown, linked with hot temperatures and longer vacations, does not seem to have impacted Fujitsu's out Read more…

By Tiffany Trader

Researchers Use DNA to Store and Retrieve Digital Movie

July 18, 2017

From abacus to pencil and paper to semiconductor chips, the technology of computing has always been an ever-changing target. The human brain is probably the com Read more…

By John Russell

The Exascale FY18 Budget – The Next Step

July 17, 2017

On July 12, 2017, the U.S. federal budget for its Exascale Computing Initiative (ECI) took its next step forward. On that day, the full Appropriations Committee Read more…

By Alex R. Larzelere

Women in HPC Luncheon Shines Light on Female-Friendly Hiring Practices

July 13, 2017

The second annual Women in HPC luncheon was held on June 20, 2017, during the International Supercomputing Conference in Frankfurt, Germany. The luncheon provid Read more…

By Tiffany Trader

Satellite Advances, NSF Computation Power Rapid Mapping of Earth’s Surface

July 13, 2017

New satellite technologies have completely changed the game in mapping and geographical data gathering, reducing costs and placing a new emphasis on time series Read more…

By Ken Chiacchia and Tiffany Jolley

Intel Skylake: Xeon Goes from Chip to Platform

July 13, 2017

With yesterday’s New York unveiling of the new “Skylake” Xeon Scalable processors, Intel made multiple runs at multiple competitive threats and strategic Read more…

By Doug Black

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 a 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. Just how close real-wo Read more…

By John Russell

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 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

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 cam 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

Nvidia’s Mammoth Volta GPU Aims High for AI, HPC

May 10, 2017

At Nvidia's GPU Technology Conference (GTC17) in San Jose, Calif., this morning, CEO Jensen Huang announced the company's much-anticipated Volta architecture a Read more…

By Tiffany Trader

Facebook Open Sources Caffe2; Nvidia, Intel Rush to Optimize

April 18, 2017

From its F8 developer conference in San Jose, Calif., today, Facebook announced Caffe2, a new open-source, cross-platform framework for deep learning. Caffe2 is the successor to Caffe, the deep learning framework developed by Berkeley AI Research and community contributors. Read more…

By Tiffany Trader

Leading Solution Providers

How ‘Knights Mill’ Gets Its Deep Learning Flops

June 22, 2017

Intel, the subject of much speculation regarding the delayed, rewritten or potentially canceled “Aurora” contract (the Argonne Lab part of the CORAL “ Read more…

By Tiffany Trader

Reinders: “AVX-512 May Be a Hidden Gem” in Intel Xeon Scalable Processors

June 29, 2017

Imagine if we could use vector processing on something other than just floating point problems.  Today, GPUs and CPUs work tirelessly to accelerate algorithms Read more…

By James Reinders

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

Google Debuts TPU v2 and will Add to Google Cloud

May 25, 2017

Not long after stirring attention in the deep learning/AI community by revealing the details of its Tensor Processing Unit (TPU), Google last week announced the Read more…

By John Russell

Russian Researchers Claim First Quantum-Safe Blockchain

May 25, 2017

The Russian Quantum Center today announced it has overcome the threat of quantum cryptography by creating the first quantum-safe blockchain, securing cryptocurrencies like Bitcoin, along with classified government communications and other sensitive digital transfers. Read more…

By Doug Black

Groq This: New AI Chips to Give GPUs a Run for Deep Learning Money

April 24, 2017

CPUs and GPUs, move over. Thanks to recent revelations surrounding Google’s new Tensor Processing Unit (TPU), the computing world appears to be on the cusp of Read more…

By Alex Woodie

Top500 Results: Latest List Trends and What’s in Store

June 19, 2017

Greetings from Frankfurt and the 2017 International Supercomputing Conference where the latest Top500 list has just been revealed. Although there were no major Read more…

By Tiffany Trader

Six Exascale PathForward Vendors Selected; DoE Providing $258M

June 15, 2017

The much-anticipated PathForward awards for hardware R&D in support of the Exascale Computing Project were announced today with six vendors selected – AMD Read more…

By John Russell

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