22、OpenCL与OpenSHMEM混合编程模型：提升并行计算性能的新方案

OpenCL与OpenSHMEM混合编程模型：提升并行计算性能的新方案

1. 背景

近期，OpenSHMEM社区对探索OpenSHMEM + X混合编程模型表现出浓厚兴趣。就像OpenMP + MPI两层并行混合模型能处理节点内的对称多处理（SMP）执行以及连接网络节点的分布式消息传递一样，将代码与OpenSHMEM混合的类似混合模型可能也会从中受益。

在本文探讨的特定案例中，OpenCL + OpenSHMEM混合模型处于相同的并行层级，这种编程模型的结合解决了在Parallella平台和Epiphany架构下各自存在的不足。OpenCL在处理具有分层内存的SMP架构方面表现出色，但它没有为处理元素或多处理器之间的处理器间通信提供语义。而OpenSHMEM为跨分区全局地址空间（PGAS）的非均匀内存访问（NUMA）提供了语义，不过对于SMP架构可能并非理想选择。Epiphany设备级架构兼具SMP和PGAS平台的特点，因此使用混合的SMP和PGAS编程模型来处理该架构是合理的。

2. Epiphany架构

Adapteva Epiphany MIMD架构是一个可扩展的二维RISC核心阵列，通过快速的二维片上网络（NoC）连接，非核心功能极少。基于该架构的处理器通过二维网状网络展现出良好的能源效率和可扩展性，但需要合适的编程模型来充分发挥其优势。

16核的Epiphany - III协处理器已集成到Parallella微型计算机平台中，其RISC阵列由双核ARM CPU支持，并可通过非对称共享内存访问片外全局内存。每个Epiphany - III网状节点包含32 KB的共享本地内存（用于程序指令和数据）、网状网络接口、双通道DMA引擎和RISC CPU核心。每个RISC CPU核心包含64字寄存器文件、序列器、中断处理程序、算术逻辑单元和浮点单元。

不同工艺下处理器的特点如下：
| 工艺 | 处理器尺寸 | 时钟频率 | 单精度峰值性能 | 功耗 | 能源效率 |
| ---- | ---- | ---- | ---- | ---- | ---- |
| 65 nm | 0.5 mm² | 600 MHz | 19.2 GFLOPS | 594 mW | 32.3 GFLOPS/瓦 |
| 28 nm | 0.128 mm² | - | - | - | 超50 GFLOPS/瓦（Epiphany IV） |

目前可用的Epiphany协处理器的原始性能与现代高性能CPU和GPU相比相对较低，但Epiphany架构具有更高的能源效率，并且设计为高度可扩展。其架构路线图显示，在不久的将来核心数量将超过1000个，随后将达到数万个核心，能源效率接近1 TFLOPS/瓦。

在Epiphany架构中，数据重用是实现高性能的关键，由于该架构在任何级别都没有硬件缓存，因此需要精确控制核心间通信。与访问任何核心的片上核心内存相比，核心访问片外映射内存会在延迟和带宽方面带来显著的性能损失。

3. 用于Epiphany的OpenCL

OpenCL是用于异构平台上并行编程加速器或协处理器的行业标准API。它主要为通用图形处理单元（GPU）计算而设计，但也可用于访问其他类型设备的计算能力，包括多核CPU和其他加速器。大多数主流高性能计算加速器都支持OpenCL，因此探索使用OpenCL来挖掘Parallella上Epiphany协处理器的计算能力是有价值的。

OpenCL由用于对协处理器设备进行编程的内核编程API和用于协调这些内核执行以及执行其他操作（如内存同步）的运行时主机API组成，这样可以将并行计算密集型工作从主机平台卸载。OpenCL编程模型基于在多个线程上并行执行内核以利用SIMD或SIMT架构。从主机平台的角度来看，并行内核被排入协处理器设备执行。每个内核在全局n维工作项范围内执行，这些工作项逻辑上划分为本地工作组。工作组内的执行线程可以通过使用屏障进行有限的同步，但工作组之间不允许同步。

OpenCL是为Epiphany架构实现的第一个标准并行编程API，COPRTHR - 1.5 SDK for Epiphany提供了对OpenCL 1.1标准的部分支持。选择OpenCL有几个原因，Epiphany - III协处理器是包含运行Linux的双核ARM CPU主机的异构微型计算机（Parallella）的一部分，因此基于主机指导将并行工作卸载到协处理器的OpenCL协同设计编程模型非常适合该平台。

