NoTrust Asked:2020-12-31 17:30:31 +0000 UTC2020-12-31 17:30:31 +0000 UTC 2020-12-31 17:30:31 +0000 UTC 为什么在多线程应用中需要创建n+1个工作线程？ 772 n物理核心数在哪里。我已经不止一次遇到过这条规则，但我就是不明白为什么要这样做，以及它是否总是比创建n线程更有效率。 многопоточность 3 个回答 Voted Best Answer Majestio 2020-12-31T18:37:07Z2020-12-31T18:37:07Z 但我不明白为什么 通常，“通用”程序除了实际计算外，还执行输入输出操作（磁盘、网络、其他设备）。在等待缓慢的操作时，最好将有用的工作加载到内核中。所以他们补充道+1。为什么+1不更多？我现在找不到了——但我记得很清楚，我看到了make -jN. 组合几乎无处不在+1。因此，既定的做法具有纯粹的实验论证。 并且它总是比创建 n 个线程更有效吗 不总是。如果进程专门用于重新计算，并且 I/O 操作的份额可以忽略不计，则添加“附加”流不会提高总速度。此外，速度可能会略有下降。 user194374 2020-12-31T18:35:42Z2020-12-31T18:35:42Z 据我所知，这样的建议是出于最大限度地利用计算能力的考虑。假设线程可以执行任何需要大量等待时间的 I/O 操作（磁盘、网络、内存），在此期间线程不会 100% 加载处理器内核。因此，创建了一个额外的n+1th 线程，此时它使用“空闲”容量。 PS 推荐不是我的，我不会争论它。;-) user177221 2020-12-31T22:15:59Z2020-12-31T22:15:59Z N+1 建议仅适用于处理非统一任务流的系统，具有频繁但短暂的 IO 中断。一个典型的例子是make -jN，这里已经提到了。在其中，“额外”线程可以让你填补由 IO 引起的 CPU 空闲。 对于处理明显相同的长任务、受 CPU 限制、没有 IO 的系统，将任务数设置为 N + 使用亲和性 - 线程绑定到特定核心更有利可图。 找出用于特定任务的线程数的最可靠方法是采取和测量。
通常，“通用”程序除了实际计算外，还执行输入输出操作（磁盘、网络、其他设备）。在等待缓慢的操作时，最好将有用的工作加载到内核中。所以他们补充道
+1。为什么+1不更多？我现在找不到了——但我记得很清楚，我看到了make -jN. 组合几乎无处不在+1。因此，既定的做法具有纯粹的实验论证。不总是。如果进程专门用于重新计算，并且 I/O 操作的份额可以忽略不计，则添加“附加”流不会提高总速度。此外，速度可能会略有下降。
据我所知，这样的建议是出于最大限度地利用计算能力的考虑。假设线程可以执行任何需要大量等待时间的 I/O 操作（磁盘、网络、内存），在此期间线程不会 100% 加载处理器内核。因此，创建了一个额外的
n+1th 线程，此时它使用“空闲”容量。PS 推荐不是我的，我不会争论它。;-)
N+1 建议仅适用于处理非统一任务流的系统，具有频繁但短暂的 IO 中断。一个典型的例子是
make -jN，这里已经提到了。在其中，“额外”线程可以让你填补由 IO 引起的 CPU 空闲。对于处理明显相同的长任务、受 CPU 限制、没有 IO 的系统，将任务数设置为 N + 使用亲和性 - 线程绑定到特定核心更有利可图。
找出用于特定任务的线程数的最可靠方法是采取和测量。