More Intel multi-core info...

[Vertizor]

In the short term future, yeah multi-core is fundamentally more beneficial than 64-bit computing. I wish they'd done multi-core first, then worry about consumer level 64-bit computing.

[lots]

Considering how the Athlon64/Opteron was designed, I would guess AMD planned to tackle both at the same time.. The Athlon64/Opteron were designed with dual core in mind, on top of the 64bit computing. Intel chips were not designed for either :P Though, you can bet the next generation ones will be..

[novadude]

Considering how the Athlon64/Opteron was designed, I would guess AMD planned to tackle both at the same time.. The Athlon64/Opteron were designed with dual core in mind, on top of the 64bit computing. Intel chips were not designed for either :P Though, you can bet the next generation ones will be..

and those next gen chips will be here sometime around 2007 :) In the time between then and now, Intel will try to get the world hooked on IA-64 again and fail. Then they will "reinvent" the PC market, by reengineering AMD's work as AMD rolls out something even better forcing Intel to play catch up again :buttrock:

[elvis]

In the short term future, yeah multi-core is fundamentally more beneficial than 64-bit computing. I wish they'd done multi-core first, then worry about consumer level 64-bit computing.

The problem there is that 64bit extensions to x86 are far easier to add than dual-core.

You're talking a whole new method of communicating between CPUs, modifications to system busses, heat issues, power issues, etc, etc. 64bit migration was exponentially easier from an engineering perspecive, and thus came first.

As for the original topic: most things I use day to day are SMP aware. I don't see multi-core "shaking up" the development community that much at all. About the only things that I use these days that aren't SMP able are consumer-level graphics APIs (the two most common being Direct3D and OpenGL). For these to become SMP-aware would basically require an entire re-write, and I don't see that happening for some time due to the complexity concerned with realtime graphics dealing with common SMP problems like thread starvation and whatnot.

In the meantime, most commerical renderers are able to be run in AMP (Asymetric - ie: one process per CPU) these days. So for most of us, dual-core will be a fairly easy upgrade, and one that will bring immediate reward.

[dotTom]

The problem there is that 64bit extensions to x86 are far easier to add than dual-core.

You're talking a whole new method of communicating between CPUs, modifications to system busses, heat issues, power issues, etc, etc. 64bit migration was exponentially easier from an engineering perspecive, and thus came first.

As for the original topic: most things I use day to day are SMP aware. I don't see multi-core "shaking up" the development community that much at all. About the only things that I use these days that aren't SMP able are consumer-level graphics APIs (the two most common being Direct3D and OpenGL). For these to become SMP-aware would basically require an entire re-write, and I don't see that happening for some time due to the complexity concerned with realtime graphics dealing with common SMP problems like thread starvation and whatnot.

In the meantime, most commerical renderers are able to be run in AMP (Asymetric - ie: one process per CPU) these days. So for most of us, dual-core will be a fairly easy upgrade, and one that will bring immediate reward.

x64 and multi core solve fundamentally different problems and can't be directly compared as "one is better than the other". You might be able to make a case for one being of more immediate practical use to the majority of computer users (not just graphics folks) in the short term.

The reason multi core will shake up the development community is because it finally brings about "prevalent SMP". A lot of applications, and I'm setting my scope wider than just graphics apps, up till now have been minimally threaded. They've done this because they've enjoyed the year on year dramatic increase that "single threaded" (let's ignore virtual processor technology like Hyper Threading for a moment) processors have offered. The vast majority of applications have ignored threading within their core functionality simply because SMP boxes are rare compared to the vast majority of single processor boxes. Where apps are threaded they typically use it for "background tasks" etc. I'm not for a moment suggesting that every algorthim is amenable to threading, it isn't, but I do think that application architectures are going to have to be a damn sight more threaded than they are today. For example, compare the UI architecture in Cinema 4D to that in Maya (and I'm a fan of the later). C4D's is far more pleasant to use in terms of true concurrent updates and also makes better use of my processors when *not* rendering. I very seldom see Maya go above 50% (assuming 2 CPUs) outside of it's render loop.

If you're at all interested in the impact on the software business as a whole then read this:

http://www.gotw.ca/publications/concurrency-ddj.htm

[lots]

Not that a Hyper Threaded CPU is capable of executing more than one instruction at a time or anything. It still is ONE physical CPU, so only one instruction can get fed through at a time. ;)

[elvis]

x64 and multi core solve fundamentally different problems and can't be directly compared as "one is better than the other". You might be able to make a case for one being of more immediate practical use to the majority of computer users (not just graphics folks) in the short term.

I didn't say one was better than the other. I merely said one was easier to implement than the other.

And again, very single app I use today is mutli-threaded (again, bar graphics APIs). It *might* have something to do with me being a linux user, but SMP support is available in almost every single app I run.

Dual core CPUs for my particular platform and development won't shake anything up. Perhaps for Windows users it might do so a little more.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.