I am using the task parallel library from .NET framework 4 (specifically Parallel.For and Parallel.ForEach) however I am getting extremely mediocre speed-ups when parallelizing some tasks which look like they should be easily parallelized on a dual-core machine.
In profiling the system, it looks like there is a lot of thread synchronization going on because of the garbage collector. I am doing a lot of allocation of objects, so I am wondering how I can improve the concurrency while minimizing a rewrite of my code.
For example are there some techniques that can be useful in this situation:
- Should I try to manage the GC manually?
- Should I be using
Dispose? - Should I be pinning objects?
- Should I be doing other unsafe code tricks?
POSTSCRIPT:
The problem is not the GC running too often, it is that the GC prevents concurrent code from being running in parallel efficiently. I also don’t consider “allocate fewer objects” to be an acceptable answer. That requires rewriting too much code to work around a poorly parallelized garbage collector.
I already found one trick which helped overall performance (using gcServer) but it didn’t help the concurrent performance. In other words Parallel.For was only 20% faster than a serial For loop, on an embarrassingly parallel task.
POST-POSTSCRIPT:
Okay, let me explain further, I have a rather big and complex program: an optimizing interpreter. It is fast enough, but I want its performance when given parallel tasks (primitive operations built into my language) to scale well as more cores are available. I allocate lots of small object during evaluations. The whole interpreter design is based on all values being derived from a single polymorphic base object. This works great in a single-threaded application, but when we try to apply the Task Parallel Library to parallel evaluations there is no advantage.
After a lot of investigation into why the Task Parallel Library was not properly distributing work across cores for these tasks, it seems the culprit is the GC. Apparently the GC seems to act as a bottle-neck because it does some behind the scene thread synchronization that I don’t understand.
What I need to know is: what exactly is the GC doing that can cause heavily concurrent code to perform badly when it does lots of allocations, and how we can work around that other than just allocating fewer objects. That approach has already occurred to me, and would require a significant rewrite of a lot of code.
If GC is running too often due to too many objects being allocated/GC-ed, try to allocate fewer of them 🙂
Depending on you scenario – try to reuse existing objects, create an object pool, use “lighter” objects that do not put so much memory pressure (or larger to reduce the number of objects allocated).
Do not try to “manage GC” by calling GC.Collect explicitly, it very rarely pays off (Rico Mariani says so)
or http://blogs.msdn.com/ricom/archive/2003/12/02/40780.aspx