A reader commented on my parallel programming post that the locks I used in my code were the cause of the slow performance I observed. With my implementation the locks are necessary or there is a possibility the code with fail, and it does quite often. I have done some research and it appears the optimal way to increase performance is to use one of the new System.Collections.Concurrent collections. The concurrent collections are designed to work in a multi-threaded environment when collections are going to be accessed concurrently with a minimal amount of locks. I am going to modify the existing code to use a ConcurrentBag<T> collection and will post the updated results here tomorrow.

In the upcoming .NET 4 release, there are new concepts designed to help developers take advantage of the trend towards multi-core processors. This sounds like a great thing, I’m all for anything that increases performance with minimal added complexity. So we should all just run out and change all of our “foreach” loops to utilize the new framework right? I felt the need to investigate what benefits we will be getting and over the next few posts I will present and discuss my findings.

My first test was to do a very straightforward and simple comparison of an everyday task. First I generate 10,000,000 strings and put them into the list. I then iterate over the list and find all strings that match “foo”, and move them to a new list. For the results, I run this process 10 times and take the average. For this first test I decided on 4 different iteration methods: standard “foreach” loop, parallel “foreach” loop, standard LINQ query, and parallel LINQ query. I decided to also throw in the LINQ queries for two reasons. First as another comparison between standard and parallel processing and second as a comparison of LINQ to standard iteration methods. I ran the tests on a quad core AMD 9950 compiled for both 32 and 64 bit platforms.

Fig. 1 – 32 bit

Fig. 2 – 64 bit

The test yield some interesting results. First of all, the parallel methods didn’t win a single test. On its face this might be strange, but when you consider then simplicity of the loop and the overheard of setting up the various threads for each CPU then the results make a little more sense. The second thing is the stunning amount of time the parallel “foreach” loop takes when compiled in 32bit mode. I have no explanation for this result, but keep in mind this is the beta version of the .NET 4 framework. I will also try to run this test on an Intel box in the near future and see if the processor makes a difference.

In conclusion, I wouldn’t be preparing to go off and change all of my loops to use the parallel extensions. The loop is going to have to have a certain level of complexity before there is anything to be gained by making the switch. My goal over the next few weeks is to more thoroughly test the parallel extensions and see if I can determine at what level of complexity we she start using them. Stay tuned.

Click hereto download the Visual Studio 2010 project.