1

スーパースカラーのアウトオブオーダー CPU がドードーのようになり、大量のシンプルでスカラーのインオーダー コアに置き換わると予測するのが流行しているようです。ソフトウェアの並列化の問題が明日解決されたとしても、まだ大量のレガシー ソフトウェアが存在するため、これは実際には起こっていないようです。その上、ソフトウェアの並列化は些細な問題ではありません。

GPGPU は、CPU がシングル スレッド パフォーマンス用に設計され、グラフィックス カードが並列処理用に設計されたハイブリッド モデルであることは理解していますが、見苦しいモデルです。プログラマーは、グラフィックス カードで実行するコードを明示的に書き直す必要があります。私の理解では、グラフィックス カードの並列処理を効率的に表現することは、マルチコアの汎用 CPU を効率的に表現するよりもはるかに困難です。

すべての PC に 1 つまたは 2 つの「高価な」スーパースカラー アウトオブオーダー コアと 32 または 64 個の「安価な」コアが付属しているが、高価なコアと同じ命令セットを使用し、場合によっては同じ部分にあるハイブリッド モデルの何が問題なのかケイ素？オペレーティング システムはこの非対称性を認識し、順序が狂ったコアを最初にスケジュールし、最も優先度の高いスレッドをスケジュールします。この優先順位付けは、OS API を介してプログラマーに明示的に公開される場合もありますが、プログラマーは、スケジューリングの詳細を制御したい場合を除き、区別を気にする必要はありません。

編集:これがおそらくプログラミングに関連していないため投票を終了する場合、ここに反論があります:なぜそのようなモデルが良いアイデアなのか悪いアイデアなのか、そして彼らがそれにプログラムしたいと思うでしょう。

4

5 に答える 5

2

@aikigaeshi私の論文に言及してくれてありがとう。私はエール・パットの学生であり、実際にはクリティカルセクションの加速というタイトルの論文の最初の著者です。たくさんの研究の末、私たちはそのアイデアを思いつきました。実際、私は最近、これについて業界会議で主要な講演をしました。これが数年間それを研究した後の私の見解です：

@dsimcha、良い分析のために質問を2つの部分に分割する必要があります。

  1. 一部のコードを他のコードよりも高速に実行する機能が必要ですか？この質問は、より単純な質問につながります。あるコードは他のコードよりも重要です。重要なコードは、スレッドがコンテンツを含むコードとして定義しました。スレッドが実行を終了するためにコードの一部を争う場合、そのコードを高速化すると、現在コードを実行しているスレッドが高速化されるだけでなく、現在のスレッドを待機しているスレッドも高速化されるため、スレッドが待機しているコードは明らかに重要になります。実行を終了します。シングルスレッドカーネルは、すべてのスレッドがシングルスレッドの終了を待機する優れた例です。クリティカルセクションは、クリティカルセクションに入りたいすべてのスレッドが、前のスレッドがクリティカルセクションを終了するのを待たなければならない別の例です。このような重要なコードをより高速に実行することは、コードが競合しているときに本質的にパフォーマンスがより重要になるため、明らかに良い考えです。削減、負荷の不均衡、貸し出しスレッドの問題など、重要なコードにつながる可能性のある他のシナリオがあり、このコードをより速く実行すると役立つ場合があります。したがって、私がパフォーマンスの非対称性と呼ぶものが必要であると強く結論付けます。

  2. パフォーマンスの非対称性を提供するにはどうすればよいですか？同じシステムに大小のコアを一緒に配置することは、この非対称性を提供する1つの方法です。これは私が調査したアーキテクチャですが、非対称性を提供する他の方法を調査するには、多くの調査を行う必要があります。周波数スケーリング、クリティカルスレッドからのメモリ要求の優先順位付け、クリティカルスレッドへのより多くのリソースの提供は、すべて非対称性を提供するための可能な方法です。大小のコアアーキテクチャに戻る：私の調査では、タスクを大コアに移行するオーバーヘッドが、重要なコードを高速化することで得られるメリットによって相殺されたため、ほとんどの場合に実行可能であることがわかりました。詳細はスキップしますが、非常に興味深いトレードオフがいくつかあります。詳細については、私の論文または博士論文を読むことをお勧めします。

また、いくつかの重要な事実を指摘したいと思います。-ソフトウェアプログラムを変更せずにこの非対称チップ（ACMP）を活用できたので、アプリケーションプログラマーの作業が増えないことを証明できました。-OSの作業が難しいとは思いませんでした。数週間で自分でランタイムを実装しましたが、これは私の研究に非常に役立ちました。OsコミュニティでOSを変更することへの恐れがあることを理解しており、エンジニアリングリソースの価値を高く評価していますが、OSの変更が制限となることに同意しません。時間とともに克服されるその問題。

-並列プログラムを作成し、既存のプログラムを研究し、プロセッサの設計を研究し、大手企業で働いた1年後、私は実際にACMPが実際にプログラマーに役立つと確信しています。現在のモデルでは、プログラマーは並列プログラムを作成し、シリアルボトルネックを特定して、並列化されるまでハンマーで叩き、次のボトルネックに進みます。一般的に、ボトルネックはますます困難になり、収穫逓減が始まります。ハードウェアがボトルネックをより速く（魔法のように）実行する機能を提供する場合、プログラマーは並列パフォーマンスを取得するためにそれほど多くの時間を無駄にする必要はありません。並列化が容易なコードを並列化し、残りをハードウェアに任せることができます。

