Jump to content
  • Advertisement
Sign in to follow this  
Roots

How freely do you use multithreading in your games?

This topic is 5002 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

Once I personally have a dual CPU, I might be willing to go through sync debugging hell for the extra performance, but until then it's not worth the added development time for a hobbyist programmer like myself.

Share this post


Link to post
Share on other sites
Advertisement
In non game-like applications i use threading a lot, but in games, i never needed to use one...(I Dont count Audio/Physics libs who handle threads themselves not requiring extra control over them)

Share this post


Link to post
Share on other sites
Quote:
Original post by Raghar
1+ thread for sound engine.
1 high priority thread for timmer.
1-2 worker threads for 3D engine. There might be additional helper threads.
1 - multiple for game engine.
5+ worker threads for game engine.


Please tell me you're joking? Am I the only one that thinks this is extreme overkill? I have no doubt you are losing alot of performance in thread management alone.

Share this post


Link to post
Share on other sites
Quote:
Original post by DrEvil
Quote:
Original post by Raghar
1+ thread for sound engine.
1 high priority thread for timmer.
1-2 worker threads for 3D engine. There might be additional helper threads.
1 - multiple for game engine.
5+ worker threads for game engine.


Please tell me you're joking? Am I the only one that thinks this is extreme overkill? I have no doubt you are losing alot of performance in thread management alone.


I don't think it's necessarily overkill - chances are that the threads for the most part are yielding and waiting for an event to perform a specific function (i.e. an event triggers a need to load a new resource from disk -> boom -> use one of the worker threads)...

The main performance hit comes from the thread initialization and startup - once it's running, you can just let it idle until it needs to act... now, writing the code to manage that and to make sure things are synched when they need to be, that would be a bit more of the challenge for me...

just my 2c.

Share this post


Link to post
Share on other sites
What would 5+ worker threads be blocked on in a game engine? And 1-2 threads for the 3d engine?

I fully understand threading networking, sound, and file IO to support asynchronous asset loading or something. Beyond that I have a hard time seeing where else additional threads would benefit in a game.

Share this post


Link to post
Share on other sites
I rarely use threads in my own projects, and at work we never use threads unless we have to.

For all disk I/O we use asynchronous reads. All platforms, including windows, support asynchronous disk reads in some fashion. The important thing to make sure is that your platform doesn't block on things like file opens and file closes. If that's the case, we normally open the file once and leave it open - we're normally reading from large pack files anyways, so a single handle is used by everyone.

For audio streaming we use the same async I/O. The async file state is updated once a frame and we use a self-managed asynchronous queue to control reads. In the past we used to just spawn threads and read data, but it became very difficult to manage because people were issuing reads all over, sometimes on the same files, and it didn't let us deal with seek time issues. On top of our asynchronous queue we have a more elabortate loader that can be tailored to different tasks's needs. The front end sorts all reads by disk offset, so that we only do forward seeks, for example. Our asynch queue can also have tokens inserted to make sure that seperate files are loaded all at once and that the queue isn't polluted by another task wanting to load a file. The important thing that we realized what that, since disk I/O can only read from one place at a time, it has to be dealt with synchronously. Only the state of the read needs to be asynchronously. Spawning multiple threads to read multiple files can actually be a negative things since, as I pointed out above, there is no easy way to manage who is reading what and in what order.

In other cases we do use threads - for tasks that run for multiple frames, such as determining AStar paths and such, we may spawn a thread, or have a second thread running that can do the query over multiple frames and return the result once complete.

Our renderer could be run in a seperate thread since there is a single data transfer process and we run a deferred renderer - we could collect everything for the current frame, send it to the renderer in the second thread, and render it during the next frame, overlapped.

I'm a big fan of threads in the right places, but I also think that you get contension issues with file i/o very quickly - doing your file I/O as part of your main task loop makes memory management of target load buffers and scheduling of I/O requests a lot easier. Just because it's in the main thread doesn't mean it can't run asynchronously.

Just some thoughts,

- S

Share this post


Link to post
Share on other sites
On single core and/or single CPU systems performance usually suffers when threads are arbitrary launched to handle certain tasks. A good threading model will address unidirectional and bidirectional communication for maximum performance while eliminating the need to fire off threads that are in all likelyhood unnecessary.

