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!
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