我正在尝试看看是否可以使用pthread_setaffinity_np()调用在OpenMP区域内设置亲和性,假设底层实现对OpenMP工作者使用了pthreads。在下面的示例代码中,设置亲和性的调用没有返回错误,sched_getcpu()调用也确认核心亲和性已正确设置。但是,与使用GOMP_CPU_AFFINITY环境变量设置亲和性相比,这种设置亲和性的方法会导致相当大的性能降级,这表明使用pthread_setaffinity_np()存在一些潜在问题。在OpenMP区域中使用pthread_setaffinity_np()有什么已知的问题吗?对于我的用例,我需要使用作为“主”的pthread,每个pthread将调用它自己的OpenMP区域,并且需要为各自的OpenMP区域显式地设置亲和性。
#pragma omp parallel for reduction(+:sum) num_threads(num_drones)
for (int i=start_N;i<end_N;i++){
if(set[omp_get_thread_num()] == 0) {
set[omp_get_thread_num()] = 1;
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(rank*num_drones+omp_get_thread_num(), &cpuset);
int error = pthread_setaffinity_np(pthread_self(), sizeof(cpuset), &cpuset);
if (error != 0) {
cout<< "\nError setting affinity";
abort();
}
} else if (set[omp_get_thread_num()] == 1){
set[omp_get_thread_num()] = 2;
assert(rank*num_drones+omp_get_thread_num() == sched_getcpu());
}
sum += v1[i];
}
发布于 2021-10-15 08:49:35
这是一个坏的想法。OpenMP运行时几乎肯定会基于它所建立的线程的亲和性来优化其内部算法和数据结构。(例如,使用分层屏障来最小化跨高速缓存和跨套接字通信)。你在那上面踩了一脚。
你说
我需要使用‘
’的pthreads,每个pthread都会调用它自己的OpenMP区域,并且需要显式地为各自的OpenMP区域设置亲和性。
然而,你还没有说任何关于,为什么,,你认为你需要这样做。
这感觉非常像一个经典的“我有一个问题,我不打算向你解释,但这是我的解决方案不起作用,所以请为我解决这个解决方案”的问题。
如果你解释一下你的真正的问题,我们也许能提供更多帮助……
(具体地说,使用OpenMP的机制明智地选择线程亲和性可能就足够了。参见Controlling OpenMP Thread Affinity)。
https://stackoverflow.com/questions/69576186
复制相似问题