我的算法/CPU 遇到了奇怪的行为，我想知道是什么原因造成的。
我正在使用的CPU：AMD 2990WX 32c/64t，操作系统：Ubuntu 18.04LTS，带有4.15.0-64通用内核。
算法(Julia 1.0.3(：
@sync @distributed for var in range(0.1,step=0.1,stop=10.0)
res=do_heavy_stuff(var) #solves differential equation,
#basically, multiplying 200x200 matrices many times
save(filename,"RES",res)
end
函数do_heavy_stuff(var(在单个 CPU 内核上求解需要 ~3 小时。 当我与 10 个进程并行启动它时(julia -p 10 my_code.jl(，每个并行循环需要 ~4 小时，这意味着每 4 小时我保存 10 个文件。随着CPU频率从4.1Ghz下降到3.4Ghz，预计速度会放缓。
如果我启动 3 个单独的实例，每个实例有 10 个进程，因此总 CPU 利用率为 30 个内核，则一个循环周期仍然需要 ~4 小时，这意味着我每 4 小时完成并保存 30 次运行。
但是，如果我运行 2 个实例(一个值为 0，另一个不错的值为 +10(，每个实例一次有 30 个进程julia -p 30 my_code.jl，我看到(使用 htop(CPU 利用率为 60(+( 线程，但算法变得非常慢(20 小时后仍然保存零文件(。此外，我看到CPU温度异常低(~45C而不是预期的65C(。
从这些信息中我可以猜测，使用(几乎(我的 cpu 的所有线程会让它做一些无用的事情，占用 CPU 周期，但没有进行浮点运算。我没有看到SSD的I/O，我只使用了一半的RAM。
我启动了mpstatmpstat -A：https://pastebin.com/c19nycsT，我可以看到我所有的核心都在空闲状态下冷却，这解释了低温，但是，我仍然不明白瓶颈到底是什么？如何从此处进行故障排除？有没有办法看看(不接触硬件(问题是 RAM 带宽还是其他什么？
编辑：我注意到，我错误地使用了mpstat。显然，mpstat -A提供了自计算机启动以来的 cpu 统计信息，而我需要的是可以使用mpstat -P ALL 2获得的短时间集成结果。不幸的是，我只是在我杀死了有问题的代码后才知道这一点，所以没有来自mpstat的真实数据。但是，我仍然感兴趣，如何解决这种情况，其中内核似乎在做某事，但结果没有显示？如何找到瓶颈？
由于您使用的是多处理，因此观察者行为最可能有两个原因：
- I/O 长时间延迟。当您处理大量磁盘数据或从网络读取数据时，您的进程自然会过时。在这种情况下，CPU 利用率可能较低，执行时间较长。
do_heavy_stuff执行时间的高差异。这种差异可能是由于不稳定的 I/O 或不同的模型参数导致不同的执行时间造成的。为什么这是一个问题需要了解@distributed如何在工作进程之间共享工作负载。也就是说，每个工人获得相等的for循环。例如，如果您有4工作人员，则第一个工作人员var范围内0.1:0.1:2.5第二个工作人员2.6:0.1:5.0依此类推。现在，如果某些var值导致繁重的任务，则第一个工作人员可能会获得 5 小时的工作，而其他工作人员可能会获得 1 小时的工作。这意味着@sync在 5 小时后完成，实际上只有一个 CPU 一直在工作。
看看你的帖子，我会强烈押注第二个原因。