when you guys reckon games start to use dual core?

[Davegod]

so when do you guys think games will start to use dual core? not necessarily in a huge way, even if just splitting the load somewhat, so even the basic 3800+ x2 will be easily beating a, say, 4400+ single core in an FPS.

unreal 3?

 

[n0cmonkey]

March.

 

[dnuggett]

Originally posted by: n0cmonkey
March.

 

[DaveSimmons]

What you're describing is in a big way, since it requires over 37% utilization of the second core (3200+ and 1200+ just to match).

I have no idea, but I'm not expecting it for at least another year.

 

[Davegod]

i meant simply load-splitting, rather than multithreading and all the bumf being talked about in certain places suggesting that a second core could be more than just some extra mhz. Mind you, the bumf reads like the usual stuff when marketers are told what gamers want and then try to connect the dots between product and $, followed by a "journalist" rewording press releases.

put another way, I'm looking at a 3700+ san diago or a 3800+ dual core (which is quite a bit more), and all i care about cpu power for is games. but I'm curious why games have been so slow to adopt it. I realise it's bound to be more complex and difficult, i.e. expensive, but i would have thought there would be some half-arsed hackjobs which offload some jobs to the other cpu.

 

[dnuggett]

Originally posted by: Davegod
i meant simply load-splitting, rather than multithreading and all the bumf being talked about in certain places suggesting that a second core could be more than just some extra mhz. Mind you, the bumf reads like the usual stuff when marketers are told what gamers want and then try to connect the dots between product and $, followed by a "journalist" rewording press releases.

put another way, I'm looking at a 3700+ san diago or a 3800+ dual core (which is quite a bit more), and all i care about cpu power for is games. but I'm curious why games have been so slow to adopt it. I realise it's bound to be more complex and difficult, i.e. expensive, but i would have thought there would be some half-arsed hackjobs which offload some jobs to the other cpu.

Dual core hardware was just released. What makes you think they are slow in adoptiing it? Not many users out there to support making games with that capability. Not yet anyway.

 

[n0cmonkey]

The game should get 100% of one CPU and the system should use the other for other tasks.

 

[DaveSimmons]

Originally posted by: Davegod
i meant simply load-splitting,.

For current games IIRC the 3800+ x2 is only as fast as a single-core 3200+. That already accounts for the second core taking over running of some non-game processes.

So unless the game code can assign at least 37% of its work to the second core, the x2 3800+ will be slower for that game than a single core 4400+. It needs to achieve a steady 25% utilization in the game code to match a single-core 4000+.

 

[EagleKeeper]

The OS will load share depending on internal threading in the code.

The more the code/application is threaded, the more the additional H/W can be utilized.

Standard code will usually get no more than 10% of a second CPU; that is one that is heavily I/O intensive.

The above numbers are experience in using NT3.1 on dual 486s.

Numbers may be slightly better due to drivers & newer H/W along with the newer OSs.

Do not expect to see code actually targeted for multiple CPUs (that require process assignment and would fail on single systems).

 

[biostud]

Next summer when Huxley hits the shelves.

 

[Velk]

Originally posted by: EagleKeeper
Do not expect to see code actually targeted for multiple CPUs (that require process assignment and would fail on single systems).

For a developer to write something like that would be unimaginably stupid, not because not enough people have multiple cpus, but mostly because they don't know how *many* multiple cpus that they have.

Expect multi-threaded games with a high degree of thread independence which will benefit from multiple cpus to become far more common over the next year or two, as both xbox360 and ps3 have basically made it a sink or swim proposition.

 

[DaveSimmons]

Originally posted by: Velk
Expect multi-threaded games with a high degree of thread independence which will benefit from multiple cpus to become far more common over the next year or two, as both xbox360 and ps3 have basically made it a sink or swim proposition.

Good point, ironically it may be console ports and PC games that are part of cross-platform projects that first include well-threaded code that runs significantly faster on dual-core systems.

But given how much harder it is to debug multithreaded code where the threads are splitting up a single task and sharing data, expect the next generation of games to be much more buggy. Buy EA games before the second patch only if you really enjoy crashing.

 

[biostud]

Originally posted by: DaveSimmons

Originally posted by: Velk
Expect multi-threaded games with a high degree of thread independence which will benefit from multiple cpus to become far more common over the next year or two, as both xbox360 and ps3 have basically made it a sink or swim proposition.

