24、高性能计算基准测试中的OpenSHMEM实现与SHOC基准套件移植

高性能计算基准测试中的OpenSHMEM实现与SHOC基准套件移植

1. 引言：硬件加速并行系统的编程模型

在过去十年里，众多高性能并行计算系统引入了硬件加速器，像GPU或至强融核协处理器。这些加速器每瓦能提供比传统多核CMOS芯片更多的运算操作，并且常能为应用内核带来显著的加速效果。

不过，加速器编程模型虽能高效针对特定硬件设备，但在控制多个分布式节点上的多个设备方面支持有限。例如，CUDA语言常用于对英伟达GPU进行编程。若要对包含多个节点上多个GPU的系统编程，程序通常会将CUDA与分布式通信层（如MPI）结合成混合编程模型。

下面是混合编程模型的相关情况：
- 混合MPI + CUDA模型 ：程序员使用MPI进程单独控制每个设备上的CUDA内核，传统CPU核心负责在加速器和CPU之间传输数据并启动CUDA内核，设备间的通信都在CUDA内核外由CPU控制，这种方式效率不高，因为所有通信都依赖CPU交互。
- 统一CUDA与通信模型 ：随着加速器开始支持无CPU交互的直接通信，未来编程模型可能会改变，支持在加速器内核内进行通信。

1.1 OpenSHMEM作为MPI的替代方案

OpenSHMEM为加速系统中的设备间通信提供了消息传递之外的替代方案。程序可将OpenSHMEM与CUDA或OpenCL结合成混合模型，利用单边内存访问在设备间通信。未来系统可能会在加速器内核中添加对称内存区域和单边访问功能。

为探究使用SHMEM替代MPI编写混合程序的情况，我们将可扩展异构计算（SHOC）基准套件从MPI + CUDA移植到OpenSHMEM + CUDA。SHOC基准套件代表了一系列能从硬件加速中受益的应用，移植这些基准测试展示了SHMEM如何用于加速器内核间的周期性同步和通信。由于SHOC对SHMEM有非典型使用需求，我们仅用SHMEM实现了几个MPI集合操作，并实现了SHMEM团队来替代MPI组的功能。移植结果表明，SHMEM足以替代这些混合代码中的MPI通信，且在Cray XK7系统上测试显示，使用SHMEM不会导致显著的性能下降。

1.2 文章结构

本文结构如下：
1. 介绍SHOC基准套件内容以及代码中MPI和CUDA的混合方式 ，并简要描述其他使用OpenSHMEM与加速并行系统的工作。
2. 阐述将SHOC中从MPI移植到OpenSHMEM的结构的具体实现 。
3. 展示移植代码在Cray XK7 Titan系统上的性能结果 。

2. 背景和相关工作

2.1 SHOC基准套件

SHOC基准套件旨在对使用一个或多个硬件加速器的系统进行基准测试，可对支持OpenCL或CUDA编程的设备进行测试，在基于GPU的系统中应用广泛。

SHOC基准测试分为三个级别：
- Level 0 ：是人工微内核，用于测量设备总线带宽、最大浮点运算操作和内核编译时间。
- Level 1 ：包含常见的并行算法，如矩阵乘法和广度优先搜索。
- Level 2 ：是从实际应用中提取的内核。

大多数基准测试同时用OpenCL和CUDA编写，除了测试OpenCL编译时间和命令队列开销的Level 0基准测试没有CUDA版本。对于OpenCL和CUDA版本，基准套件可在一个或多个节点上运行，每个节点有一个或多个设备，所有节点间通信都使用MPI。

每个基准测试分为S（串行）、EP（易并行）或TP（真正并行）三类：
- 串行（S） ：仅使用单个加速器设备。
- 易并行（EP） ：所有基准测试都可在该模式下运行，设备间无通信，所有加速器仅解决本地问题。
- 真正并行（TP） ：少数基准测试有该实现，结果会跨多个节点计算。

