进程与线程对性能的影响

Question

显然，如果性能很关键，那么原型和概要是有意义的。但同样，也可以在StackOverflow上寻求智慧和建议:)

对于任务间通信不频繁或适合消息传递的高度并行任务的处理，使用进程(fork()等)或线程是否存在性能劣势？

线程之间的上下文切换比进程之间的上下文切换更便宜吗？有些处理器有单指令上下文切换功能，不是吗？主流操作系统是否更好地利用了多线程或多进程的SMP？如果进程从不写入这些页面，那么fork()的COW开销是否比线程更高？

诸若此类。谢谢!

Answer 1

创建过程很慢的想法是一个旧的想法，在过去更是正确的。谷歌的Chrome团队在某个地方做了一个小段落，说明它的影响不再那么大了，下面是Scott Hanselman对这个主题的看法：http://www.hanselman.com/blog/MicrosoftIE8AndGoogleChromeProcessesAreTheNewThreads.aspx

我对此的看法是线程更快，但只是中等程度的快，而且目前线程更容易出错。

我听说.NET 4.0将扩展线程库...关于system.threading.thread.For的事？我能想到几个我想去的地方...对于这个千项列表中的每一项，去做点什么吧。

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

Answer 2

在下面的网址中，你会发现一个真实世界的基准测试，以及一个真实世界应用程序中的fork和pthread_create的比较，尽管它是从2003年开始的，事情可能有一点变化。从这个基准测试中快速推断，如果你有超过500个进程或线程，那么fork的伸缩性看起来会更好。

http://bulk.fefe.de/scalable-networking.pdf -第29至32页

Answer 3

我的猜测是，线程更快，因为它们是更轻量级的解决方案。进程被设计为相互隔离。每个进程使用它自己的TLB，而线程共享一个虚拟地址空间(afaik)，因此这可能是一个参数。如果你想进行某种分布式计算，进程是很有用的。

一般来说，关于线程之类的东西，我建议你去看看OpenMP或英特尔-TBB。这些人真的很了解多线程和高性能计算。