[MPI/Net Perf]On Network Locality in MPI-Based HPC Applications

论文题目：On Network Locality in MPI-Based HPC Applications
文章时间：2020年8月前
会议/期刊：ICPP '20
作者背景： 德国海德堡大学
笔记时间：2021年10月31日周天
论文地址：https://dl.acm.org/doi/abs/10.1145/3404397.3404436

---

Abtract
通过互连网络的数据移动在延迟和能量上超过本地内存访问多个数量级。当很多优化聚焦于提升内存访问次数，网络大距离传输可以轻轻松松dash这些改进，导致整体代价的提升。因此，对Network Locality的深入理解是进一步优化的关键，比如改进ranks对物理实体的映射。
本文中，我们聚焦于于硬件无关的应用层和通用网络结构的Locality。为了量化前者，我们提出了两个新的度量衡，rank Locality和 selectivity。我们的研究选择了16个exascale proxy mini app，最大到了1152个rank。我们对他们的trace进行了MPI空间层面的分析。在三种不同的网络结果，tori，fat tree，dragonfly 评估了我们的方案。本文工作给予大规模的实验设计，基于不同的应用规模和拓扑。

大多数的数据在10个以内的ranks传输。对于小rank的应用，3Dtorus最好，对于大rank的应用，fattree更好。一般情况下，网络是高度未利用的。93%的情况下，网络利用率超过1%。总之，这意味着统计数据可以辅助选择更高级的映射，比如使得通讯量多的ranks在靠近的物理实体上，这可以最小化全部的包的hops，因此可以提升延迟和减少拥塞的概率。

第一章 Intro

第三章 相关工作

使用模型来代表并行应用的通信行为的工作有17.不考虑并行计算的关系来描述通信是不完整的。应用的行为常常是无规律动态的，因此模拟工具主要是用于理解通信行为。

HPC应用的locality特征主要考虑的是内存的locality，有着数量众多的研究，有关于HPC对内存延迟和带宽的研究12，4。13描述了对HPC应用时间和空间locality的定义。还有分析HPC应用在GPU分配和MPI的locality。11

考虑并行的通信特征，2介绍了几个关于通信特征的度量衡，包括消息产生的频率，消息的空间分布，消息的长度等。利用统计回归模型，分析网络活动日志，消息传播时间和空间分布是确定的。MPI通信的locality被工作6分析过，主要聚焦于event locality，消息终点的locality，和消息大小的locality。

通信特征相关的文章有8，9，15，18

第四章 方法论

为了深入理解HPC exascale应用的通讯特征，分析了大量的MPI的trace。下文介绍了分析的应用和分析的过程。介绍了两种新的度量衡。
用热力图来衡量MPI应用的locality，适合小规模rank。现有的文献调研发现缺乏对网络特征的度量衡，我们介绍了两个度量衡。用于理解通信的空间关系和如何利用它们进一步做优化。

4.1 MPI层
在MPI层，不存在消息在网络传播的具体路径信息，消息长度和网络利用率。但是关于locality的insight可以在这层看到。比如确定特定的通信参与者或通讯组们帮助提升映射和减少全部网络跳数。

4.1.1 locality
rank locality代表MPI层两个rank间的空间距离。距离越近，locality越大，直接邻居的locality是100%，这个度量衡忽略了拓扑和映射关系，及对应的影响。

只有点对点通信考虑locality。

4.1.2 selectivity
selectivity描述了在某个应用程序中有多少个合作伙伴等级控制着一个等级的通信。对于给定的source rank，这个度量是通过确定目标rank和其他rank通信的数量，排序后在阈值内的数量来计算。
这个度量衡也只是描述点对点通信。少量的rank贡献了主要的通信。

4.2 拓扑locality

第七章 讨论

在硬件不感知的应用层，我们引入了rank locality and selectivity，大多数应用的selectively非常low，rank locality随着ranks的数量减少而significantly减少。这意味着尽管只有很少的通讯参与者，数据分布不局限于邻居rank。通讯模式的一个重要的因素是 the dimensionality of the underlying problem。这个观察也在多核的研究中被证实，节点间的网络流量很多。因此，将秩连续地映射到给定的拓扑并没有利用小选择性的好处，因为通信伙伴很可能在空间上是分开的。为了减少网络流量和从on-ship通讯上获益，深度理解通讯对是必要的，大多数应用程序的低选择性表明，只有使用优化的映射才能显著降低流量。正如维数分析所建议的，可以根据给定的应用程序裁剪网络拓扑来进一步减少流量。然而，最佳方法和可能的优化程度在很大程度上取决于应用程序。

Dragonfly的结果没有那么好，可能和他的路由策略有关。

应用层的locality和系统层面的locality没有直接的相关性，所以得倒的启示也不适用于所有的程序。针对相似应用做更细粒度分析是有价值的。

网络的利用率非常低，说明很大一部分的energy被浪费了。总之，研究MPI应用里面的slackness是有用的。

第八章 总结

一些分析

---

想要阅读的相关文献
2，6，11，13