Openmpでの削減は、コード内の同じスレッド数で異なる結果を返します。

Question

openmpで "reduce"を使用している私のコードは、実行結果と同じ結果を返しません。

ケース1：使用して "削減"（ⅱ）FUNCと

sum = 0; 
omp_set_num_threads(4); 
#pragma omp parallel for reduction(+:sum) 
for(ii = 0; ii < 100; i++) 
    sum = sum + func(ii); 

は副作用があります。実際、func（ii）は並列実行で競合状態につながる可能性のある他のcalcul（）関数を使用します。私はcalcul（）関数がこの問題の原因になると思います。しかし、私は「クリティカル」を使用しますが、結果は常に同じですが、このソリューションはパフォーマンスにはあまり適していません。

ケース第2回：使用

func(int val) 
{ 
    read_file(val); 
    calcul(); /*calculate something from reading_file(val)*/ 
    return val_fin; 
} 

はそれを解決するために私を助けてくださいFUNC（ⅱ）機能付き

sum = 0; 
#pragma omp parallel for 
for(ii = 0; ii < 100; i++) 
{ 
    #pragma omp critical 
    sum = sum + func(ii); 
} 

"クリティカル"？

ありがとうございます！

Answer 1

コード内のすべてが正しい場合でも、操作（追加）の結合性のために、OpenMPの削減とは異なる結果が得られる可能性があります。 与えられたスレッド数に対して同じ結果を再現できるようにするには、共有配列の各スレッドの部分合計を格納して、自分で削減を実装する必要があります。並列領域の後で、マスタースレッドはこれらの結果を追加できます。このアプローチは、スレッドが常に同じ反復、すなわち静的スケジューリング・ポリシーを実行することを意味する。

関連質問： Order of execution in Reduction Operation in OpenMP

Answer 2

2番目のケースでパフォーマンスが低下する理由は、ループ本体全体がcriticalであるため、実際には何も並列に実行できません。

あなたには、いくつかの競合状態がcalcul機能であると言うので、ちょうどfunc内部のその行にcriticalセクションを置くことを検討してください。そうすることで、ファイルを並列に読み取ることができます（これは、実行を遅くするI/Oかもしれません）。

パフォーマンスがまだ悪い場合は、ネストされたcalcul関数を調べ、競合条件を特定する必要があります。

基本的には、criticalセクションを可能な限り押し下げるか、まったく削除する必要があります。共有変数を非常に簡単に更新する場合、代わりにOpenMP atomicプラグマを使用することができます。これはパフォーマンスは向上しますが、柔軟性は大幅に低下します。