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.