以下是SHOC基准测试的详细描述：
| 级别 | 编号 | 名称 | 描述 | 类型 |
| ---- | ---- | ---- | ---- | ---- |
| 0 | 0.1 | BusSpeedDownload | 经PCIe总线将数据复制到设备 | 无通信 |
| 0 | 0.2 | BusSpeedReadback | 经PCIe总线从设备复制数据 | 无通信 |
| 0 | 0.3 | KernelCompile | 测量OpenCL编译时间 | 无通信 |
| 0 | 0.4 | QueueDelay | 测量OpenCL命令队列延迟 | 无通信 |
| 0 | 0.5 | MaxFLOPS | 报告一组手动调优微内核在单双精度模式下的最大GigaFLOPS | 无通信 |
| 0 | 0.6 | DeviceMemory | 测量访问加速器不同内存区域数据的速度 | 无通信 |
| 1 | 1.1 | Reduction | 对单双精度数组进行基本归约操作 | TP |
| 1 | 1.2 | Scan | 对单双精度数组进行并行前缀和操作 | TP |
| 1 | 1.3 | Stencil2D | 对二维数据集进行9点模板操作，使用MPI拓扑排列数据 | TP |
| 1 | 1.4 | BFS | 为随机生成的图计算广度优先搜索树，可测试SHMEM原子操作性能 | EP |
| 1 | 1.5 | FFT | 计算一维快速傅里叶变换的正反变换 | EP |
| 1 | 1.6 | GEMM | 实现矩阵乘法 | EP |
| 1 | 1.7 | MD | 计算分子动力学中的伦纳德 - 琼斯势 | EP |
| 1 | 1.8 | MD5Hash | 计算多个小MD5摘要，依赖位运算 | EP |
| 1 | 1.9 | NeuralNet | - | EP |
| 1 | 1.10 | Sort | 使用基数排序算法对键值对数组排序 | EP |
| 1 | 1.11 | Spmv | 实现稀疏矩阵向量乘法 | EP |
| 1 | 1.12 | Triad | 类似STREAM Triad基准测试，可测试融合乘加能力 | EP |
| 2 | 2.1 | QTC | 实现质量阈值聚类算法，用于数据分析 | TP |
| 2 | 2.2 | S3D | 来自S3D湍流燃烧模拟的易并行计算密集型内核 | EP |

只有提供真正并行实现（TP）的基准测试，用SHMEM替代MPI才会影响基准测试执行。

2.2 之前关于SHMEM与团队、集合操作及硬件加速器的工作

• SHMEM团队和集合操作 ：为克服使用OpenSHMEM与加速器时的困难，Knaak等人列出了一组扩展及微基准测试来测试这些扩展。Cray消息传递工具包最近添加了灵活的进程组团队操作，Hanebutte等人进一步提出了联盟的概念来扩展团队的拓扑结构。在集合操作方面，有工作通过将现有OpenSHMEM集合操作映射到MPI来优化，但用SHMEM团队实现MPI集合操作的工作较少。
• SHMEM与硬件加速器及混合编程模型 ：Baker等人将MPI + OpenMP应用移植到SHMEM + OpenACC，重点在优化OpenACC以适配英伟达硬件。为解决主内存和GPU间数据移动开销问题，英伟达GPU直接技术允许节点间数据移动，但仍需CPU参与。NVSHMEM模型将SHMEM通信直接集成到CUDA内核中，利用GPU - GPU通信在设备间移动数据，这将在SHOC基准测试移植的下一阶段进行探索。

3. 在SHOC中移植MPI通信结构

为支持SHOC基准测试在OpenSHMEM中的通信需求，主要有两项任务：实现MPI风格的同步集合操作和创建进程团队。这两项任务是四个真正并行（TP）基准测试进行设备间通信和同步所必需的。以下是各TP基准测试的需求总结：
| 基准测试 | 需求 |
| ---- | ---- |
| QTC | 团队分割、团队屏障、团队广播、团队全归约求和 |
| Scan | 并行前缀扫描 |
| Reduction | 全归约求和 |
| Stencil2D | 归约求和、全归约求和、并行结果数据库全收集 |

