【问题标题】:Performance of MPI_Reduce vs (MPI_Gather + Reduction on Root)MPI_Reduce 与(MPI_Gather + Reduction on Root)的性能
【发布时间】:2018-04-25 15:50:34
【问题描述】:

使用 MPICH2 库的 CRAY 超级计算机。每个节点有 32 个 CPU。

我在 N 个不同的 MPI 等级上有一个浮点数,其中每个等级都在不同的节点上。我需要对这组浮点数执行归约操作。我想知道 MPI_Reduce 是否比 MPI_Gather 更快,对于任何 N 值,在根上计算减少。请假设在根等级上完成的减少将使用可以利用 N 个线程的良好并行减少算法完成.

如果对于任何 N 值都不是更快,那么对于较小的 N(如 16)或较大的 N 是否会更适合?

如果是真的,为什么? (例如,MPI_Reduce 是否会使用一种树通信模式,该模式倾向于在它用于与树的下一层通信的方法中隐藏归约操作的时间?)

【问题讨论】:

    标签: mpi supercomputers


    【解决方案1】:

    假设MPI_Reduce 总是比MPI_Gather + local reduce 快。

    即使在 N 的情况下,归约比收集慢,MPI 实现也可以轻松地在这种情况下根据收集 + 局部归约来实现归约。

    MPI_Reduce 仅比 MPI_Gather + 局部减少有优势:

    1. MPI_Reduce 是更高级别的操作,为实现提供更多优化机会。
    2. MPI_Reduce 需要分配更少的内存
    3. MPI_Reduce 需要在同一链路上传输更少的数据(如果使用树)或更少的数据(如果使用直接全对一)
    4. MPI_Reduce 可以跨更多资源分配计算(例如使用树通信模式)

    也就是说: 永远不要假设任何关于性能的事情。测量。

    【讨论】:

    • 很好的答案。我只想添加一篇旧论文,它提出了 MPI 性能背后的一些一般原则并对其进行测量:自洽 MPI 性能指南 JL Traff、WD Gropp、R Thakur、pdfs.semanticscholar.org/0dfc/…
    • @angmo 很棒的发现!起初我认为规则 (24) 与我的假设相矛盾——但我认为 n 表示收集数组的总大小以及每次缩减的数据大小——所以它确实有意义。因此,我会添加MPI_Reduce(n) <= MPI_Gather(n/p)
    • 确实,(24) 是以一种棘手的方式形成的(直到您发表评论,我才完全意识到这一点,谢谢!)。他们说“可以通过将大小为 ni 的所有进程与所有进程的贡献相加来从每个进程中收集连续的数据块,除了 i 贡献的 ni 个零块” - 所以就像他们将收集与非常特殊的缩减进行比较......
    • 感谢@Zulan 的清晰且逻辑一致的回答!当然,正如您所指出的,测量以确认。另外,感谢@ang mo 提供该论文的链接。很有帮助。
    • @Zulan:在仔细阅读规则 24 之后,似乎 MPI_Gather(n)
    猜你喜欢
    • 2014-01-25
    • 1970-01-01
    • 1970-01-01
    • 2013-07-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-01-21
    • 1970-01-01
    相关资源
    最近更新 更多