我的问题是：如果我一次提交数百或数千,会发生什么 – 远远超过CPU的数量？很明显,每个作业单独运行需要更长的时间,但我想知道这种方法的整体效率与每个CPU一次只有一个作业.我还可以编写一个更复杂的方法来监视进度并保持每个CPU只占用一个作业(例如在Python中使用多处理),但是这会占用昂贵的程序员时间,而我想知道最终结果是否真的是任何更快.
速度方面,除了你的线程花费大量时间睡眠(在这种情况下,它为你的其他线程提供执行机会)之外,你不太可能获得性能提升而不是可用的物理线程产生更多线程.请注意,线程休眠可以在I / O绑定进程中以及在争用锁时隐式和隐藏.这实际上取决于你的线程是否花费大部分时间等待某些事情(例如：更多数据来自服务器,用户做某事,文件更新,访问锁定资源)或者只是去尽可能快地并行.如果是后一种情况,使用比实际可用线程更多的线程会降低你的速度.拥有比任务更多的线程的唯一方法可以帮助吞吐量是当这些线程浪费时间睡眠时,让其他线程在睡眠时做更多的机会.
但是,它可能会使您更容易生成所有这些任务并让操作系统处理调度.
使用更多的线程,您可以减少潜在的速度(即使在吞吐量方面).它在某种程度上取决于你的调度和线程池如何工作以及这些线程是否花费时间休眠,但是线程不一定是构造的便宜的东西,并且具有那么多线程的上下文切换可能比你自己的调度过程更昂贵有很多关于你想要做什么的信息,以及什么时候比只看到需要执行的大量线程的操作系统更合适的信息.
高效的库(如英特尔的线程构建模块)将池中的线程数与物理硬件(不多也不少)相匹配是有原因的.它往往是最有效的路线,但考虑到手动调度,工作窃取等需要,它实施起来最笨拙.所以有时候一次只能产生一大堆线程会很方便,但你通常不会这样做是一种优化,除非你在另一个答案中指出I / O绑定,你的线程只是花费大部分时间睡觉并等待输入.
如果您有这样的需求,最有效的方法是找到一个好的并行处理库(例如：PPL,TBB,OMP等).然后你只需编写一个并行循环,让库专注于如何最有效地处理线程并平衡它们之间的负载.在这些情况下,您可以专注于应该执行的任务,但在执行时不一定.