OpenMP 中的"static"和"dynamic"计划有什么区别?

What's the difference between "static" and "dynamic" schedule in OpenMP?

本文关键字:什么 区别 计划 dynamic 中的 static OpenMP      更新时间:2023-10-16

我开始使用C++处理OpenMP。

我有两个问题:

  1. 什么是#pragma omp for schedule
  2. dynamicstatic之间有什么区别

请举例说明。

其他人已经回答了大部分问题,但我想指出一些特定的情况,其中特定的调度类型比其他类型更适合。调度控制循环迭代在线程之间的分配方式。选择正确的时间表会对应用程序的速度产生很大影响。

static调度意味着迭代块以循环方式静态映射到执行线程。静态调度的好处是,OpenMP运行时保证,如果您有两个迭代次数相同的独立循环,并使用静态调度用相同数量的线程执行它们,那么每个线程在两个并行区域中都将接收到完全相同的迭代范围。这在NUMA系统上非常重要:如果在第一个循环中接触到一些内存,它将驻留在执行线程所在的NUMA节点上。然后在第二个循环中,同一个线程可以更快地访问同一个内存位置,因为它将驻留在同一个NUMA节点上。

假设有两个NUMA节点:节点0和节点1,例如两个插槽中都有4核CPU的两个插槽Intel Nehalem板。然后线程0、1、2和3将位于节点0上,线程4、5、6和7将位于节点1:上

|             | core 0 | thread 0 |
| socket 0    | core 1 | thread 1 |
| NUMA node 0 | core 2 | thread 2 |
|             | core 3 | thread 3 |
|             | core 4 | thread 4 |
| socket 1    | core 5 | thread 5 |
| NUMA node 1 | core 6 | thread 6 |
|             | core 7 | thread 7 |

每个核心都可以从每个NUMA节点访问内存,但远程访问比本地节点访问慢(在Intel上慢1.5倍-1.9倍)。你运行这样的东西:

char *a = (char *)malloc(8*4096);
#pragma omp parallel for schedule(static,1) num_threads(8)
for (int i = 0; i < 8; i++)
memset(&a[i*4096], 0, 4096);

在这种情况下,如果不使用巨大的页面,4096字节是x86上Linux上一个内存页面的标准大小。此代码将使整个32KiB阵列a归零。malloc()调用只是保留虚拟地址空间,但实际上并不"接触"物理内存(这是默认行为,除非使用其他版本的malloc,例如像calloc()那样将内存归零的版本)。现在这个数组是连续的,但只在虚拟内存中。在物理内存中,一半将位于连接到套接字0的内存中,另一半位于连接到插槽1的内存中。这是因为不同的部分由不同的线程归零,并且这些线程位于不同的内核上,并且有一种叫做第一次触摸NUMA策略的东西,这意味着内存页被分配在第一次"触摸"内存页的线程所在的NUMA节点上。

|             | core 0 | thread 0 | a[0]     ... a[4095]
| socket 0    | core 1 | thread 1 | a[4096]  ... a[8191]
| NUMA node 0 | core 2 | thread 2 | a[8192]  ... a[12287]
|             | core 3 | thread 3 | a[12288] ... a[16383]
|             | core 4 | thread 4 | a[16384] ... a[20479]
| socket 1    | core 5 | thread 5 | a[20480] ... a[24575]
| NUMA node 1 | core 6 | thread 6 | a[24576] ... a[28671]
|             | core 7 | thread 7 | a[28672] ... a[32768]

现在让我们运行另一个类似的循环:

#pragma omp parallel for schedule(static,1) num_threads(8)
for (i = 0; i < 8; i++)
memset(&a[i*4096], 1, 4096);

每个线程将访问已经映射的物理内存,并且它将具有与第一个循环期间相同的线程到内存区域的映射。这意味着线程将只访问位于其本地内存块中的内存,这将是快速的。

现在假设第二个循环使用另一个调度方案:schedule(static,2)。这将把迭代空间"切割"成两次迭代的块,总共将有4个这样的块。将会发生的是,我们将有以下线程到内存的位置映射(通过迭代次数):

|             | core 0 | thread 0 | a[0]     ... a[8191]  <- OK, same memory node
| socket 0    | core 1 | thread 1 | a[8192]  ... a[16383] <- OK, same memory node
| NUMA node 0 | core 2 | thread 2 | a[16384] ... a[24575] <- Not OK, remote memory
|             | core 3 | thread 3 | a[24576] ... a[32768] <- Not OK, remote memory
|             | core 4 | thread 4 | <idle>
| socket 1    | core 5 | thread 5 | <idle>
| NUMA node 1 | core 6 | thread 6 | <idle>
|             | core 7 | thread 7 | <idle>

