short and long worker thread VS sincronization and global efficiency
-
I have a long routine that I'm thinking to modify splitting it in different parallel worker-thread. This to try to reach 100% on multicore CPU and let the time required be less. Now when I start the worker-threads (say 3-5) the main-thread have to (simply) wait that the other worker-threads ends. Then it have to repeat this stage for many iterations. A simple solution I found is to start in the main-thread a loop that do a simple Sleep (for some ms) and then checks some flags that the worker-threads sets when ending. When it understand that all the threads are end it make some computations and start all again. What I test is that for long worker-thread it seems to work (CPU reaches 100%), but when the worker-thread are very shorts (some ms) it looks that the CPU doesn't reach high values. I think because the time spent into the sleep function is too much in comparison with the time required from the worker thread. Because the time required from the worker-thread depends on a complex combination of the input parameters and I can't estimate at the beginning then I tried to start with a sleepTime = 2m (very low!) increasing it after every loop of the main-thread. But again the CPU in case of short processing looks to low. Any suggestion? Diffent approaches?
Russell
-
I have a long routine that I'm thinking to modify splitting it in different parallel worker-thread. This to try to reach 100% on multicore CPU and let the time required be less. Now when I start the worker-threads (say 3-5) the main-thread have to (simply) wait that the other worker-threads ends. Then it have to repeat this stage for many iterations. A simple solution I found is to start in the main-thread a loop that do a simple Sleep (for some ms) and then checks some flags that the worker-threads sets when ending. When it understand that all the threads are end it make some computations and start all again. What I test is that for long worker-thread it seems to work (CPU reaches 100%), but when the worker-thread are very shorts (some ms) it looks that the CPU doesn't reach high values. I think because the time spent into the sleep function is too much in comparison with the time required from the worker thread. Because the time required from the worker-thread depends on a complex combination of the input parameters and I can't estimate at the beginning then I tried to start with a sleepTime = 2m (very low!) increasing it after every loop of the main-thread. But again the CPU in case of short processing looks to low. Any suggestion? Diffent approaches?
Russell
-
I have a long routine that I'm thinking to modify splitting it in different parallel worker-thread. This to try to reach 100% on multicore CPU and let the time required be less. Now when I start the worker-threads (say 3-5) the main-thread have to (simply) wait that the other worker-threads ends. Then it have to repeat this stage for many iterations. A simple solution I found is to start in the main-thread a loop that do a simple Sleep (for some ms) and then checks some flags that the worker-threads sets when ending. When it understand that all the threads are end it make some computations and start all again. What I test is that for long worker-thread it seems to work (CPU reaches 100%), but when the worker-thread are very shorts (some ms) it looks that the CPU doesn't reach high values. I think because the time spent into the sleep function is too much in comparison with the time required from the worker thread. Because the time required from the worker-thread depends on a complex combination of the input parameters and I can't estimate at the beginning then I tried to start with a sleepTime = 2m (very low!) increasing it after every loop of the main-thread. But again the CPU in case of short processing looks to low. Any suggestion? Diffent approaches?
Russell
Why not have your main threads wait for your worker threads to finish (usually called a join) rather than sleeping and polling? boost::thread has a join facility and if you're using something Microsofty you can get the same effect using WaitForMulipleObjects. Cheers, Ash
-
Why not have your main threads wait for your worker threads to finish (usually called a join) rather than sleeping and polling? boost::thread has a join facility and if you're using something Microsofty you can get the same effect using WaitForMulipleObjects. Cheers, Ash
maked the test. it is the same as before. This is the result: My notebook has 2 CPU so if I start a long function as a single thread the CPU go not more to 50%. Using 3 parallel long threads the CPU goes to 100%. But if the worker-thread are short it looks that the program spends more time in syncronization then in processing because the CPU stays under 45-40%. I done the test also runung the program compiled in release mode (speed optimization) inside and outside Visual studio.... the result is the same. does anybody has some tips?
Russell
-
I have a long routine that I'm thinking to modify splitting it in different parallel worker-thread. This to try to reach 100% on multicore CPU and let the time required be less. Now when I start the worker-threads (say 3-5) the main-thread have to (simply) wait that the other worker-threads ends. Then it have to repeat this stage for many iterations. A simple solution I found is to start in the main-thread a loop that do a simple Sleep (for some ms) and then checks some flags that the worker-threads sets when ending. When it understand that all the threads are end it make some computations and start all again. What I test is that for long worker-thread it seems to work (CPU reaches 100%), but when the worker-thread are very shorts (some ms) it looks that the CPU doesn't reach high values. I think because the time spent into the sleep function is too much in comparison with the time required from the worker thread. Because the time required from the worker-thread depends on a complex combination of the input parameters and I can't estimate at the beginning then I tried to start with a sleepTime = 2m (very low!) increasing it after every loop of the main-thread. But again the CPU in case of short processing looks to low. Any suggestion? Diffent approaches?
Russell
Russell' wrote:
A simple solution I found is to start in the main-thread a loop that do a simple Sleep (for some ms) and then checks some flags that the worker-threads sets when ending. When it understand that all the threads are end it make some computations and start all again.
There are several MFC synchronization classes just for this. Anytime you have to use
Sleep()to get the desired result, it is most likely a bad design."One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
-
maked the test. it is the same as before. This is the result: My notebook has 2 CPU so if I start a long function as a single thread the CPU go not more to 50%. Using 3 parallel long threads the CPU goes to 100%. But if the worker-thread are short it looks that the program spends more time in syncronization then in processing because the CPU stays under 45-40%. I done the test also runung the program compiled in release mode (speed optimization) inside and outside Visual studio.... the result is the same. does anybody has some tips?
Russell
How long are the threads processing for before they're terminating? If it's less than a second you're not going to get a big speedup. That's life unfortunately! There are all sorts of things that can slow processing of threads down: - the most common one is not partitioning the data properly so you've got complex synchronisation objects involved. It takes time to lock a mutex or raise a semaphore - you're blowing the shared L2 cache. Either the data working set is too big to fit in the cache so all your threads slow down as they're punting each other's data out OR there's no locality of reference in the data structures you're using. For example sharing a map between threads can be eyewateringly slow compared to sharing a vector. You could try compiling for size and see if that affects the number of cache misses (faster code is usually bigger so less of it fits in the processor cache) - it just takes time to start up a thread. Somewhere between 10ms and 100ms depending on your system Anyway the upshot of this is it's a bit hard to work out what's wrong without seeing some code and then most of the people on here probably couldn't make very good guesses as to what's wrong (me included). The other moral of this story is to only start multiple threads when you've got something specific for them to do that's going to slow down the responsiveness of your application if you do it on your main thread. Cheers, Ash
-
How long are the threads processing for before they're terminating? If it's less than a second you're not going to get a big speedup. That's life unfortunately! There are all sorts of things that can slow processing of threads down: - the most common one is not partitioning the data properly so you've got complex synchronisation objects involved. It takes time to lock a mutex or raise a semaphore - you're blowing the shared L2 cache. Either the data working set is too big to fit in the cache so all your threads slow down as they're punting each other's data out OR there's no locality of reference in the data structures you're using. For example sharing a map between threads can be eyewateringly slow compared to sharing a vector. You could try compiling for size and see if that affects the number of cache misses (faster code is usually bigger so less of it fits in the processor cache) - it just takes time to start up a thread. Somewhere between 10ms and 100ms depending on your system Anyway the upshot of this is it's a bit hard to work out what's wrong without seeing some code and then most of the people on here probably couldn't make very good guesses as to what's wrong (me included). The other moral of this story is to only start multiple threads when you've got something specific for them to do that's going to slow down the responsiveness of your application if you do it on your main thread. Cheers, Ash
Aescleal wrote:
it just takes time to start up a thread. Somewhere between 10ms and 100ms depending on your system
oh ... too much ... that is surely the problem I verified with my routine! I then need to restyle the main thread to find if it is useful or not fire up some worker-thread thanks, Matteo
Russell