Multithreading
-
Hello, Suppose to have a 4 processors system. It is better to have 32 working threads or 8 groups of 4 working threads to do the same job. In the first case I can ignore the number of processors because the work it is splitted equally on everyone. In the second I have to take care of it but maybe the OS is less involved in continually switching from thread to thread... Any other consideration to help me decide? :confused: Thanks a lot, Alberto Bencivenni www.devDept.com
-
Hello, Suppose to have a 4 processors system. It is better to have 32 working threads or 8 groups of 4 working threads to do the same job. In the first case I can ignore the number of processors because the work it is splitted equally on everyone. In the second I have to take care of it but maybe the OS is less involved in continually switching from thread to thread... Any other consideration to help me decide? :confused: Thanks a lot, Alberto Bencivenni www.devDept.com
Alberto Any other considerations? Sure: what are the threads doing, do the threads interact with other (operating system) processes and threads, are you going to be implementing a thread pool (that is, sharing lots of thread-like activity amongst a small set of threads), how are you implementing synchronization, how many objects need synchronization, do the threads interface with the UI thread, etc, etc. What I'm trying to get at is this. The question as posed has no right or wrong answer. To find out your answer, you need to write the app, or as much of the app as makes sense, and then profile it (that is run it and tweak it) in the environment you want. Worrying too much about fine details like how can you extract as much performance from a four processor system versus, say, a two processor system when you don't have the actual code is putting the cart before the horse. Writing performant multithreaded apps tends to be more about how efficient and well-written your inter-threadd communication is set up than anything else. Also, in my experience, trying to second-guess the operating system by forcing some threads onto some CPU and others onto another, could do more harm than good. Cheers, Julian [MSFT] Program Manager, C# This posting is provided "AS IS" with no warranties, and confers no rights.
-
Hello, Suppose to have a 4 processors system. It is better to have 32 working threads or 8 groups of 4 working threads to do the same job. In the first case I can ignore the number of processors because the work it is splitted equally on everyone. In the second I have to take care of it but maybe the OS is less involved in continually switching from thread to thread... Any other consideration to help me decide? :confused: Thanks a lot, Alberto Bencivenni www.devDept.com
I seem to recall that the optimal number of active worker threads per CPU is two. If those threads will be waiting, you will, of course, need a larger thread pool. To scale correctly, you should detect the number of CPUs and act accordingly, but unless you are doing something very specialized (like assigning a thread to a CPU) I'd suggest using a single pool. Of course, you'd want to empirically test any proposed solution to the extent possible. (I can't actually emphasize this enough. I've been surprised more than once by actual performance in heavily multi-threaded apps.)
-
I seem to recall that the optimal number of active worker threads per CPU is two. If those threads will be waiting, you will, of course, need a larger thread pool. To scale correctly, you should detect the number of CPUs and act accordingly, but unless you are doing something very specialized (like assigning a thread to a CPU) I'd suggest using a single pool. Of course, you'd want to empirically test any proposed solution to the extent possible. (I can't actually emphasize this enough. I've been surprised more than once by actual performance in heavily multi-threaded apps.)
Interesting, in my work project, I've been assuming something like a minimum of 10 threads and an upper bound of 25 threads. (I've been using Mike Woodring's ThreadPool, which seems far more superior to System.Threading.ThreadPool.) I'm worried that it's overloading the CPU... My project does a lot of work with collecting a bunch of Web pages and parsing them. Some time is spent waiting for a page to be received, but a lot more is spent processing/scraping the pages. Perhaps I'll try a lower minimum and perhaps a lower maximum.
-
Alberto Any other considerations? Sure: what are the threads doing, do the threads interact with other (operating system) processes and threads, are you going to be implementing a thread pool (that is, sharing lots of thread-like activity amongst a small set of threads), how are you implementing synchronization, how many objects need synchronization, do the threads interface with the UI thread, etc, etc. What I'm trying to get at is this. The question as posed has no right or wrong answer. To find out your answer, you need to write the app, or as much of the app as makes sense, and then profile it (that is run it and tweak it) in the environment you want. Worrying too much about fine details like how can you extract as much performance from a four processor system versus, say, a two processor system when you don't have the actual code is putting the cart before the horse. Writing performant multithreaded apps tends to be more about how efficient and well-written your inter-threadd communication is set up than anything else. Also, in my experience, trying to second-guess the operating system by forcing some threads onto some CPU and others onto another, could do more harm than good. Cheers, Julian [MSFT] Program Manager, C# This posting is provided "AS IS" with no warranties, and confers no rights.
Julian, I have - lets say 16 - working threads that are doing a very intensive task and 1 UI threads that waits for them. I work on a double Intel XEON processor workstation. After waiting this 16 workers (with the WaitAll on 16 ManualResetEvent handles) I sort the results alter the data and start again. In 2 words a GA algorithm. Threads are completely indipendend one from the other and don't interact with the UI thread. In my opinions should be better to detect the number of processor (suppose 2) and do 8 job on each processor (this would mean 1 UI thread, 2 workers and 2 MaualResetEvent for synchronization). The other option is to start all the 16 threads and leave the OS to split the work between available processors. I did not consider the Threadpool because I read somewere that it is not good for very intensive tasks... Am I right? :-O Do you know any article that specifically talk about these matters? :confused: Thanks a lot, Alberto Bencivenni www.devDept.com
-
I seem to recall that the optimal number of active worker threads per CPU is two. If those threads will be waiting, you will, of course, need a larger thread pool. To scale correctly, you should detect the number of CPUs and act accordingly, but unless you are doing something very specialized (like assigning a thread to a CPU) I'd suggest using a single pool. Of course, you'd want to empirically test any proposed solution to the extent possible. (I can't actually emphasize this enough. I've been surprised more than once by actual performance in heavily multi-threaded apps.)
Hello Joe, So, we can say that to improve the application performances it is better to use the smallest number of thread that keep processors at 100% of usage? :eek: Thanks a lot, Alberto Bencivenni www.devDept.com
-
Hello Joe, So, we can say that to improve the application performances it is better to use the smallest number of thread that keep processors at 100% of usage? :eek: Thanks a lot, Alberto Bencivenni www.devDept.com
For optimal performance you want to minimize context switches, so the fewest number of threads using the maximum amount of CPU is the best. (Realize, of course, that if your threads are using up their entire slice, you will see serious system degredation from other, especially low priority, processes [like the GUI].)
-
Julian, I have - lets say 16 - working threads that are doing a very intensive task and 1 UI threads that waits for them. I work on a double Intel XEON processor workstation. After waiting this 16 workers (with the WaitAll on 16 ManualResetEvent handles) I sort the results alter the data and start again. In 2 words a GA algorithm. Threads are completely indipendend one from the other and don't interact with the UI thread. In my opinions should be better to detect the number of processor (suppose 2) and do 8 job on each processor (this would mean 1 UI thread, 2 workers and 2 MaualResetEvent for synchronization). The other option is to start all the 16 threads and leave the OS to split the work between available processors. I did not consider the Threadpool because I read somewere that it is not good for very intensive tasks... Am I right? :-O Do you know any article that specifically talk about these matters? :confused: Thanks a lot, Alberto Bencivenni www.devDept.com
I don't know. The best answer I can give is: write it to not "know" about the number of processors. This is the simplest code you could write: you're going to let the OS do all the scheduling work. After all the OS is going to be context-switching under you anyway to service the network, do file IO, do whatever. If the performance isn't all it's cracked up to be, now add some moderately complex code to identify how many processors there are, how to split up the total work between processors, etc. Run it and profile. Tweak. Run it and profile. Rinse and repeat. I would doubt that you'd make much difference for the amount of work it will take you. I would hazard a guess that improving the algorithm that's doing the work will get you more bang for your coding buck. The threadpool is designed to obviate the need to continually create OS threads, an expensive process. That's all. It makes no difference to the speed of execution of code in the thread. References, wow. Not off the top of my head, no, sorry. Certainly I don't know of any in the C#/.NET world. Cheers, Julian Program Manager, C# This posting is provided "AS IS" with no warranties, and confers no rights.