文章的全名：Communication Characteristics of Large-Scale Scientific Applications for Contemporary Cluster Architectures

这篇文章发表在IPDPS 2002，相隔现在已经很多年了。它所谓large scale其实也只是64个进程，在当时是64个处理器，但到现在也就是很小规模的一个多核机群而已。这让人不得不感慨，计算机发展真是日新月异。

这篇文章的想法也比较简单，就是挑选了一些他们认为重要的应用程序，然后详细分析了这些应用程序的计算和通信行为。由于作者使用的系统规模在当时是很大的，而且分析得非常详细，因此才能进入IPDPS这种rank 1的国际会议。试想一下，如果我们能够在Jaguar上或者Roadrunner上运行几个或者十几个典型应用，比如气象的、石油勘探的、图形图像处理的、地震的等等，再加上详细的profiling和分析，说明这些典型应用的通信特征和计算特征，一定也是非常非常牛的文章。

书归正传，先看看它都测了什么。该文章共测试了5个典型应用sPPM、SMG2000、SPHOT、Sweep3D和Samrai，分析了它们的点对点通信、集合通信、浮点运算和内存读操作特征。profiling的手段主要是通过MPI规范中的profiling层加上硬件计数器挖掘数据。这两种手段对应用程序的通信、计算特征的影响应该是比较小的，因为硬件计数器不会引入影响，而MPI profiling层应该是经过特殊优化的。文章给出了不同应用在总体规模不变，增加进程（处理器）数量时的扩展性和保持处理器数量不变，增加问题规模时的扩展性。统计了指令总数、读指令总数、浮点操作总数，平均消息个数、平均消息大小、平均目标数量、集合通信数量和集合通信净荷大小这些数据。

文章结论：一句话总结的话：证明了之前小规模时得到的特征在大规模下依然存在！具体地：

对于点对点通信，根据Table 4，在64进程规模，点对点通信净荷的长度一般小于16KB，最大不超过512KB。这和Figure 1有所出入，Figure 1中有1MB大小的消息。

对于集合通信，根据Table 5，在64进程规模，集合通信净荷的长度一般小于128B，最大不超过256B。这和Figure 2也有所出入，Figure 2中在512B处明显还有集合消息分布。

对于浮点运算，浮点运算数量和问题规模紧密联系，根据Table 6，在64进程规模，在两次通信点之间，一般能够进行8M次计算，最少1K次，最多1G次。

对于内存读操作，不管问题的规模怎样，平均每3到5条指令中就有一条是load reference，这使得指令级并行跟问题规模扩展之间没什么联系。

以上结论告诉我们：针对点到点通信，我们的RDMA引擎支持到16KB较为合适，当然支持得越大越好。针对集合通信，我们要支持到128B大小，最好是256B。针对浮点运算和内存读操作，选择能力强的处理器还是有必要的。

最后，附上pdf原文下载。Communication Characteristics of Large-Scale

转载本文请联系原作者获取授权，同时请注明本文来自王凯科学网博客。
链接地址：https://m.sciencenet.cn/blog-432545-314363.html

上一篇：Win7安装 XP mode，处理器不需要支持虚拟化
下一篇：硬件实现两个无符号数相加时，结果是否溢出的判断方法