景派HPC研究院

由景派科技的技术团队组成，主要分享高性能计算领域的技术信息，与解答各位朋友在技术上遇到的问题和瓶颈，欢迎大家在文章下方的留言区讨论与提问。

平台信息：

测试依赖软件：

1. Intel® oneAPI Base Toolkit
2. Intel® oneAPI HPC Toolkit
3. HPL 2.3
4. OSU Micro-Benchmarks 5.7
5. IOzone 3-491
6. STREAM

1 HPL 测试

1.1 节点理论峰值性能 

 的计算如公式1所示。

其中CPU单周期浮点计算能力(float operations per CPU cycle, fpc)的计算方法,对于有 FMA 单元的 CPU ，其单周期双精度浮点计算能力计算如公式2所示。

单周期单精度浮点计算能力计算如公式3所示。

FMA(Fused Multiply-Add instructions，融合乘加指令) 单元：在 AVX2.0 指令集后支持了 FMA3 指令，原本，做

需要先做一次乘法再做一次加法，而利用 FMA 指令可以在一个周期内做完这个运算，所以可以认为做一次 FMA 运算等于做两次常规浮点运算[2]。

对于没有 FMA 单元的 CPU ，其单周期双精度浮点计算能力计算如公式4所示。

单周期单精度浮点计算能力计算如公式5所示。

因此对于本次测试的 AMD 服务器，可以算出其理论峰值性能为：

1.2 关键参数选择与优化

HPL 测试中关键参数有四个：P、Q、N、NB，需要根据服务器的配置情况进行优化，而其余参数使用官方推荐即可。

1.2.1 N 和 NB

