Potential Pitfalls in Parallel Programming



In my previous article, we have seen the internal working of the Parallel Programming; let's see the potential pitfalls of the parallel programming in this article.

In many cases parallel programming can provide significance improvement over the normal sequential programming. But sometimes, parallelizing the loop introduces complexity that leads to severe performance issues. Let's discuss about those areas in detail here.

Parallel is not always faster

We should not assume blindly that parallel programming is always faster. Some cases like loops with few iterations and fast user delegates are not sped up in parallel programming when compared with normal sequential programming. Since many factors are involved in the performance, measuring the actual results can show which one performs better.

Code Example

Parallel1.gif

In the first example, we are doing an expensive function using PLINQ, so PLINQ will produce the results faster. Whereas the second query uses the normal mod operator function using PLINQ, here the PLINQ will produce the results slower compared with the normal LINQ, because it creates some extra overhead for doing the simple operations.

Number of Logical Cores Matters

Queries or any loops that are delightfully parallel run faster on machines that have more cores, because the work will be divided among the cores. However it's not a simple rule like parallel loop will run twice as fast on an eight core computer as a four core computer. Again it depends on how the queries or loops are constructed in a function. When tuning the function, it is important to measure the actual results in each iteration with different machines.

Parallel2.gif

Parallel Sometimes Choose Sequential

There are certain situations in which the parallel programming will execute the code in normal sequential mode.

The following list describes the query shapes that PLINQ by default will execute in sequential mode:

  • Queries that contain a Select, indexed Where, indexed SelectMany, or ElementAt clause after an ordering or filtering operator that has removed or rearranged original indices.
  • Queries that contain a Take, TakeWhile, Skip, SkipWhile operator and where indices in the source sequence are not in the original order.
  • Queries that contain Zip or SequenceEquals, unless one of the data sources has an originally ordered index and the other data source is indexable (i.e. an array or IList(T)).
  • Queries that contain Concat, unless it is applied to indexable data sources.
  • Queries that contain Reverse, unless applied to an indexable data source.

High Level Architecture of Parallel Programming in .NET 4.

References: http://msdn.microsoft.com/en-us/library/dd460693.aspx

Hope the above article helps you to decide when to choose parallel and when to go for sequential programming.
 


Similar Articles