Linux：多核 CPU 中的进程和线程
与进程相比，线程是否不太可能从多核处理器中受益？换句话说，内核会决定在单核上而不是在多核上执行线程吗？
我说的是属于同一进程的线程。
Is it true that threads, compared to processes, are less likely to benefit from a multi-core processor? In other words, would the kernel make the decision of executing threads on a single core rather than on multiple cores?
I'm talking about threads belonging to the same process.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我不知道（各种）Linux 调度程序如何处理这个问题，但是当线程在不同的内核上运行时，线程间通信会变得更加昂贵。
因此，如果还有其他进程需要 CPU 时间，调度程序可能会决定在同一 CPU 上运行某个进程的线程。
例如，对于双核 CPU，如果有两个进程有两个线程，并且都使用它们获得的所有 CPU 时间，则最好在第一个核心上运行第一个进程的两个线程，而在另一个进程上运行另一个进程的两个线程在第二个核心上。
I don't know how the (various) Linux scheduler handle this, but inter-thread communication gets more expensive when threads are running on different Cores.
So the scheduler may decide to run threads of a process on the same CPU if there are other processes needing CPU time.
Eg with a Dual-Core CPU, if there are two processes with two threads and all are using all CPU time they get, it is better to run the two threads of the first process on the first Core and the two threads of the other process on the second core.
这对我来说是新闻。尤其是 Linux，线程和进程之间几乎没有区别。它们实际上只是共享地址空间的进程。
That's news to me. Linux in particular makes little distinction between threads and processes. They are really just processes that share their address-space.
多个单线程进程比单个多线程进程对系统来说更昂贵。但他们将以相同的效率受益于多核 CPU。另外，线程间通信比进程间通信便宜得多。如果这些线程确实形成单个应用程序，我投票支持多线程。
Multiple single-threaded processes are more expensive to the system than single multi-threaded ones. But they will benefit from multicore CPU with same efficiency. Plus inter-thread communication is much cheaper then inter-process communication. If these threads really form single application i vote for multithreading.
共享内存多线程给从工具链到开发、调试、推理和测试代码的一切带来了巨大的复杂性成本。在可以合理使用多进程设计的地方，切勿使用共享内存多线程。
@Marcelo 是对的，任何像样的操作系统都会以非常相似的方式对待线程和进程，线程的一些 cpu 亲和力可能会减少多线程进程的多处理器使用，但是您应该看到，对于共享公共 .文本段也是如此。
根据复杂性和架构设计限制选择线程与进程，速度几乎永远不会考虑在内。
Shared-memory multithreading imposes huge complexity costs on everything from your tool-chain, to development, to debugging, reasoning, and testing your code. NEVER use shared-memory multithreading where you can reasonably use a multi-process design.
@Marcelo is right, any decent OS will treat threads and processes very similarly, some cpu-affinity for threads may reduce the multi-processor usage of a multi-threaded process, but you should see that with any two processes that share a common .text segment as well.
Pick threads vs. processes based on complexity and architectural design constraints, speed will almost never come into it.
它实际上完全取决于调度程序、多处理类型和当前运行环境。
不假设任何事情，测试，测试，测试！
如果您是系统上唯一的多线程进程，那么多线程通常是一个好主意。
然而，从易于开发的角度来看，有时您需要单独的地址空间和共享数据，尤其是在 NUMA 系统中。
可以肯定的一件事是：如果它是“超线程”系统，则凭借紧密的内存共享，线程的效率要高得多。
如果是常规的多核处理..应该类似。
如果是 NUMA 系统，最好保持数据共享和代码分离。同样，这完全取决于架构，除非您从事 HPC 业务，否则性能并不重要。
如果您从事 HPC（超级计算）业务，请测试！这完全取决于机器（平均收益为 10-25%，如果您谈论的是差异天数，这一点很重要）
It actually all depends on the scheduler, type of multiprocessing, and current running environment.
Assume nothing, test, test, test!
If you're the only multi-threaded process on the system, multi-threading is generally a good idea.
However, from the perspective of the ease of development, sometimes you want separate address spaces and shared data, especially in NUMA systems.
One thing for sure: If it's a 'HyperThreaded' system, threads are much more efficient by virtue of close memory sharing.
If it is a regular multi-core processing.. it should be similar.
If it is a NUMA system, you're better off keeping data shared and code separate. Again, it's all architecture dependent, and it doesn't matter performance-wise unless you're in the HPC business.
If you are in the HPC (supercomputing) business, TEST!. It's all machine dependent (and benefits are 10-25% on average, it matters if you're talking days of difference)
虽然 Windows 使用纤维和线程，但我有时认为 Linux 使用进程和麻线。
我发现，在编写多线程进程时，在设计线程进程时，您确实必须严谨、迂腐、有纪律、有血性，以便它们在使用机器上可用的任何数量的核心时实现利益平衡该进程将继续运行。
在 Linux 上，与进程相比，线程从多核处理器中受益的可能性较小，这是真的吗？没有人知道。
Whereas Windows uses fibres and threads I sometimes think Linux uses processes and twine.
I've found that in writing multi-threaded processes you really have to be rigorous, pedantic, disciplined and bloody-minded in designing threaded processes in order for them to achieve a balance of benefit in using whatever number of cores are available on the machine that the process is to run on.
Is it true, on Linux, that threads, compared to processes, are less likely to benefit from a multi-core processor? No one knows.