"Performance is not the problem," a vote against multicore

I like contrarians. Probably because I’m usually too lazy to avoid group think myself, and I’m glad to be saved the effort. Jonathan Edwards, a Research Fellow at MIT, isn’t excited about the move to multicore

More importantly, I believe the whole movement is misguided. Remember that we already know how to exploit multicore processors: with now-standard multithreading techniques. Multithreaded programming is notoriously difficult and error-prone, so the challenge is to invent techniques that will make it easier. But I just don’t see vast hordes of programmers needing to do multithreaded programming, and I don’t see large application domains where it is needed. Internet server apps are architected to scale across a CPU farm far beyond the limits of multicore. Likewise CGI rendering farms. Desktop apps don’t really need more CPU cycles: they just absorb them in lieu of performance tuning. It is mostly specialized performance-intensive domains that are truly in need of multithreading: like OS kernels and database engines and video codecs. Such code will continue to be written in C no matter what.

The context for this post is that Jonathan is looking for a research topic, not pontificating idling on how the world should be. I think he’s possibly correct on the “vast hordes” thing, and I agree about where multithreaded code is likely to have an impact.

But there is some pretty neat stuff that can be done in OS kernels, database engines, and video codecs. With the extra power available to them, programmers could start to spend more time attending to the needs of their users, rather than forcing their users to express their needs in the limited vocabulary of a performance-constrained application. There are a lot of helpful things we know how to do with human-computer interfaces that have simply been too resource-intensive. With new cycles lying around for the taking, any work that makes computerized tools fit more naturally into human workflow is work worth doing. Note that this does not include adding a “wood grain” effect to 3D bar charts in PowerPoint.

Read the rest of the post at Jonathan’s blog.

Trackbacks

  1. […] An interesting view on this story and comments in this post on insideHPC. “Performance is not the problem,” a vote against multicore […]

Comments

  1. I appreciate a contrarian opinion, but I think Jonathan is looking at this backwards. The history of computing and of technology in general is one of exponential growth enabling unprecedented benefit to society.

    It’s too simplistic to say “Performance is not the problem”. Performance is *always* a problem in HPC, and HPC is integral to technology advancement and competitive growth. In areas where performance is not a “problem”, a lack of enabling capability growth would still be detrimental.

  2. HPCer – you have more succinctly framed in your first paragraph the point I was making toward the end of my post. You’ve also added on an angle I didn’t, which is of course that performance _is_ the motivating problem in HPC. My only slight addition to your comment is that I’m not sure that multicore is helping our performance problem. The real shame I see is that codes only get 1-5% of peak on modern processors, and that number is getting worse, not better. If we’re having a chip architecture revolution, I would rather have had one that lets us use more of what we’re paying for.

  3. It’s a fact of life that I (an HPC professional) am nowhere near as influential on processor companies as my Mom (a PC user). Multicore really isn’t a revolution, more like a mainstream evolution that the HPC world must assimilate.

    That said, there’s great opportunity in the “cheap” capacity that multicore can offer. If you really want to change the world, make a $25K box of cores easy enough for a small company to use for HPC. Sounds simple, but it really isn’t. Microsoft sees the potential and they’ve finally started to overcome hubris that was holding their HPC back. A lot of academia is caught up in esoteric approaches for emerging platforms which might be more sexy in a proposal but are a lot further from the rubber meeting the road.