Affinity part 2 - 系统拓扑结构和控制亲和性

Affinity part 2 - System topology and controlling affinity — ROCm Blogs (amd.com)

在 Part 1 的亲和性博客系列中，我们研究了为高性能计算 (HPC) 工作负载设置亲和性的重要性。在这篇博文中，我们的目标如下：

1. 推荐一些可以帮助你了解系统拓扑结构的工具

2. 讨论如何验证亲和性是否为你的运行正确设置

3. 展示如何为不同类型的应用程序设置亲和性

请注意，这里提供的工具和技术可能无法在你的系统上正常工作。这可能是由于不同的消息传递接口（MPI）实现，内核版本或新的系统配置。这些笔记作为参考，我们希望你能根据其中的思想并应用到你的系统设置中。

了解系统拓扑

在异构系统中，我们拥有不同类型的资源，例如CPU、GPU、内存控制器、NIC（网络接口卡）等。 有许多工具可以逐步帮助您了解系统上的非一致内存访问（NUMA）配置。在本节中，我们将展示一些工具的示例及其可以为我们提供的信息。

CPU 信息 - lscpu

lscpu 工具是 Linux® 发行版的一部分，它可以用于以易读的文本格式显示有关 CPU 架构的信息。下面是 lscpu 输出的一部分内容。需要注意的一些主要项包括系统上的插槽数量、每個插槽的物理核心数量、每个物理核心上的硬件线程 (HWT) 数量以及系统上配置的 NUMA 域。在每个 NUMA 域旁边是属于该域的物理核和 HWT 列表。在这种情况下，有 2 个插槽和 8 个 NUMA 域，这表明是 NPS4 配置。前 4 个 NUMA 域在插槽 0 中，接下来的 4 个 NUMA 域在插槽 1 中。

Thread(s) per core:  2
Core(s) per socket:  64
Socket(s):           2
NUMA node(s):        8
NUMA node0 CPU(s):   0-15,128-143
NUMA node1 CPU(s):   16-31,144-159
NUMA node2 CPU(s):   32-47,160-175
NUMA node3 CPU(s):   48-63,176-191
NUMA node4 CPU(s):   64-79,192-207
NUMA node5 CPU(s):   80-95,208-223
NUMA node6 CPU(s):   96-111,224-239
NUMA node7 CPU(s):   112-127,240-255

CPU NUMA 配置 - numactl

numactl工具是Linux系统的一部分, 可用于控制进程或共享内存的NUMA策略。它还可以用来显示哪些CPU核心或硬件线程(HWT)属于每个NUMA域。下面是`numactl -H`输出的示例。在这里可以看到，不同插槽中NUMA域之间的距离较大。

numactl -H
available: 8 nodes (0-7)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143
node 0 size: 64306 MB
node 0 free: 59767 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159
node 1 size: 64502 MB
node 1 free: 61327 MB
node 2 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175
node 2 size: 64502 MB
node 2 free: 61605 MB
node 3 cpus: 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191
node 3 size: 64447 MB
node 3 free: 61272 MB
node 4 cpus: 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207
node 4 size: 64502 MB
node 4 free: 52763 MB
node 5 cpus: 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223
node 5 size: 64502 MB
node 5 free: 54458 MB
node 6 cpus: 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239
node 6 size: 64502 MB
node 6 free: 57521 MB
node 7 cpus: 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255
node 7 size: 64492 MB
node 7 free: 55638 MB
node distances:
node   0   1   2   3   4   5   6   7 
  0:  10  12  12  12  32  32  32  32 
  1:  12  10  12  12  32  32  32  32 
  2:  12  12  10  12  32  32  32  32 
  3:  12  12  12  10  32  32  32  32 
  4:  32  32  32  32  10  12  12  12 
  5:  32  32  32  32  12  10  12  12 
  6:  32  32  32  32  12  12  10  12 
  7:  32  32  32  32  12  12  12  10 

GPU 信息 - rocm-smi

rocm-smi 工具是 ROCm™ 系列的一部分。`rocm-smi` 可用于显示系统上 GPU 的详细信息。看看下面的 rocm-smi 输出。它显示系统上有 8 个 AMD Instinct™ MI210 GPU。

===================== ROCm System Management Interface ===========================
=================== Concise Info ================================================
Device  [Model : Revision]    Temp    Power  Partitions      SCLK    MCLK     Fan  Perf  PwrCap  VRAM%  GPU%  
        Name (20 chars)       (Edge)  (Avg)  (Mem, Compute)                                                   
=======================================================================================
0       [0x0c34 : 0x02]       34.0°C  43.0W  N/A, N/A        800Mhz  1600Mhz  0%   auto  300.0W    0%   0%    
        Instinct MI210                                                                                        
