使用 Intel oneAPI DPC++ 编译器将 OpenMP 卸载到 NVIDIA GPU

Question

我的任务是编写一个将 OpenMP 卸载到 GPU 的程序。 目前，我使用 Intel oneAPI DPC++ 编译器icpx v2022.1.0 编译我的代码，并打算在后端使用 NVIDIA Tesla V100。 请在下面找到我的Makefile的相关部分：

MKLROOT   = /lustre/system/local/apps/intel/oneapi/2022.2.0/mkl/latest

CXX       = icpx
INC       =-I"${MKLROOT}/include"
CXXFLAGS  =-qopenmp -fopenmp-targets=spir64 ${INC} --gcc-toolchain=/lustre/system/local/apps/gcc9/9.3.0
LDFLAGS   =-qopenmp -fopenmp-targets=spir64 -fsycl -L${MKLROOT}/lib/intel64
LDLIBS    =-lmkl_sycl -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lsycl -lOpenCL -lstdc++ -lpthread -lm -ldl

${EXE}: ${OBJ}
    ${CXX} ${CXXFLAGS} $^ ${LDFLAGS} ${LDLIBS} -o $@

代码编译时没有错误和警告，但我不完全确定它在运行时是否使用 GPU。

1. 我该如何验证呢？ 我可以使用 Intel 或 NVIDIA 分析器来检查吗？
2. 我的假设是否正确，英特尔编译器支持卸载到 NVIDIA GPU？
3. 或者我应该更好地使用 NVIDIA 编译器来启用 OpenMP 卸载到 NVIDIA 显卡？

Answer 1

我该如何验证呢？ 我可以使用 Intel 或 NVIDIA 分析器来检查吗？

在具有 Nvidia GPU（如 V100）的系统上，您可以使用nvidia-smi来检查 GPU 的 state。 您还可以使用 Nsight 套件（或旧的已弃用的 nvvp ）之类的分析器。

我的假设是否正确，英特尔编译器支持卸载到 NVIDIA GPU？

据 Intel 称，它受支持：

英特尔® oneAPI DPC++/C++ 编译器和英特尔® Fortran 编译器的 OpenMP* 卸载到 GPU 功能可为各种加速器编译 OpenMP 源文件。 只有 icx 和 ifx 编译器支持 OpenMP 卸载功能。

据我了解，它们为 GPU 或 SPIR64 二进制文件生成基于 Clang 的中间代码。

根据英伟达的说法，前者当然可以在英伟达 GPU 上使用（尽管缺乏英特尔和英伟达提供的信息）。

后者与SPIR标准有关。 事实上，AFAIK，DPC++ 是开放SYCL标准的实现，可以为SPIR-V 生态系统生成代码。 SPIR 表示标准便携式中间表示。 它旨在让高级语言为许多后端生成一个统一的可移植代码。 然后硬件供应商必须支持它，以便所有高级语言/工具都支持供应商。 因此，供应商不必直接支持高级语言/工具。

虽然我没有找到 Nvidia 提供的直接支持 SPIR-V 的任何信息，但 SPIR 代码可以在支持 OpenCL 和 Vulkan 最新版本 (>=1.2) 的设备上执行。 幸运的是，Nvidia 最近声称支持 OpenCL 3.0 。

简而言之，它应该可以在目标 Nvidia GPU 上工作，尽管它可能还不简单。

或者我应该更好地使用 NVIDIA 编译器来启用 OpenMP 卸载到 NVIDIA 显卡？

主流的 Nvidia 编译器包装器nvcc旨在支持 CUDA 代码，这些代码基本上只能在 Nvidia GPU 上工作（有很好的支持）。 LLVM 应该支持 Nvidia GPU（使用 CUDA 生态系统），但设置可能有点棘手（并且您需要最新版本的工具链以避免许多问题）。 GCC，当使用正确的标志和依赖项构建时，支持从版本 5 开始将 OpenACC 卸载到 Nvidia PTX，从版本 7 开始支持将 OpenMP 卸载到 PTX。此外，虽然 Nvidia 在其编译器包装器nvcc中不支持 OpenMP 卸载，但它还分发nvc和具有OpenMP和OpenACC卸载功能的nvc++编译器（以前称为 PGI HPC 编译器）。

请注意，OpenMP 卸载仍然是相当新的且相当实验性的，尽管到目前为止一些供应商似乎提供了良好的支持。

Answer 2

由于在这个领域有很多积极的开发，对于哪个编译器最适合卸载到 NVIDIA GPU 的问题的答案可能会随着时间/版本（以及应用程序）而变化。 因此，如果您想确保获得最佳性能，您将需要使用您的特定应用程序对不同编译器的最新版本（参见 Jérôme Richard 的回答）进行基准测试，并在未来继续这样做。

根据您的应用程序的大小和复杂性，有人可能会争辩说，这花费的时间可以更好地用于实现 CUDA 内核，但另一方面，糟糕的 CUDA 实现可能与从 OpenMP 生成的“最差编译器”一样慢。

有一些论文对不同的 OpenMP 实现进行了基准测试，但目前我还没有找到包括 OP 使用的 Intel 编译器在内的任何论文。 面向 NVIDIA V100 GPU (2020) 的 OpenMP 编译器的性能评估结果可能不再有意义。

面向云和 HPC 的 GPU 加速分子对接应用程序的可移植性：可移植编译器指令能否提供跨所有平台的性能？ (2022)可能值得研究一下，以了解 OpenMP 的实现、优化和可移植替代方案的概述。

话虽如此，如果您没有其他理由使用 DPC++ 编译器，并且不想进行所有基准测试，我宁愿 go 用于大型已建立的 FOS 工具链（GCC 或 Clang）之一用户群或 NVIDIA HPC 编译器，因为他们有兴趣在自己的硬件上快速运行。 在英特尔编译器更加成熟并且有更多公开可用的结果之前，我只会将其用于卸载到英特尔硬件。

由于带有 AMD（ Frontier和LUMI ）和 Intel（ Aurora ）加速器的新型超级计算机已经出现或将在不久的将来出现，我预计加速器和可移植编程模型之间的大量比较将会发布，因为许多 HPC 库和应用程序将需要支持所有供应商的加速器。