Multithreading
by Pat Wilson · in Technical Issues · 01/19/2001 (8:35 am) · 3 replies
I was curious as to the use of multithreading in a game engine. Right now the only threads I see would be the main engine thread, a user input thread, and a networking thread. However, are these even advantagous, because the standard person has a single processor computer, and therefore can only do one thread at a time. Also, what is the cost of swapping threads, and is there any performance increase with the use of multiple threads, or is it even a performance decrease.
About the author
#2
The best strategy is to have a single main thread with all other threads sleeping. Having two (or more) concurrent threads running at the same time just does too much cache damage. In an early version of Tribes and Starsiege we experimented with having the client and server run simultaneously in different threads when you hosted a server game. The results were very disappointing, we lost around 20% of our throughput just to threading overhead. As it stands today the client processes first then the server.
There are a few time critical tasks where sleeping threads can be very useful. Filling streaming audio buffers is a great example. If your program does not service these buffers when needed you will hear a pop/skip, having a high priority thread waiting to be signaled when the buffer is low so that it can quickly wake up and fill the buffer and go back to sleep is a great use of threads.
I would recommend against threading input, the OS already threads and buffers this data for you so there is no need to do it again, just get all the inputs at the beginning of each frame. If I remember correctly Dinput timestamps all input events anyway. I can see arguments against this because it could induce latency in processing. Here is how I visualize a frame, a frame is a snapshot in time, no time (game time) passes during that snapshot and it's processing. To take that snapshot you process all the information that has accumulated since the last time you you took a snapshot and render the frame. If any data comes in while you are processing this frame it is for the next snapshot.
You can thread networking but in general it is just as easy to process it at the beginning of each frame. If you are using blocking sockets or developing a high performance, high throughput router where it is important to minimize real-time latency then there are definite advantages to threading. But with games were are generally dealing with game time and are usually not so concerned about replying to or relaying a particular packet as much as processing the data in a reasonable amount of time. I think the Tribes networking code is a testament that frame processing can be quite effective.
01/22/2001 (1:57 pm)
You need to be very careful when implementing multi-threaded code. While it can elegantly solve numerous coding problems, it can also transparently impose a noticeable amount of overhead. On a single processor machine, a single threaded program that polls "sub-processes" will always have a bit of an edge over a multi-threaded program. The cost of the CPU context switch these days is negligible, but the damage done to cache coherency can add up quickly. That said I still believe there are good uses for threads in today's games.The best strategy is to have a single main thread with all other threads sleeping. Having two (or more) concurrent threads running at the same time just does too much cache damage. In an early version of Tribes and Starsiege we experimented with having the client and server run simultaneously in different threads when you hosted a server game. The results were very disappointing, we lost around 20% of our throughput just to threading overhead. As it stands today the client processes first then the server.
There are a few time critical tasks where sleeping threads can be very useful. Filling streaming audio buffers is a great example. If your program does not service these buffers when needed you will hear a pop/skip, having a high priority thread waiting to be signaled when the buffer is low so that it can quickly wake up and fill the buffer and go back to sleep is a great use of threads.
I would recommend against threading input, the OS already threads and buffers this data for you so there is no need to do it again, just get all the inputs at the beginning of each frame. If I remember correctly Dinput timestamps all input events anyway. I can see arguments against this because it could induce latency in processing. Here is how I visualize a frame, a frame is a snapshot in time, no time (game time) passes during that snapshot and it's processing. To take that snapshot you process all the information that has accumulated since the last time you you took a snapshot and render the frame. If any data comes in while you are processing this frame it is for the next snapshot.
You can thread networking but in general it is just as easy to process it at the beginning of each frame. If you are using blocking sockets or developing a high performance, high throughput router where it is important to minimize real-time latency then there are definite advantages to threading. But with games were are generally dealing with game time and are usually not so concerned about replying to or relaying a particular packet as much as processing the data in a reasonable amount of time. I think the Tribes networking code is a testament that frame processing can be quite effective.
#3
01/22/2001 (7:05 pm)
Exelent responce, Rick. Just what I was looking for. Thanks =) 
Torque Owner Rick Overman
--Rick