使用 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 庫和應用程序將需要支持所有供應商的加速器。