All these new n-core CPU systems...

[Matzon]

dedicating a core to do a single type of work is basically bad design - and I am pretty sure that alan wake doesn't do that either, despite the presentation. They're more likely dedicating a thread and let the OS decide the core its running on.

The only reason to let a thread only run on one core (setting affinity) is that you want to avoid core switches, which might incur a high cost (relatively). However scheduling a thread on 1 core, might mean that some of the integer or floating point operations stall becase the single core isn't fast enough.

[princec]

If I ever get near maxing out a CPU with game logic I'll be sure to investigate the horrible complexities of multicore game programming Until then it's all just pipe dreams!

Cas

[Mr_Light]

What is the point of having more than 2 cores?

Having 2 cores enables you to have all your background stuff running on one core and whatever your main application is on the other.  That's useful.  Having more than that seems like a waste.  What if I'm running one really computation-intensive thread?  Then all the cores but 1 are wasted.

I would much rather have a 4 ghz processor than a processor with 4 1 ghz cores.  A processor with 2 2 ghz cores would be all right though.

ghz or better: frequency goes up the power consumption goes up exponantially, multicore allows for more performace while keeping the power consumption descrete. now you might be like I don't care too much about my power bill but the heat that comes with it also has to be moved hence the huge fans you see today. offcourse performance wise there is also the whole how-much-gets-done-in-a-clockcycle bit.

multicore scales better then ghz's

I don't really deal with hardware this is all 2nd hand but I think it's pritty accurate.

Games published by our own members! Check 'em out!

[Riven]

What is the point of having more than 2 cores?

Having 2 cores enables you to have all your background stuff running on one core and whatever your main application is on the other.  That's useful.  Having more than that seems like a waste.  What if I'm running one really computation-intensive thread?  Then all the cores but 1 are wasted.

I would much rather have a 4 ghz processor than a processor with 4 1 ghz cores.  A processor with 2 2 ghz cores would be all right though.

Say you're doing collision-detection, (not collision-response), in really complex and high-tri-count scenes. Why limit yourself to 1 thread handling the game-logic, when you have 4 available. There is so much to gain, with so little effort, it would be a waste not to take advantage of it.

We all rather have 64GHz cores, just like we'd rather have flying cars and holographics harddisks, but hey, it's not going to happen anytime soon, so lets enjoy the 32x 2GHz, AI controlled cars and hybrid harddisks for a while

[uj]

I'm wondering what the difference is for the normal programmer?
tions?

Basically any Java program will be able to run faster on a multi-core processor. (If they actually will is a question of how well implemented the JVM is to take advantage of the CPU cores). This is because in Java concurrency is inherent. Some of Java's appearant slowlyness is because it has made use of concurrency which hasn't been well executed on a single-core processor. But once multi-core is in place the obstacle is removed and many programs will run much faster.

So in summary multicore is good for Java. It's good even if you don't do anything, but it's even better if you adapt for concurrency. Any programmer interested in this should buy a copy of Java Concurrency in Practice by Brian Goetz and others. It's already a classic.

[appel]

Ok, I agree, maybe it's time to read a book on this subject before babbling more.

[grazi]

Just because you can run something broken up across multiple threads doesn't always mean its a good idea, or even faster. In fact, a lot of basic things are a lot slower when broken out to be parallel, and a lot of parallel things can run slower then just a linear approach at times, sorts are famous for this.

Yes, in general multiple cores are great for Java, and yes java supports it pretty well. But just becareful on your design and learn how to deal with multithreading & concurrency before going nuts trying to use it all over the place. Bad things can happen.

[Riven]

Why would sorting the same data on 2 threads be bad? First you do a rough sort, dividing your dataset in low/high, and then process the 2 segments on 2 threads.

[Orangy Tang]

Or you could use merge sort, which is basically the same idea and can be massively parallel.

Unfortunately for most uses the overhead of thread creation and context switching is likely to eat up any gain you'd get (and possibly more).

[elias]

Tim Sweeney of Unreal fame did a pretty interesting presentation about the whole multithreaded game engine issue, separating the engine into sections of increasing inherent parallelism (Simulation, Numeric computation (e.g. physics), and Shading (rendering)) and suggesting how to do each in parallel with reasonable speedup. I was especially intrigued by the atomic threading primitive, which would replace regular and hard-to-get-right locking primitives in game logic code.

 - elias

Games published by our own members! Check 'em out!

[Riven]

ofcourse you're not going to create threads for the sorting, you already have a bunch of worker-threads laying around

[Jamison]

My thoughts are as follows: if you have the ability to allow two or more threads to control your game (update/render), go for it. But let the OS decide which thread runs on which core. However, if you can't control which thread goes on which core, then a problem arises. If the OS asigns both threads to the same core, they won't run simultaneously. Say this is the OS's thread queue, in which case the OS assigns each thread to a differant core:
CORE 1:
   Process 1
   Process 2
   Process 3
   Process 4
   Process 5 (Your game's UPDATE thread)
   Process 6
   Process 7
   Process 8

CORE 2:
   Process 1
   Process 2
   Process 3
   Process 4
   Process 5
   Process 6
   Process 7 (Your game's RENDER thread)
   Process 8

This would be great, however, if the OS assigns your threads to the same core, it would be like your game is running on a single core system, each thread would have to wait for the process ahead of it to finish, and would have to wait for your other thread to finish. Here's how the OS's thread queue might look in that situation:
   Process 1
   Process 2 (Your game's RENDER thread)
   Process 3
   Process 4
   Process 5
   Process 6
   Process 7 (Your game's UPDATE thread)
   Process 8

My point here is, if you can't control which thread goes on which core, just use a single-thread game, or it may run slower if your threads are running on the same core (or even 3 are on one core, and 1 on the other, etc).

Take the Xbox 360, they have "3 symmetrical cores running at 3.2 GHz each" and "2 hardware threads per core; 6 hardware threads total" (source: http://hardware.teamxbox.com/articles/xbox/1144/The-Xbox-360-System-Specifications/p1). This means they can run 6 threads sumultaneously, however, it's using custom hardware, and the hardware is dedicated specifically to the game. So the 360 obviously makes use of these 6 threads running at the same time. I bet the 360 has the ability to choose which thread goes on which core, or the 360 automaticly assigns each new thread to a core which does not already have a thread running, meaning it cannot allocate more than 6 threads. Note that this is only my guess, I have NOT confirmed this.

[darkprophet]

elias, i seem to remember reading that, but I can't find it. Would you mind linking me please ?

DP

[Mr_Light]

sorry to burst your bubble but with any semi intelligent thread assigner would prefend the situation that you describe from arrising. obviously that render and update thread will take a significant amount of a bite out of the core/cpu resources and figure out on it's own that it would be better to assign it to separate cpu if it can't figure it out its probebly not nessasery. If theres an other program bound to the other cpu already and stresses it it will be more efficient to have it all run on one core. Perhaps some hint's that one thread should be or not on the same core/cpu would allow for quicker discovery or could render optimalisation towards memory share or what not but that all is still a whole differend approuch from tieing it to one cpu.

the same issues that arise from your approach are quite similair to the problem arised with hardcoded memory spaces and multi programs and the resulting conflicts.


//edit
xbox..  console games/programms can pull this off because they are actually aware of everything going on, on the machine pc/computerprograms are not and should gracefully share/claim resouces. This also includes cores.