A year or so ago I noticed the news that Intel were experimenting with an 80 core processor. I was worried... multi-core processors are now standard; people are starting to write software to take advantage of this. But concurrent programming is hard. I run a team with some good programmers in it, but in most pieces of code I see that use threads and synchronisation I can usually find a subtle threading bug. These bugs are not the kind of thing you can test for with all the nice unit testing tools that we normally use.
I was lucky to attend a talk at QCON2008 by Joe Armstrong. He pointed out no-one in the hardware world is currently anticipating a limit to scaling by multiple cores; there is anticipation of thousands of cores within the next 10 years. Joe also pointed out Amdahl's Law and noted that if 10% of your program is serial then the most speedup you can get is 10x. This is very thought-provoking: we will need to push concurrent programming into the core of development but, from my own experience, we desperately need new programming paradigms to make sure we don't create terribly buggy software.
Fortunately, maybe there's some help on the horizon. For a start, the Java folks are focussing on fine-grain concurrency features for Java 7 (JSR166y). By using high-level constructs, programmers can describe problems and algorithms in a way that these features can execute effectively on multi-processor systems, yet the constructs are easy to get right.
Even better, we have Erlang, a 20-year old language that has been used in some very hardcore situations (telephone switches) and has a simple and massively scalable concurrency model built into the very core of the language.
The advent of multi-core and the imminent arrival of massively multi-core processors makes this a very good time to be learning more about Erlang and the concurrency features planned for your language of choice.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment