The problem - in any kind of close-coupled multi-processing, you hit a point of diminishing returns as you add processors, where the coordination overheads become larger than the gains - has been obvious for quite a while. Gene Amhdal pointed it out in the early seventies. The chip manufacturers' engineers know this perfectly well, but marketing departments have been caught up in the race to the most cores, and kept on demanding them. It's just like the megahurtz wars.

They will, of course, point out that they are answering the point by putting more memory controllers onto processors - Intel's forthcoming Nahalem has three, while Sun's UltraSPARC T2 has eight - but this only moves the bottleneck elsewhere. The penalties for coordination between memory busses may become the problem, or else something else. But there isn't a Happy Hunting Ground of unrestrained parallelism out there waiting for Moore's Law to go far enough. There's only more and more struggle to make it work.

I don't expect that the manufacturers will change strategy soon; given that some kinds of code don't need much coordination, there will be example cases they can claim as "programming the right way" for quite a while. But there is no one right way, and no simple route; anyone who claims to have found it is fooling himself, usually by looking at a small set of problems, and claiming his ideas generalise to everything.

I don't know what the next fashion will be; were I given the power to decide, I'd ask either for memory that was a load faster, or some really huge on-chip caches, say half a GB. Those two ideas would have pretty similar effects: reducing the "memory wall". To get really huge amounts of processing power, we're probably going to need to climb out of the Von Neumann playpen, and deal with some different programming model entirely.