OpenMP卸载英特尔oneAPI DPC++编译器到NVIDIA

Question

我正在执行写将OpenMP卸载到GPU的程序的任务。目前，我用Intel oneAPI DPC++编译器icpx v2022.1.0编译我的代码，目的是在后端使用NVIDIA 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. 我怎么才能证实呢？我可以使用英特尔或NVIDIA分析器来检查吗？
2. 我的假设是正确的，英特尔编译器支持卸载到NVIDIA GPU？
3. 还是我应该更好地使用NVIDIA编译器使OpenMP卸载到NVIDIA显卡？

Answer 1

我怎么才能证实呢？我可以使用英特尔或NVIDIA分析器来检查吗？

在使用像V100这样的Nvidia GPU的系统上，您可以使用nvidia-smi来检查GPU的状态。您还可以使用分析器，如Nsight套件(或旧的不推荐的nvvp)。

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

据英特尔，它被支持：

OpenMP*卸载到Intel oneAPI DPC++/C++编译器的GPU特性，并且Intel Fortran编译器为广泛的加速器编译OpenMP源文件。只有icx和ifx编译器支持OpenMP卸载特性。

据我所知，它们要么为GPU生成基于Clang的中间代码，要么生成SPIR64二进制代码。

前者当然可以用于Nvidia GPU 根据Nvidia (尽管英特尔和Nvidia提供的信息不足)。

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

虽然我没有找到任何信息提供的Nvidia直接支持SPIR-V，SPIR代码可以执行的设备上支持最近的版本(>=1.2)的OpenCL和Vulkan。幸运的是，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卸载到Nvidia。此外，虽然Nvidia不支持在编译器包装器nvcc中卸载OpenMP，但它还支持OpenMP和OpenACC卸载的nvc和nvc++编译器(以前称为PGI编译器)。

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

Answer 2

由于在这个领域有许多积极的开发，对于哪个编译器最适合卸载到NVIDIA GPU的问题的答案可能会随着时间/版本(以及应用程序)的不同而有所不同。因此，如果您想确保自己获得了最好的性能，就需要用特定的应用程序对不同编译器的最新版本(参见Jér me Richard的答案)进行基准测试，并在今后继续这样做。

根据应用程序的大小和复杂性，人们可能会认为，实现CUDA内核所需的时间可能会更好，但另一方面，一个糟糕的CUDA实现可能会像从OpenMP生成的“最糟糕的编译器”一样慢。

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

对于了解OpenMP的实现、优化和可移植的替代方案，用于云和HPC的GPU加速分子对接应用程序的可移植性:便携编译器指令能否提供所有平台的性能？(2022)可能是值得研究的。

尽管如此，如果您没有其他使用DPC++编译器的理由，并且不想做所有这些基准测试，我宁愿选择一个大型的、已建立的FOS工具链(GCC或Clang)，因为用户基础很大，或者因为他们对快速使用自己的硬件感兴趣，所以选择NVIDIA编译器。在英特尔编译器建立得更好，并且有更多的公开结果之前，我只会使用它将其卸载到Intel硬件。

由于拥有AMD的新超级计算机(边疆和Intel (奥罗拉加速器已经出现或将在不久的将来出现)，我期望在加速器和便携式编程模型之间进行大量比较，因为许多高性能计算机库和应用程序将需要支持所有厂商的加速器。