然而，在将OpenCL用于Epiphany架构时存在一些限制和约束。OpenCL是为GPU等大规模多线程架构设计的，而Epiphany没有硬件多线程支持，早期的软件多线程实验由于资源限制也未成功。因此，Epiphany的OpenCL设备执行模型必须将工作组大小限制为设备上的物理核心数量。

实现OpenCL for Epiphany时遇到的最重大技术问题是协调Epiphany协处理器的物理内存架构与OpenCL标准定义的逻辑内存模型。OpenCL地址空间限定符将物理局部性和可见性的概念混合在一起。对于Epiphany架构，在OpenCL工作组中执行线程的每个核心所共有的物理内存最好描述为对称分布式共享内存。这种内存对于执行线程来说是物理本地的，同时对所有其他线程具有共享可见性，因为远程核心可以非均匀地访问任何核心的本地内存。管理这种对称分布式内存的使用和重用对于Epiphany架构的性能至关重要。

最初在OpenCL for Epiphany的实现中提供了一些扩展，包括一组线程间内存复制例程，允许直接在一个核心的本地内存和另一个核心的本地内存之间复制数据。这些例程以非标准的方式解决了OpenCL的问题，使算法能够以良好的性能实现。后来发现，OpenSHMEM正是解决使用OpenCL for Epiphany时出现的关键问题所需的接口。

4. 用于Epiphany的OpenSHMEM

最近开发了针对Epiphany架构的OpenSHMEM实现，该接口为Epiphany设备级执行提供了完整的OpenSHMEM 1.3标准访问。它填补了由于缺乏能够在通过NoC分布的片上内存上实现良好性能的标准编程模型而留下的空白。从概念上讲，Epiphany架构的物理内存直接映射到OpenSHMEM和PGAS内存模型。不过，Epiphany的OpenSHMEM接口没有涉及协处理器卸载或片外内存的概念，对于需要这些概念的应用程序，需要使用混合编程模型。

5. 混合OpenCL + OpenSHMEM编程模型

基于上述工作，我们提出了一种混合编程模型，将OpenCL与OpenSHMEM结合用于基于Epiphany架构的并行处理器的设备级编程。简单来说，OpenSHMEM直接解决了在为这种架构实现OpenCL时遇到的最关键技术问题，取代了最初为支持核心间数据重用和在实现Epiphany算法时实现良好性能而引入的非标准扩展。

同时，OpenCL对OpenSHMEM起到补充作用。对于采用并行协处理器的混合平台，OpenCL支持将并行工作卸载到协处理器，而OpenSHMEM标准中没有定义等效操作。

Epiphany的OpenSHMEM提供了OpenCL概念中的处理元素或多处理器之间的核心间通信。在Epiphany架构中，它们是相同的。每个多处理器有一个处理元素，以解决OpenCL规范中本地内存的分层内存概念。OpenCL接口定义了全局或常量内存。

该混合编程模型使用OpenCL开发控制整个应用程序的主机代码，并通过卸载并行计算内核来指导协处理器的操作。OpenCL内核编程语言与标准C密切相关，用于实现内核。OpenCL没有合适API的分布式共享内存通过OpenCL内核中的OpenSHMEM暴露。OpenSHMEM编程模型嵌套在OpenCL中，可以看作是对OpenCL的扩展。使用这种混合编程模型开发应用程序将与使用OpenCL的方法非常相似。

从应用程序开发的角度来看，仍然使用OpenCL协同设计模型，OpenCL主机代码的开发无需更改。OpenCL设备编程API通过OpenSHMEM进行扩展。每个OpenCL内核将包含一个独特的OpenSHMEM并行作业，其上下文继承自OpenCL内核。每次将OpenCL内核排入执行时，都在其中执行支持OpenSHMEM API的所有初始化和分配要求。虽然OpenCL内核允许通过全局内存进行通信，但不允许在内核之间或OpenCL工作组之间使用OpenSHMEM API进行通信，这遵循了OpenCL执行模型，即允许工作组内同步，但不允许工作组之间同步。不过，如果使用单个工作组，OpenCL模式中工作分布在多个包含多个工作项的工作组中的嵌套并行性可以忽略。

由于OpenSHMEM API包含在OpenCL设备内核上下文中，所有OpenSHMEM内存分配仅在一个内核内可见，并且在多次内核调用之间不会持久化。

在可移植性方面，使用混合OpenCL + OpenSHMEM编程模型不符合OpenCL标准，并且无法移植到仅存在纯OpenCL实现的其他架构。但对于开发高性能代码的程序员来说，这种缺乏通用性的问题并不是一个重大问题，因为编程标准的实用性更多地在于为程序员提供熟悉的语法和语义来创建特定于架构的代码。

