為什么 OpenMP 減少在共享內存結構上比 MPI 慢？

Question

我試圖測試兩個向量的內積（元素值是動態計算的）的 OpenMP 和 MPI 並行實現，並發現 OpenMP 比 MPI 慢。 我使用的 MPI 代碼如下，

#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <omp.h>
#include <mpi.h>


int main(int argc, char* argv[])
{
    double ttime = -omp_get_wtime();
    int np, my_rank;
    MPI_Init(&argc, &argv);
    MPI_Comm_size(MPI_COMM_WORLD, &np);
    MPI_Comm_rank(MPI_COMM_WORLD, &my_rank);

    int n = 10000;
    int repeat = 10000;

    int sublength = (int)(ceil((double)(n) / (double)(np)));
        int nstart = my_rank * sublength;
        int nend   = nstart + sublength;
    if (nend >n )
    {
           nend = n;        
       sublength = nend - nstart;
    }   


        double dot = 0;
    double sum = 1;
    
    int j, k;
    double time = -omp_get_wtime();
    for (j = 0; j < repeat; j++)
    {
                double loc_dot = 0;
            for (k = 0; k < sublength; k++)
            {
            double temp = sin((sum+ nstart +k  +j)/(double)(n));
            loc_dot += (temp * temp);
           }
        MPI_Allreduce(&loc_dot, &dot, 1, MPI_DOUBLE, MPI_SUM, MPI_COMM_WORLD);
            sum += (dot/(double)(n));
    }
    time += omp_get_wtime();
    if (my_rank == 0)
    {
            ttime += omp_get_wtime();
        printf("np = %d sum = %f, loop time = %f sec, total time = %f \n", np, sum, time, ttime);
    }
        return 0;       
}

我已經嘗試了幾種不同的 OpenMP 實現。 這是我可以實現的不復雜且接近最佳性能的版本。

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


int main(int argc, char* argv[])
{

    int n = 10000;
    int repeat = 10000;


    int np = 1;
    if (argc > 1)
    {
        np = atoi(argv[1]);
    }
        omp_set_num_threads(np);
        
        int nstart =0;
        int sublength =n;

        double loc_dot = 0;
    double sum = 1;
     #pragma omp parallel
     {
    int i, j, k;
        
    double time = -omp_get_wtime();

    for (j = 0; j < repeat; j++)
    {
            #pragma omp for reduction(+: loc_dot)  
            for (k = 0; k < sublength; k++)
            {
            double temp = sin((sum+ nstart +k  +j)/(double)(n));
            loc_dot += (temp * temp);
           }
                #pragma omp single 
                {
           sum += (loc_dot/(double)(n));
           loc_dot =0;
        }
    }
    time += omp_get_wtime();
        #pragma omp single nowait
        printf("sum = %f, time = %f sec, np = %d\n", sum, time, np);
     }
   
   return 0;        
}

這是我的測試結果：

OMP
sum = 6992.953984, time = 0.409850 sec, np = 1
sum = 6992.953984, time = 0.270875 sec, np = 2
sum = 6992.953984, time = 0.186024 sec, np = 4
sum = 6992.953984, time = 0.144010 sec, np = 8
sum = 6992.953984, time = 0.115188 sec, np = 16
sum = 6992.953984, time = 0.195485 sec, np = 32

MPI
sum = 6992.953984, time = 0.381701 sec, np = 1
sum = 6992.953984, time = 0.243513 sec, np = 2
sum = 6992.953984, time = 0.158326 sec, np = 4
sum = 6992.953984, time = 0.102489 sec, np = 8
sum = 6992.953984, time = 0.063975 sec, np = 16
sum = 6992.953984, time = 0.044748 sec, np = 32

誰能告訴我我錯過了什么？ 謝謝！

更新：我為 OMP 編寫了一個可接受的 reduce 函數。 現在性能已經接近MPI的reduce功能了。 代碼如下。

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

double darr[2][64];
int    nreduce=0;
#pragma omp threadprivate(nreduce)


double OMP_Allreduce_dsum(double loc_dot,int tid,int np)
{
       darr[nreduce][tid]=loc_dot;
       #pragma omp barrier
       double dsum =0;
       int i;   
       for (i=0; i<np; i++)
       {
           dsum += darr[nreduce][i];
       }
       nreduce=1-nreduce;
       return dsum;
}

