Making A Difference

Mike Wood presented on PLINQ or Parallel LINQ, a pre-beta addition to LINQ that takes advantage of multi-processor machines. Chris Woodruff, scheduled to present, could not make the trip from Michigan due to work commitments and production issues.

Mike compared the evolution of threading and parallel processing to the evolution of writing and the printing press. Where writing evolved from a heavily manual process to a printing press, and then to a simple “print” button, threading similarly evolved to a point where we almost have the print button. Threading is HARD. If you write threading code and you think threading is easy, then you have bugs in your code. Writing dependable threading code requires using threading libraries that implement proven and tested routines so you don’t have to handle every case manually. The PLINQ libraries, in this context, are almost “print” button nirvana.

LINQ works off of extension methods off the IEnumerable<T> interface. PLINQ adds the AsParallel keyword to get access to the PLINQ extension methods of IParallelEnumerable. Using PLINQ, Mike’s example code on a dual-processor machine ran in 1/2 the time of the LINQ example without writing a line of threading code. With PLINQ, threading was obvious as the output returned in no specific order where the LINQ example returned the output serially.

You can find PLINQ in the System.Threading namespace. PLINQ implements three processing strategies: 1) Inverted Enumeration, 2) Pipelining, and 3) Stop & Go. Pipelining and Stop & Go return collections while Inverted Enumeration simply processes and does not return anything. Inverted Enumeration also does not incur the overhead of merging results after completing the processing.

Of course using PLINQ has its issues. Thrown exceptions require some diligence to resolve as your code doesn’t handle each thread. Specifically, you need to catch AggregateException and look through the exceptions it has captured to find lower level information about what just happened. Also, parallel processing isn’t always the right solution. Amdahl’s law models the performance benefit of parallelization against the the amount of work that can actually be parallelized. You achieve the best performance results as more of the application can actually run in parallel and is not as dependent on sequential processing.

PLINQ, therefore, does not save the world. You won’t use it for every solution. In fact, a good practice is to develop your solution and then try PLINQ to understand if it actually helps. Test it. See if it will work for you.

- Andy

This entry was posted Friday, September 26th, 2008 at 4:01 pm and is filed under Cincinnati IT Community. You can leave a response, or trackback from your own site.