6. 应用与结果

矩阵乘法是许多科学应用中的核心构建块。我们将混合OpenCL + OpenSHMEM编程模型应用于使用Cannon算法的矩阵 - 矩阵乘法。Cannon算法通过二维并行分解有效地利用了这种并行架构。该算法将方阵 - 矩阵乘法问题（C = A * B）分解到N×N的处理元素集合中。每次子矩阵 - 子矩阵乘法后，相邻处理元素之间会共享子矩阵。通信模式从在二维网状网络拓扑中将矩阵A的列向左倾斜，矩阵B的行向上倾斜开始。

为了进行参考，我们对纯OpenCL实现进行了基准测试。在该实现中，每个核心的每个线程必须从全局内存中读取子矩阵，缺乏数据重用，因此性能较低。使用OpenCL单独实现时，对于128×128的矩阵大小，最高性能可达794 MFLOPS。需要注意的是，该架构受片外带宽的限制很大，特别是在直接加载内存而不是使用片外DMA引擎时。

然后，我们使用OpenSHMEM修改了相同的OpenCL代码。OpenCL主机代码无需更改，在OpenCL内核中包含OpenSHMEM头文件，并使用OpenSHMEM语义为矩阵A、B和C分配核心本地缓冲区。进一步修改OpenCL内核，使用OpenSHMEM的put调用和适当的线程间屏障同步来实现子矩阵的移位。这样，子矩阵只需从全局内存中读取一次，然后进行重用，这对于在Epiphany架构上实现最佳性能是必要的。

混合OpenCL + OpenSHMEM编程模型的性能最高可达1812 MFLOPS。由于OpenSHMEM支持数据重用，混合实现轻松超越了仅使用OpenCL的参考实现。虽然该应用程序的性能仍然受片外带宽的限制，但通过OpenSHMEM接口的核心间通信将性能提高了2.3倍。不同矩阵大小的性能结果如下表所示：
| 矩阵大小 | OpenCL性能（MFLOPS） | OpenCL + OpenSHMEM性能（MFLOPS） | 加速比 |
| ---- | ---- | ---- | ---- |
| 32 × 32 | 218 | 504 | 2.3x |
| 64 × 64 | 424 | 1000 | 2.4x |
| 128 × 128 | 794 | 1817 | 2.3x |

7. 结论

我们提出并验证了一种用于低功耗Epiphany RISC阵列处理器等设备级并行编程架构的混合OpenCL + OpenSHMEM编程模型。该混合模型直接解决了单独使用OpenCL处理该架构时遇到的最关键缺陷。引入OpenSHMEM允许对片上分布式对称共享内存进行适当管理，这对于在该架构上获得高性能至关重要。矩阵 - 矩阵乘法的基准测试表明，该混合编程模型可以为该架构实现更好的性能，并且大大优于仅使用OpenCL的情况。

8. 未来工作展望

虽然混合OpenCL + OpenSHMEM编程模型已经展现出良好的性能提升，但仍有一些方面值得进一步探索和改进。

在可移植性方面，尽管目前认为缺乏通用可移植性对于高性能代码开发不是重大问题，但可以研究如何在一定程度上提高其可移植性，例如开发一些中间层或适配层，使得该混合模型能够在更多架构上有一定的兼容性。

对于性能优化，虽然已经通过OpenSHMEM实现了数据重用和核心间通信的优化，但片外带宽仍然是性能的限制因素。未来可以研究如何更好地利用片外DMA引擎，或者开发新的算法和策略来减少对片外带宽的依赖。

在应用扩展方面，可以将该混合编程模型应用到更多的科学计算和工程应用中，如机器学习、图像处理等，以验证其在不同领域的有效性和性能提升效果。同时，针对不同的应用场景，可以进一步优化混合编程模型的使用方式，以更好地满足特定应用的需求。

OpenCL与OpenSHMEM混合编程模型：提升并行计算性能的新方案

9. 技术优势分析

混合OpenCL + OpenSHMEM编程模型在多个方面展现出显著优势，以下为详细分析：
- 数据重用与性能提升 ：OpenSHMEM支持数据重用，使得子矩阵只需从全局内存读取一次，避免了重复读取带来的性能开销。如在矩阵乘法应用中，通过OpenSHMEM的put调用和屏障同步实现子矩阵移位，有效提高了计算效率，性能提升可达2.3倍以上。
- 解决OpenCL内存管理问题 ：OpenCL在处理Epiphany架构的物理内存时存在不足，而OpenSHMEM提供了对称分布式共享内存的管理接口，弥补了OpenCL的缺陷，使内存管理更加高效。
- 互补功能增强 ：OpenCL擅长将并行工作从主机卸载到协处理器，而OpenSHMEM提供了核心间通信的语义，两者结合实现了功能互补，充分发挥了Epiphany架构的性能。