Good point, ironically it may be console ports and PC games that are part of cross-platform projects that first include well-threaded code that runs significantly faster on dual-core systems.

But given how much harder it is to debug multithreaded code where the threads are splitting up a single task and sharing data, expect the next generation of games to be much more buggy. Buy EA games before the second patch only if you really enjoy crashing.

specially if the U3 Engine is used for all three platforms.

 

[SonicIce]

Isn't UT2004 multithreaded? Like it uses the 2nd core for sound or something.

 

[luigi1]

My thoughts? Not untill the motherboards and chipssets settle. But I'm allways driven to buy the games. Ill guess a year to 18 months. The game developers want to be used by as wide an group as they can. Joe sixpack dosnt know about this yet.

 

[DaveSimmons]

Originally posted by: SonicIce
Isn't UT2004 multithreaded? Like it uses the 2nd core for sound or something.

Sound uses very little CPU so it doesn't help much. Many games use some threading, but like Doug said that might make a dual-core run a game 10% faster than a single core clocked at the same speed.

To make a real improvement there is typically some thread that is doing most of the data crunching, and it is written to work sequentially, for example to update the position of every object on a map one-by-one.

To really speed up a game you need to split that heavily-loaded task into 2 threads running in parallel, each sharing part of the work. It can be hard to split up the work evenly, and when one new value depends on other new values it can be hard to make sure one thread waits on the other thread to finish changing those values.

It's easy to create "deadlock" where each of the two threads is waiting on the other one to finish something, so both freeze up and the work is never finished.

 

[EagleKeeper]

Originally posted by: Velk

Originally posted by: EagleKeeper
Do not expect to see code actually targeted for multiple CPUs (that require process assignment and would fail on single systems).

For a developer to write something like that would be unimaginably stupid, not because not enough people have multiple cpus, but mostly because they don't know how *many* multiple cpus that they have.

Expect multi-threaded games with a high degree of thread independence which will benefit from multiple cpus to become far more common over the next year or two, as both xbox360 and ps3 have basically made it a sink or swim proposition.

For commercial purposes that bolded section of the above statement is very true.

However, some applications (customized) that are intended for multiple processors, will actually target certain processes/threads to certain a CPUID for performance reasons.
Deliberate distributed processing. wihtin a box.

Saves swicthing overhead on the OS. Acts the same as having dedicated boxes on a network for specific functions.

 

[Velk]

Originally posted by: DaveSimmons

Originally posted by: SonicIce
Isn't UT2004 multithreaded? Like it uses the 2nd core for sound or something.

Sound uses very little CPU so it doesn't help much. Many games use some threading, but like Doug said that might make a dual-core run a game 10% faster than a single core clocked at the same speed.

Yeah, I think you would be lucky to get 10% also - having music play as an independent thread works ok, but sound is intimately tied to the process of the rest of the game. When you press the 'fire' button, you get a gunshot. If the sound is in a separate thread, the thread checking for you pressing the fire button has to tell it that. If you are using EAX type 3d sound it's even worse, because the sound thread also needs to know a great deal about where you are in respect to the walls and what the walls are, to pick the appropriate echo and environment effect.

My guess would be that the biggest initial gains are going to be in the form of distributed AI. A lot of game programmers are already pretty familiar with client/server setups - to my mind it would make a lot of sense to be able to split opponent or bot AI off into their own threads for an FPS say, as the usual mutiplayer model is expecting independent action of entities within the game via a very narrow communication stream anyway ( other players over network connections ).

 

[DaveSimmons]

Even AI for a single opponent as in a RTS (the enemy commander) can be made somewhat parallel, but it's hard to make the left half properly aware of what the right half is doing

I haven't done game programming since the C=64 days so I only have a vague idea of what the main CPU bottlenecks are in a game, but I do know writing multithreaded code can be painful when you have 2 threads working on pieces of a single task.

 

[sparkyclarky]

At least a year.

 

[PingSpike]

Its going to be a b|tch to program for, games have been a traditionally single cpu domain. I agree, we're going to be seeing some horribly buggy dual core games for awhile. I bet a lot of developers are going to be slow to get on board, because its going to be more costly to develop. ames are getting extremely complex now, and a lot of bugs in a initial release is actually expected by most people...this isn't going to make the developers job any easier, and its going to make things a real b|tch to troubleshoot. I'm not rushing out to buy a dual core chip.

I bet it will be a year at least until we start seeing games with some rudimentary support...it'll be much longer than that before it becomes well supported.