Reputation: 4347
I'm working on an application that does some heavy number crunching. It is intended to run on a single computer. Recently, we've started looking at multithreading to speed up the calculations. Some of the algorithms can be made to run parallel without much effort, and I use a fixed thread pool to run each of the sub tasks.
What I was wondering is: how is the number of threads (the size of the pool), typically specified for these kinds of algorithms? I suspect this is typically done by using either a configuration file, or a commandline parameter, but I haven't seen any examples like that, so I was wondering if there are better ways.
Related to this: Is it even relevant to specify the number of threads? I was thinking that setting the pool size to the number of assignable cores will likely run the fastest, but is the thread-contention for processing power in the case of over assignment even relevant for performance? Eg: will setting 20 max threads on a 4 core machine be worse than setting 4 max threads?
Edit: the application is intended for sale, so I have no idea what computers it will be run on. I'm looking for general guidelines, and best practices.
Upvotes: 1
Views: 348
Reputation: 32286
A rule of thumb is to use NUMBER_OF_CORES + 1
threads (certain parallel build systems use this) - one "spare" thread to work during another thread's IO. To find the number of cores, refer to this SO question.
Upvotes: 2
Reputation: 10357
The number of threads depends on several factors, mainly the number of HW cores like you mention, and also on the problem being solved/worked on in the threads. It might be best to do some trial and error with different thread pool sizes.
If the work that the threads are doing is hard-core number crunching like you mention, then I wouldnt expect much of an increase in performance by using more threads than HW cores. If the threads are doing work where they have to wait on external entities (like networking) then you may see an increase in performance by using more threads.
Upvotes: 0