以下是技术优势的对比表格：
| 优势类型 | OpenCL | OpenSHMEM | 混合模型 |
| ---- | ---- | ---- | ---- |
| 数据重用 | 弱 | 强 | 强 |
| 内存管理 | 不足 | 良好 | 良好 |
| 并行工作卸载 | 强 | 无 | 强 |
| 核心间通信 | 无 | 强 | 强 |

10. 实施步骤与注意事项

若要使用混合OpenCL + OpenSHMEM编程模型进行开发，可参考以下步骤：
1. 环境准备 ：确保系统支持OpenCL和OpenSHMEM，安装相应的SDK和库。
2. OpenCL主机代码开发 ：使用OpenCL开发控制整个应用程序的主机代码，指导协处理器的操作。
3. OpenCL内核代码编写 ：使用与标准C密切相关的OpenCL内核编程语言实现内核。
4. 集成OpenSHMEM ：在OpenCL内核中包含OpenSHMEM头文件，使用OpenSHMEM语义分配内存，并实现核心间通信。
5. 同步与通信处理 ：在OpenCL内核中使用OpenSHMEM的put调用和屏障同步实现数据传输和线程同步。
6. 性能测试与优化 ：对程序进行性能测试，根据测试结果进行优化，如调整工作组大小、优化内存访问等。

在实施过程中，需要注意以下事项：
- 工作组大小限制 ：由于Epiphany架构的特性，OpenCL设备执行模型必须将工作组大小限制为设备上的物理核心数量。
- 内存分配可见性 ：OpenSHMEM内存分配仅在一个内核内可见，且在多次内核调用之间不会持久化。
- 通信限制 ：不允许在内核之间或OpenCL工作组之间使用OpenSHMEM API进行通信，需遵循OpenCL执行模型。

11. 应用场景拓展

除了矩阵乘法，混合OpenCL + OpenSHMEM编程模型还适用于多种科学计算和工程应用，以下为部分典型场景：
- 机器学习 ：在神经网络训练中，需要大量的矩阵运算和数据传输。该混合模型可以提高矩阵乘法的性能，加速训练过程。同时，核心间通信功能可以实现数据的高效共享和同步，提高训练的并行性。
- 图像处理 ：图像处理涉及到大量的像素级计算和数据处理。混合模型可以利用OpenCL的并行计算能力和OpenSHMEM的内存管理优势，实现图像的快速处理，如图像滤波、边缘检测等。
- 计算流体力学 ：该领域需要进行大规模的数值模拟和计算，对计算性能和数据通信要求较高。混合模型可以有效提高计算效率，减少计算时间。

以下是不同应用场景的性能预期表格：
| 应用场景 | 纯OpenCL性能 | 混合模型性能预期提升 |
| ---- | ---- | ---- |
| 机器学习 | 一般 | 2 - 3倍 |
| 图像处理 | 中等 | 2 - 2.5倍 |
| 计算流体力学 | 较低 | 2.3 - 2.8倍 |

12. 总结与展望

混合OpenCL + OpenSHMEM编程模型为基于Epiphany架构的并行处理器提供了一种高效的编程解决方案。通过结合OpenCL和OpenSHMEM的优势，该模型解决了单独使用OpenCL时的关键问题，显著提高了计算性能。在矩阵乘法等应用中，混合模型的性能提升效果明显，证明了其有效性。

未来，随着技术的不断发展，混合OpenCL + OpenSHMEM编程模型有望在更多领域得到应用。通过进一步优化和改进，如提高可移植性、减少片外带宽依赖等，可以使其在不同架构和应用场景中发挥更大的作用。同时，随着Epiphany架构的不断升级和扩展，该混合模型也将不断适应新的需求，为高性能计算提供更强大的支持。

以下是混合编程模型发展的mermaid流程图：

graph LR
    A[当前混合模型] --> B[提高可移植性]
    A --> C[优化片外带宽利用]
    A --> D[拓展应用领域]
    B --> E[更广泛架构兼容]
    C --> F[更高性能提升]
    D --> G[多领域应用验证]
    E & F & G --> H[未来混合模型]

综上所述，混合OpenCL + OpenSHMEM编程模型具有广阔的发展前景，将为并行计算领域带来新的突破和机遇。