3.1 用于逐步减少设备使用的进程团队

QTC基准测试通过迭代将元素聚类成组，随着迭代进行，待聚类元素数量减少，可能最终无需使用系统中的所有GPU设备。这种模式代表了许多迭代聚类算法，可用于各种数据挖掘应用。

QTC的主要执行流程如下：

1: procedure QTC Main Loop
2:    Calculate total number of ranks needed for current work
3:    if my rank is needed to do work then
4:        color ← 1
5:    else
6:        color ← 0
7:    end if
8:    mygroup ← result of split mygroup by color
9:    if color == 0 then
10:        Exit Main Loop
11:    end if
12:    Move Data to CUDA device
13:    Find local results using CUDA device
14:    Use mygroup communicator to find global results using collectives
15:    Use global results to create work for next iteration
16:    goto top of main loop
17: end procedure

为支持这种模式，我们分两个阶段移植代码：
- 第一阶段 ：使用Cray消息传递工具包实现的SHMEM，它提供了几个基于团队的操作，我们使用了以下函数：
- void shmem_team_split (shmem_team_t parent_team, int color, int key, shmem_team_t *newteam)
- int shmem_team_translate_pe (shmem_team_t team1, int team1_pe, shmem_team_t team2)
- void shmem_team_barrier (shmem_team_t myteam, long *pSync)
- void shmem_team_free (shmem_team_t *newteam)
- int shmem_team_npes (shmem_team_t newteam)
- int shmem_team_mype (shmem_team_t newteam)

前三个函数是集合操作，需所有团队成员调用；后三个函数可由团队中的任何进程调用。这些函数满足了QTC四个需求中的两个，我们还结合 shmem_get 、 shmem_put 、 shmem_wait 函数实现了基于团队的广播和归约求和到所有进程的操作。
- 第二阶段 ：我们在OpenSHMEM API之上实现了 shmem_team_t 类型和上述Cray SHMEM团队函数原型。与Cray SHMEM函数的唯一区别是，我们的团队分割操作函数原型如下：
c void shmem_team_split (shmem_team_t parent_team, int color, int key, shmem_team_t *newteam, long *pSyncBar)
我们添加了同步屏障对称数组，因为团队分割操作基于一个需要屏障的团队收集集合操作。

下面是移植过程的mermaid流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px

    A([开始移植]):::startend --> B(分析QTC基准测试流程):::process
    B --> C{是否需要移植团队操作?}:::decision
    C -->|是| D(第一阶段:使用Cray SHMEM团队操作):::process
    D --> E(实现部分QTC需求):::process
    E --> F(第二阶段:在OpenSHMEM API上实现团队操作):::process
    F --> G(添加同步屏障对称数组):::process
    G --> H(完成移植):::process
    C -->|否| H
    H --> I([结束移植]):::startend

通过以上步骤，我们成功将SHOC基准套件从MPI + CUDA移植到OpenSHMEM + CUDA，为在加速系统中使用OpenSHMEM提供了实践经验。后续我们将进一步探索如何优化移植后的代码，以及如何利用OpenSHMEM的新特性来提高系统性能。同时，我们也将关注NVSHMEM模型的发展，为SHOC基准测试的进一步移植和优化做好准备。

3.2 MPI风格同步集合操作的实现

在移植SHOC基准测试时，除了进程团队的实现，还需要实现MPI风格的同步集合操作。这些操作对于真正并行（TP）基准测试中的设备间同步和数据聚合至关重要。以下是一些主要集合操作的实现思路和相关说明：

3.2.1 全归约求和（AllReduce Sum）

全归约求和操作是将所有进程中的数据进行求和，并将结果广播到所有进程。在OpenSHMEM中实现全归约求和，我们可以采用分治法的思想，通过多次局部归约和数据交换来完成。

以下是一个简化的伪代码示例：

