这与以下帖子密切相关，Przemyslaw Szufel的回答很好。
假设我有一台40核的机器，我决定遵循Przemyslaw的建议，并使用@distributed而不是Threads来执行数组分配操作。这样可以很好地加快速度。
我的算法与上述用户情况的唯一细微差别是我有嵌套循环。当然，我总是可以向量化正在执行赋值操作的数组，但这会使我的代码复杂化。我是否应该在最外层循环之前简单地包含@sync @distributed，然后保留它？还是我需要在（在我的情况中）两个内部循环之前放置其他宏，以最大限度地提高并行化的好处？
如果是分布式循环，通常只希望并行化最外面的循环。为什么？因为分散了工作量，所以需要花费大量时间。
但是，在某些情况下，您可能需要搜索不同的并行化策略。
让我们考虑执行时间不平衡的情况。@distributed采取一种幼稚的方法，平均地划分了工作人员之间的循环。假设您有一个循环，例如：
for i in 1:100
for j in 1:i
## do some heavy-lifting
end
end
放在@distributed外部循环之前效率很低，因为所有并行执行都将等待最后一个块，其中j将处理所有最长的值。这是一个典型的循环，其中并行化的值几乎不存在。在这种情况下，通常可以采用以下方法：
i值的数量比核心数大几个数量级，那会很好k in 1:(100*(100+1)/2)，分布于它，然后计算相应的值i和j最后，如果作业时间严重不平衡并且上述方法不起作用，则需要使用一些作业轮询机制。一种可行的方法是使用asyncmap生成远程任务，另一种可行的方法是使用外部工具-我通常bash为此使用一些简单的脚本-我在GitHub上发布了使用bash并行化作业的方法：https：//github.com。 com / pszufe / KissCluster
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句