这里发生了两件坏事:

  • 线程4到7保持空闲,并且一半的计算能力丢失
  • 线程2和3访问非本地内存,并且它们将花费大约两倍的时间来完成,在此期间线程0和1将保持空闲

因此,使用静态调度的优势之一是它提高了内存访问的局部性。缺点是调度参数选择不当会破坏性能。

dynamic调度是在"先到先得"的基础上进行的。具有相同线程数的两次运行可能(而且很可能)产生完全不同的"迭代空间"->"线程"映射,这一点可以很容易地验证:

$ cat dyn.c
#include <stdio.h>
#include <omp.h>
int main (void)
{
int i;
#pragma omp parallel num_threads(8)
{
#pragma omp for schedule(dynamic,1)
for (i = 0; i < 8; i++)
printf("[1] iter %0d, tid %0dn", i, omp_get_thread_num());
#pragma omp for schedule(dynamic,1)
for (i = 0; i < 8; i++)
printf("[2] iter %0d, tid %0dn", i, omp_get_thread_num());
}
return 0;
}
$ icc -openmp -o dyn.x dyn.c
$ OMP_NUM_THREADS=8 ./dyn.x | sort
[1] iter 0, tid 2
[1] iter 1, tid 0
[1] iter 2, tid 7
[1] iter 3, tid 3
[1] iter 4, tid 4
[1] iter 5, tid 1
[1] iter 6, tid 6
[1] iter 7, tid 5
[2] iter 0, tid 0
[2] iter 1, tid 2
[2] iter 2, tid 7
[2] iter 3, tid 3
[2] iter 4, tid 6
[2] iter 5, tid 1
[2] iter 6, tid 5
[2] iter 7, tid 4

(当使用gcc时观察到相同的行为)

如果使用dynamic调度来运行来自static部分的示例代码,则保留原始位置的可能性仅为1/70(1.4%),发生远程访问的可能性为69/70(98.6%)。这一事实经常被忽视,因此实现了次优性能。

staticdynamic调度之间进行选择还有另一个原因——工作负载平衡。如果每次迭代所花费的时间与完成的平均时间大不相同,那么在静态情况下可能会出现高度的工作不平衡。以完成迭代的时间随迭代次数线性增长的情况为例。如果迭代空间在两个线程之间静态划分,则第二个线程的工作量将是第一个线程的三倍,因此在2/3的计算时间内,第一个线程将处于空闲状态。动态调度引入了一些额外的开销,但在这种特殊情况下,将导致更好的工作负载分布。一种特殊的dynamic调度是guided,其中随着工作的进行,每个任务都会得到越来越小的迭代块。

由于预编译的代码可以在各种平台上运行,如果最终用户能够控制调度,那就太好了。这就是为什么OpenMP提供了特殊的schedule(runtime)子句。对于runtime调度,类型取自环境变量OMP_SCHEDULE的内容。这允许在不重新编译应用程序的情况下测试不同的调度类型,还允许最终用户根据其平台进行微调。

我认为误解源于您错过了关于OpenMP的要点。在一句话中,OpenMP允许您通过启用并行性来更快地执行程序。在程序中,可以通过多种方式启用并行性,其中之一就是使用线程。假设你有和数组:

[1,2,3,4,5,6,7,8,9,10]

并且您希望将该数组中的所有元素递增1。

如果您要使用

#pragma omp for schedule(static, 5)

这意味着将向每个线程分配5个连续迭代。在这种情况下,第一个线程将使用5个数字。第二个将需要另外5个,依此类推,直到没有更多的数据要处理或达到线程的最大数量(通常等于内核的数量)。工作负载的共享是在编译期间完成的。

在的情况下

#pragma omp for schedule(dynamic, 5)

工作将在线程之间共享,但此过程将在运行时发生。因此涉及更多的开销。第二个参数指定数据块的大小。

由于对OpenMP不太熟悉,我可能会认为,当编译的代码将在与编译代码的系统具有不同配置的系统上运行时,动态类型更合适。

我推荐下面的页面,其中讨论了用于并行化代码的技术、前提条件和限制

https://computing.llnl.gov/tutorials/parallel_comp/

其他链接
http://en.wikipedia.org/wiki/OpenMP
C中openMP中静态和动态调度的区别
http://openmp.blogspot.se/

循环分区方案不同。静态调度器将N个元素上的循环划分为M个子集,然后每个子集将严格包含N/M个元素。

动态方法动态计算子集的大小,如果子集的计算时间不同,这可能很有用。

如果计算时间变化不大,则应使用静态方法。