寻找最大的 Problem Size N，使之尽可能接近总内存但避免使用 swap（以免因此降低性能），同时如果 N 设置得太小会导致低性能表现；一般矩阵占据系统内存 80%为最佳。 双精度(Double），80%总内存的 Problem Size 计算如公式6所示。

因此本次测试的 AMD 服务器的 Problem Size N 为：

NB 值的选择主要是通过实际测试得到最优值。但 NB 的选择上还是有一些规律可寻，如: NB 不可能太大或太小，一般在 256 以下；NB × 8 一定是 Cache line 的倍数等；大小几乎总是在 [32 .. 256] 区间内；最佳值取决于系统的计算/通信性能比。 通过先小规模抽取、再大规模验证（小规模测试选择 3 个性能表现不错的 NB，再通过大规模测试验证这些选择）的方法，本文发现 NB 取 180 时结算结果最优，因此参数 NB 设置为 180。

确定了 N 和 NB 之后，可以进一步对其进行优化，使用公式7将 N 和 NB 对齐，可以得到更好的结果：

结果优化后的 Problem Size N 为：

1.2.2 P 和 Q

一般来说参数 P 和 Q 的选择遵循一下几点：

1. ，且一个进程对于一个 CPU 可以得到最佳性能。对于 Intel Xeon 来说，关闭超线程可以提高 HPL 性能。

2. ；一般来说，P 的值尽量取得小一点，因为列向通信量（通信次数和通信数据量）要远大于横向通信。

3. ，即 P 最好选择 2 的幂。HPL 中，L 分解的列向通信采用二元交换法（Binary Exchange），当列向处理器个数 P 为 2 的幂时，性能最优。例如，当系统进程数为 4 的时候， 选择为  的效果要比选择  好一些。

4. 在集群测试中，= 系统 CPU 总进程数（物理核心数）。如系统为总核数为 16 核，则 P 和 Q 值应该为 4.

本次测试的 AMD 服务器为 32 物理核心，且未开启超线程，因此  选择为 32，P 选择为 4，Q 选择为 8。

1.3 测试结果

使用上述参数，计算出本 AMD 服务器的吞吐量 ，用时 3760.52 s`结果如下图所示：

由于测试时间有限，并没有进行大规模调优，因此测试最大值与理论最大值相差较大，效率值如下：

2 OMB 通信效率测试

OSU MPI Benchmarks 由 Ohio State University 提供的 MPI 通信效率评测工具，分为点对点通信和组通信两种形式，通过执行各种不同模式的 MPI，来测试带宽和延迟。本测试采用点对点通信的方式，测试 AMD 服务器的通信效率。

• 本次测试需要的OSU MPI Benchmarks软件已经编译完成且一下所有操作均在编译主目录下执行。

2.1 MPI 单向带宽测试

经过多轮测试，最优结果为：

从结果可知单向 MPI 带宽为 。

2.2 MPI 双向带宽测试

经过多轮测试，最优结果为：

从结果可知双向 MPI 带宽为 。

2.3 MPI 带宽延迟测试

经过多轮测试，最优结果为：

从结果可知 MPI 带宽延迟为 。

2.4 MPI 多进程带宽延迟测试

经过多轮测试，最优结果为：

从结果可知 MPI 多进程带宽延迟为 。

2.5 多线程带宽延迟测试

其中-t 4表示一个线程发送消息，四个线程接收消息。

经过多轮测试，最优结果为：

从结果可知，多线程带宽延迟为 。

3 基于 IOzone 的 IO 性能测试

IOzone 是一个文件系统基准测试工具，生成并度量各种文件操作。Iozone 已经被移植到许多机器上，并在许多操作系统下运行。IOzone 可用于对供应商的计算机平台进行广泛的文件系统分析。 基准测试测试以下操作的 I / O 性能：

• Read, write, re-read, re-write, read backwards, read strided, fread, fwrite, random read, pread ,mmap, aio_read, aio_write

官方文档中的测试定义：

• Read: 测试读一个已存在的文件的性能。

• Re-Read: 测试读一个最近读过的文件的性能。Re-Read性能会高些，因为操作系统通常会缓存最近读过的文件数据。这个缓存可以被用于读以提高性能。

• Random Read: 测试读一个文件中的随机偏移量的性能。许多因素可能影响这种情况下的系统性能，例如：操作系统缓存的大小，磁盘数量，寻道延迟和其他。

• Write: 测试向一个新文件写入的性能。当一个新文件被写入时，不仅仅是那些文件中的数据需要被存储，还包括那些用于定位数据存储在存储介质的具体位置的额外信息。这些额外信息被称作“元数据”。它包括目录信息，所分配的空间和一些与该文件有关但又并非该文件所含数据的其他数据。拜这些额外信息所赐，Write的性能通常会比Re-write的性能低。

• Re-write: 测试向一个已存在的文件写入的性能。当一个已存在的文件被写入时，所需工作量较少，因为此时元数据已经存在。Re-write的性能通常比Write的性能高。

• Random Write: 测试写一个文件中的随机偏移量的性能。同样，许多因素可能影响这种情况下的系统性能，例如：操作系统缓存的大小，磁盘数量，寻道延迟和其他。

• Random Mix: 测试读写一个文件中的随机偏移量的性能。同样，许多因素可能影响这种情况下的系统性能，例如：操作系统缓存的大小，磁盘数量，寻道延迟和其他。这个测试只有在吞吐量测试模式下才能进行。每个线程/进程运行读或写测试。这种分布式读/写测试是基于round robin 模式的。最好使用多于一个线程/进程执行此测试。

• Backwards Read: 测试使用倒序读一个文件的性能。这种读文件方法可能看起来很可笑，事实上，有些应用确实这么干。MSC Nastran是一个使用倒序读文件的应用程序的一个例子。它所读的文件都十分大（大小从G级别到T级别）。尽管许多操作系统使用一些特殊实现来优化顺序读文件的速度，很少有操作系统注意到并增强倒序读文件的性能。 Record Rewrite: 测试写与覆盖写一个文件中的特定块的性能。这个块可能会发生一些很有趣的事。如果这个块足够小（比CPU数据缓存小），测出来的性能将会非常高。如果比CPU数据缓存大而比TLB小，测出来的是另一个阶段的性能。如果比此二者都大，但比操作系统缓存小，得到的性能又是一个阶段。若大到超过操作系统缓存，又是另一番结果。

• Strided Read: 测试跳跃读一个文件的性能。举例如下：在0偏移量处读4Kbytes，然后间隔200Kbytes,读4Kbytes，再间隔200Kbytes，如此反复。此时的模式是读4Kbytes，间隔200Kbytes并重复这个模式。这又是一个典型的应用行为，文件中使用了数据结构并且访问这个数据结构的特定区域的应用程序常常这样做。许多操作系统并没注意到这种行为或者针对这种类型的访问做一些优化。同样，这种访问行为也可能导致一些有趣的性能异常。一个例子是在一个数据片化的文件系统里，应用程序的跳跃导致某一个特定的磁盘成为性能瓶颈。

• Fwrite: 测试调用库函数fwrite()来写文件的性能。这是一个执行缓存与阻塞写操作的库例程。缓存在用户空间之内。如果一个应用程序想要写很小的传输块，

• fwrite()函数中的缓存与阻塞I/O功能能通过减少实际操作系统调用并在操作系统调用时增加传输块的大小来增强应用程序的性能。这个测试是写一个新文件，所以元数据的写入也是要的。

• Frewrite:测试调用库函数fwrite()来写文件的性能。这是一个执行缓存与阻塞写操作的库例程。缓存在用户空间之内。如果一个应用程序想要写很小的传输块，fwrite()函数中的缓存与阻塞I/O功能能通过减少实际操作系统调用并在操作系统调用时增加传输块的大小来增强应用程序的性能。这个测试是写入一个已存在的文件，由于无元数据操作，测试的性能会高些。

• Fread:测试调用库函数fread()来读文件的性能。这是一个执行缓存与阻塞读操作的库例程。缓存在用户空间之内。如果一个应用程序想要读很小的传输块，fwrite()函数中的缓存与阻塞I/O功能能通过减少实际操作系统调用并在操作系统调用时增加传输块的大小来增强应用程序的性能。

• Freread: 这个测试与上面的fread 类似，除了在这个测试中被读文件是最近才刚被读过。这将导致更高的性能，因为操作系统缓存了文件数据。

• Mmap:许多操作系统支持mmap()的使用来映射一个文件到用户地址空间。映射之后,对内存的读写将同步到文件中去。这对一些希望将文件当作内存块来使用的应用程序来说很方便。一个例子是内存中的一块将同时作为一个文件保存在于文件系统中。mmap 文件的语义和普通文件略有不同。如果发生了对内存的存储，并不是立即发生相应的文件I/O操作。使用MS_SYNC 和MS_ASYNC标志位的 msyc()函数调用将控制内存和文件的一致性。调用msync() 时将MS_SYNC置位将强制把内存里的内容写到文件中去并等待直到此操作完成才返回。而MS_ASYNC 置位则告诉操作系统使用异步机制将内存刷新到磁盘，这样应用程序可以直接返回而不用等待此操作的完成。这个测试就是测量使用mmap()机制完成I/O的性能。

• Async I/O: 许多操作系统支持的另外一种I/O机制是POSIX 标准的异步I/O。本程序使用POSIX标准异步I/O接口来完成此测试功能。例如： aio_write(), aio_read(), aio_error()。这个测试测量POSIX异步I/O机制的性能。

以上说明均参考并翻译自 IOzone 官方文档[4]。IOzone 功能强大，因此参数很多，在此不再一一介绍，请参考官方文档。

3.1 测试命令

命令说明：

3.2 测试结果

3.2.1 结果可视化

IOzone 源码的src/current目录下附带有绘图脚本，只需要使用流行的画图工具 gnuplot 就可进行作图，使用前请确保已经安装 gnuplot 。使用如下方法可用安装：

CentOS ：

Ubantu :

直接运行作图脚本即可作图：

• 注意：../../../iozeon-a-g755.62G-1.out是我运行测试后输出文件的目录，请自行替换。

Write

具体数据如下图所示：

写入测试中，随着文件大小超过内存大小，写速度降低并且稳定至 550000 KB/s 左右。

Fwrite

具体数据如下图所示：

文件写入测试中，随着文件大小超过内存大小，文件写入速度降低并且稳定至 450000 KB/s 左右。

Frewrite

具体数据如下图所示：

文件重写测试中，随着文件大小超过内存大小，文件重写速度降低并且稳定至 440000 KB/s 左右。

ReWrite

具体数据如下图所示：

重写测试中，随着文件大小超过内存大小，重写速度降低并且稳定至 420000 KB/s 左右。

Record rewrite

具体数据如下图所示：

测试写与覆盖写一个文件中的特定块的性能时，可以发现块大小为 CPU 缓存大小时性能非常高，但随着文件与块大小增大超过内存大小，性能呈起伏变化。

Random write

具体数据如下图所示：

随机写测试中，当文件大小超过内存大小后，写入速度只有 330000 KB/s 左右，比非随机写入低了很多。

Read

具体数据如下图所示：

读取测试中，当文件大小与块大小接近与 CPU 缓存的时候，读取性能非常高；随着文件大小与块大小增大，并且文件大小最终超过了内存大小之后，读取性能降低并且稳定在 660000 KB/s 左右。

Reread

具体数据如下图所示：

重读测试中，趋势变化基本与读取测试中一致，但性能比读取测试中高；当文件大小超过内存大小之后，读取速率降低并且稳定在 800000 KB/s 左右。

Stride read

具体数据如下图所示：

可以发现就算文件大小超过内存大小，但只要读取的块够大，读取速率就能高达 900000 KB/s ，否则就是正常的读取速率。

Random read

具体数据如下图所示：

结果与跨步读取类似，读取在大文件下只要块足够大，读取速率就很高。

Re-fread

具体数据如下图所示：

文件重读操作在文件足够大的情况下依然能保持较高性能。

Fread

具体数据如下图所示：

可以看出对于大文件文件，读速率能达到 800000 KB/s 。

Read Backwards

具体数据如下图所示：

文件大小超过内存大小后，在块足够大的情况下，读取速率就会高

3.2.2 总结

本次使用 IOzone 对 AMD 服务器的 IO 进行了十分全面的测试，最终结果表明：在文件大小超出系统最大缓存（内存）且的情况下，本 AMD 服务器的各项读取相关操作基本能保持 600000 KB/s 的速率；其中某些读取操作与偏移量相关，因此即使读取文件足够大，在读取块较大的情况下依然能保持 900000 KB/s 以上；小文件的读速度普遍在 600000 KB/s 左右，而小文件的写操作速率普遍在 350000 ~ 400000 KB/s 左右；写相关操作除了随机写速率只有 370000 KB/s 左右意外，其他相关操作速率基本在 430000 KB/s 以上。

4 STREAM 内存带宽测试

STREAM 是一套综合性能测试程序集，通过 fortran 和 C 两种高级且高效的语言编写完成，由于这两种语言在数学计算方面的高效率， 使得 STREAM 测试例程可以充分发挥出内存的能力。 STREAM 测试得到的是可持续运行的内存带宽最大值，而并不是一般的硬件厂商提供的理论最大值。

4.1 测试过程

4.1.1 下载stream.c：

wget http://www.cs.virginia.edu/stream/FTP/Code/stream.c

4.1.2 使用gcc将其编译成二进制文件

gcc -O3 -mcmodel=medium -fopenmp -DSTREAM_ARRAY_SIZE=-DNTIMES=-DOFFSE=stream.c -o stream.o

• 注意：这并不是最终编译参数，请您仔细看完下面文档再确定。

核心编译参数说明：

可以看出，-DSTREAM_ARRAY_SIZE参数是比较重要的，STREAM源码[5]内对其有详细的说明。我们要保证测试中每个数组大小至少是L3 cache的四倍大小，实际测试中要充分考虑内存容量的需求，三个数组占用可用内存总量的 60% 比较合适。本次测试中，AMD 服务器每颗 CPU 的L3 cache为16384K也就是256MB，那么本 AMD 服务器STREAM_ARRAY_SIZE的最小值为：

那么三个数组占用总的内存是：

而本 AMD 服务器的内存是377.81 GB，使用最小值的话是远远不够的，因此按照可用内存总量的 60% 来计算STREAM_ARRAY_SIZE：

最终得出：。其他两个参数使用默认值，因此最终多线程测试的编译命令是：

gcc -O3 -mcmodel=medium -fopenmp -DSTREAM_ARRAY_SIZE=10000000000 -DNTIMES=100 stream.c -o stream.mt.10G

单线程测试的编译命令是：

gcc -O3 -mcmodel=medium -DSTREAM_ARRAY_SIZE=10000000000 -DNTIMES=100 stream.c -o stream.10G

4.1.3 运行测试

若只是简单测试，直接运行编译后的可执行文件即可：

./stream.mt.10G > stream.mt.10G.out &
./stream.10G > stream.10G.out &

本文为了探究 AMD 服务器的内存带宽与 STREAM 软件并行线程数的关系，使用了如下脚本测试了从单一线程到 32 线程内存带宽的变化趋势：

#!/bin/bash
# 测试单线程
gcc -O3 -mcmodel=medium -DSTREAM_ARRAY_SIZE=10000000000 -DNTIMES=100 stream.c -o stream.10G
./stream.10G > stream.10G.out
# 测试多线程，从2到32，间隔2
for ((i=2;i<=30;i+=2))
do
gcc -O3 -mcmodel=medium -fopenmp -DSTREAM_ARRAY_SIZE=10000000000 -DNTIMES=100 stream.c -o stream.mt.10G.$i
export OMP_NUM_THREADS=$i
echo OMP_NUM_THREADS=$(OMP_NUM_THREADS)
./stream.mt.10G.$i > stream.mt.10G.$i.out
done

4.2 结果分析

测试结果如下表所示：

为了方便管擦规律，使用 Excel 绘制了结果的折线图：

可以发现随着线程数的增加，测试所得的四种操作速率并非呈线性增加。在线程数从 1 增加至 4 时，内存带宽的增长基本与线程数呈正相关，随后增长逐渐缓慢；在线程数为 20 时出现了异常，具体原因暂不清楚。

5 参考资料

[1] Tips 3: Measure Performance in giga floating point operations per second (Gflops)：https://software.intel.com/content/www/cn/zh/develop/articles/a-simple-example-to-measure-the-performance-of-an-intel-mkl-function.html

[2] 简谈 CPU 峰值性能怎么计算：http://bbs.keinsci.com/thread-786-1-1.html

[3] IOzone 官网：http://iozone.org/

[4] IOzone 官方文档：extension://idghocbbahafpfhjnfhpbfbmpegphmmp/assets/pdf/web/viewer.html?file=http%3A%2F%2Fwww.iozone.org%2Fdocs%2FIOzone_msword_98.pdf

[5] stream.c源码：http://www.cs.virginia.edu/stream/FTP/Code/stream.c