0

私がほとんど知らないトピックについて質問して申し訳ありませんが、この考えは本当に私を悩ませており、インターネット上で答えを見つけることができませんでした.

背景: 私は、コンピューター サイエンスの研究をしている友人の 1 人と話していました。私は主にその場しのぎの開発を行っているため、CS の概念の大部分は機能レベルで理解しています (動作方法よりも使用方法を知っています)。彼は、単一のスレッドで実行されていた「十分に並列化された」アルゴリズムを複数のスレッドで実行されるアルゴリズムに変換しても、彼が期待していた処理速度の向上にはつながらなかったと述べていました。

理由: このアルゴリズムを実行しているコンピューターのアーキテクチャを尋ねたところ、16 コア (仮想化されていない) と答えました。マルチコア プロセッサについて私が知っていることによると、複数のコアで実行されるアルゴリズムの処理速度の向上は、並列化の程度にほぼ比例するはずです。

質問: 「十分に並列化」され、真のマルチコア プロセッサで実行するように正しくプログラムされたアルゴリズムが、数倍速く実行されないのはどうしてでしょうか? ここに欠けている情報がありますか、それとも実装に問題がある可能性が高いですか?

その他:スレッドが個々のコアが利用できるよりも多くの電力を消費している可能性があるかどうかを尋ねたところ、明らかに各コアは 3.4 GHz で動作していました。これは、アルゴリズムが必要とする量をはるかに超えており、診断が実行されている場合、実行時にコアが使い果たされることはありません。

4

2 に答える 2

2

何かを共有している可能性があります。何が共有されているかは明らかではないかもしれません。

最も一般的な非自明の共有リソースの 1 つは、CPU キャッシュです。スレッドが同じキャッシュ ラインを更新している場合、そのキャッシュ ラインは CPU 間でバウンスする必要があり、すべてが遅くなります。

これは、メモリ内で互いに近くにある (読み取り専用であっても) 変数にアクセスするために発生する可能性があります。すべてのアクセスが読み取り専用であれば問題ありませんが、そのキャッシュ ラインに書き込みを行っている CPU が 1 つでもあれば、バウンスが発生します。

これを修正する強引な方法は、共有変数を次のような構造に入れることです。

struct var_struct {
    int value;
    char padding[128];
};

128 をハードコーディングする代わりに、どのシステム パラメータまたはプリプロセッサ マクロがシステム タイプのキャッシュ ライン サイズを定義しているかを調べることができます。

共有が行われるもう 1 つの場所は、システム コール内です。一見無害に見える関数でさえ、グローバル ロックを取得している可能性があります。しばらく前に、プロセスとスレッドの識別子と親の識別子を返す関数をロックして、このような問題を修正する Linux について読んだことを思い出したようです。

于 2013-01-24T21:57:03.817 に答える
0

多くの場合、パフォーマンスとコアの数は S 字型の曲線です。最初は明らかに増加しますが、ロックや共有キャッシュなどの負担が大きくなると、コアを追加してもあまり増加せず、低下することさえあります。したがって、不思議なことは何もありません。アルゴリズムの詳細を知ることができれば、それを高速化するアイデアを見つけることができるかもしれません.

于 2013-01-24T20:17:59.170 に答える