Jump to content
  • Advertisement
Sign in to follow this  
murdock

Utilizing Multiple core processors

This topic is 3792 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Has anyone here tried to utilize multiple cores for their games instead of the single core/processor approach? I was just curious to see if it was worth persuing and what advantages/disadvantages it might entail other than the obvious. =)

Share this post


Link to post
Share on other sites
Advertisement
Does it need anything else than the obvious humongous amount of extra processing power [looksaround]? Designing a good multi-threaded system is of course harder and debugging can be a bitch but other than that I don't see disadvantages.

Whether it's worth pursuing or not depends on your needs.

E: Oh and of course the number of cores will just keep going up (and speed of a single core will probably go down) in future so getting ready for it isn't exactly a bad choice.

[Edited by - virus- on May 27, 2008 5:32:08 PM]

Share this post


Link to post
Share on other sites
It is hard to really use multiple cores persistently throughout an application, because many applications (and games) are not easily parallelizable. For example simply using two threads to send your render commands to the graphics card not only won't run any faster, but it also won't work at all (never try that!).
However, some components can be moved to another thread (core), and that is certainly done by many people these days.

Quote:
what advantages/disadvantages it might entail
Threads make your program a lot more complicated, and threads on multiple cores even more so. You should have a good insight about how to synchronize threads and how to share/pass data between them before even thinking about using threads.
On the positive side, having two things run on two cores in parallel can obviously be quite a bit faster than running them one after the other. For example, you could calculate the physics for the next few frames while the main thread is still busy rendering the current one.
Also, threads can be wonderful to offload things that might otherwise stall your game in an unpleasant way (network, loading data, etc.).

Share this post


Link to post
Share on other sites
I was thinking that multiple cores could provide advantages to improving performance in AI programming.

Share this post


Link to post
Share on other sites
Quote:
Original post by murdock
I was thinking that multiple cores could provide advantages to improving performance in AI programming.
Short answer is yes it can. Lets assume that most of the AI works via scripts (which usually is the case). If the virtual machine supports multi-threading you can process X (number of cores) scripts at the same time, the amount of performance gained depends on how well the system is designed (how much synchronization you need).

Share this post


Link to post
Share on other sites
Quote:
Original post by murdock
Has anyone here tried to utilize multiple cores for their games instead of the single core/processor approach?
Yes.

Quote:
I was just curious to see if it was worth persuing ...

It can be. If you have something which is CPU bound, and if it can be suitably parallelized, then yes, it may be worth pursuing. If it isn't CPU bound, then it obviously isn't worth pursuing. If it is difficult or impossible to parallelize, then it is probably not worth pursuing.

Note that many libraries that you already use take advantage of multiprocessing if it is available. Direct3D will run many graphics operations in parallel. DirectSound will do a lot of mixing and nearly all playback asynchronous to your application. The OS will asynchronously process your network packets and prepare them for your use. Etc.

Also, there is a big difference between running different tasks in parallel (rendering thread, AI thread, networking thread, input thread ) and running a single task in parallel (AI partitioning the processing amongst all available processors). The former is generally easy, but doesn't scale well to more processors. The latter generally requires more effort, but can scale nicely.
Quote:
... and what advantages/disadvantages it might entail other than the obvious. =)

I don't know what you consider "obvious".

There is an additional cost for developing, debugging, and testing multiprocessing software. With properly experienced and educated developers and appropriate tools, the cost is fairly small. Without that experience and/or education, the development cost can be quite significant.

There is a computational penalty for keeping multiple processing elements synchronized and locked as necessary. This computational cost will be known and understood by people with the experience and education noted above.

Share this post


Link to post
Share on other sites



Another aspect might be 'can you keep your quad CPU fed with enough data to keep all 4 running efficiently'.

I have a Q6600 system that I havent had a chance yet to run tests of my expected CPU loads (HEAVY AI, but with a large data set -- so cant count on it staying in the 8meg cache much). Im not sure the memory I paid way too much for (PC9200) would even be worth the cost.

The big solution is clustering (which has even worse parallelization problems than multi-core) and I eventually aim to find out if dual cpus work almost as well as quads in clusters (and I suppose for the 8 core cpus that will be coming in the near future).





Share this post


Link to post
Share on other sites
Quote:
Original post by murdock
Has anyone here tried to utilize multiple cores for their games instead of the single core/processor approach?
I was just curious to see if it was worth persuing and what advantages/disadvantages it might entail other than the obvious. =)
In my hobby engine, I'm currently experimenting with a technique I call "deferred function calls" (there's probably an existing name for this pattern...) - where each function called on an entity is pushed into a queue (hopefully a lock-free queue) and processed on the *next* update-frame. This should allow me to update multiple entities at once (one per core) without the need to lock any of them.
Quote:
Original post by murdock
I was thinking that multiple cores could provide advantages to improving performance in AI programming.
Yes! AI code usually involves lots of 'searching' algorithms (pathfinders, planners, etc), and as fans of Herb Sutter know, searching algorithms are one of the few bits of code that can actually go superlinear - that is, if you double the amount of cores, you can actually get a performance boost larger than double!
Quote:
Original post by samoth
It is hard to really use multiple cores persistently throughout an application, because many applications (and games) are not easily parallelizable.
I'm always hearing people say that games are hard to parallelize, but the way I see it, games are usually made up of a simulation consisting of hundreds of individual entities. As long as each of those entities can be simulated in isolation, this sounds like the perfect situation for parallelization...

And anyway, even if you *can* only parallelize 10% of your application - let's say the particle simulation as an example - then as users keep doubling the amount of cores in their systems, you can at least keep doubling the amount of particles in your sim ;)

Share this post


Link to post
Share on other sites
Quote:
Original post by Hodgman
I'm always hearing people say that games are hard to parallelize, but the way I see it, games are usually made up of a simulation consisting of hundreds of individual entities. As long as each of those entities can be simulated in isolation, this sounds like the perfect situation for parallelization...


The nature of simulation is that you tend to work with large or complete cross-sections of the data at very frequent intervals, eg. many times a second. This is generally the worst case for parallel programming since the typical parallel algorithm accepts some extra processing latency in return for greatly enhanced processing bandwidth. Unfortunately it's no good having your game run at a solid 75fps if you don't start turning the view until 20 frames after you started moving your mouse.

Plus, most of the time in games the only entities that can be simulated in isolation are the ones not affecting very much, and which you were already optimising away anyway.

So generally, simulation-style games are not all that easy to gain parallel benefits from. It can be done of course, but you have to change your algorithms quite a bit more than you would in many business or analytical applications.

[Edited by - Kylotan on May 28, 2008 7:59:31 AM]

Share this post


Link to post
Share on other sites
What about if you did lock your threads at the end of each frame? I know its not ideal because you won't utilize all the processing power available but wouldn't you still gain an advantage of processing some tasks in parallel such as CPU skinning , AI and rendering? Then at the end of the frame you wait until all threads have finished before continuing the next? Is this going to cause problems on single core CPUs?

I don't know that much about this so please correct me if i'm wrong or missing something because I was considering doing it this way.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!