1       [0x0c34 : 0x02]       39.0°C  42.0W  N/A, N/A        800Mhz  1600Mhz  0%   auto  300.0W    0%   0%    
        Instinct MI210                                                                                        
2       [0x0c34 : 0x02]       33.0°C  41.0W  N/A, N/A        800Mhz  1600Mhz  0%   auto  300.0W    0%   0%    
        Instinct MI210                                                                                        
3       [0x0c34 : 0x02]       38.0°C  42.0W  N/A, N/A        800Mhz  1600Mhz  0%   auto  300.0W    0%   0%    
        Instinct MI210                                                                                        
4       [0x0c34 : 0x02]       33.0°C  43.0W  N/A, N/A        800Mhz  1600Mhz  0%   auto  300.0W    0%   0%    
        Instinct MI210                                                                                        
5       [0x0c34 : 0x02]       35.0°C  42.0W  N/A, N/A        800Mhz  1600Mhz  0%   auto  300.0W    0%   0%    
        Instinct MI210                                                                                        
6       [0x0c34 : 0x02]       33.0°C  40.0W  N/A, N/A        800Mhz  1600Mhz  0%   auto  300.0W    0%   0%    
        Instinct MI210                                                                                        
7       [0x0c34 : 0x02]       39.0°C  42.0W  N/A, N/A        800Mhz  1600Mhz  0%   auto  300.0W    0%   0%    
        Instinct MI210                                                                                        
======================================================================================
================= End of ROCm SMI Log =============================================

GPU NUMA 配置 - rocm-smi --showtoponuma

rocm-smi --showtoponuma 可以帮助了解每个 GPU 的 NUMA 绑定。例如，在这里我们看到 GPU 0 最接近 NUMA 节点 3，并且从 lscpu 或 numactl 输出中，我们知道 NUMA 节点 3 包含的 CPU 核心/硬件线程是 48-63, 176-191。所以，在这个系统中，最好在诸如 48 核心上运行使用 GPU 0 的进程。

================= ROCm 系统管理接口 ============================
====================== Numa 节点=======================================
GPU[0]         : (拓扑) Numa 节点: 3
GPU[0]         : (Topology) Numa 亲和性: 3
GPU[1]         : (Topology) Numa Node: 2
GPU[1]         : (Topology) Numa Affinity: 2
GPU[2]         : (Topology) Numa Node: 1
GPU[2]         : (Topology) Numa Affinity: 1
GPU[3]         : (Topology) Numa Node: 0
GPU[3]         : (Topology) Numa Affinity: 0
GPU[4]         : (Topology) Numa Node: 7
GPU[4]         : (Topology) Numa Affinity: 7
GPU[5]         : (Topology) Numa Node: 6
GPU[5]         : (Topology) Numa Affinity: 6
GPU[6]         : (Topology) Numa Node: 5
GPU[6]         : (Topology) Numa Affinity: 5
GPU[7]         : (Topology) Numa Node: 4
GPU[7]         : (Topology) Numa Affinity: 4
======================= ROCm SMI Log日志结束 ===================================

节点拓扑 - lstopo

lstopo 是 Linux 上 hwloc 包的一部分，它可以以各种输出格式显示系统的拓扑结构。在下图中，我们看到表示节点上两个插槽的两个包。每个包有 4 个 NUMA 域。

放大到 NUMA 节点 1，如下图所示，我们看到它有 16 个 CPU 内核，每个内核有 2 个硬件线程（HWT），并通过 PCIe 接口连接一个 GPU。注意，8 个物理内核共享一个 L3 缓存。如果所有线程读取的数据都适合放在缓存中，将同一进程的线程放在同一个 L3 缓存区域中靠近在一起可以提高缓存重用率。

验证亲和性设置

在测量性能之前，检查是否设置了正确的亲和性总是一个好主意。以下是一些可以做到这一点的方法：

• 查看 top 或 htop 可以告诉我们进程及其线程运行在哪些CPU逻辑处理器（HWTs）上。

• 如果使用OpenMPI，可以使用 mpirun --report-bindings 来显示每个rank可能被放置的核心选择。

• 对于MPI + OpenMP® 程序，可以使用橡树岭国家实验室的领导计算设施（OLCF）提供的以下简单的“Hello, World”程序来检查映射: hello_mpi_omp

• 对于MPI + OpenMP + HIP程序，可以使用OLCF提供的带有HIP的简单“Hello, World”程序来验证映射: hello_jobstep

• Bob Robey的书《并行计算基础》第14章中的示例代码可以用于验证OpenMP、MPI和MPI+OpenMP情况的映射

在使用Slurm批处理命令运行作业时，最好在作业之前使用相同的Slurm配置运行上述之一的hello world程序，以验证亲和性设置。

设置亲和性

简单来说，设置亲和性就是选择在这次运行中进程和其线程将使用的CPU核心、GPU以及/或其他资源。在不同场景下，亲和性设置可能会有所不同。识别不同的情况并应用正确的方法是关键。在以下部分中，为不同情况展示了一组具有代表性的技术。请注意，每个工具可能提供更多功能，您可以针对您的使用情况进行利用。由于这些功能经常变化，最好始终参考各个工具的手册页。 

串行、单线程应用程序

如果您的应用程序仅在单个 CPU 核心上运行，那么一个快速的方法是使用基于 Linux 的 numactl 工具来固定进程。这是一个简单的例子，表明操作系统可以将进程调度到核心 1 或 2 上。

numactl -C 1,2 ./exe

提示: 由于核心 0 可能被操作系统用于处理中断和其他系统活动，为减少运行时的可变性，最好避免使用核心 0。

在下面的示例中，我们请求该进程的所有内存仅分配在 NUMA 节点 0 上。

numactl -C 1,2 -m 0 ./exe

串行、多线程应用程序

在本节中，我们将讨论使用 Pthreads 或 OpenMP 实现的多线程应用程序，并介绍一些可用于设置此类应用程序亲和性的工具。

为基于Pthreads的应用设置亲和性

可以使用`numactl`来固定进程及其线程，只需指定要绑定的核心范围。在下面的例子中，我们请求在核心1到7上运行可执行程序，并在NUMA节点0和1之间交错所有内存分配。

numactl -C 1-7 -i 0,1 ./exe

为基于OpenMP的应用设置亲和性

虽然`numactl`可以用在使用Pthreads或OpenMP构建的多线程应用上，OpenMP 5.2标准还规定了一些环境变量，可以结合使用这些变量来控制基于OpenMP的多线程应用的亲和性。下面是一些关键环境变量的说明。

• OMP_PLACES指示了用于进程及其线程放置的硬件资源。一些例子包括抽象名称，这些名称依赖于实现，例如`cores`、`threads`、`sockets`、`L3CACHE`或`NUMA`，或由非负数描述的明确的地方列表。考虑以下示例：

  • export OMP_PLACES=threads表示每个地方是一个硬件线程（HWT）

  • export OMP_PLACES={0,1} 表示在核心0和1上运行进程及其线程

  • export OMP_PLACES={0:$OMP_NUM_THREADS:2} 表示在核心`0, 2, 4, ... $OMP_NUM_THREADS`上运行进程及其线程

• OMP_PROC_BIND 指示如何将OpenMP线程绑定到资源。我们可以提供一个由逗号分隔的`primary`、`close`、`spread`或`false`列表，以指示嵌套级别并行的策略。

  • export OMP_PROC_BIND=close 表示将线程绑定在接近主要线程的位置

  • export OMP_PROC_BIND=spread 表示将线程均匀分布在指定位置

  • export OMP_PROC_BIND=primary 表示将线程绑定在与主要线程相同的位置

  • export OMP_PROC_BIND=false to 表示禁用线程亲和性

OpenMP 规范包含有关这些环境变量和其他变量的更多详细信息。

如果使用GNU OpenMP实现来构建应用程序，我们还可以使用环境变量`GOMP_CPU_AFFINITY`为进程及其线程设置亲和性。在下面的例子中，我们运行一个有16个线程的进程并将它们绑定到核心0, 4, 8, … 60。

export GOMP_CPU_AFFINITY=0-63:4
export OMP_NUM_THREADS=16
./exe

多进程（MPI），多线程应用

多进程应用程序使用MPI支持时，可以根据应用程序所构建的MPI实现或提交作业所使用的调度程序，采用多种进程放置、顺序和绑定选项。

OpenMPI 的 mpirun 命令提供了几个与亲和性相关的选项，如 --map-by 和 --report-bindings。mpirun 手册页 对这些选项和其他详细信息进行了广泛的记录。下面是使用OpenMPI 5.0.2运行4个MPI rank的示例，其中每个rank有2个OpenMP线程。在这里，我们混合使用了 mpirun 选项和OpenMP环境变量，以在NUMA域中分散每个rank的两个线程，并将每个rank保持在其自己的NUMA域中。

OMP_NUM_THREADS=2 OMP_PROC_BIND=spread mpirun -np 4 --map-by NUMA ./hello_mpi_omp

