« Ruby debugger hacking | Main | Co-dependent co-processors »
May 03, 2005
One is the loneliest number...
I saw tonight's Slashdot link on Orion's 96 cpu desktop cluster and it got me thinking.
It has 96 1.2GHz x86 cpus, which is an interesting direction to take. I was thinking tonight about how power, speed and price are intertwined with each other, and I wonder if Orion's system is signaling a future trend. More cpus per box, but with relaxed speeds for each core. Their system costs $100k, but the main concept could be used to build cheaper systems than that.
Imagine 32 1.2 GHz cpus (relative to today's Opteron or G5 processors) on a single host. You wouldn't be doing crazy 2-3GHz speeds, which means much less power consumption, and higher tolerances for manufacturing error. Perhaps slower speeds and power consumption would let you fit more cores per die compared to the models that maximize performance-per-core. For example, maybe I can fit four 1.6GHz cores per socket instead of the normal pair of 2.5 GHz cores. More cores with slower speeds means you'll have to utilize each core more fully, though.
Along those lines, I liked Herb Sutter's recent article in DDJ about the coming concurrency revolution, he described how performance-per-core isn't increasing as much as it used to, and how concurrency will soon become a required skill for most developers, similar to how OO is such a common idiom today. I agree!
Concurrency is hard, though. I've been working with threaded software for a couple of years, and the more I learn, the more I realize how damn hard it is to get right. Herb mentioned that perhaps future languages will have greater support for concurrency built-in, and hinted at a future article covering that topic. I'm very much looking forward to reading it.
I don't know when low-level primitives will be a requirement for programming languages, but probably not for a while. I like the new java.util.concurrent package in 5.0, it really expanded my thread toolbox. I bet that future Java releases include more support for concurrency, 5.0 showed that Sun wasn't afraid to make relatively large changes to the language features and syntax.
I think that deeply understanding concurrency will be a great long-term skill to have. I recently started a long-term project so I could spend more of my research/study time learning new things about threaded programming and its philosophy. I'm going to spend 3-6 months refreshing the basics and just doing lots of concurrent programming, and then I'll start to study more deeply on interesting topics that pop up during the first period. I'm guessing there'll be a lot of time spent on locks, transactions, and ordering...
Posted by djb at May 3, 2005 11:34 PM