I have Google Alerts send me news on three topics:

1. "Eugene Mirman" - my brother is a comedian, and I like to keep tabs on his touring schedule and TV appearances;
2. "Guns N' Roses" - still keeping hope alive that Slash and Axl will reconcile, and the band will reunite;
3. And of course, "MULTICORE" - what's new in the multicore world, advances on the silicon side of things, as well as the programming of multicore chips.

Jonathan Ericson's great column, "Parallelism: It's Everywhere, It's Everywhere" in the May 2nd Dr. Dobb's Report got me thinking. In it, he reports on Stanford University's formation of a Pervasive Parallelism Lab, and reflects on the multicore buzz:

So is all the buzz about parallelism the real deal or is it just more PR? Well, Bill Dally, chair of the computer science department at Stanford, thinks it's the real deal: "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."

Ten minutes later, I received the day's Google Alerts regarding scores of stories dealing with multicore chips, and the various efforts dealing with the programming of these chips. And an hour later, Yahoo! News told me about a whole bunch more. The drumbeat is unmistakable: for everyone involved in computing - vendors of chips, hardware, system and tools software, developers of application software, etc. - the issues around multicore are keeping more than a few of us up at night. The avalanche of news, though, feels like a relatively recent phenomenon, but I wasn't sure - so decided to look. The results surprised me.

Multicore in the News

As a proxy for news coverage, I checked out a few print and on-line sources:

• Dow Jones' Factiva service, great for looking at news coverage in printed publications
• Google News, to capture online news features
• Google Blogs, as a proxy for the blogosphere's attention to multicore

First, here's the Factiva data for the phrase "multicore". An order of magnitude change in coverage in just a couple years, with the "hockey stick" starting sometime around 2004 - my guess is that this related to the first mainstream multicore chips, dual-core x86, hitting the market.

To better focus on stories dealing with the multicore programming, I decided to play around with the search criteria a bit more:

• Volume of printed news stories that have both "multicore" and "programming" in the headline and/or 1st paragraph;
• Volume of online mentions of "multicore programming" in Google News
• And for fun, I searched Factiva for "global warming" mentions

I looked at a bunch of different search terms, and the results are fairly consistent. Here are the results (note that the vertical axis is a log scale).

Here's a Google News timeline for the multicore programming search term:

Couple observations:

1. The growth of coverage for all the search terms appears exponential;
2. Before 2005, there's no record in the Factiva database of a story where "multicore" and "programming" were in the headline and/or lead paragraph;
3. The growth rate for the multicore-related searches is outpacing the growth rate for global warming coverage!!

Multicore in the Blogosphere

This is echoed in the blogosphere as well. Although Google Blog Search is still in beta (and the results change a bit from one run to the next), there's a couple eye-opening stats:

1. In all of 2006, there were 329 blog posts dealing with multicore programming;
2. Last month alone (April 2008), there 434 blog posts on the topic.

Wow! Exponential growth in coverage, perhaps correlated with an exponential growth in the concerns around the topic. The other thing I find curious is the timing: the news coverage "woke up" just as the first multicore processors were hitting the market. But that roadmap was clear years before! And yet, relatively little attention paid, and arguably modest progress in the way of tools to solve the multicore programming challenge.

Calling Al Gore...

Clearly, both global warming and multicore programming are getting a lot of attention these days. And hopefully, there will be progress on both, soon. Al Gore has done a great job alerting the world to global warming, and my hope is that he will now help spread the word about the multicore software challenge. Otherwise, without progress on these two key issues facing the globe, by the year 2022 there will be hundreds of millions of news stories on both topics, and multicore programming will overtake global warming in terms of coverage:

What do YOU Think?

• When did you start worrying about multicore programming?
• Is it time for Al Gore to help the multicore community?

When we decided to spin out the Cilk project from MIT, I think we had a good sense of what was needed by software developers going multicore. After all, we'd been working on the technology in the lab for 15 years and had won numerous awards for our research.

Before committing to a detailed, prioritized feature set and schedule, however, we wanted to really delve into the key issues facing software developers going multicore. To that end, we conducted over 70 in-depth interviews with customer prospects.

Over the course of the interviews, we heard a triad of key themes repeatedly:

1. Development time
2. Software reliability
3. Application performance

Moreover, when we asked these folks to prioritize these three properties in the context of a multicore software solution and name the one property they could most easily live without, ninety percent of them said, "All three are essential. Two out of three won't cut it." Let's look one by one at each issue in this multicore software triad and the challenges it poses for software developers.

Application performance

At some level, performance is what multicore is all about, but for many applications, it's really more about minimizing response time, not just maximizing throughput. Running two copies of the app isn't good enough - you want one copy to run twice as fast, or, as in the games market, you have a "time box" and need to do as much as you can within a given time budget. Application performance is also about scaling. Do you solve the problem once and for all, or are you reimplementing your software as every new processor generation produces chips with more cores? And, does your multicore solution scale down, as well as up, meaning that your multicore-enabled software runs just as fast on one core as your original code, or is there a substantial overhead?

Development time

Every company worries about getting their product out on time. That's particularly hard with multicore, because parallel-programming talent is hard to find. At one $300M company we talked to, they have 200 programmers and a C++ code base of over 7 million lines. We asked how many had any experience with multithreading or other parallel programming technologies. They answered, "You're looking at them." There were 5 software developers in the room. A good software solution to multicore addresses all 200 of their programmers, not just 5. That means a complete redesign of a major app is out of the question, and maintaining multiple sources - the original and a parallel one - is problematic.

Software reliability

Race conditions: the bane of parallel programming! How will you debug your parallel application? How can you test it effectively before release? Unless you can find race conditions, it doesn't matter how fast the execution time or easy the coding process, a race bug can bring it all down. Famous race bugs include the Therac-25 radiation therapy machine, which killed three people and injured several others, and the North American Blackout of 2003, which left over 50 million people without power. These pernicious bugs are notoriously hard to find. You can run regression tests in the lab for days without a failure only to discover that your software crashes in the field with regularity. If you're going to multicore-enable your application, you need a reliable way to find and eliminate race conditions.

Cilk++

In building the Cilk++ platform, the Cilk Arts engineers have worked hard to address all three components of the multicore software triad:

• Application performance: The runtime library provides linear speed-up on applications, while exhibiting virtually no overhead on a single processor.
• Development time: Cilk++ requires programmers to learn only a handful of simple keywords, enabling even junior programmers to develop multicore software.
• Software reliability: The Cilkscreen race detector finds races - guaranteed - localizing them to file, line number, and variable reference, including stack traces.

Share YOUR perspective!

We would love to hear from you:

1. What do you think - does this perception reflect your needs when going multicore? What requirements might the triad miss?
2. How would you prioritize the 3 aspects?
3. Which of the three attributes would you give up, if you had to?