問題タブ [barrier]

目標は、実行時間とプロセス数を測定することです。

私は MPI の初心者で、どこかで行き詰まっています。

hello world プログラムを作成し、グローバル ランタイムをテストしたいと考えています。

システム時間を測定する前にすべてのプロセスが終了することを確認するためにバリアを使用しようとしましたが、セグメンテーション違反が発生します。

私のコード:

セグメンテーション違反が発生する理由を理解するのを手伝ってください。

アトミック、特に __sync_fetch_and_add を使用して、回転するスレッド バリアを実装しようとしています。https://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Atomic-Builtins.html

私は基本的に、pthread バリアに代わるものを求めています。約100のスレッドを並行して実行できるシステムでUbuntuを使用しています。

これは明らかな理由で機能しません (スレッドが bar=0 を設定する可能性があり、別のスレッドが無限の while ループに陥るなど)。ここで実装を見ました: C++11 アトミックを使用して (スピニング) スレッド バリアを記述しますが、複雑すぎるようで、pthread バリアよりもパフォーマンスが悪いと思います。

この実装では、バーのキャッシュ ラインがスレッド間でピンポンされるため、メモリ階層内でより多くのトラフィックが生成されることも予想されます。

これらのアトミック命令を使用して単純なバリアを作成する方法についてのアイデアはありますか? さらに、通信に最適なスキームも役立ちます。

Intel プロセッサのアウト オブ オーダー効果を実証するために、マルチスレッド プログラムを作成しました。プログラムはこの記事の最後に添付されています。期待される結果は、x が handler1 によって 42 または 0 として出力されたときです。ただし、実際の結果は常に 42 です。これは、アウト オブ オーダー効果が発生しないことを意味します。

コマンド「gcc -pthread -O0 out-of-order-test.c」でプログラムをコンパイルしました Intel IvyBridge プロセッサ Intel(R ) Xeon(R) CPU E5-1650 v2。

順不同の効果を見るために何をすべきか知っている人はいますか?

Linux カーネル コードから、preempt_enable()とpreempt_disable()はただbarrier():

理解できません。barrier()プリエンプションを無効または有効にするのにa だけで十分なのはなぜですか?

Elixir の (サイクリック) バリアの最もエレガントな実装は何ですか? 実装するアルゴリズム (頂点カラーリング) には、生成されたプロセスの待機フェーズ (「並列で同期的に実行」し、すべてのプロセスの結果を使用して終了条件をチェックする) を含むループがあり、アルゴリズム 5 の「6 色」です。 「分散コンピューティングの原則から、Ch。1.

ほとんどの参照は .NET、pthread、およびその他のスレッド関連の計算に関するものであるため、バリアが正しいパターンであるかどうかはわかりません。もっと「エリキシル」な方法があるかもしれません。

私はまだコードを持っていません(パターンを探しています)が、同じ問題の「遅い」バージョンを実装するコードは次のとおりです: https://codereview.stackexchange.com/questions/111487/coloring-trees-in-エリクサー

私が得たアイデアは、トップレベルのプロセス (グラフ ノードごとに 1 つのプロセスを生成するプロセス) を使用して、ノード プロセスを同期させるメッセージを送受信することです。ノード プロセスも相互に通信することに注意する必要があります。親は、最上位ループの 1 回の反復中に子にメッセージを送信します。ただし、複雑なのは、トップレベルがノードのメッセージを受信した後、すべてのノードが反復を実行する前にプロセスを続行しないことです (ほとんどの場合、末尾再帰を使用します)。そこでバリア機構を考えました。

ディスパッチ バリアをグローバル キューではなくカスタム キューに追加する必要があることをどこかで読みました。その正確な理由はわかりません。ありがとう。

私は最近、メモリバリアの cpu の推移性を読みましたが、著者は、一般的なバリアのみが推移性を保証できると強調しています。でも、よくわかりません。例えば：

X が CPU3 のキャッシュでステータスが変更され、Y が CPU2 のキャッシュでステータスも変更されたとします。

読み取りバリアの前に書き込みバリアを追加すると、CPU1 はそのストア バッファを CPU2 と共有します。（一般バリアとなります）

1) CPU1 はストアバッファに X(X=1) の値を設定します。

2) CPU2 は、ストア バッファ (共有ストア バッファ) から X の値を読み取ります。

3) CPU2 はストア バッファ (書き込みバリア) で X をマークし、無効化キューを読み取り、CPU3 からの無効化メッセージがないことを確認します (読み取りバリア)。

4) CPU2 は、X のキャッシュ ラインを無効から変更済みに変更したいので、無効化メッセージを CPU3 に送信します。

5) CPU3 は X の無効化メッセージを受信し、無効化キューに入れ、CPU2 に応答します。

6) CPU2 は応答を受信し、X = 1 をメモリまたはキャッシュに書き込み、Y == 0 をロードします。

...

7) CPU3 は、ジェネラル バリアを実行すると、無効化されたキューに X の無効化メッセージがあることを検出します。その後、X は 1 に等しくなければなりません。

わかります。ただし、perbook の図 14.3 から別の例を読みました。

アサートを発射する機会がいくつかあります。Quick Quiz 14.2 の回答で、すべてのバリアを smp_mb に変更すると修正できると著者は述べています。

では、私の質問は、なぜスレッド 1 のバリアを smp_mb に変更する必要があるのですか? スレッド 0 とスレッド 1 が CPU0 と CPU1 で実行され、それらがストア バッファを共有している場合です。スレッド 1 が Store C = 1 を実行した後、それらのストア バッファは吹き飛ばされます。

[A(wb)、B、C]

スレッド 2 (CPU2 で実行) もバリアの代わりに smp_mb を使用するため、C == 1 が表示される場合、A が 1 でなければならないことが保証されます。

上記のすべてを MESI メモリ コヒーレンシ プロトコルで説明します。作者は、CPU の推移性を保証するために、smp_mb の代わりにスレッド 1 にバリアを作成する別のプロトコルがあることを意味するのでしょうか?

誰か私に例を教えてください。

特定のプロトコルでの推移性について考えるのは間違いかもしれません。覚えておかなければならないことは、非常に多くの異なるプロトコルとアーキテクチャーがあるため、rmb() または wmb() は CPU の推移性を保証できないということです。