I am currently working on an application that has an "embarrassingly Parallel" scenario. Is there any guideline/algorithm to determine ideal number of tasks to maximize CPU utilization.
-
When you say "task" do you mean "System.Threading.Task" or the high level concept of "things that need doing"? If the latter, what mechanism *are* you using to actually parallelize your code? – Servy Jan 03 '14 at 21:19
3 Answers
I think the best approach is to first let the framework deal with that and do something more complicated only when that isn't good enough.
In your case, it would probably mean using Parallel.ForEach()
to process some collection, instead of manually using n Task
s.
When you find out that Parallel.ForEach()
with default settings doesn't parallelize the work in the way you would want, then you try fiddling with it, by setting MaxDegreeOfParallelism
or using a custom partitioner.
And only when that still isn't good enough, then you should consider using Task
s.

- 236,525
- 50
- 385
- 514
If you could maintain a number of threads equal to the number of cores (or double if you have Hyperthreading enabled) the CPU should be utilized in the optimal way.
Also, the related post might be helpful: Optimal number of threads per core.
This depends on your task. If you only process and don't wait for I/O, you should have as many as you have cores.
Sending queries to many different servers, waiting 20 to 40ms for a response, reading some I/O from some disk drive or tape recorder, and then processing only a single ms, every core can serve 30 threads or more.

- 19,906
- 19
- 75
- 162
-
Thank you for the inputs. As I cannot assume that my method is the only one running on the server, is there a way to determine number of current threads on the server (Something similar to Environment.ProcessorCount) and a scientific approach to calculate ideal number of tasks dynamically. – Kiran Vedula Jan 02 '14 at 23:08
-
I don't believe that you can calculate the optimal number of threads just using the thread count as an input. There is a varying amount of background tasks and services, with threads regularly checking for input and then going back to sleep. Question is how long you have to wait for I/O. Reading data from SSD, I/O time is negligible (and won't get any better using more threads), hard disk access time is in the milliseconds, and internet server response time is in the tens of milliseconds. You would use a profiler to check. – Alexander Jan 03 '14 at 07:07
-
Ah, I forgot: You could also use the processor usage to determine the need for more threads. But the heuristics is not as simple as it sounds: If processor usage of you program does not increase when adding another thread, I/O already is the limiting factor. On the other hand, when you have 100% processor usage, I/O could be low - more threads could increase performance by keeping I/O constantly at limit. – Alexander Jan 03 '14 at 07:11
-
Thank you for providing more insights, this really helps. Thank you. – Kiran Vedula Jan 05 '14 at 19:02