Obviously there are benefits from spawning threads to handle input, sound, and networking and to handle tasks during non critical times (i.e. loading data and updating a progress bar) but anything beyond that and performance is likely to suffer - especially with excessive amounts of mutex locking and context switching.

As dual core and dual CPU systems become more common place the real benefit will be in the rendering pipeline. You'll start to see more systems that switch between two threads where one is always doing transformations of map and static mesh data in preparation for rending of the next scene. Or a single thread for rendering and an additional thread for some super cpu intensive (and realistic) AI.


If you want to see real world performance issues in dealing with threads and intensive operations look into IO Completion Ports and networking on Win2K/XP and how using more threads than there are CPU's/Cores hurts performance.


The bottom line is that if you are running on a single core you still only have ONE execution context so spawning threads for anything other than events that need to be handled in real time is pretty much pointless.

Share this post


Link to post
Share on other sites
Quote:
Original post by DrEvil
Quote:
Original post by Raghar
1+ thread for sound engine.
1 high priority thread for timmer.
1-2 worker threads for 3D engine. There might be additional helper threads.
1 - multiple for game engine.
5+ worker threads for game engine.


Please tell me you're joking? Am I the only one that thinks this is extreme overkill? I have no doubt you are losing alot of performance in thread management alone.


1/29 on single CPU, gain is at least 27/20 on multiple CPUs. Actually it's more memory access limited than CPU limited.

Clean workable design with experience.

One of thread use is consistence, and long term background task. Basically you want them being interrupted at unknown time and live somewhere when they will not abuse system resources. If they are done in time, fine it could result in better AI, if not, it's no problem, even aproximate NP hard problem solution is better than none. Of course you need to have a multitiered dispatch. Fallback, not optimal solution that might be ready in reasonable time, better solution, nearly optimal solution. It's nice when you have a backround thread and some free CPU time to acomplish such effort.

Obviously when some tasks are parallel, it would be bad idea to don't do them in parallel order. (Of course especially in single core, luckily they would be gone soon, you'd be doing a lot of sleeping, yielding, and wait on single object.)

Of course something like this could be called attempt to melt multicore dual CPU system. ~_^

Threads are sometimes also a way how to make game / 3D engine more clean.

Actually majority of problems with threads, and timing, are because of badly done windoze XP sheduler. (It looks like it was optimalized on office programs, not concurent multithreaded programs.) Of course Linux works better, but it has problems with video drivers, and lack of reasonably looking/working GUI configuration programs.

Share this post


Link to post
Share on other sites
Quote:
Original post by DrEvil
Quote:
Original post by Raghar
1+ thread for sound engine.
1 high priority thread for timmer.
1-2 worker threads for 3D engine. There might be additional helper threads.
1 - multiple for game engine.
5+ worker threads for game engine.


Please tell me you're joking? Am I the only one that thinks this is extreme overkill? I have no doubt you are losing alot of performance in thread management alone.


1/29 on single CPU, gain is at least 27/20 on multiple CPUs. Actually it's more memory access limited than CPU limited.

Clean workable design with experience.

One of thread use is consistence, and long term background task. Basically you want them being interrupted at unknown time and live somewhere when they will not abuse system resources. If they are done in time, fine it could result in better AI, if not, it's no problem, even aproximate NP hard problem solution is better than none. Of course you need to have a multitiered dispatch. Fallback, not optimal solution that might be ready in reasonable time, better solution, nearly optimal solution. It's nice when you have a backround thread and some free CPU time to acomplish such effort.

Obviously when some tasks are parallel, it would be bad idea to don't do them in parallel order. (Of course especially in single core, luckily they would be gone soon, you'd be doing a lot of sleeping, yielding, and wait on single object.)

Of course something like this could be called attempt to melt multicore dual CPU system. ~_^

Threads are sometimes also a way how to make game / 3D engine more clean.

Actually majority of problems with threads, and timing, are because of badly done windoze XP sheduler. (It looks like it was optimalized on office programs, not concurent multithreaded programs.) Of course Linux works better, but it has problems with video drivers, and lack of reasonably looking/working GUI configuration programs.

Share this post


Link to post
Share on other sites
I simply don't trust the use of threads, though this is down to the fact that I haven't taken the time out to learn them thoroughly.

I've done alright without them so far, so until I have a reason for using them I won't bother with them.

To each their own! ^_^

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!