于 2011-05-10T07:54:38.807 に答える
2

W00t、なんて素晴らしい質問 = D

一見すると、2 つの問題があることがわかります。今のところ、引数を公開するときに、CPU バウンドの並列アプリケーションを検討することをお勧めします。

1 つ目は、オペレーティング システムに課される制御オーバーヘッドです。OS は、プロセスを実行する CPU にプロセスをディスパッチする責任があることを思い出してください。さらに、OS は、この情報を保持するデータ構造への同時アクセスを制御する必要があります。したがって、OS がタスクのスケジュールを抽象化するという最初のボトルネックが発生しました。これはすでに欠点です。

以下は良い実験です。CPU を多用するアプリケーションを作成してみてください。次に、atsar などの他のアプリケーションを使用して、ユーザー時間とシステム時間の統計を取得します。ここで、同時スレッドの数を変化させて、システム時間に何が起こるかを調べます。データをプロットすると、(そうではない) 無駄な処理の増加を把握するのに役立つ場合があります。

次に、システムにコアを追加すると、より強力なバスも必要になります。CPUコアは、計算を実行できるようにメモリとデータを交換する必要があります。したがって、コアが増えると、バスへの同時アクセスが増えます。複数のバスを備えたシステムを設計できると主張する人もいるかもしれません。はい、確かに、そのようなシステムが設計される可能性があります。ただし、コアによって使用されるデータの整合性を維持するために、追加のメカニズムを配置する必要があります。いくつかのメカニズムはキャッシュ レベルに存在しますが、プライマリ メモリ レベルに展開するには非常にコストがかかります。

スレッドがメモリ内のデータを変更するたびに、他のスレッドがこのデータにアクセスするときに、この変更を他のスレッドに伝播する必要があることに注意してください。これは、並列アプリケーション (主に数値アプリケーション) で通常行われるアクションです。

それでも、現在のモデルは醜いというあなたの意見には賛成です。そして、はい、プログラマーがビットの移動に全責任を負っているため、今日では GPGPU プログラミング モデルで並列処理を表現するのがはるかに難しくなっています。私は、メニーコアおよび GPGPU アプリケーション開発のための、より簡潔で高レベルの標準化された抽象化を期待しています。

于 2011-04-21T00:16:09.490 に答える
1

あなたの投稿は、問い合わせというより仮説のように読めます。このトピックは異種アーキテクチャとして知られており、現在活発な研究分野です。業界カンファレンスでは、ヘテロ戦略に関する興味深いワークショップや基調講演を見つけることができます。

http://scholar.google.com/scholar?q=heterogeneous+architectures&hl=en&btnG=Search&as_sdt=1%2C5&as_sdtp=on

すべての PC に 1 つまたは 2 つの「高価な」スーパースカラー アウト オブ オーダー コアと 32 または 64 個の「安価な」コアが付属しているが、高価なコアと同じ命令セットがあり、おそらく同じ部分にあるハイブリッド モデルの何が問題なのかケイ素？

それには何も「問題」はありませんが、多くの実際的な問題があります。たとえば、あなたはスレッドの優先順位によるスケジューリングについて言及していますが、これは、スケジューリングを適切に決定するために必要な多くの指標の 1 つにすぎません。最も優先順位の高いスレッドが、大きなコア キャッシュをあまり活用しないデータ ストリーミング アプリである場合はどうなるでしょうか? このストリーミング アプリを小さなコアでスケジュールすると、正味のシステム パフォーマンスが向上しますか?

于 2011-04-21T16:08:46.837 に答える
1

大規模なアーキテクチャ担当者の多くは、異種アーキテクチャが多くの可能性を示すという点で、実際にあなたに同意するでしょう。先日、 Yale Pattがこの役職に就いた講演を見て、次世代の成功するアーキテクチャは、多数の小さなコアで補われたいくつかの大きな高速コアで構成されると予測しました。あるグループは、このアイデアを使用して、重要なセクションで実行されているスレッドを移行できるより大きなコアを提供することで、同時実行のオーバーヘッドを実際に軽減しました。

于 2011-04-21T20:41:43.913 に答える
1

あなたのアイデアは、AMD の Fusion の計画によく似ています。AMD は GPU を CPU に統合しています。現在、これはIntelのAtomを置き換えることを目的とした低電力の低速設計用ですが、ラップトップチップに移行しています.

サーバーチップ用のAMDのブルドーザー設計が数年以内にFusionを使用し、おそらくブルドーザー浮動小数点ユニットを完全に置き換えるという噂はかなり信頼できると思います。

これらの GPU ユニットは同じ命令セットを使用していませんが、GPU が CPU に組み込まれているため、コンパイラ自体が、他のタイプの MMX/SSE ベクトル命令タイプであるかのように、GPU を自由に使用できることを考慮してください。

考えられる例は、浮動小数点数の C++ ベクトルで計算を行うループです。最適化を AMD-Whatever に設定したコンパイラは、マシン コードを記述してベクトル メモリを固定し、GPU プログラムを呼び出して結果を待つことができます。

これは、SSE の自動ベクトル化最適化が既に行っていることよりも少しだけ複雑です。データを XMM レジスターにロードし、操作を実行して、データをレジスターから分割して戻します。

于 2011-04-21T16:24:42.997 に答える