tags:

views:

116

answers:

2

I'm curious about the performance characteristics of Parallel.ForEach. Given any valid construct inside a Parallel.ForEach loop, is it always preferable to use Parallel.ForEach over a foreach loop? I'm specifically wondering about the overhead of invoking the Parallel Tasks library on small sets or other edge cases where a foreach loop might be faster. I know the library is pretty smart about when/how to spawn threads...are there cases where it's better to just leave code in a foreach loop, or is the overhead for calling Parallel Tasks generally negligble, so if you can, you should use Parallel.ForEach?

This question is similar and provides good functional difference information but doesn't really speak to performance. Note that I'm ignoring compatibility to .NET <4 as a reason for staying with a foreach:

http://stackoverflow.com/questions/1924535/c-any-benefit-of-listt-foreach-over-plain-foreach-loop

+6  A: 

It's not always preferable. For fast loop bodies, Parallel.ForEach can degrade performance. One of the guidelines listed in Parallel Programming Coding Guidelines is to measure both before and after parallelization.

Other useful articles have been published by the parallel computing group.

Stephen Cleary
Emil Lerch
+1 for referencing the Parallel Programming Coding Guidelines.
Steven
+2  A: 

I would say to always stick with simple (i.e. regular foreach) and only implement more complex stuff (i.e. Parallel ForEach) when you have a measurable requirement to do so. So if you can prove that in a particular instance that the normal foreach isn't as fast as you need, and you can prove for that particular instance that the Parallel foreach will solve your problem, then use the Parallel.

Otherwise just keep it simple.

NotDan
I disagree with this, "as fast as you need" is not the same "as fast as the user would like". We should look at pallelizing things more frequently as the avg number of cores rises.
Henk Holterman