11

PS3 での Cell プロセッサのプログラミングは、通常のデスクトップにある他のプロセッサのプログラミングとどう違うのですか?

セル プロセッサの可能性を最大限に活用するために、どのような種類のプログラミング パラダイム、テクニック、プラクティスが使用されていますか?

PS3 の開発に関して私が耳にするすべての記事は、「Cell Processor でのプログラミング方法の学習」について論じています。これは、手を振るだけでなく、実際には何を意味するのでしょうか?

4

4 に答える 4

18

ジョージが言及したすべてのことに加えて、SPU はストリーミング ベクトル プロセッサとしてより適切に考えられています。それらは、SPU にメモリのチャンクをロードさせ、それを操作してみて、それが必要であると判断するのではなく、DMA を介して SPU の限られたメモリを介して供給することができる、数値データの長いシーケンスで機能するアルゴリズムがある場合に最適に機能します。メモリ外のどこかへのポインターをたどる、それをロードする、続行する、別のポインターを見つける、など。

そのため、それらのプログラミングは並行性とスレッドの単純なモデルではありません。それは、高性能の数値計算または科学計算に似ています。また、極端な不均一なメモリ アクセスでもあります。

さらに、すべてのプロセッサは深いパイプラインで順序付けられているため、プログラマは、データの危険性と命令のバブル、およびコンパイラが処理する必要があると言われている多数のマイクロ最適化すべてについて、より多くの注意を払う必要があります (ただし、実際にはそうではありません）。分岐の予測ミス、ロード ヒット ストア、キャッシュ ミスなどは、そのようなレイテンシを隠すために操作の順序を調整できるアウト オブ オーダー プロセッサよりもはるかに多くの損害を与えます。

具体的な例については、Mike Acton のCellPerformanceブログをご覧ください。マイクは、私のお気に入りの昔ながらのアセンブリ好きで、この業界で好成績を収めている悪党であり、この問題で本当に腕を磨いています。

于 2009-08-31T05:12:28.757 に答える
14

PS3 のセル部分は、6 つの SPU プロセッサで構成されています。それらはそれぞれ 256 KB の非共有メモリを持ち、お互いと PowerPC ホスト プロセッサ間の DMA を可能にする高速リングを介して接続されています。それらはパイプライン化またはキャッシュされません。これは、共有メモリ、パイプライン、およびキャッシングを備えたマルチコア x86 とはかなり異なります。また、SPU プロセッサは PowerPC と同じ命令セットを使用しないため、非対称性があります。

要するに、典型的な共有メモリのマルチスレッド プログラムは、なんらかの作業なしで Cell に落とし込むことはできません (ただし、コンピュータ サイエンスはさまざまなマシンが同じように見えるように懸命に取り組んでいるため、一部の実装者はプロセスを自動化しようと懸命に努力しています)。 .

大まかに言えば、プログラムは、Cell のハード メモリ制限内に収まるタスクに分割する必要があります。これらは並行して実行でき、各サブタスクは利用可能な Cell プロセッサーにシーケンスできます。低レベルでは、コンパイラ (またはアセンブリ プログラマ) は、プロセッサ上で高速に実行されるコードを生成するために、より多くの作業を行う必要があります。処理を高速化するための実行時のトリックはありません。理論的には、これらのプログラマー/コンパイラーに優しい機能は、より多くのより高速な SPU を提供するために費やすことができるシリコンと速度にコストがかかるというものです。もちろん、PS3 でこれ以上 SPU を取得することはありませんが、一般的には、チップ上で使用可能なトランジスタの数ごとにより多くの SPU を取得できます。

于 2009-08-31T05:04:57.663 に答える
3

「PS3の開発に関して私が聞いたすべての記事は、 『Cell Processorでプログラミングする方法を学ぶ』について論じています。これは、手を振る以外に本当に何を意味するのでしょうか？」

さて、あなたがSPUで扱わなければならないもの...

  • 不可分操作（ロックフリーのtry-discardスタイル）。
  • メモリ領域間の強力な区別。どのポインタがどのメモリ領域を指しているかを知る必要があります。そうしないと、すべてが台無しになります。
  • データとコードの間に強制的なハードウェアの区別はありません。これは実際には楽しいことです。動的なコードの読み込みを設定し、基本的にサブルーチンを出し入れすることができます。自己変更コードは可能ですが、SPUでは必ずしも実用的ではありません。
  • ハードウェアデバッグ支援の欠如。
  • 限られたメモリサイズ。
  • 高速メモリアクセス。
  • SIMD操作に向けてバランスの取れた命令セット。
  • 浮動小数点「落とし穴」。

理想的には、SPUが常に有用な作業を実行し続けることを望んでいますが、それは非常に困難です。これらは、特定の種類の問題の処理に適していないだけでなく、多くの場合、システムをSPUで効率的に移動するには、完全な再設計が必要になる場合があります。PPUで簡単に検出できる問題のデバッグは、SPUで数日かかる場合があります。

人々が「細胞をプログラムする方法を学ぶ」というフレーズを使うとき、彼らはほとんど手を振っていると思います。1週間で基本を学ぶことができます。課題は、その知識を実際のコードに適用しようとすることです。これは、多くの場合、すでに存在し、SPUでの使用に適した形式ではありません。

于 2009-09-04T22:59:40.493 に答える
3

George Philips と Crashworks に完全に同意します。唯一付け加えておきたいのは、SPU プログラミングは基本的にジョブ管理に関するものだということです。SPU を最大限に活用するには、SPU を継続して結果をフィードバックする必要があります。座ってフレームの結果を待つ必要があり、残りの SPU がアイドル状態になっている場合、1 つの SPU が複雑な後処理を実行しても意味がありません。そのため、ジョブをどのように分散させるかには多くの検討が必要であり、これはデータをどのように分割するかに大きな影響を与えます。

于 2009-08-31T14:01:14.817 に答える