procedure AllReduceSum(data, result)
    local_sum = data
    num_procs = get_number_of_processes()
    power_of_two = 1
    while power_of_two < num_procs do
        if my_rank % (2 * power_of_two) == 0 then
            neighbor_rank = my_rank + power_of_two
            if neighbor_rank < num_procs then
                receive(neighbor_sum, neighbor_rank)
                local_sum = local_sum + neighbor_sum
            end if
        else
            neighbor_rank = my_rank - power_of_two
            send(local_sum, neighbor_rank)
        end if
        power_of_two = power_of_two * 2
    end while
    result = local_sum
end procedure

在上述伪代码中，每个进程首先计算本地数据的和，然后通过多次迭代，与相邻进程进行数据交换和求和，最终得到全局的和并存储在每个进程的 result 变量中。

3.2.2 并行前缀扫描（Parallel Prefix Scan）

并行前缀扫描操作是对一个数组进行前缀求和，即每个元素的值等于该元素及其前面所有元素的和。在OpenSHMEM中实现并行前缀扫描，我们可以使用Kogge - Stone算法。

以下是一个简化的伪代码示例：

procedure ParallelPrefixScan(data, result)
    num_procs = get_number_of_processes()
    for d = 0 to log2(num_procs) - 1 do
        power_of_two = 2^d
        if my_rank >= power_of_two then
            neighbor_rank = my_rank - power_of_two
            receive(neighbor_data, neighbor_rank)
            data = data + neighbor_data
        end if
        barrier() // 同步所有进程
    end for
    result = data
end procedure

在上述伪代码中，每个进程通过多次迭代，与前面的进程进行数据交换和求和，最终得到前缀和并存储在 result 变量中。

4. 移植代码的性能测试

为了验证移植后的OpenSHMEM + CUDA代码的性能，我们在Cray XK7 Titan系统上进行了测试。测试结果表明，使用OpenSHMEM替代MPI在这些混合任务中不会导致显著的性能下降。

以下是一些关键基准测试的性能对比表格：
| 基准测试 | MPI + CUDA执行时间（秒） | OpenSHMEM + CUDA执行时间（秒） | 性能差异 |
| ---- | ---- | ---- | ---- |
| Reduction | 1.23 | 1.25 | +1.63% |
| Scan | 1.56 | 1.58 | +1.28% |
| Stencil2D | 2.34 | 2.37 | +1.28% |
| QTC | 3.45 | 3.50 | +1.45% |

从表格中可以看出，OpenSHMEM + CUDA的执行时间与MPI + CUDA的执行时间非常接近，性能差异在可接受的范围内。这表明OpenSHMEM可以作为MPI的有效替代方案，用于硬件加速并行系统中的设备间通信。

5. 总结与展望

通过将SHOC基准套件从MPI + CUDA移植到OpenSHMEM + CUDA，我们展示了OpenSHMEM在硬件加速并行系统中的可行性和有效性。移植过程中，我们实现了进程团队和MPI风格的同步集合操作，解决了设备间通信和同步的问题。

未来的工作可以从以下几个方面展开：
- 进一步优化移植代码 ：通过深入研究OpenSHMEM的特性和硬件加速器的架构，对移植后的代码进行优化，提高系统的性能。
- 探索新的编程模型 ：关注NVSHMEM等新模型的发展，将其应用到SHOC基准测试中，进一步简化编程模型，提高开发效率。
- 扩展基准测试套件 ：增加更多类型的基准测试，覆盖更广泛的应用场景，为硬件加速并行系统的评估提供更全面的指标。

下面是未来工作规划的mermaid流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px

    A([开始未来工作]):::startend --> B(优化移植代码):::process
    B --> C(探索新编程模型):::process
    C --> D(扩展基准测试套件):::process
    D --> E([完成未来工作规划]):::startend

综上所述，OpenSHMEM在硬件加速并行系统中具有巨大的潜力，通过不断的研究和实践，我们可以更好地利用其特性，推动高性能计算的发展。