ストリーム・プロセッシング
読者がJavaプログラマーなら"*"を"[]"で読み替えてくれればだいたい同じ意味になる。 ここでの問題点は、様々な属性がメモリ上に分散してしまうことである。キャッシュミスを発生させないようにするため、すべての "red" を書き換え、次にすべての "green" とすべての "blue" を書き換えなければならない。結果的にそれほど悪くないようにも見えるが、ストリームプロセッサが提供するものと比べると制約が強すぎる。
ストリームプロセッサに対しては、構造体を使うことが推奨されている。アプリケーションの観点から見ると、すべての属性が多少柔軟性を持って定義できる。 GPU を例とすると、多数の属性(最低でも16の)が利用できる。各々の属性について、アプリケーションはコンポーネントの数とフォーマット(現状は基本型のみがサポートされている)を宣言できる。次に、ある要素が点在しているのか連続しているのかを定義しながら、様々な属性がメモリブロックに割り当てられ、事実上インターリーブされたデータ形式を許容している。 GPU がストリームの処理を開始する際、すべての属性を単一のパラメータセット(大抵は、構造体や"魔法のグローバル変数"のような形式である)に集め、演算を実行し、次の処理(あるいは演算結果の回収)のためにメモリのどこかの領域に結果をばらまく。
まとめると、アプリケーション側にはより大きな柔軟性があるが、ストリームプロセッサ側では非常に秩序だった形式である。
一方、PentiumやAthlon64などの標準的なプロセッサは、64bit幅のデータバスをひとつ持っているだけである (訳注:2005年時点?)。
メモリアクセスのパターンもかなりの部分予測可能である。配列は存在するが、カーネルの呼び出しにおいて、メモリの配置は固定的である。複数レベルのポインタによる間接参照にほぼ対応するのはindirection chainであるが、これは最終的に(ストリーム内の)特定のメモリ領域を読み書きすることが保証されているものである。
ストリームプロセッサの実行ユニット (ALUクラスタ) はその SIMD 的な性質から、読み書きの操作はまとめて行われることになっており、メモリは低レイテンシよりも高バンド幅に最適化される (これはたとえば、RambusとDDR SDRAMの違いである)。これはメモリバスの調停を効率的にする。
ストリームプロセッサのほとんど (90%) の作業はチップ内で行われ、全体のデータの1%のみがメモリに格納される。これが、カーネルの一時的な記憶と、依存関係を明らかにすることにより得られるものである。
内部的には、ストリームプロセッサは通信や管理用の機能を備えるが、興味深いのは Stream Register File (SRF) である。これは概念的にはストリームデータを外部のメモリにバルク転送するために格納する大規模なキャッシュである。