Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

mreiland

multi-threading in a game engine: experiences please

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

I'm currently a programmer involved in the the 0AD project(http://wildfiregames.com/0ad/). We have been discussing whether the engine should be multi-threaded or not, and I'm just curious what other people's experiences have been. Threading mouse movements, etc., isn't a big deal, and helps with the responsiveness of the app, but we're contemplating threading more of the engine. To be specific, we'd like to thread the AI calculations(among other things), but we're worried about not having control over the timing. Has anyone else implemented threads extensively in your games? If so, what was threaded, and what problems did you run into? How did you solve them? :: Edit :: The platform we are targeting is the PC(Windows and Linux) Thank You, Michael Reiland [edited by - mreiland on January 11, 2004 3:45:12 PM] [edited by - mreiland on January 11, 2004 5:04:14 PM]

Share this post


Link to post
Share on other sites
Advertisement
In my games, the sound and input is threaded from the main thread. The only problems I''ve ever had have been with thread priorities, which were causing issues with the sound.

These problems were on PS2, and were only apparent when streaming sounds off of CDROM.

I dont know what platform your project is on, but our threads use the PS1 processor on the PS2 so the threads aren''t limited to the one processor. However, as I said above, this isn''t without it''s issues. If it''s done properly then its definately worthwhile.

Hope this is helpful.

Share this post


Link to post
Share on other sites
I have never used threading in a game before, but there certainly are areas where it can be very usefull.
The mouse movement that you mentioned is a good example. But you could also have the renderer run in a separate thread. A particular good candidate for threading is a process that involves lot of IO. For instance a level loader, or texture manager. If it runs in a separate thread the game will not stall while stuff is loaded from disk.

But threading also adds a lot of complexity and a whole new area of bugs. You should be very carefull about the data that a thread uses. Because there is now the possibility that two threads will simultaneously access the same data. So you should use mutexes.

I think threads can be very helpfull but use them with caution. And only use them when it makes sense.

Share this post


Link to post
Share on other sites
Sorry RavNaz, I should have specified the platform(edited my original post). We're developing for the PC(Linux and Windows).

Rule, that's exactly what we're trying to do, which is why we're currently researching it. For most of us this is our first *major* game, so we were hoping to get the practical experience of you old fogies who've been there before

Let me just mention this real quick and see what ppl think.

We're planning on implementing a basic profiler within the code(the algorithm is from GPG). The problem is that it becomes much tougher to do in a multi-threaded environment. If we decide to go with multi-threading, do you guys think it will be worth the trouble? I know it's not going to be as extensive, or as good, as a normal profiler, but it would allow us to get some information without relying on some 3rd party software.


Michael Reiland

[edited by - mreiland on January 11, 2004 5:13:42 PM]

Share this post


Link to post
Share on other sites
Well threads can be a very usefull tool if used properly. I''ve used them quite some in my games. The optimal number of threads that actually add to performance of a game engine is around 2-4 (speaking from experience). Stripping input into a seperate thread is pointless, since that way you''d have to put every sub system into a seperate thread (extending this theorem). Systems that gain by being in seperate threads:
- SIMD processing ( when HT hardware present improvements are quite substantial)
- Physics should be decoupled to a seperate thread if using lockstep simulation since it has it''s own update frequency.
It is good to keep the renderer in the main thread (the process'' default thread).
When multi-threading try to stay away from on-demand threading since it can add substantial overhead if done at the peak times (and that''s probably when you would create a new thread).
One more good system to place inside a seperate thread is AI, which shows it''s good side in places where distributed calculation must be performed such as pathfinding and grouping (distributed as in over a number of frames).
Putting the core system in a seperate thread from my previous experience doen''t gain you any advantage, rather it can be a bottlencek sometimes.

I would recommend to keep the number around 4 threads since that''s what I have learned behaves well and scales well.
These were just some general pointers and tips from past experience, but I can give you more specific design pros and cons if you''reinterested.

Share this post


Link to post
Share on other sites
You''d definitely need threads for networking. For example, you''d need one listening for incoming connections, etc.

If that''s one of the things you''ll be later implementing, make sure you really think it through NOW . An engine designed with networking in mind from day one can differ substantially from one that isn''t, and those are the kind of changes that could be classified as "rewriting the entire thing" (at least some parts, depending on the type of game it''s for). That''s my opinion based on very limited experience with the subject, though.

---
shurcooL`

Share this post


Link to post
Share on other sites
Thanks everyone.

Weddo you can contact me via IM:


MSN: mreiland1978@hotmail.com
ICQ: 330209646


Also, feel free to hop onto our forums(http://forums.wildfiregames.com/0ad/) and meet our community. We'd love to hear input from someone who has more experience than us.

PS
That offer is open to everyone who would like to help

Michael Reiland

[edited by - mreiland on January 11, 2004 10:52:59 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by shurcool
You''d definitely need threads for networking. For example, you''d need one listening for incoming connections, etc.

You don''t need threads (at least not ones you manage yourself) for networking if you''re using non-blocking sockets.

I prefer to avoid multi-threading myself as it can introduce a lot of bugs, and make it very hard to debug (typically, while you have one thread paused for debugging, the others still go at full speed).

Share this post


Link to post
Share on other sites
http://c2.com/cgi/wiki?AvoidThreadsForOptimization

Just some notes on what can go wrong with too many threads... browse around on the pages linked from there, too. (Hell, read the whole wiki, lots of fun stuff hanging around.)

Share this post


Link to post
Share on other sites
I think that there was a good document put out at the last GDC on the subject. Mostly it involved intels hyperthreading extention but it applies to threads in general. I don''t have the link right now but it should be in the GDC''s doc archive.

Basically it suggested breaking things up into worker threads. So physics grinding would actually have 2 threads on a hyperthreading processor. Also arranging things so your threads never have to block by breaking the data up certain ways was a big improvement.

There is alot more in the article. If you can''t find it I''ll see if I can post the link after I get back tonight.

Share this post


Link to post
Share on other sites

  • 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!