Multiple Threads Vs Thread Pool
Author
If I have 12 mobile units querying my pathfinding engine simultaneously,
Should I use 12 independent threads, one for each unit, or
Use a thread pool instead.
Both have drawbacks,
If I use 12 threads, the application won't be so responsive.
If I use a thread pool, some units will not be able to move while
it is in the queue.
What is your opinion?
Thanks
Jack
If you take one step backwards, the problem is that some computations take longer than a frame to complete (e.g. pathfinding). Your solution is to move these computations onto a thread/thread-pool.
There's no need to use threads or thread-pools for this, if you go back and solve the initial problem in a different way - such as re-designing the pathfinding code so that it can stop after performing some of the computation and then be resumed next frame.
There's no need to use threads or thread-pools for this, if you go back and solve the initial problem in a different way - such as re-designing the pathfinding code so that it can stop after performing some of the computation and then be resumed next frame.
Quote:If I use 12 threads, the application won't be so responsive.IMHO there wouldn't be any issues with that amount of threads, because OS takes care of them very well [dispatching]. Take a look at windows task manager, even wmplayer.exe has about 20 threads and that's pretty resposive.
@siavash
Your analysis contains a flaw. 20 threads can be very responsive if they are all blocked waiting for something to happen. But if we are talking about 20 runnable threads all vying for processor time, then responsiveness is going to suffer.
@lucky6969b
Use a small thread pool. You generally don't want many more active threads than you have logical processors. Another consideration for responsiveness is to cap the total processor time doing pathfinding relative to the rest of your program.
For example, if you make it so that your pathfinding algorithm can be suspended and restored, then you can give the pathfinder X milliseconds to work with every frame, and once it reaches its allocated time it saves state and pauses, allowing other tasks to run. You can also have a queue of pathfinding tasks, so that you don't end up in the situation of trying to process hundreds or thousands of tasks in some small time segment, with none of them really making progress.
On the other hand, have you profiled how many units are making pathfinding requests on average, and how long these tasks take to complete? The more information you have here the better you can design a system that meets your pathfinding latency and bandwith requirements.
Your analysis contains a flaw. 20 threads can be very responsive if they are all blocked waiting for something to happen. But if we are talking about 20 runnable threads all vying for processor time, then responsiveness is going to suffer.
@lucky6969b
Use a small thread pool. You generally don't want many more active threads than you have logical processors. Another consideration for responsiveness is to cap the total processor time doing pathfinding relative to the rest of your program.
For example, if you make it so that your pathfinding algorithm can be suspended and restored, then you can give the pathfinder X milliseconds to work with every frame, and once it reaches its allocated time it saves state and pauses, allowing other tasks to run. You can also have a queue of pathfinding tasks, so that you don't end up in the situation of trying to process hundreds or thousands of tasks in some small time segment, with none of them really making progress.
On the other hand, have you profiled how many units are making pathfinding requests on average, and how long these tasks take to complete? The more information you have here the better you can design a system that meets your pathfinding latency and bandwith requirements.
Author
Hodgman and Siavash,
Thanks for your input. I am still trying to work out
the solution, you are very helpful indeed.
Jack
[Edited by - lucky6969b on April 26, 2010 6:28:49 AM]
Thanks for your input. I am still trying to work out
the solution, you are very helpful indeed.
Jack
[Edited by - lucky6969b on April 26, 2010 6:28:49 AM]
Author
Quote:Original post by rip-off
@siavash
Your analysis contains a flaw. 20 threads can be very responsive if they are all blocked waiting for something to happen. But if we are talking about 20 runnable threads all vying for processor time, then responsiveness is going to suffer.
@lucky6969b
Use a small thread pool. You generally don't want many more active threads than you have logical processors. Another consideration for responsiveness is to cap the total processor time doing pathfinding relative to the rest of your program.
For example, if you make it so that your pathfinding algorithm can be suspended and restored, then you can give the pathfinder X milliseconds to work with every frame, and once it reaches its allocated time it saves state and pauses, allowing other tasks to run. You can also have a queue of pathfinding tasks, so that you don't end up in the situation of trying to process hundreds or thousands of tasks in some small time segment, with none of them really making progress.
On the other hand, have you profiled how many units are making pathfinding requests on average, and how long these tasks take to complete? The more information you have here the better you can design a system that meets your pathfinding latency and bandwith requirements.
Hi rip-off,
Enter 8920140.000000
... do work
Leave 8920182.000000 Time Used: 42.000000
The app spends about 1 to several hundred milli seconds per iteration on p.f..
I wonder I need to re-design my code, but my algorithm is good for dynamic pathfinding since it is incremental in nature... it seems to be very slow when spawning 12 threads at the same time though.... or could you provide some good references/links for this? (especially for the stop and restart thing)
Thanks
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
