TechVideoGPU的博客

oneAPI GPU Optimization Guide 的中文版

如果一个列表项是一个指向映射到设备的对象的指针，那么在结构中对列表项的引用将被转换为对一个设备指针的引用， 该设备指针是局部于结构体并且引用相应对象的设备地址。如果列表项不指向映射对象，它必须包含一个有效的设备地址，列表项引用将被转换为对一个局部设备指针的引用，该指针引用这个设备地址。在 C++ 中，每个列表项应为指针类型、数组类型、指针的引用类型或数组的引用类型。在 C++ 中，每个列表项应为指针类型、数组类型、指针的引用类型或数组的引用类型。它表示列表项已经具有有效的设备地址，因此可以直接从设备访问。

我们将使用一个 Fortran 示例来说明如何适当地选择内存分配，以避免冗余的数据传输并提高性能。这个 Fortran 示例使用了 OpenMP 部署，并且是根据 NWChem （一个高性能的计算化学应用程序）进行改编的。在这个示例中，有一个 4 层的循环嵌套。最内层的 k 循环调用了omp_fbody例程，该例程将两个对sgemm的调用部署到设备上， 然后将一个 reduction 计算（ reduction 变量emp4i和emp5i）部署到设备上。

区域完成，可以继续处理工作共享循环。通过工作共享循环末尾的隐式 barrier 保证了。区域（第 48 行）中计算两个向量 v1 和 v2 的乘积。一半的计算在主机上由执行。区域的末尾有一个隐式 barrier ，该 barrier 确保遇到。设备上进行另一半的计算。子句，那么性能可能会得到提高， 因为这样主线程就不必等待。区域完成后才能继续并参与主机上的计算（工作共享循环）。区域在设备上异步执行， 而无需主机线程空闲等待。构造的主机线程也可以继续。区域来在设备上进行计算。区域完成之前不能继续。

可以通过使用更多可以并行运行的 work-item 来提高部署代码的性能，从而利用更多的 GPU 资源（填满 GPU ）。循环迭代的 ND-range 划分由编译器和 runtime 启发式算法决定，还取决于 GPU 驱动程序和硬件配置。因此它会随着时间而改变。但是，基于 LIBOMPTARGET_DEBUG=1 输出确定划分的方法将保持不变。

支持将 OpenMP 部署到 GPU 上。当使用 OpenMP 时，程序员在代码中插入设备指令， 指示编译器将应用程序的某些部分部署到 GPU 上。部署计算密集型代码可以获得更好的性能。本节涵盖了与 OpenMP 部署相关的各种主题， 以及如何提高部署代码的性能。基于 LLVM 的 Intel® C/C++ 和 Fortran 编译器，

它有助于识别应用程序中最耗时（热点）的函数，应用程序是 CPU 还是 GPU 限制， 它如何有效地将代码卸载到 GPU ，以及最佳的代码部分来优化顺序性能和线程性能等。有关此工具的信息，请参阅本文档的。选项时，查看跟踪末尾的主机和设备端摘要， 在 “API Timing Results” 和 “Device Timing Results” 标题下。文件头提供有关 SIMD 宽度，编译器选项以及其他信息的信息。的文件，该文件提供有关 GPU 的信息， 例如 EU 计数，线程计数，切片计数等。

Compile:Run:在特定 GPU 上的性能（无填充）如下（仅 1 堆栈）:= 0。

使用以下编译器选项启用 OpenMP 部署到 Intel® GPU。这些选项适用于 C/C++ 和 Fortran。默认情况下，Intel® 编译器将程序转换为中间语言表示 SPIR-V, 并将其存储在编译过程生成的二进制文件中。该代码可以通过在 runtime 中将 SPIR-V 代码 转换为平台的汇编代码以便在任何硬件平台上运行。这个过程被称为即时 (JIT) 编译。要启用编译器优化报告的输出，请添加以下选项：-qopenmp编译器选项相当于-fiopenmp，并且 这两个选项可以互换使用。

如 “ SYCL 线程层次结构和映射” 一章所述， 部署到 GPU 上的并行循环（执行范围） 的迭代被划分为 work-group、sub-group 和 work-item。ND-range 表示总执行范围，它被划分为大小相等的 work-group。一个工 work-group 是一个 1、2 或 3 维的 work-item 集合。每个 work-group 可以划分为 sub-group。sub-group 表示一小段连续的 work-item, 它们被一起作为 SIMD 向量处理。

在 Intel® 数据中心 GPU Max 系列上执行时， 整个 GPU (可能具有多个堆栈) 可以被视为一个设备， 或者每个堆栈都可以被视为一个设备。OpenMP 执行模式具有一个主机设备， 但有多个目标设备。设备是具有自己的 本地存储和数据环境的逻辑执行引擎。子句、 (隐式或显式) barrier 或其他同步机制 实现异步执行的代码区域之间的同步。子句指定)， 并将构造中的代码部署到设备上。区域结束时， 数据从设备传输回主机（如果指定）。构造时，数据从主机传输到设备 (例如，如果由。

支持将 OpenMP 部署到 GPU 上。当使用 OpenMP 时，程序员在代码中插入设备指令， 指示编译器将应用程序的某些部分部署到 GPU 上。部署计算密集型代码可以获得更好的性能。本节涵盖了与 OpenMP 部署相关的各种主题， 以及如何提高部署代码的性能。基于 LLVM 的 Intel® C/C++ 和 Fortran 编译器，

还有另一种编写kernel的方法，在设备上访问主机上的只读变量的副本，将其作为定义kernel的 lambda 函数中变量捕获的一部分， 如下所示。如果在此程序块内提交读取 A 或 B buffer的另一个kernel， 则在第二个kernel完成之前，该新kernel无法启动。访问模式通知runtime，在kernel开始执行之前，数据需要在设备上可用，但在计算结束时不需要将数据从设备复制到主机。进行的， 第44和45行中的声明使它们成为只读的，这可以防止它们在生命周期结束时从设备复制回主机。

在以下示例中，kernel在 for 循环内重复启动。由于buffer C 是在 for 循环内声明的， 因此它在每次循环迭代中都会被分配和释放。除了buffer的分配和释放之外，与buffer关联的内存在每次迭代中从主机重复 地传输到设备以及从设备传输到主机。当在 for 循环内重复启动kernel时，可以通过在循环外部声明buffer来防止重复分配和释放buffer。更好的方法是在 for 循环之前声明buffer C，以便仅分配和释放一次，从而通过避免主机和设备之间的多余数据传输来提高性能。

然后，通过对每个值应用函数，将这个新vector转换为第三个vector， 最后将这个第三个vector作为输入传到另一个kernel中以进行一些额外的计算。在许多领域中这种形式的计算非常常见，在这些领域中，算法是迭代的，并且一个计算的输出需要作为另一个计算的输入。在某些情况下，可能需要将加速器上的kernel计算的数据带到主机并对其进行一些操作， 然后将其发送回设备以进行进一步处理。在这种情况下，我们最终将产生设备到主机传输的开销，然后再次产生主机到设备传输的开销。的计算中，如下所示。

如果buffer指向的内存未在page边界上对齐，则将分配新内存以便在page边界上对齐，并将buffer内容复制到该内存中。然后通过将buffer中的新内存与加速器共享（对于不共享任何内存的加速器，从主机上的buffer复制内容到设备上）或使用页表避免来复制可在设备上使用的内存（对于共享内存的加速器）。，则在创建buffer时它们将被复制并分配新内存，而不是重用主机vector中的内存。当执行此代码时，我们看到与传入vector相关联的地址与buffer中存在的内存以及加速器设备中存在的内存不同。

SYCL为设备上的内存管理提供了几种选择。本节将简要介绍相关概念以及性能折衷。有关深入解释，请参见。与其他语言特性一样，规范定义了行为但不定义实现，因此性能特征可能在软件版本和设备之间发生变化。本指南提供最佳的实践指导。Buffers。buffer是一个可以从设备和主机访问的数据容器。SYCL runtime通过提供分配、读取和写入内存的API来管理内存。runtime负责在主机和设备之间移动数据，并同步对数据的访问。(USM)。

实际信号包含更多数据（和噪声）， 但是无论您是对齐 1D 信号，叠加 2D 图像 还是执行 3D 体积图像配准，原则都是相同的。不幸的是， 添加人工信号的代码在主机上运行， 因此 SYCL runtime 必须使主机和设备数据一致。傅里叶相关中使用的信号通常很大， 特别是在 3D 成像应用中， 因此不必要的数据传输会降低性能。请注意，查找最大相关值位置 的最后一步在主机上执行。通常会向信号添加随机噪声，以防止 神经网络训练期间过度拟合， 向图像添加视觉效果，或改善从次优探测器 获得的信号的可检测性等。

常见的计算密集型操作，如矩阵乘法， 已经得到了广泛的研究。他们还使用调优技术，如缓存阻塞和循环展开， 以在不管矩阵A和B的形状如何的情况下实现性能提升。本节讨论使用来自库的高效函数， 例如|onemkl|或|onednn|，而不是手工编写的替代方案。例如，矩阵乘法是一种常见的、直接的数学运算。用于数学运算的 oneMKL 用于数据分析和机器学习的 oneDAL 用于深度学习框架开发的 oneDNN 用于视频处理的 oneVPL 在创建自己的实现之前， 请检查所需操作是否已在oneAPI库中可用。

oneDPL 和 oneMKL 示例执行相同的操作序列： 从时钟获取随机数种子，初始化随机数引擎， 选择所需的随机数分布，然后生成随机数。幸运的是， SYCL 库包含许多标准 C++ 函数 的替代方法，包括生成随机数的函数。的第18章（库）以了解支持的函数概述。这里提供了一个简单的示例， 以说明从 SYCL kernel 中 调用不受支持的函数时会发生什么。一些标准的 C++ 函数可以在 SYCL kernel 中调用，但并非所有函数都可以。, 但在 GPU 设备上没有 SYCL 等效函数。

oneAPI 工具包提供了几个库， 可以通过提供专门的 API 简化编程过程， 用于优化应用程序。本节提供了使用库的步骤， 包括代码示例，用于应用程序加速。有关每个库的详细信息，包括可用的 API， 请参阅特定库的主要文档。

这将防止需要传输输入 buffer，但是 kernel 的内存占用将会增加， 因为所有的输出 buffer 必须同时驻留在 context 中，而在之前使用相同 queue 的方法中， 设备上的相同内存可以用于输出 buffer。在上面的示例中，kernel 的计算需求较低，所以整体执行时间主要由内存传输主导。需要注意的问题是，当一个 kernel 被提交到具有不同 context 的新 queue 时， JIT 过程会将 kernel 编译到与 context 关联的新设备。

这统一了用于CPU 的 Intel® Advanced Matrix Extensions (Intel® AMX)， 用于 GPU 的 Intel® Xe Matrix Extensions (Intel® XMX)， 以及 NVIDIA* Tensor Cores 等目标。然而，对于想要构建自己的神经网络应用程序的用户来说，这些库和框架太上层，因为用户无法进行自定义优化， 并且很臃肿，因为库的体积很大。此外，机器学习领域引入了新的操作并持续变化，对于这些操作， 框架和库没有提供及时和高效的解决方案。

context 是由用户直接构建的，或者在创建 queue 时隐式构建的， 用于保存 SYCL runtime 和 SYCL 后端操作设备所需的所有 runtime 信息。一般来说，创建一个新的 context 是一项繁重的操作， 因为每次向新 context 的 queue 提交 kernel 时，都需要 JIT 编译程序。上面的 kernel 被重写为下面的样子，其中在循环内部创建的新 queue 和循环外部的 queue 共享 context。在这种情况下，性能与一个 queue 的性能相同。

在这些情况下，不能保证打印到控制台的语句的特定顺序，您应该预料到来自不同 work-item 的语句被交错输出。SYCL* 提供了一些功能，以帮助使这项任务类似于标准的 I/O C/C++ 程序， 但是由于加速器的工作方式，您需要理解一些特性。类，让您可以从 kernel 内部向控制台打印信息， 也提供了一种简单的方式来调试简单问题，而无需求助于调试器。如果大小不足， 可能会导致语句不被打印，或者打印的信息比预期的少。当再次运行此程序时，我们可能会以完全不同的顺序得到输出，这取决于线程的执行顺序。

你可以在一个迭代空间上提交一个 kernel，这样就可以对指定的数据对象进行计算。在 oneAPI 卸载模型中，kernel 是执行计算的单元。本节将介绍与 kernel 编程、提交和执行相关的内容。

Intel® 数据中心 GPU Max 系列产品支持两种 GRF 模式：小 GRF 模式和大 GRF 模式。每个执行单元（EU）总共有 64 KB 的寄存器存储空间。在小 GRF 模式下， 一个 EU 中的单个硬件线程可以访问 128 个 GRF 寄存器，每个寄存器宽度为 64B。在这种模式下，每个 EU 可用的硬件线程数为 8。在大 GRF 模式下， 一个 EU 中的单个硬件线程可以访问 256 个 GRF 寄存器，每个寄存器宽度为 64B。在这种模式下，每个 EU 可用的硬件线程数为 4。

oneAPI 包括许多库，例如 oneTBB、oneMKL、oneDNN 和 oneVPL，这些库提供在各种加速器架构上运行的常见计算操作的高度优化版本。根据应用程序的需求，用户可以直接调用这些库中的函数，并获得针对底层架构的高效实现。这是开发并行程序最简单的方法， 前提是库中包含所需函数。通常的工作流程是用户从串行程序开始， 确定代码中执行时间较长的部分（称为热点），并将它们转换为可以部署到加速器上执行的并行kernel。像 OpenMP* 这样的基于指令的方法是另一种开发并行程序的方法。

三个关键概念决定了在加速器上的软件优化。你的优化工作应该遵循这些概念。

ND-Range kernel 的索引空间被划分为 work-group，sub-group 和 work-item。work-item 是最基本的单位。一组 work-item 组成一个 sub-group， 一组 sub-group 组成一个 work-group。work-item 和 work-group 到硬件向量引擎 (VE) 的映射是依赖于实现的。所有的 work-group 都同时运行，但根据资源的可用性，它们可能被安排在不同的时间运行。

传统上，GPU 用于创建计算机图形，例如 图像、视频等。由于具有大量执行单元以实现大规模并行性， 现代 GPU 也用于执行传统上在 CPU 上执行的计算任务。这通常称为 GPU 或 GPGPU 上的通用计算。许多高性能计算和机器学习应用程序 从 GPGPU 中受益匪浅。

这是由主机端提交的 kernel 在设备端开始执行的时间。由主机端发起的 kernel 提交和实际开始执行并不立即发生 - 它们是异步的， 因此我们必须跟踪与 kernel 相关的以下时间。这是因为在主机上完成 kernel 提交后， 设备端需要一些时间来准备执行 kernel，这取决于设备的可用性和 runtime 的调度策略。相同的代码，如果在 parallel_for 的末尾没有 wait()，那么它将测量主机端将 kernel 提交给 runtime 所需的时间。Kernel 提交的开始时间。

通常，work-item 需要共享数据并相互通信。一方面，所有 work-group 中的所有 work-item 都可以访问全局内存， 因此数据共享和通信可以通过全局内存进行。但是，由于其较低的带宽和较高的延迟， 通过全局内存进行共享和通信效率较低。另一方面， 在矢量引擎（VE）线程中同时执行的 sub-group 中的 work-item 可以非常高效地共享数据并相互通信， 但 sub-group 中的 work-item 数量通常较小，数据共享和通信的范围非常有限。

然而，寄存器空间有限，比内存空间小得多。如果没有足够的寄存器来保存所有变量，则寄存器可能会溢出， 或者当前在寄存器中的某些变量可以移动到内存中以腾出空间给其他变量。如果同一 sub-group 中的 work-item 共享私有 bin， 那么整个 sub-group 只需要 256 个私有 bin，或者每个 work-item 只需要 16 个私有 bin。如果 bin 的数量很大，例如大于 1024，即使私有 bin 在同一 sub-group 中共享， 也不会有足够的寄存器空间用于存储私有 bin。

这种累积是并行完成的，然后更新到 work-group 中所有 work-item 共享的数组中。此时，work-group 中的所有 work-item 使用 barrier 在彼此之间同步， 以在共享内存中将中间结果减少到最终结果。这个 kernel 显式地创建了一个 work-group， 并将向量中所有元素的责任分配给 work-group 中的 work-item。在下面显示的 kernel 中，使用全局原子操作解决了相同的问题， 其中每个 work-item 使用它需要累积的值更新全局变量。

设计高性能异构计算软件需要开发者利用加速器（如GPU）的优势，并且需要与设计传统同构计算软件时不同的思考方式。你需要了解你的代码将在哪些硬件上运行，以及哪些特征会影响硬件性能。你的目标是构建的代码能够最大化硬件能力并且产生正确答案。oneAPI是一种跨行业的、开放的、基于标准的、统一的编程模型，为加速器架构提供了一种通用的开发体验。加速器的一个独特特征是它们增强了平台上主CPU的计算能力。使用加速器的主要好处是通过将软件分别部署到主机和加速器，这样可以在加速器上运行最佳的计算部分来提高整体的性能。

在某些情况下， 获得更高性能的代码的更好方法是显式地指定 work-group 的数量和大小，向编译器提供提示以获得良好性能。这将允许编译器提升 load 和 store 次序，从而为指令完成提供更多时间并获得更好的指令调度。展开的优点是执行的指令更少，因为循环不必迭代那么多次，从而节省了比较和分支的指令。下面的 kernel 使用了 restrict 指令，它向编译器提供了一个提示，即循环内访问的向量之间没有别名， 编译器可以像在前面的示例中手动完成的那样，将 load 提升到 store 之前。

在 SYCL 中，您可以为 nd_range kernel 选择 work-group 大小。work-group 的大小对计算资源，向量通道和 work-item 之间的通信的利用率具有重要影响。同一 work-group 中的 work-item 可能具有对 SLM 和硬件同步功能等硬件资源的访问权限， 这将使它们比跨 work-group 的 work-item 运行和通信更高效。因此， 通常应选择加速器支持的最大 work-group 大小。

在中, 我们了解到 SIMD 分歧会对性能产生负面影响。如果 sub-group 中的所有 work-item 执行相同的指令，则 SIMD 通道得到最大程度的利用。如果一个或多个 work-item 走了不同的路径，则两条路径都必须执行才能合并。分歧是由条件检查引起的，尽管并非所有条件检查都会导致分歧。一些条件检查，即使它们不会导致 SIMD 分歧，仍然可能是性能隐患。总的来说，移除条件检查有助于提高性能。

在下面显示的 kernel 中，work-group 中的每个 work-item 都参与归约网络， 最终将该 work-group 中的所有元素求和。在这个 kernel 中，每个 work-item 操作一定数量的向量元素， 然后 work-group 中的一个线程通过线性遍历包含中间结果的 SLM 将所有这些元素归约为一个结果。归约运算符是关联的，在某些情况下也是可交换的。下面的 kernel 与上面的类似，只是使用树形归约来减少 work-group 中所有 work-item 的中间结果。