Cellマイクロプロセッサのソフトウェア開発には、 PowerPC互換のPPUコア向けの従来型の開発手法と、機能が縮小されたSPUコプロセッサに関する新たなソフトウェア開発上の課題が混在している。
Cell BEエコシステムの開発を加速し、GCCベースのCellコンパイラ、binutils、Linuxオペレーティングシステムの移植版を含むCellアプリケーション開発環境を提供するために、オープンソースソフトウェアベースの戦略が採用されました。[ 1 ]
Octopilerは、ソフトウェア開発者がCellプロセッサ用のコードを記述できるようにするためのIBMのプロトタイプコンパイラです。[ 2 ] [ 3 ] [ 4 ]
VMX (Vector Multimedia Extensions)技術は、概念的にはSPUプロセッサが提供するベクトルモデルと類似していますが、いくつかの重要な違いがあります。
VMX Javaモードは、デフォルトのIEEE標準規格のJava言語仕様1サブセットに準拠しており、Java標準規格で規定されていないIEEEおよびC9X規格への準拠も拡張されています。一般的な実装では、非Javaモードでは非正規化値をゼロに変換しますが、Javaモードではプロセッサがそのような値に遭遇するとエミュレータにトラップします。
IBM PPE Vector/SIMDマニュアルには倍精度浮動小数点演算に関する定義は記載されていませんが、IBMはCell PPE VMXテクノロジーに関連する特定の倍精度性能数値を示唆する資料を公開しています。
Cell 用のコンパイラは、 C および C++ で有用な SPU 命令を公開するための組み込み関数を提供します。オペランドの型のみが異なる命令(加算の場合は a、ai、ah、ahi、fa、dfa など)は、通常、オペランドの型に基づいて適切な命令を選択する単一の C/C++ 組み込み関数で表現されます。
IBM Powerマイクロプロセッサ、特にmacOSのPowerPC版向けに開発されたVMX( Altivec)コードの多くは、SPU上での利用に適応できる可能性がある。移植の実現可能性は、VMX固有の機能の使用状況によって異なり、容易なものから非現実的なものまで様々である。しかし、主要なワークロードは通常、SPUアーキテクチャにうまく適合する。
場合によっては、既存の VMX コードをそのまま移植できます。VMX コードが非常に汎用的(実行環境に関する仮定が少ない)であれば、変換は比較的簡単です。2 つのプロセッサは異なるバイナリ コード形式を指定しているため、少なくとも再コンパイルが必要です。同じ動作をする命令であっても、命令名が異なるため、これもマッピングする必要があります。IBM の開発ツールキットには、このマッピングの多くを自動化するコンパイラ組み込み関数が含まれています。
しかし、多くの場合、直接同等の命令は存在しません。回避策は明白な場合もあれば、そうでない場合もあります。たとえば、SPUで飽和動作が必要な場合は、追加のSPU命令をコーディングすることで実現できます(ただし、効率は多少低下します)。一方、Javaの浮動小数点演算が必要な場合は、SPUプロセッサではほぼ不可能です。SPUで同じ計算を実現するには、まったく異なるアルゴリズムをゼロから書き直す必要があるかもしれません。
VMXとSPUアーキテクチャの最も重要な概念的類似点は、同じベクトル化モデルをサポートしている点です。そのため、Altivecに適合したほとんどのアルゴリズムは、SPUアーキテクチャにも問題なく適合します。
異なるSPUのローカルストレージ間でデータを転送すると、パフォーマンスに大きな負荷がかかる可能性があります。個々のSPUのローカルストレージは、さまざまな戦略を用いて悪用される可能性があります。
密行列計算などの局所性の高いアプリケーションは、セルBEのローカルストアにとって理想的なワークロードクラスである。[ 5 ]
ストリーミング計算は、マルチバッファリング戦略を用いたメモリブロック転送のソフトウェアパイプライン処理によって効率的に処理できる。 [ 1 ]
ソフトウェアキャッシュはランダムアクセスに対する解決策を提供する。[ 6 ]
より高度なアプリケーションでは、異なるデータタイプに対して複数の戦略を使用することができます。[ 7 ]