A number of comments on my last post suggested I work on multi-core parallelism. There are a number of reasons why I am steering clear of that topic.
First of all, it seems everyone is doing it, and I hate crowds. Secondly, I was heavily involved in the early days of multithreading and transactions back in the 70′s and 80′s. Been there, done that, got the Lucite trophy.
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.
There are only two groups that want multicore. One is the computer hardware industry, which has become addicted to rapid obsolescence, and whose sales will fall if computers start lasting more than a few years. The other group is researchers looking for a topic. Multicore programming is an irresistible bait for researchers: it is a hard puzzle, with quantifiable results, and a shot at changing the world. Unfortunately it is turning out that there is little quantifiable difference between the plethora of alternatives, leaving it as a matter of subjective judgment, which they hate. I already see signs that the multicore research frenzy has peaked.
That said, Subtext does suggest a transactional model of computation related to some of the recent research. But parallelism is just a possible side-benefit. The point is to allow the programmer to express their intent without having to mentally compile a linear execution schedule. Performance is not the problem. Write that on the board 100 times.
Update: It looks like I really stepped in it this time, so let me clarify my position.
Giving a multicore CPU to a programmer is like giving a drink to an alcoholic. Saint Knuth taught us that premature optimization is the root of all evil. I’m here to tell you that virtually all of programming is premature optimization. Once, just once, try to write a program without ever thinking about performance. I know I can’t. We have this fatal attraction to performance problems: they are just so shiny and clear-cut: a chance to be clever with a well-defined problem. The other issues we grapple with in programming are so vague and ambiguous and ultimately unknowable. But those are the essential issues, and thinking about performance is a distraction from them.
Inventing new programming languages and techniques to get better performance on multicore chips goes completely in the wrong direction. We should be figuring out how we could improve programming given unbounded performance. Then figure out how to optimize it. I have come to believe that our programming languages and design patterns are all a giant case of premature optimization. So maybe we need multicore, and maybe we need to complicate programming as a result, but it is just digging ourselves deeper into the hole we’re in, and should not be celebrated.
Update: see rebuttal in next post.