Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I just finished coding a (basic) ray tracer in C# for fun and for the learning experience. Now I want to further that learning experience. It seems to me that ray tracing is a prime candidate for parallel processing, which is something I have very little experience in. My question is this: how do I know the optimum number of concurrent processes to run?

My first instinct tells me: it depends on how many cores my processor has, but like I said I'm new to this and I may be neglecting something.

share|improve this question
"how do I know the optimum number of concurrent processes to run?" - by testing for different numbers. Sometimes an algorithm doesn't gain much from running in parallel (considering the overheads). – Oded Apr 11 '12 at 16:02
And once you have the number of cores, you can start wondering about the wonderful problems of Load Balancing, if it is Dynamic Load Balancing it can be even more fun! – Zenon Apr 11 '12 at 16:22
@Zenon - Ah. I had thought load balancing would be an issue if I was doing distributed computing over several disparate machines, not cores in the same machine. – System Down Apr 11 '12 at 16:33
@SystemDown - Well, as soon as your computations are not done sequentially, you will have to worry about how to divise the tasks and how to merge them together at the end, also who and when can modify the objects shared between the processes, and how the memory is divided between the processes. The implementation is (IMO) more complicated when you do it with many machines, but the "spirit" stays the same. Some languages are easier to distribute (e.g. Scala) but you will always have to make a lot of decisions. – Zenon Apr 11 '12 at 17:54
The answer depends on how you structure your code and what your target hardware architecture is like. Programming for GPUs is different from multicore CPUs. I upvoted Mike Brown's answer because it likely answers your question and is applicable to your existing code, but for an example of other ways to structure your code, read cache-oblivious algorithms. – Sonia Apr 11 '12 at 17:54
up vote 4 down vote accepted

The .NET framework has a built-in setting that optimizes the number of concurrent threads if you use the ThreadPool directly or the more convenient Task Parallel Library API. I believe it is something like 20 per logical core (but I don't see that in the documentation anymore). If you want to control your threads directly, you can still call the ThreadPool's GetMaxThreads function to see what the framework recommends. For a really neat demo of leveraging the features of C#, check out this raytracer implemented using LINQ

share|improve this answer
Wait. Does that mean that "for each" is automatically parallelized? – System Down Apr 11 '12 at 16:28
If you use Parallel.ForEach it is. – Michael Brown Apr 11 '12 at 16:36
Interesting! Thanks for the tip. – System Down Apr 11 '12 at 16:38

The maximum improvement one could achieve is described by Amdahl's law. How parallelizable your application can become is a combination of the task and algorithms used. To determine the optimal number of processor cores will involve measuring performance and probably simulation.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.