threading
-
Thank you for the information. The optimal number of threads equals the number of processors on a system and it shouldn't exceed twice the processor count. Correct? Why not 3 times?
The main message is it is not tens of threads: just adding more and more threads will increase the overhead and not reduce the overall execution time. And it does depend on the thread function: if it is pure computation, one thread per processor will do; if there is I/O latency involved, two per processor will be better (and more typically does not help due to I/O limitations); if it is a pure Sleep() you can have as many as you want. The good thing is if you organize things around Environment.ProcessorCount: 1. you can try another factor and observe what it brings you. 2. your app is less likely to suddenly behave badly when you move it to a system with a different processor count (which may well happen when you fix the number of threads). And as Patrick pointed out, you are not completely in charge: 1. with .NET you will not (easily) control which thread runs on which processor; 2. other apps and services will be running too.
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - use PRE tags to preserve formatting when showing multi-line code snippets - before you ask a question here, search CodeProject, then Google
-
Can I just say, this entire discussion in the context of the .NET Framework is a waste of time. The Framework provides no control over where those threads are going to execute, nor do they provide synchronization capabilities across processor cores. The only limit on the number of threads you can actually create is the limit of the addressable memory space on the machine. If you really need a parallelized application, the .NET Framework is not the platform to use. If you need this, you should be using something like MPI, OpenMP, or a newer solution by Intel called Threading Building Blocks (http://osstbb.intel.com/[^]) which is aware not only of separate processors, but distinct processor cores. So far as I am aware, there are no .NET wrappers for those libraries. You'd be using C/C++. Once you get to those libraries, a question of how many threads to use becomes heavily dependent on what each thread is doing and the overall architecture of a parallelized application.
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
Yeah, it is not perfect, but my main objective was to warn against too many threads; some people seem to expect performance increases linearly with the number of threads, which obviously is not true at all. So for a single processor I often give the following approach: "as a first approximation, this is what you could do: write and run the code to use a single thread; observe the CPU load (with Task Manager) as a percentage. The inverse number is the number of threads you want, so if it is close to 100% extra threads won't bring you anything; if it is near 25% using four threads MIGHT increase the performance by four, bringing the CPU load to 100%. More threads than that won't help you." And one should not forget the obvious approach to increasing performance, is by optimizing the application at all levels: algorithms, data structures, coding, compiler settings, etc. :)
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - use PRE tags to preserve formatting when showing multi-line code snippets - before you ask a question here, search CodeProject, then Google
-
Can I just say, this entire discussion in the context of the .NET Framework is a waste of time. The Framework provides no control over where those threads are going to execute, nor do they provide synchronization capabilities across processor cores. The only limit on the number of threads you can actually create is the limit of the addressable memory space on the machine. If you really need a parallelized application, the .NET Framework is not the platform to use. If you need this, you should be using something like MPI, OpenMP, or a newer solution by Intel called Threading Building Blocks (http://osstbb.intel.com/[^]) which is aware not only of separate processors, but distinct processor cores. So far as I am aware, there are no .NET wrappers for those libraries. You'd be using C/C++. Once you get to those libraries, a question of how many threads to use becomes heavily dependent on what each thread is doing and the overall architecture of a parallelized application.
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
-
The main message is it is not tens of threads: just adding more and more threads will increase the overhead and not reduce the overall execution time. And it does depend on the thread function: if it is pure computation, one thread per processor will do; if there is I/O latency involved, two per processor will be better (and more typically does not help due to I/O limitations); if it is a pure Sleep() you can have as many as you want. The good thing is if you organize things around Environment.ProcessorCount: 1. you can try another factor and observe what it brings you. 2. your app is less likely to suddenly behave badly when you move it to a system with a different processor count (which may well happen when you fix the number of threads). And as Patrick pointed out, you are not completely in charge: 1. with .NET you will not (easily) control which thread runs on which processor; 2. other apps and services will be running too.
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - use PRE tags to preserve formatting when showing multi-line code snippets - before you ask a question here, search CodeProject, then Google
-
Can I just say, this entire discussion in the context of the .NET Framework is a waste of time. The Framework provides no control over where those threads are going to execute, nor do they provide synchronization capabilities across processor cores. The only limit on the number of threads you can actually create is the limit of the addressable memory space on the machine. If you really need a parallelized application, the .NET Framework is not the platform to use. If you need this, you should be using something like MPI, OpenMP, or a newer solution by Intel called Threading Building Blocks (http://osstbb.intel.com/[^]) which is aware not only of separate processors, but distinct processor cores. So far as I am aware, there are no .NET wrappers for those libraries. You'd be using C/C++. Once you get to those libraries, a question of how many threads to use becomes heavily dependent on what each thread is doing and the overall architecture of a parallelized application.
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
So just because a better threading lib exists in C one shouldn't use threading in .NET? Weird logic. I've used multithreading in dozens of situations in .NET and although it is not "aware" of the number of physical processors/cores it generally does a good job. Why? Because the operating system takes care of it.
-
So just because a better threading lib exists in C one shouldn't use threading in .NET? Weird logic. I've used multithreading in dozens of situations in .NET and although it is not "aware" of the number of physical processors/cores it generally does a good job. Why? Because the operating system takes care of it.
Robert Rohde wrote:
So just because a better threading lib exists in C one shouldn't use threading in .NET? Weird logic. I've used multithreading in dozens of situations in .NET and although it is not "aware" of the number of physical processors/cores it generally does a good job. Why? Because the operating system takes care of it.
Of course not. I was responding specifically in the context of counting threads based on the number of processors you have. That's pointless in .NET. Yes, the OS will do some thread parallelization for you, but if you actively want to use those processors you have to use lower level languages with specialized libraries. There's nothing wrong with threading, but you have to understand your problem and the limitations of various solutions before you start creating tons of threads thinking it will solve your problem, as Luc accurately points out.
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
-
Robert Rohde wrote:
So just because a better threading lib exists in C one shouldn't use threading in .NET? Weird logic. I've used multithreading in dozens of situations in .NET and although it is not "aware" of the number of physical processors/cores it generally does a good job. Why? Because the operating system takes care of it.
Of course not. I was responding specifically in the context of counting threads based on the number of processors you have. That's pointless in .NET. Yes, the OS will do some thread parallelization for you, but if you actively want to use those processors you have to use lower level languages with specialized libraries. There's nothing wrong with threading, but you have to understand your problem and the limitations of various solutions before you start creating tons of threads thinking it will solve your problem, as Luc accurately points out.
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
Patrick Sears wrote:
I was responding specifically in the context of counting threads based on the number of processors you have. That's pointless in .NET.
Not totally. I agree that you cannot be 100% sure that if you run 4 threads in .NET that every thread will run on its own core (although it does it very often). Nevertheless you have a "hint" on how many parellel threads might be good. If you know you have only one core than you would normally not start several threads (assumming its only about number crunching). But I agree with your other points. :) Robert
-
Patrick Sears wrote:
I was responding specifically in the context of counting threads based on the number of processors you have. That's pointless in .NET.
Not totally. I agree that you cannot be 100% sure that if you run 4 threads in .NET that every thread will run on its own core (although it does it very often). Nevertheless you have a "hint" on how many parellel threads might be good. If you know you have only one core than you would normally not start several threads (assumming its only about number crunching). But I agree with your other points. :) Robert
Robert Rohde wrote:
Not totally. I agree that you cannot be 100% sure that if you run 4 threads in .NET that every thread will run on its own core (although it does it very often). Nevertheless you have a "hint" on how many parellel threads might be good. If you know you have only one core than you would normally not start several threads (assumming its only about number crunching).
And I also agree with you there ;)
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
-
Robert Rohde wrote:
So just because a better threading lib exists in C one shouldn't use threading in .NET? Weird logic. I've used multithreading in dozens of situations in .NET and although it is not "aware" of the number of physical processors/cores it generally does a good job. Why? Because the operating system takes care of it.
Of course not. I was responding specifically in the context of counting threads based on the number of processors you have. That's pointless in .NET. Yes, the OS will do some thread parallelization for you, but if you actively want to use those processors you have to use lower level languages with specialized libraries. There's nothing wrong with threading, but you have to understand your problem and the limitations of various solutions before you start creating tons of threads thinking it will solve your problem, as Luc accurately points out.
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
Patrick Sears wrote:
but you have to understand your problem and the limitations of various solutions before you start
Sorry but that is counter the VB way of life. You "start" by dragging and dropping controls onto a form. All the rest of the development is insignificant overpaid typing.
-
Patrick Sears wrote:
but you have to understand your problem and the limitations of various solutions before you start
Sorry but that is counter the VB way of life. You "start" by dragging and dropping controls onto a form. All the rest of the development is insignificant overpaid typing.
led mike wrote:
Sorry but that is counter the VB way of life. You "start" by dragging and dropping controls onto a form. All the rest of the development is insignificant overpaid typing.
Hehehe, touche' :-D
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee