Parallel.Foreach as fast / slow as normal ForEach

Question

UPDATE: I used Threading to split up the Loop in the Amount of Kernels (8 in my Case) and the complete Loop went through in under 1 second. So the problem is not, that the Operation is not faster with threading. Why did Parralel Extension fail in this case?

Hey everyone. I want to convert my ForEach with Parrallel.Foreach. The problem is, that the parralelisation brings hardly any advantage for me.

Original:

foreach (Entities.Buchung buchung in buchungen) {
    Int32 categoryID = manager.GetCategoryID(new Regelengine.Booking(buchung)); // Average 4ms
    buchung.Category = categoryID.ToString();
}

Parallel:

System.Threading.Tasks.Parallel.ForEach(buchungen, buchung => {
    Int32 categoryID = manager.GetCategoryID(new Regelengine.Booking(buchung));
    buchung.Category = categoryID.ToString();
});

Results:

---------------------------
Stopwatched Results for 1550 entries in the List:
---------------------------
Parallel.Foreach 00:00:07.6599066
Average Foreach: 00:00:07.9791303

Maybe the problem is, that the actual action in the loop is so short? But nobody can tell me, that parallelising 1550 operations on an Intel I7 won't save any time.

Answer 1

There is only one resource you can take advantage of by using Parallel.For: CPU cycles. When you have N cores then you can theoretically speed up your code by a factor of N. What is however required is that it is actually CPU cycles that is the constraint in your code. Which is not often the case unless you execute computationally expensive code. Other constraints are the speed of the hard disk, the network connection, a dbase server, in select cases the bandwidth of the memory bus. You've only got one of those, Parallel.For cannot magically give you another disk.

Testing whether Parallel.For will speed up your code is pretty simple. Just run the code without parallelizing and observe the CPU load in Taskmgr.exe or Perfmon. If one core isn't running at 100% then your code is not compute bound. If it is running at, say, 10% then you can only ever hope to make it take 90% of the time no matter how many cores you have. Which you'll get by overlapping I/O wait time with processing time, two threads will get that done.

Answer 2

Questions that you should consider in this are:

• What is the overhead of spinning up a thread?
• What is the overhead of my thread safety (locks)?
• Where are the actual bottlenecks and will multithreading really help?

The last is your biggest consideration here. For example, if you are maxing your i/o channel, all the threads in the world won't do squat. So is your task CPU bound or I/O bound?