我正在尝试制作一个程序,以并行执行可变数量的可能(但不一定)的计算繁重的任务.这些任务(可运行类型)将全部同时提交,并且一旦所有这些任务完成,线程池应关闭(换句话说,线程池仅需要接受初始任务,仅此而已).
在此站点上找到的大多数答案中,问题都与基于服务器的任务(我的程序在适当的台式机上运行)或在不定期的时间间隔内接受任务的池有关.在不是特定用途的问题中,答案通常是“取决于情况”.
我的线程经验基本上为零,因此我真的不知道最佳的“线程数与任务强度”比率是多少.
对于上下文,我正在研究的程序处理矩阵的集合(以3D数组表示),其中每个矩阵最多可以包含1000×1000个元素.任务之一可能是执行卷积运算,每个任务是对集合中某个矩阵的运算.
有针对这种特定类型问题的建议吗？
最佳答案
在询问服务器问题时,您会听到相同的结果：不要做假设,要做实验.
尝试确定(最坏的情况：猜测)用户在其上运行软件的典型硬件设置.然后确保您可以进行很好的自动化性能测试.然后看看会发生什么.
但是,事实是：那没有太大帮助.您会看到,在运行自己的服务器时,(希望)可以控制这些计算机忙于处理的工作负载.对于桌面设置,远程用户可以在其框上运行您的代码…您对这里正在运行的其他内容几乎没有任何了解.您可能会发现16个线程适合50％的用户.但是其余的也许正在他们的机器上做很多其他事情,而16对他们来说已经太多了.
这才是真正的症结所在.无论您为特定的硬件配置找到了什么“好选择”,都无法控制其他工作负载.
从这个角度来看,我会很保守.对于CPU密集型工作负载,“太多”的线程还是无济于事,因此,请以CPU的数量或更好的内核数量为起点.
除此之外,这里可能真正有用的是：向您的应用程序添加某种“数据收集”.含义：让它定期回电,告诉您类似的事情：“这是我正在运行的硬件,我正在使用X线程,而系统上的其他工作量是Y”.这可能会帮助您掌握一些启发式方法,以适应最重要的用户设置.但要努力收集哪些数据.先定义要回答的问题,然后提取回答这些问题所需的数据.
