c – OpenMP和NUMA的关系?

前端之家收集整理的这篇文章主要介绍了c – OpenMP和NUMA的关系?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有一个双插槽Xeon E5522 2.26GHZ机器(禁用超线程)在 Linux内核3.0上运行ubuntu服务器支持NUMA.架构布局是每个插槽4个物理内核.
OpenMP应用程序在此计算机上运行,​​我有以下问题:

>当在NUMA机器感知内核上运行时,OpenMP程序是否会自动利用(即线程及其私有数据在执行时保存在numa节点上)?如果没有,可以做些什么?
>那么NUMA和每个线程的私有C STL数据结构呢?

解决方法

当前的OpenMP标准定义了一个布尔环境变量OMP_PROC_BIND,用于控制OpenMP线程的绑定.如果设置为true,例如
shell$OMP_PROC_BIND=true OMP_NUM_THREADS=12 ./app.x

那么OpenMP执行环境不应该在处理器之间移动线程.遗憾的是,关于如何绑定这些线程并且这就是OpenMP语言委员会中的特殊工作组正在解决的问题. OpenMP 4.0将带有新的envrionment变量和子句,允许用户指定如何分配线程.当然,许多OpenMP实现都提供了自己的non-standard methods to control binding.

仍然大多数OpenMP运行时都不是NUMA意识到的.他们会愉快地将线程分派给任何可用的cpu,您必须确保每个线程只访问属于它的数据.这方面有一些一般性的提示

>不要对(C/C++)/ DO(Fortran)循环并行使用动态调度.
>尝试初始化稍后将使用它的同一线程中的数据.如果你使用相同的团队大小和相同数量的迭代块运行两个separete parallel for循环,那么静态调度两个循环的块0将由线程0,块1 – 线程1执行,依此类推.
>如果使用OpenMP任务,请尝试初始化任务主体中的数据,因为大多数OpenMP运行时实现任务窃取 – 空闲线程可以从其他线程的任务队列中窃取任务.
>使用支持NUMA的内存分配器.

我的一些同事已经彻底评估了NUMA对不同OpenMP运行时的行为,并专门研究了NUMA对英特尔实施的意识,但这些文章尚未发布,因此我无法为您提供链接.

有一个名为ForestGOMP的研究项目,旨在为libgomp提供NUMA感知的直接替代品.也许你应该看一看.

猜你在找的C&C++相关文章