Thread useage opinions
Author
Is anyone here a proponent of using threads? I mean it seems like if they were so good, then more people would use them right? I have found a nice article explaning them at gametutorials, and now I'm wondering if I should add them to my game engine as well as my normal programs. I was trying to think of the pros and cons, but I can only think of the cons. Does anyone know the pros of using threads in a program as well as a game engine, and if so what are they? Thank you in advance for your time.
If you use 2 threads, your game will run much faster on P4s with hyperthreading and can also benefit from multiple processors. Right now, using more than 2 heavy threads(threads that do lots of processing as opposed to using the OS's "wait for networking/input/music to finish/etc" functions) isn't really neccessary or beneficial, but in 5 years it may be commonplace for desktop machines to have 4-8 cores so maybe then it actually could benefit from that many threads =-)
Author
Quote:Original post by Extrarius
If you use 2 threads, your game will run much faster on P4s with hyperthreading and can also benefit from multiple processors. Right now, using more than 2 heavy threads(threads that do lots of processing as opposed to using the OS's "wait for networking/input/music to finish/etc" functions) isn't really neccessary or beneficial, but in 5 years it may be commonplace for desktop machines to have 4-8 cores so maybe then it actually could benefit from that many threads =-)
Ahh I see. I happen to use a P4 w/ HT and I love it. So I'm thinking mabey for my game engine, have the support and option to use them, but don't make them a critical component, since most people won't experience any benefits. As for other programs, I think I will use threads for fun, and not for any performance enchancements, even though Im starting to get some crazy ideas of what I can do if my xml parser class used threads [wink]. Thanks for your input - Im open to more!
[Edited by - Drew_Benton on May 25, 2005 9:08:40 PM]
Hi there,
I'm intending to use Threads as a DirectPlay Listener for packets and messages coming in.
I think that'll improve performance as the thread can sleep for 200ms per listening cycle while the main game does frame timing management at 50 fps (20 ms delay) per second.
I've once heard that listening to packets on the main loop could be inefficient. Therefore I'm moving on to threads since I have nothing to lose.
Cheers!!
I'm intending to use Threads as a DirectPlay Listener for packets and messages coming in.
I think that'll improve performance as the thread can sleep for 200ms per listening cycle while the main game does frame timing management at 50 fps (20 ms delay) per second.
I've once heard that listening to packets on the main loop could be inefficient. Therefore I'm moving on to threads since I have nothing to lose.
Cheers!!
When interacting with certain libraries you often have to use threads. A common offender is BSD sockets.
Other uses might include redrawing the mouse pointer independently of the framerate or background sound mixing to prevent jerky audio and/or reduce the mixing buffer's length.
In general you'll benefit the most from extra threads when the amount of communication between them is kept to a minimum.
Also, if the XML parser needs to be fast then it's time to reconsider your choice of format.
Other uses might include redrawing the mouse pointer independently of the framerate or background sound mixing to prevent jerky audio and/or reduce the mixing buffer's length.
In general you'll benefit the most from extra threads when the amount of communication between them is kept to a minimum.
Quote:Original post by Drew_BentonDon't use threads for "fun", I doubt that it'll be a fun experience.
As for other programs, I think I will use threads for fun, and not for any performance enchancements, even though Im starting to get some crazy ideas of what I can do if my xml parser class used threads.
Also, if the XML parser needs to be fast then it's time to reconsider your choice of format.
Author
[part 1]
Just for refrence, my XML parser class is super fast, I just like experimenting everynow and then, who knows what you can discover [wink]. Take a look at this tutorial on threads. I never used threads before since the first time I tried it, it wasnot fun, but this tutorial makes them very easy and understandable, so it is *a little fun*.
[part 2]
I definitly see the use for threads in a game that uses some sort of internet communication. I agree that listneing in the main loop eats up lots of clock cycles where threads can take care of that.
Now what I'm thinking now is to use threads for any internet communications and file loading. Other than that, I dont think threads can be much use to my game engine. I tried makeing a little test program using threads and I could not see any benefits from moving the EventProcessing to a thread, since the functions after it rely on when the function is done. I tired moving the rendering code to a thread and that was no bueno! Thanks for the input! Any more ideas of what I could use them for?
[Edited by - Drew_Benton on May 25, 2005 9:36:49 PM]
Quote:Original post by doynax
Don't use threads for "fun", I doubt that it'll be a fun experience.
Also, if the XML parser needs to be fast then it's time to reconsider your choice of format.
Just for refrence, my XML parser class is super fast, I just like experimenting everynow and then, who knows what you can discover [wink]. Take a look at this tutorial on threads. I never used threads before since the first time I tried it, it wasnot fun, but this tutorial makes them very easy and understandable, so it is *a little fun*.
[part 2]
I definitly see the use for threads in a game that uses some sort of internet communication. I agree that listneing in the main loop eats up lots of clock cycles where threads can take care of that.
Now what I'm thinking now is to use threads for any internet communications and file loading. Other than that, I dont think threads can be much use to my game engine. I tried makeing a little test program using threads and I could not see any benefits from moving the EventProcessing to a thread, since the functions after it rely on when the function is done. I tired moving the rendering code to a thread and that was no bueno! Thanks for the input! Any more ideas of what I could use them for?
[Edited by - Drew_Benton on May 25, 2005 9:36:49 PM]
A mistake a lot of people make is "why should I wait for this? I should make a new thread instead!"
Why is that a mistake? It is obviously a bad thing to waste time doing nothing just waiting around, right? Definitely, but threading is almost never the only way to avoid waiting. With sockets, for example, there is almost always some way to set sockets to non-blocking which means the socket functions will return immediately even if there is no data incoming (on windows, the socket functions return a special error code when you would normally wait for data on a non-blocking socket).
Threads are good for some things, but make sure there aren't better solutions first.
Why is that a mistake? It is obviously a bad thing to waste time doing nothing just waiting around, right? Definitely, but threading is almost never the only way to avoid waiting. With sockets, for example, there is almost always some way to set sockets to non-blocking which means the socket functions will return immediately even if there is no data incoming (on windows, the socket functions return a special error code when you would normally wait for data on a non-blocking socket).
Threads are good for some things, but make sure there aren't better solutions first.
Quote:Original post by Drew_BentonQuote:Original post by doynax
Don't use threads for "fun", I doubt that it'll be a fun experience.
Also, if the XML parser needs to be fast then it's time to reconsider your choice of format.
Just for refrence, my XML parser class is super fast, I just like experimenting everynow and then, who knows what you can discover [wink]. Take a look at this tutorial on threads. I never used threads before since the first time I tried it, it wasnot fun, but this tutorial makes them very easy and understandable, so it is *a little fun*.
Agreed, threads are a valuable technique that comes in handy on many occations. Just don't try to apply them where they don't fit, even if it's just for the learning experience.
Try doing some simple things and get some experience with thread communication - because that's the hard part.
Quote:Original post by Drew_Benton
I definitly see the use for threads in a game that uses some sort of internet communication.
For a server, especially a one for dozens of players, this is probably a good idea.
However depending on your networking model it might be of little value to the client. Think about what you'll actually do with a new game state received in the background, you won't be able to display any changes until next frame anyway.
Using threads to sample and send input on regular intervals is probably not be such a bad idea though.
[Edited by - doynax on December 14, 2004 9:44:59 PM]
Quote:Original post by Drew_Benton
I definitly see the use for threads in a game that uses some sort of internet communication.
I would probably suggest one thread for a simple networked game, just don't get too carried away and spawn a thread per client. The Multi-Player Networking FAQ states:
Quote:
Q10) Should I spawn a thread per connection in my game code?
A10) The short answer is "likely no." The longer answer is that, if you're using UDP, you should only need a single socket, from which you can read a packet, process a packet, repeat. If you're using TCP, you will need a socket per player, but the players are likely sharing and affecting a single world state inside the program, which needs to be protected by locking; thus, the extra threads would just end up blocking on locks anyway, so using select() and reading out what's there, then processing it, is recommended. Some users find "co-operative threads" or fibers to be a nice middle ground, because it gives some of the advantages of real threads (a stack per context) without the locking overhead (because yield is explicit).
I would say that its good to use threads until you notice a loss in performace. I'm currently working on a SDL game, and I thought it would be a good idea to use threads for rendering everything. It worked fine as long as you had a nice graphics card, but some computers (i.e. my laptop) have the CPU do most of the graphics processing and continually redrawing the screen killed the fps on any computer with a bad graphics card.
Author
Ok awesome. Thank you all for your feedback, it really helps listening to other people because I have more viewpoints to base my secisions on. I did decide to drop threads all together, I have no real use for the yet. Hope to see you again on my next post [wink]. Bye!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
