D. schedule 句の使用

並列領域に末尾で1 文字以上のバリアがその中の追加をバリアいることもあります。各バリアでチームの他のメンバーは到着最後にスレッドを待機する必要があります。この待機時間を最小限に抑えるため共有作業はすべてのスレッドがバリアに到達してように配布する必要があります。一部のあるの共有作業が For の構造体に含まれている場合はschedule の句はこの目的で使用できます。

同じオブジェクトを繰り返し参照がある場合For の構造のスケジュールの選択はキャッシュの表示やサイズなどストレージ デバイスの特性に応じてメモリ アクセス時間が偶数または (Non-Uniform かどうかは主に従って決定されます。このような考慮事項はスレッドがループの作業が比較的少ない割り当てるスレッドを一連のループの配列の要素のセットを指定することによって一貫している可能性があります。これはすべてのループで同じ境界を持つ 静的 のスケジュールを使用してできます。次の例ではスケジュールが重要でない場合は K がわかりでも値が 2 番目のループに下限使用することに注意してください。

#pragma omp parallel
{
#pragma omp for schedule(static)
  for(i=0; i<n; i++)
    a[i] = work1(i);
#pragma omp for schedule(static)
  for(i=0; i<n; i++)
    if(i>=k) a[i] += work2(i);
}

残りの例ではすべてのスレッドが可能な計算のリソースを受信するとメモリ アクセスが最も優勢な考慮事項には異なり特に指定がない限りと仮定してください。この場合For の構造のスケジュールの選択は暗黙の最後のバリアまたは最も近い後続のバリア最も近い前のバリアとの間で発生するすべての共有作業して nowait の場合句は異なります。それぞれのスケジュールでそのスケジュールの種類が最善の選択であると考えられます方法を簡単な例を次に示します。短い説明は各例に示します。

静的 のスケジュールは最も単純な場合同じ作業量を必要としているイテレーションが For の一つの構造体を含む並列領域にも適しています。

#pragma omp parallel for schedule(static)
for(i=0; i<n; i++) {
  invariant_amount_of_work(i);
}

静的 のスケジュールには各スレッドが他のスレッドとイテレーションの数は約取得する各スレッドは独立して割り当てられたイテレーションを確認するにはプロパティによって表されるられ従って作業を配布する同期必要はありませんが各イテレーションが同じ作業量が必要な場合はすべてのスレッドが同時に終了すること。

p のスレッドのチームでは 切り上げた値を 使用します (n/pn =) は p*q -0 <= r\p <. で満たす ] 整数です *。*この例の 静的 スケジュールに 1 個の実装では最初の p-1 スレッドに q)および最後のスレッドに q-r の イテレーションを割り当てます。別の適切な実装では最初の p-r の スレッドに q の イテレーションを割り当てます残りの 右辺 に q-1 イテレーションです。これはプログラムの特定の実装の詳細と理由を使用しない方法について説明します。

動的 のスケジュールにはあるいは予測できない影響を必要とするイテレーションの For の構造の例に適した作業量です。

#pragma omp parallel for schedule(dynamic)
  for(i=0; i<n; i++) {
    unpredictable_amount_of_work(i);
}

最後のイテレーションを実行するにはスレッドのスケジュール 動的 の長さがバリアにプロパティを待たずによっては機能別のスレッドが付けられます。これは使用可能になったイテレーションの各割り当ての同期のスレッドは一度に割り当てる必要があります。同期のオーバーヘッドが大きい最小のチャンク k サイズ を 指定してk ほど残存までスレッドが サポートを 一度に割り当てるように1 より小さくできます。これはスレッドがバリアが長く待ってないというよりも保証されている) k の イテレーションの最後のチャンクを実行する別のスレッドを受け取ります。

同じ効果を各イテレーションのさまざまな作業量が多くなる 動的 のスケジュールはスレッドが別のコンピューティング リソースを受け取った場合に便利です。同様に動的なスケジュールはスレッドが別の場合に For の構造に到達する経路が されました のスケジュールが必要な場合があります。これらの状況の一部には便利な場合があります。

されました のスケジュールはスレッドがほぼ同じくらいの作業量が必要な各イテレーションで For の構造のさまざまな時にくる可能性がある場合に適しています。これが発生することがあります。たとえばFor の構造は nowait の句と For の一つ以上のセクションまたは構造体が付きます。

#pragma omp parallel
{
  #pragma omp sections nowait
  {
    // ...
  }
  #pragma omp for schedule(guided)
  for(i=0; i<n; i++) {
    invariant_amount_of_work(i);
  }
}

k チャンクのサイズを指定する最後のイテレーションを実行するには別のスレッドを使用するスレッドがバリアが長く待ってないという 動的 されました のスケジュールによりまたは Ultimate k の イテレーションです。このようなスケジュールでは されました のスケジュールはプロパティで少数の同期が必要です付けられます。チャンクのサイズ k は一般的な実装はすべてのイテレーションの割り当て ] = CEILING ( 割り当て ) n/p 最初の使用可能なスレッドへのイテレーションでは n-q と p*k に大きいためにn と繰り返しを設定します。

これらの例ではになるほど明確に最適なスケジュールの選択と ランタイム のスケジュールにプログラムを変更し再コンパイルしないでスケジュールチャンクのサイズの実験用に便利です。また最適なスケジュール (予測可能な方法で) するプログラムを適用する入力データによって場合に便利です。

異なるスケジュールの利点と欠点の例については次の 8 つがスレッド間の 1000 のイテレーションを共有することを検討してください。各時間の単位としてイテレーションと使用中の変更の処理量があるとします。

すべてのスレッドが同時に呼び出すと 静的 のスケジュールと構造体は同期なしで 125 単位実行します。ただし到着に 1 個のスレッドが遅い 100 単位と仮定します。次に残りの 7 種類のスレッドがバリアに 100 単位を待ち構造体全体の実行時間は 225 になります。

スレッドがバリアに複数の単位を待機しないことを 動的 と されました のスケジュールを確認するため遅延スレッドが 138 単位にだけ増加すると同期の遅延が乗算する構造体では実行時になります。このような遅延がわずかな場合が重要になります。 動的 が同期の数の 1000 が されました の 41 がであることは 1 個の既定のチャンクのサイズを前提としています。25 の両方のチャンクのサイズ 動的 と されました は40 と 20 だけに番号を付けて必要な同期の遅延の完了に 150 単位それぞれ。