int main(int argc, char* argv[])
{


    int np = 1;
    if (argc > 1)
    {
        np = atoi(argv[1]);
    }
        omp_set_num_threads(np);
    double ttime = -omp_get_wtime();

    int n = 10000;
    int repeat = 10000;
        
     #pragma omp parallel
     {
        int tid = omp_get_thread_num();
    int sublength = (int)(ceil((double)(n) / (double)(np)));
        int nstart = tid * sublength;
        int nend   = nstart + sublength;
    if (nend >n )
    {
           nend = n;        
       sublength = nend - nstart;
    }   
        
    double sum = 1;
    double time = -omp_get_wtime();

    int j, k;
    for (j = 0; j < repeat; j++)
    {
                double loc_dot = 0;
            for (k = 0; k < sublength; k++)
            {
            double temp = sin((sum+ nstart +k  +j)/(double)(n));
            loc_dot += (temp * temp);
           }
           double dot =OMP_Allreduce_dsum(loc_dot,tid,np);
           sum +=(dot/(double)(n));
    }
    time += omp_get_wtime();
        #pragma omp master
        { 
       ttime += omp_get_wtime();
       printf("np = %d sum = %f, loop time = %f sec, total time = %f \n", np, sum, time, ttime);
    }
     }
   
   return 0;        
}

Answer 1

首先，此代碼對同步開銷（軟件和硬件）非常敏感，導致 OpenMP 運行時實現和低級處理器操作（例如緩存/總線效果）本身出現明顯的奇怪行為。 實際上，每 45 毫秒執行一次的基於j的循環的每次迭代都需要完全同步。 這意味着 4.5 us/迭代。 在這么短的時間內，需要減少和廣播在 32 個內核中傳播的部分和。 如果每個內核在共享原子位置累積自己的值，例如每個原子添加 60 ns（可擴展至強處理器上原子的實際開銷），則將需要32 * 60 ns = 1.92 us因為此過程在 x86 上按順序完成處理器到目前為止。 由於障礙，這個小的額外時間代表了總執行時間的 43% 的開銷！ 由於對原子變量的爭用，時序通常要差得多。 此外，屏障本身很昂貴（它們通常在 OpenMP 運行時中使用原子實現，但可以更好地擴展）。

由於隱式同步和復雜的硬件緩存效應，第一個 OpenMP 實現很慢。 實際上， omp for reduction指令在其區域的末尾和omp single執行隱式屏障。 減少本身可以通過多種方式實現。 ICC 的 OpenMP 運行時使用一個聰明的基於樹的原子實現，它應該可以很好地擴展（但並不完美）。 此外， omp single節會導致一些緩存行反彈。 實際上，結果loc_dot可能會存儲在更新它的最后一個內核的緩存中，而執行此部分的線程可能會在另一個內核上進行調度。 在這種情況下，處理器必須將緩存行從一個 L2 緩存移動到另一個緩存（或直接從 L3 緩存加載與硬件狀態相關的值）。 同樣的事情也適用於sum （它傾向於在內核之間移動，因為執行該部分的線程可能不會總是被安排在同一個內核上）。 最后，必須在每個核心上廣播sum變量，以便它們可以開始新的迭代。

最后一個 OpenMP 實現要好得多，因為每個線程都處理自己的本地數據，它只使用一個屏障（這種同步對於算法來說是強制性的）並且更好地使用緩存。 累積部分可能並不理想，因為所有內核可能會獲取先前位於所有其他 L1/L2 緩存中的數據，從而導致全對全廣播模式。 這種硬件操作幾乎不能擴展，但也應該是順序的。

請注意，最后一個 OpenMP 實現受到false-sharing 的影響。 實際上， darr項將連續存儲在內存中並共享相同的緩存行。 結果，當一個線程寫入darr ，相關的內核將請求緩存行並使位於其他內核上的緩存行無效。 這會導致內核之間的緩存線反彈。 然而，在當前的 x86 處理器上，緩存行是 64 字節明智的， double變量占用 8 字節，導致每個緩存行有 8 個項目。 因此，它減輕了緩存線彈跳的影響，通常為 8 個內核而不是 32 個內核。 話雖如此，項目打包有一些好處，因為每個內核只需要 4 個緩存行獲取來執行全局累積。 為了防止錯誤共享，可以分配一個（8 倍）更大的數組並在項目之間保留一些空間，以便每個緩存行存儲 1 個項目。 目標處理器上的最佳策略可能是使用基於樹的原子歸約，就像 ICC OpenMP 運行時使用的那樣。 理想情況下， sum減少和障礙可以合並在一起以獲得更好的性能。 這是 MPI 實現可以在內部執行的操作 ( MPI_Allreduce )。

請注意，所有實現都受到非常高的線程同步的影響。 這是一個問題，因為由於某些操作系統/硬件事件（網絡、存儲設備、用戶、系統進程等），某些核心上會定期發生某些上下文切換。 一個關鍵問題是任何現代 x86 處理器上的頻率縮放：並非所有內核都以相同的頻率工作，並且它們的頻率會隨着時間而變化。 由於障礙，最慢的線程會減慢所有其他線程的速度。 在最壞的情況下，某些線程可能會被動等待，使某些內核進入睡眠狀態（C 狀態），然后根據平台配置花費更多時間喚醒其他內核，從而進一步減慢其他內核的速度。

要點是：
代碼越同步，它的擴展性就越低，優化的難度就越大。