上面的示例还展示了运行hello_mpi_omp以通过编程方式验证绑定的操作。下面显示的示例输出是在拓扑结构类似于本文章节点拓扑 - lstopo部分中所描述的节点上获得的。在这里，我们看到每个MPI rank被固定到来自唯一NUMA域的两个硬件线程 (HWT)。

MPI 000 - OMP 000 - HWT 000
MPI 000 - OMP 001 - HWT 008
MPI 002 - OMP 000 - HWT 032
MPI 002 - OMP 001 - HWT 040
MPI 003 - OMP 000 - HWT 048
MPI 003 - OMP 001 - HWT 056
MPI 001 - OMP 000 - HWT 016
MPI 001 - OMP 001 - HWT 024

请注意，在某些情况下，`mpirun` 会自动将进程绑定到硬件资源，这有时可能会让人困惑。当您的绑定选项未能产生预期结果时，我们建议您参考 mpirun 手册页，并查找任何默认设置，例如在OpenMPI 5.0 手册中描述的那些。

Slurm 作业调度程序提供了一套丰富的选项来控制任务与硬件资源的绑定。有关所有这些选项的文档，请参见 srun 或 slurm.conf 的手册页。重要的是要注意，Slurm配置在每个站点有所不同，因此我们建议查看您站点系统管理员的建议。

MPICH 没有太多与亲和性相关的选项，但如果它是与Slurm集成构建的，则可以使用Slurm绑定在运行时设置亲和性。

CPU + GPU 混合应用

在使用 CPU 核心和 GPU 的混合应用中，我们需要额外控制每个进程到 GPU 设备的亲和性。默认情况下，所有进程都能看到所有的 GPU 设备。在这篇博客系列的第一部分中，我们已经看到了将进程映射到同一个 NUMA 域内的 GPU 设备和 CPU 核心的重要性。现在，我们将看看实现这一目标的不同方法。我们的目标是提供给你不同的技术，以便你可以确定哪些方法在你的系统上有效。

应用或库（如 MPI）可能使用 HIP 运行时或 ROCr 运行时（ROCm 栈中的低级运行时库）之一来构建。根据使用的运行时库，可以使用两个环境变量之一来设置 GPU 设备的亲和性。对 HIP 应用，可以使用环境变量 HIP_VISIBLE_DEVICES 来限制 HIP 运行时可见的 GPU 设备。在使用 OpenMP 目标卸载功能将计算卸载到 GPU 的应用中，可以使用环境变量 ROCR_VISIBLE_DEVICES 来限制 ROCr 运行时可见的 GPU 设备。注意，由于 HIP 运行时依赖于 ROCr 运行时，因此只能进一步限制 ROCR_VISIBLE_DEVICES 可见的 GPU 子集。

在一些 HPC 站点，提供了方便的 Slurm 绑定使得这种亲和控制变得轻松。Frontier 用户指南 提供了非常好的文档，介绍如何使用 Slurm 选项将进程及其线程映射到 Frontier 上的 CPU、GPU 和 NIC。

在某些情况下，当使用 OpenMPI 和 OpenMP 选项实现 CPU 绑定时，可以使用一个在实际可执行文件之前由 mpirun 运行的包装脚本来实现 GPU 亲和性。为了给你一个概念，下面是一个使用本地秩 ID 将 8 个进程映射到节点上 8 个 GPU 设备的简单包装脚本：

$ cat set_gpu_device.sh
#!/bin/bash
export HIP_VISIBLE_DEVICES=$OMPI_COMM_WORLD_LOCAL_RANK
exec $*

现在，假设与上一节相同的案例，在一个节点上运行 8 个 MPI 秩，每个秩运行 2 个 OpenMP 线程，我们可以用下面的命令同时映射 CPU 和 GPU：

OMP_NUM_THREADS=2 OMP_PROC_BIND=spread mpirun -np 4 --map-by NUMA ./set_gpu_device.sh ./hello_jobstep

注意这次我们运行的是hello_jobstep 程序来验证 CPU 和 GPU 的绑定。上述命令的输出显示每个秩使用了不同的 GPU 设备:

MPI 000 - OMP 000 - HWT 000 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 000 - OMP 001 - HWT 008 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 001 - OMP 000 - HWT 016 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 001 - OMP 001 - HWT 024 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 002 - OMP 000 - HWT 032 - RT_GPU_ID 0 - GPU_ID 2 - Bus_ID 03
MPI 002 - OMP 001 - HWT 040 - RT_GPU_ID 0 - GPU_ID 2 - Bus_ID 03
MPI 003 - OMP 000 - HWT 048 - RT_GPU_ID 0 - GPU_ID 3 - Bus_ID 27
MPI 003 - OMP 001 - HWT 056 - RT_GPU_ID 0 - GPU_ID 3 - Bus_ID 27

一个稍微扩展的脚本可以在 HPC Training Examples repository 中找到，它为更通用的情况（如在多节点上运行、在每个 GPU 设备上打包多个秩、跨越 OpenMP 线程或跨越 MPI 秩以均匀分布进程）设置 CPU 和 GPU 亲和性。由于这个脚本同时管理 CPU 和 GPU 亲和性设置，因此需要使用 mpirun --bind-to none 选项，而不是使用 OMP_PROC_BIND 设置或 --map-by mpirun 选项。这个脚本可以很容易地扩展到其他 MPI 环境，比如 MPICH 或 Slurm。下例是运行 16 个 MPI 秩，每个秩 8 个线程，在节点上有 8 个 GPU，所以每个 GPU 超额订阅了 2 个 MPI 秩：

OMP_NUM_THREADS=8 mpirun -np 16 --bind-to=none ./set_cpu_and_gpu_affinity.sh ./hello_jobstep

在上一个例子中运行 hello_jobstep 的部分输出如下，可看到 MPI 秩 0 和 1 在 GPU 0 上运行，MPI 秩 2 和 3 在 GPU 1 上运行，依此类推。秩 0 和 1 在 NUMA 域 0（核心 0-15）内紧密打包，每个线程使用一个物理核心。对于如该节点中的 NPS4 配置，为了获得完整的 CPU 内存带宽，我们需要将进程和线程均匀分布在两个插槽间。

MPI 000 - OMP 000 - HWT 000 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 000 - OMP 002 - HWT 002 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 000 - OMP 007 - HWT 007 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 000 - OMP 006 - HWT 006 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 000 - OMP 001 - HWT 001 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 000 - OMP 005 - HWT 005 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 000 - OMP 003 - HWT 003 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 000 - OMP 004 - HWT 004 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 001 - OMP 000 - HWT 008 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 001 - OMP 003 - HWT 011 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 001 - OMP 001 - HWT 009 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 001 - OMP 006 - HWT 014 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 001 - OMP 005 - HWT 013 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 001 - OMP 002 - HWT 010 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 001 - OMP 004 - HWT 012 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 001 - OMP 007 - HWT 015 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63
MPI 002 - OMP 000 - HWT 016 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 002 - OMP 006 - HWT 022 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 002 - OMP 002 - HWT 018 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 002 - OMP 004 - HWT 020 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 002 - OMP 005 - HWT 021 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 002 - OMP 003 - HWT 019 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 002 - OMP 007 - HWT 023 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 002 - OMP 001 - HWT 017 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 003 - OMP 000 - HWT 024 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 003 - OMP 001 - HWT 025 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 003 - OMP 002 - HWT 026 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 003 - OMP 004 - HWT 028 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 003 - OMP 003 - HWT 027 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 003 - OMP 006 - HWT 030 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 003 - OMP 005 - HWT 029 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
MPI 003 - OMP 007 - HWT 031 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43
<snip>

结论

亲和性是实现高性能计算（HPC）应用程序更好性能的重要考虑因素。设置亲和性需要了解系统的拓扑结构，并知道如何控制应用程序和系统的映射。在这篇博客中，我们向读者介绍了几种用于研究系统并相应控制亲和性、位置和顺序的工具和技术。本文绝不是阐述所有可能的亲和性控制方法的全面权威，而是展示了一些可能的方法。我们强调阅读所有这些工具的手册页的重要性，以找出适合您系统的方法。如果您有任何问题或意见，我们鼓励您参与Github讨论。

参考资料

• Frontier，首个百亿亿次级计算机

• Frontier用户指南，奥克里奇领导计算设施，奥克里奇国家实验室（ORNL）

• 平行和高性能计算，Robert Robey 和 Yuliana Zamora，Manning出版公司，2021年5月

• OpenMP 规范

• MPICH

• OpenMPI

• Slurm

• Ab Initio分子动力学CP2K代码的性能分析，Dewi Yokelson, Nikolay V. Tkachenko, Robert Robey, Ying Wai Li和Pavel A. Dub，_化学信息与建模杂志 2022 62 (10)_，2378-2386，DOI: 10.1021/acs.jcim.1c01538

• 平行计算入门，第14章代码示例

• ORNL的代码示例:

  • hello_mpi_omp

  • hello_jobstep

免责声明

OpenMP名称和OpenMP徽标是OpenMP架构审查委员会的注册商标。

HPE是Hewlett Packard Enterprise Company及其附属公司的注册商标。

Linux是Linus Torvalds在美国和其他国家的注册商标。