Nick Harris – Having experienced and even participated in just such hype 15 years ago about how every computer would have a DSP, I don’t believe you, and I don’t think you have considered the issue in full. Special processors are disliked by consumers because they end up costing more (since each has its own memory, bus, small OS in each, etc.). Special processors are disliked by developers because they have to write code for them, especially since the special processors usually require assembly coding to maximumize their speed.

There are two problems with, “brilliant AI on one core, audio on another core and graphics on a third.” The first is that one process will almost always dominate all other processes and so the extra cores will be idle most of the time while the entire game is bottlenecked by the most expensive process. The second is that each of those tasks is going to be consuming lots of memory, both RAM and cache. Depending on how you set things up you may actually slow down the entire process by distributing it just because you your distributed cache isn’t too slow for whatever your bottleneck operation happens to be at the moment.

The bottom line is that distributed/parallel computing is a lot less useful in practice than it sounds. To get really good results requires both a problem that is amenable to parallel processing (and a lot aren’t) and endless fine-tuning. And even then there are many problems where more processors won’t help at all (a lot of tasks are just far too sequential).

I think the 360 and other next-generation consoles will see a huge difference graphically in the future due to their isolation of tasks. (IE processor one processing graphics, processor two spending more time then previously allowed for brilliant artificial intelligence, and processor three focuses on audio and managing the other two.) You are judging the next-generation consoles on the first games released for them. The first games rarely take full advantage of a new consoles potential.

Thirdly, I agree that writing programs to operate this way is difficult for old hacks like us who learned on single processors, but I think as new programmers are taught on multi-core processors, and classes in colleges focus more closely on this, it will become a more intuitive and second natured ability for most programmers of the future. Also side-note I think there will be many more extensions to graphics APIs, compilers, coding languages that will take advantage of the multi-core processors in the furture.

Have you written much parallel code? Having done so I can say two things:

1) It’s very hard. Programming even a simple task in parallel to get even a two-time speedup can be a huge chore.

2) For most problems there are natural bounds to how much parallelism you can harness before communication overhead, memory bandwidth and dependencies lock you down. If you can’t get the data to your processors, or can’t do anything on all your other processor until one processor finishes then it doesn’t matter how many processors you have.

This is why the next gen consoles aren’t that much of an improvement over the last gen. They have lots of processing power across lots of cores. However they provide only marginally better memory size/bandwidth than the past generation. They can crunch a lot of numbers, if and only if they could actually get those numbers to the cores, which they can’t, and performance is only slightly better than the past generation.

For one, when CPUs reach (about) 8 cores, you’ll find that suddenly graphics accelerators aren’t needed, since 8 non-optimized CPU cores should match an optimized GPU.

In early 1990, speech recognition could only be done on a DSP. Then came the Pentium with floating point, and speech recognition was done on that. DSP cards for PCs disappeared (not that there were many in the first place). A DSP is still faster at FFTs, but it doesn’t really matter. Cost/flexibility tradeoffs for the user means that they’ll go for the cheaper solutions, which will ultimately be CPU-based rendering.

Music synthesis used to be done on a DSP too, although it wasn’t called that. It was called a sound card with 16-voice polyphony. Now-a-days, unless you buy a high-end sound card, the synthesis is done on the CPU. Sound cards used to do MPEG decompress, but now its all CPU.

Furthermore, as graphics quality gets better (aka: ray tracing), you’ll find that GPUs, which are vector processors, don’t do any better than CPUs.

Of course, if you’re writing casual games, none of this matters… unless your casual games start using 3D, speech recognition, music synthesis, etc. Even then, you won’t have to worry much about multithreaded code yourself.

Another note: Dual-core computers came out Q1 2007. Quad-core computers will be out around Q1 2007 (as far as I recall), doubling once every 24 months instead of every 18.

But games, for instance, are much less of a CPU driver these days, as more people are playing the high-end 3D games on consoles and using their PCs for lighter weight fare (including casual games). And to the extent that CPU busting games ARE still out there (i.e. 3D shooters, WoW, etc), they’re bound much more by graphics card than by CPU, in general.

Otherwise, the last few years have seen a lot more web-type things, and a lot of music-type things. Neither of those are very CPU bound. Video, maybe, but that’s still more a question of bandwidth than CPU, for the most part.

~phil

If your parents are running software like your common antivirus solutions, these sit in the backround always scanning memory, always looking at incoming web traffic on the integrated firewall, etc. This takes a lot of cycles. This is exactly the sort of thing that going dual cpu is going to help with. Granted, on a windows machine, I/O is still a bigger bottleneck with such software, because of win32 kernel issues with DMA (not always using it). Thus, disk writes hurt extra because you’re hitting the BIOS for disk writes, freezing the whole system with a hardware interupt. Adding more memory to prevent paging alleviates most of this problem.

Most adult users seem to use 1 program at a time, but the generations who have grown up with computers multitask- a lot. My neice isn’t particularly computer literate, but I’ve never seen her use a computer without 6 different applications running the foreground, with multiple backround tasks (downloading files, ripping CDs, mp3 player, rss feeds, etc.).

Also keep in mind that OSes (let alone applications) have never really been optimised for multiple cpus outside of the CS research community. Techniques do exist for getting high performance across multiple (and many, 8+) cores, but they’ve never been implimented in a production environment. Expect the XBox 360 to change that; and since the 360 has a non-power-of-two number of CPU cores (3), there will probably be a bit of new computers science generated by dealing with that.

100% improvement every 18 months equals ~58.7% improvement annually.

So, by comparison on this simple measure, the rate of annual improvement has dropped to about a quarter of what it was just a few years earlier.

And the road map for near-term future CPU improvements shows things probably getting flatter in years ahead – again, with the push for multi-core, which sounds splashy (TWICE as many CPUs as your old machine!) but in fact has a quite low impact on effective speed (in my opinion).