logo标签列表

Linux: 多核 CPU 中的进程和线程

linuxmultithreadingprocess
5

相对于进程而言，线程是否更不容易受益于多核处理器？换句话说，内核是否会决定在单个核心上执行线程而不是在多个核心上执行？

我说的是属于同一进程的线程。

6个回答
9
我不知道各种Linux调度程序如何处理这个问题，但是当线程在不同的核心上运行时，线程间通信会变得更加昂贵。
因此，如果有其他需要CPU时间的进程存在，调度程序可能会决定在同一CPU上运行一个进程的线程。
例如，使用双核CPU，如果有两个进程和两个线程，且它们都在使用所有的CPU时间，那么最好将第一个进程的两个线程运行在第一个核心上，将另一个进程的两个线程运行在第二个核心上。
2

多个单线程进程对系统的开销比单个多线程进程更大。但它们将以相同的效率从多核CPU中受益。此外，线程间通信比进程间通信要便宜得多。如果这些线程确实形成单个应用程序，则我投票支持多线程。

但是它们将以相同的效率从多核CPU中受益。在这里的“它们”是指进程还是线程？“但是”让我感到困惑，抱歉。 - someguy
1
这并不是真的，来自同一进程的两个线程在不同核心上运行需要大量的内存/缓存同步，而对于独立的进程则不需要。 - Gordon Wrigley
@tolomea，这也不是完全正确的。如果需要并发地写入共享内存，则无论是线程还是进程，都会产生内存一致性成本。操作系统调度线程和进程；CPU核心将直接执行它们所接收到的程序计数器。大多数主流处理器至少有一个共享缓存级别，并且通过嗅探写入以保持内存视图的一致性，而无需经过主内存。当在多个CPU之间共享内存时，这会变得更加昂贵，但无论共享访问的来源在哪里，情况都是一样糟糕的。 - tbone
2

这对我来说是新闻。特别是在Linux系统中，线程和进程之间的区别不大。它们实际上只是共享地址空间的进程。

显然在文档的某处写有这个。虽然如此，我宁愿相信你的话而不是模糊的传言。 - someguy
看一下clone()系统调用。 - Marko Kevac
2

共享内存多线程对于从工具链到开发、调试、推理和测试代码的所有方面都会带来巨大的复杂性成本。只要可以合理使用多进程设计，就不要使用共享内存多线程。

@Marcelo是正确的，任何好的操作系统都会将线程和进程视为非常相似的，一些线程的CPU亲和力可能会降低多线程进程的多处理器使用率，但你也应该看到任何共享公共.text段的两个进程也会有这种情况。

根据复杂性和架构设计约束选择线程与进程，速度几乎永远不会成为问题。

我赞同设计应该放在首位，但是当你说“永远不要使用共享内存多线程”时，你自相矛盾了。我理解你所说的线程更加复杂，但这是一种夸张。除非有道理使用进程（也许是用于“多文档”应用程序），否则我仍然会坚持使用线程。 - someguy
1

这实际上完全取决于调度程序、多处理类型和当前运行环境。

不要假设，测试，测试，测试！

如果您是系统上唯一的多线程进程，则多线程通常是一个好主意。

然而，从开发的易用性角度来看，有时您需要单独的地址空间和共享数据，特别是在NUMA系统中。

有一件事可以确定：如果它是“超线程”系统，则由于紧密的内存共享，线程效率要高得多。

如果它是常规的多核处理...应该类似。

如果它是NUMA系统，则最好保持数据共享和代码分离。同样，这完全取决于架构，并且除非您从事HPC业务，否则在性能方面并不重要。

如果您从事HPC（超级计算）业务，请进行测试！这完全取决于机器（平均受益为10-25％，如果您谈论的是天数差异，则很重要）

-2

尽管Windows使用纤程和线程，但我有时认为Linux使用进程和绳子。

我发现，在编写多线程进程时，您必须严谨、苛求、自律并且要在设计线程进程时非常努力，以便它们能够在运行该进程的机器上利用可用的任何核心数量来实现平衡的效益。

在Linux上，相对于进程而言，线程是否不太可能从多核处理器中受益？没有人知道。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接