Interesting, but ...
It's an interesting article - thanks for the link.
He seems to gloss over an elephant in the room though, namely existing applications. There's a lot of existing code baggage that needs to be moved to new machines every few years. People aren't going to be rewriting 10^10 lines of Cobol in some sort of hyperthreaded, Concurrent-compliant, uberframework. Systems will get better at executing existing code as well or manufacturers won't be able to sell as many machines.
How will they get better? He's right that CPU speed isn't going to increase as fast as before. He's right that on-chip cache sizes will increase (at least to some extent). But I think he's minimizing the difficulty in taking "full" advantage of threading, etc. NCR and others had 32+ CPU boxes ~ 10 years ago, IIRC. OS/2 has had threading for many, many years. There is not going to be a quick transition to hyperthreaded applications if the past is any guide. Unless there are good software tools to do it.
What I do see happening, potentially, is some small company coming up with a plug-in VM-like system that sits on the OS or on the hardware and lets existing applications take better advantage of parallelism in the hardware. Maybe DesqView will have a renaissance. ;-) The folks at VMWare showed that a lot of interesting and effective virtualization could be done on x86 machines that many thought was too difficult to do well. With larger registers, multiple cores, etc., such virtualization should become easier in the future.
He may be right about the importance of understanding concurrency, especially if the Cell processor takes off. It would have been a better article if he could have tied the Cell in, but I guess a lot of the design aspects of it are still under NDA.
My $0.02.
Cheers,
Scott.
(Who anxiously awaits a concurrent 64-bit hyperthreaded ping.)
