As you may have noticed, workshops, conferences, and summits on multicore and parallelism seem to be all the rage these days. A recent example is USENIX's second annual workshop on Hot Topics in Parallelism (HotPar '10), which took place on June 14-15 in Berkeley, California. It featured a mix of speakers from academia and industry, with perhaps a bit of a slant toward the former. The usual suspect organizations from the parallel computing universe showed up, including UC Berkeley, Intel, MIT, Stanford University, University of Illinois, Microsoft, NVIDIA, and a handful of others.

The presentations, which delved into everything from parallelizing Firefox and multicore schedulers, to the limits of GPGPU acceleration, have been conveniently posted on the workshop's website. But if you want the Cliff Notes version, Real World Technologies covered the event, and Tarek Chammah has penned a well-constructed article highlighting some of the more interesting HotPar talks.

He also wrapped some context about the nature of parallel programming around the HotPar report. In particular, Chammah reminds us that there are different dimensions to parallelism, namely granularity, regularity, and data sharing patterns; and they are manifested in different forms. Although Chammah covers a few presentations that are a bit esoteric, such as the one on shared states in video games, the whole article is worth a read. That said, I'd like to point to two HotPar presentations that I think everyone should take a look at -- and which are also covered the Real World Technologies piece.

The first is based on a paper (PDF) by Georgia Tech's Richard Vuduc exploring the limits of GPU acceleration. Actually, I covered this topic a few weeks ago in a previous blog, so I won't rehash it here. Suffice to say that the performance claims for GPUs and CPUs must be approached with a healthy level of skepticism. The non-controversial conclusion is that some applications are going to be better suited to one architecture or another. The unfortunate aspect to this is that one may have to do a lot of code tweaking and testing to find out which one is optimal.

The second presentation worth perusing takes a look at the parallelism "problem" from the 50,000 foot-level, specifically from the perspective of cloud computing. Karu Sankaralingam of the University of Wisconsin-Madison says that everyone needn't get so worked up about this parallel computing thing, since it's not the problem people think it is. In his paper, Get the Parallelism out of My Cloud (PDF), Sankaralingam argues that the nature of cloud computing, which seems poised to become the dominant computing paradigm, does not necessitate traditional rocket-science parallelism. Rather it needs concurrency (tasks running at the same time, but unrelated to one another), which is a far easier proposition, software-wise, and can be managed by a small number of software gurus that actually need to program at the level of multicore processors.

Of course, for HPC-types this is not the case. In supercomputers, true parallelism is the norm and it is pervasive. Unfortunately for Sankaralingam, he gave his cloud-parallelism soliloquy in the presence of such people, who took exception to this "Parallelism: What Me Worry" approach. From Chammah's coverage:

...The iconoclastic talk understandably caused a minor ruckus in the room. There were no less than seven questioners lined up to challenge or pillory the speaker, who took it all in stride. It was mentioned by others that though chip throughput performance follows Moore’s Law, latency does not. Dr. [David] Patterson noted that current devices already feature multiple cores, and he bet Karu that a future iPhone will sport 8-10 application programmable cores in a few years with developers taking advantage of their data parallelism in Objective C.

Sankaralingam's point is not without merit, though. Even in the rarified air of high performance computing, high-level languages like C and Fortran are used for most codes, with parallelism superimposed via calls to MPI and numerical libraries. Nobody programs in assembly anymore. And although the average HPC developer needs to know quite a bit more about parallel programming than the average code-slinger, more of the low-level details are probably going to end up being encapsulated in software frameworks, like Ct, Chapel, MATLAB, and so on.

Until then, the parallel programming challenge will continue to be one of the hottest topics in computer science, as well as the industry. My guess is that we will likely see a lot more HotPar workshops before this becomes a solved problem.