显然，如果性能至关重要，那么原型和配置文件是有意义的。但同样，可以在StackOverflow上寻求智慧和建议：）
为了处理高度并行的任务，其中任务间通信很少或适合消息传递，使用进程（fork（）等）或线程是否存在性能劣势？
线程之间的上下文切换是否比进程之间的更便宜？有些处理器有单指令上下文切换吗？主流操作系统是否更好地利用具有多个线程或进程的SMP？如果进程永远不会写入那些页面，那么fork（）的COW开销是否比线程更昂贵？
等等。谢谢！
答案 0 :(得分：7)
过程创建缓慢的想法是旧的，过去更为真实。谷歌的Chrome团队在某个地方做了一个关于它不再具有什么影响力的小段落，这里有Scott Hanselman关于这个主题：http://www.hanselman.com/blog/MicrosoftIE8AndGoogleChromeProcessesAreTheNewThreads.aspx
我对它的看法是线程更快？但是只是适度，所以现在用线程更容易出错。
我听说.NET 4.0将扩展线程库...关于system.threading.thread.For的一些事情？我可以想到一些我想要做的地方......对于这千件物品清单中的每件物品都要做点什么。
答案 1 :(得分：2)
在下面的URL中，您将找到真实世界的基准测试以及实际应用程序中fork与pthread_create的比较，尽管从2003年开始，事情可能会有所改变。从这个基准测试中快速推理，如果你有超过500个进程或线程，它看起来更好。[/ p>
答案 2 :(得分：1)
我的猜测是，线程更快，因为它们是更轻量级的解决方案。流程旨在彼此隔离。每个进程使用它自己的TLB，而线程共享一个虚拟地址空间（afaik），所以这可能是一个参数。如果您想进行某种分布式计算，则进程非常有用。
一般来说，关于线程和内容，我建议您研究一下OpenMP或Intel-TBB。这些人真的了解他们的多线程和高性能计算。
答案 3 :(得分：1)
归结为隔离成本：进程彼此隔离（例如，单独的内存资源，保护，单独的文件句柄等），而线程可以共享进程内的资源。这需要时间和时间资源支持＆amp;强制执行隔离。
与此世界中的任何内容一样，您必须为所得到的内容“付费”。
答案 4 :(得分：0)
根据这本书：http://reiber.org/nxt/pub/Linux/LinuxKernelDevelopment/Linux.Kernel.Development.3rd.Edition.pdf Linux将所有线程都实现为标准进程。考虑到你在写COW - 这是linux。更多信息请参见第33-34页。