Performance impact of Processes vs Threads

Question

Clearly if performance is critical it makes sense to prototype and profile. But all the same, wisdom and advice can be sought on StackOverflow :)

For the handling of highly parallel tasks where inter-task communication is infrequent or suits message-passing, is there a performance disadvantage to using processes (fork() etc) or threads?

Is the context switch between threads cheaper than that between processes? Some processors have single-instruction context-switching don't they? Do the mainstream operating systems better utilise SMP with multiple threads or processes? Is the COW overhead of fork() more expensive than threads if the process never writes to those pages?

And so on. Thanks!

Answer 1

The idea that processes are slow to create is an old one, and was much more true in the past. Google's Chrome team did a little paragraph somewhere about how it's not as big an impact anymore, and here is Scott Hanselman on the subject: http://www.hanselman.com/blog/MicrosoftIE8AndGoogleChromeProcessesAreTheNewThreads.aspx

My take on it is that threads are faster?'c but only moderately so, and currently it's easier to make mistakes with threads.

I have heard that .NET 4.0 is going to extend the thread library... Something about system.threading.thread.For ? And I can think of a few places I'd want to do that... For each item in this thousand item list go do something.

http://reedcopsey.com/?p=87

Answer 2

At the following URL you will find a real world benchmark and a comparison of fork vs. pthread_create in a real world application, though its from 2003 and things may have changed a bit. Quickly reasoning from this benchmark, it looks like fork scales better if you have more than 500 processes or threads.

http://bulk.fefe.de/scalable-networking.pdf - pages 29 to 32