Question

我在看问题omp parallel for loop (reduction to find max) ran slower than serial codes 我尝试运行提供的代码块（这是一个简化的副本）

#include <stdlib.h>
#include <time.h>
#include <stdio.h>
#include <omp.h>

int main()
{
    double sta, end, elapse_t;
    int bsize = 46000000;
    double *buffer = malloc(bsize * sizeof(double));
    int max_val = 0;

    srand(time(NULL));
    for (int i = 0; i < bsize; i++)
        buffer[i] = rand() % 10000;

    sta = omp_get_wtime();

#pragma omp parallel for reduction(max : max_val)
    for (int i = 0; i < bsize; i++) {
        max_val = max_val > buffer[i] ? max_val : buffer[i];
    }
    end = omp_get_wtime();
    printf("time %f\n", end - sta);

    free(buffer);
    return 0;
}

赞成：

gcc test.c -o test -O3 -fopenmp

由于最初的帖子是关于表演的，我注意到结果与跑步的结果非常不同，因此我不时地跑了200次并看了一下表演：

$ for i in `seq 200`; do ./test ; done | sort -u

正在给我：

time 0.025260
time 0.025261
time 0.025272
time 0.025319
time 0.025321
...
time 0.036945
time 0.037185
time 0.037988
time 0.039659
time 0.040315
time 0.040645
time 0.041171

所以你可以看到最慢的一次比最快的时间多50％，这是一见钟情。

有什么可以解释这个？

我尝试在450M设置bsize然后表现非常相似（+ - 5％），但我感到困惑：这是否意味着openmp性能是不可预测的，除非是非常大的东西？

编辑：

我的conf是Fedora Linux 26内核4.13.4-200.fc26.x86_64＃1 SMP Thu 9月28日20:46:39 UTC 2017 x86_64 x86_64 x86_64 GNU / Linux

没有特殊的环境变量（与openMP无关）

CPU

Intel（R）Core（TM）i3-5010U CPU @ 2.10GHz

典型的未分类样本是：

time 0.027549
time 0.026125
time 0.027008
time 0.026982
time 0.027888
time 0.025868
time 0.031977
time 0.044448
time 0.027515
time 0.032198
time 0.026162
time 0.025598
time 0.025791

编辑2：由于不同的评论，我最终意识到这个测试并不相关，特别是因为与任务调度可能引入的开销相比，时间确实很短。因此，我认为这个问题不相关，谢谢你的答案，对不起浪费我可能造成的时间。

Answer 1

你发布的时间非常小，因此很多其他因素都会进入游戏，而不仅仅是openmp。考虑使用大型数据集或多次重复循环（如果有意义）

另外，考虑到创建线程的开销可能无法补偿openmp pragma中的极其简单的循环体（只是在向量中搜索最大值）并且运行一次。

OpenMP随机性能？

1 个答案: