ストリーム処理

コンピュータサイエンスにおいて、ストリーム処理（イベントストリーム処理、データストリーム処理、分散ストリーム処理とも呼ばれる）は、ストリーム、つまり時間内のイベントのシーケンスを計算の中心的な入力オブジェクトと出力オブジェクトとして扱うプログラミングパラダイムである。ストリーム処理には、データフロープログラミング、リアクティブプログラミング、分散データ処理が含まれる。^[1]ストリーム処理システムは、データストリームの並列処理を公開することを目的としており、効率的な実装のためにストリーミングアルゴリズムに依存している。これらのシステムのソフトウェアスタックには、計算を表現するためのプログラミングモデルやクエリ言語、分散とスケジューリングのためのストリーム管理システム、浮動小数点ユニット、グラフィックス処理ユニット、フィールドプログラマブルゲートアレイなどの加速のためのハードウェアコンポーネントなどのコンポーネントが含まれる。^[2]

ストリーム処理パラダイムは、実行できる並列計算を制限することで、並列ソフトウェアとハ​​ードウェアを簡素化します。データのシーケンス (ストリーム)が与えられると、一連の操作 (カーネル関数) がストリーム内の各要素に適用されます。カーネル関数は通常パイプライン化され、外部メモリとのやり取りに関連する帯域幅の損失を最小限に抑えるために、最適なローカルオンチップメモリ​​の再利用が試みられます。1つのカーネル関数がストリーム内のすべての要素に適用される均一ストリーミングが一般的です。カーネルとストリームの抽象化によってデータの依存関係が公開されるため、コンパイラ ツールはオンチップ管理タスクを完全に自動化して最適化できます。ストリーム処理ハードウェアは、たとえばスコアボードを使用して、依存関係が判明したときにダイレクト メモリ アクセス(DMA) を開始できます。手動の DMA 管理がなくなることでソフトウェアの複雑さが軽減され、それに伴いハードウェア キャッシュ I/O もなくなることで、算術論理ユニットなどの特殊な計算ユニットによるサービスに伴うデータ領域の拡張が軽減されます。

1980 年代には、データフロー プログラミング内でストリーム処理が研究されました。一例として、 SISAL (Streams and Iteration in a Single Assignment Language) 言語があります。

ストリーム処理は、本質的には妥協であり、従来の DSP または GPU タイプのアプリケーション (画像、ビデオ、デジタル信号処理など) には非常にうまく機能するデータ中心のモデルによって駆動されますが、よりランダムなデータ アクセスを伴う汎用処理 (データベースなど) には適していません。モデルの柔軟性をある程度犠牲にすることで、より簡単で高速かつ効率的な実行が可能になります。状況に応じて、プロセッサ設計は、最大の効率性のために調整されるか、柔軟性とトレードオフされる可能性があります。

ストリーム処理は、次の 3 つのアプリケーション特性を示すアプリケーションに特に適しています。^{[引用が必要]}

• 計算強度、つまり I/O またはグローバル メモリ参照あたりの算術演算の数。今日の多くの信号処理アプリケーションでは、この値は 50:1 をはるかに超えており、アルゴリズムの複雑さとともに増加しています。
• 同じ関数が入力ストリームのすべてのレコードに適用され、以前のレコードの結果を待たずに多数のレコードを同時に処理できる場合、カーネルにはデータ並列性が存在します。
• データ ローカリティは、信号およびメディア処理アプリケーションで一般的な特定の種類の時間的ローカリティであり、データが 1 回生成され、アプリケーション内で後で 1 回または 2 回読み取られ、その後は読み取られません。カーネル間で渡される中間ストリームやカーネル関数内の中間データは、ストリーム処理プログラミング モデルを使用してこのローカリティを直接キャプチャできます。

ストリーム内のレコードの例は次のとおりです。

• グラフィックスでは、各レコードは三角形の頂点、法線、および色の情報になります。
• 画像処理では、各レコードは画像の 1 つのピクセルである可能性があります。
• ビデオエンコーダでは、各レコードは256ピクセルでデータのマクロブロックを形成する。
• 無線信号処理では、各レコードはアンテナから受信したサンプルのシーケンスになります。

各レコードに対して、入力から読み取り、それに対して操作を実行し、出力に書き込むことしかできません。複数の入力と複数の出力を持つことは許可されていますが、読み取りと書き込みの両方が可能なメモリは許可されていません。

例として、次のコード フラグメントは、イベント ストリーム内のパターンの検出を示しています。最初のコードは、継続的なSQLクエリ (タイムスタンプとウィンドウ期間に基づいて到着データを処理して永久に実行されるクエリ) を使用してデータ ストリームを処理する例です。このコード フラグメントは、株式注文用と結果の株式取引用の 2 つのデータ ストリームの JOIN を示しています。クエリは、注文が行われてから 1 秒以内に取引に一致するすべての注文のストリームを出力します。出力ストリームはタイムスタンプ (この場合は、注文ストリームのタイムスタンプ) で並べ替えられます。

SELECT DataStream Orders.TimeStamp 、Orders.orderId 、Orders.ticker 、Orders.amount 、Trade.amount FROM Orders JOIN Trades OVER ( RANGE INTERVAL ' 1 ' SECOND FOLLOWING ) ON Orders.orderId = Trades.orderId ;​​​​​​​​​​​​ 
     
    
 
       
   

別のサンプル コード フラグメントでは、教会の鐘が鳴る、タキシードまたはモーニング スーツを着た男性の登場、ゆらめく白いガウンを着た女性、空中を舞う米など、一連の外部「イベント」の中から結婚式を検出します。「複合」または「合成」イベントとは、個々の単純なイベントから推測されるもので、結婚式が行われています。

Person.Gender EQUALS "man"かつ、Person.Clothes EQUALS "tuxedo"の場合に、Person.Clothes EQUALS " gown "かつ、( Church_Bell OR Rice_Flying )が2時間以内に成立する場合、アクションはWedding です。       

     
    
  
 

基本的なコンピュータは、シーケンシャル実行パラダイムから始まりました。従来のCPUはSISDベースであり、概念的には一度に 1 つの操作のみを実行します。世界のコンピューティング ニーズが進化するにつれて、管理するデータの量が急速に増加しました。シーケンシャル プログラミング モデルでは、処理能力に対するニーズの増大に対応できないことは明らかでした。大量の計算を実行するための代替方法を見つけるためにさまざまな努力が払われましたが、唯一の解決策は、ある程度の並列実行を活用することでした。これらの努力の結果がSIMDです。これは、1 つの命令を複数の (異なる) データ インスタンスに適用できるプログラミング パラダイムです。ほとんどの場合、SIMD はSWAR環境で使用されていました。より複雑な構造を使用することで、MIMD並列処理も可能になりました。

これら 2 つのパラダイムは効率的でしたが、実際の実装では、メモリ アラインメントの問題から同期の問題、並列処理の制限まで、さまざまな制限がありました。スタンドアロン コンポーネントとして生き残った SIMD プロセッサはわずかで、ほとんどは標準 CPU に組み込まれました。

100 個の 4 成分ベクトル(つまり合計 400 個の数値) を含む 2 つの配列を加算する簡単なプログラムを考えてみましょう。

for ( int i = 0 ; i < 400 ; i ++ )結果[ i ] = source0 [ i ] + source1 [ i ];        
        

これは最もよく知られているシーケンシャル パラダイムです。バリエーション (内部ループ、構造など) は存在しますが、最終的にはその構造に集約されます。

for ( int el = 0 ; el < 100 ; el ++ ) // 各ベクトルに対してVector_sum ( result [ el ], source0 [ el ], source1 [ el ]);         
      

これは実際には単純化しすぎています。命令が機能することを前提としています。これは命令組み込み関数vector_sumで発生することですが、ベクトル コンポーネントの数やそのデータ形式など、多くの情報は実際には考慮されていません。これはわかりやすくするために行われます。

ただし、この方法では、デコードされた命令の数がnumElements * componentsPerElementからnumElementsに減っていることがわかります。ループの実行回数が少なくなるため、ジャンプ命令の数も減ります。これらの利点は、4 つの数学演算を並列実行することによって得られます。

しかし、パックされた SIMD レジスタには一定量のデータが保持されるため、それ以上の並列処理は不可能です。速度の向上は、4 つの並列操作を実行するという仮定によって多少制限されます (これはAltiVecとSSE の両方に共通であることに注意してください)。

//これはデモンストレーション用の架空の言語です。elements = array streamElement ([ number , number ])[ 100 ] kernel = instance streamKernel ( "@arg0[@iter]" ) result = kernel .invoke ( elements )    
   
  

このパラダイムでは、各コンポーネント ブロックを個別に定義するのではなく、データセット全体が定義されます。データセットの記述は、最初の 2 行にあると想定されます。その後、ソースとカーネルから結果が推測されます。簡単にするために、入力データと出力データは 1:1 でマッピングされていますが、これは必須ではありません。適用されるカーネルは、はるかに複雑になることもあります。

このパラダイムの実装では、ループを内部的に「展開」することができます。これにより、スループットをチップの複雑さに合わせて調整でき、数百のALUを簡単に利用できます。^{[3] [4]}複雑なデータパターンを排除することで、この余分な電力の多くを利用できるようになります。

ストリーム処理は SIMD/MIMD 処理の分岐ですが、混同しないでください。SIMD 実装は多くの場合「ストリーミング」方式で動作しますが、そのパフォーマンスは比較できません。モデルは、それ自体ではるかに優れたパフォーマンスを可能にする非常に異なる使用パターンを想定しています。

標準CPUなどの汎用プロセッサに適用した場合、1.5倍の高速化しか達成できないことが指摘されています。^[5]対照的に、アドホックストリームプロセッサは、主に効率的なメモリアクセスとより高いレベルの並列処理により、10倍以上のパフォーマンスを簡単に達成します。^[6]

モデルによって許容される柔軟性にはさまざまなレベルがありますが、ストリーム プロセッサは通常、カーネルまたはストリーム サイズに何らかの制限を課します。たとえば、コンシューマー ハードウェアには、高精度の計算を実行する能力が欠けていたり、複雑な間接チェーンが欠けていたり、実行できる命令の数に下限があったりすることがよくあります。

スタンフォード大学のストリーム処理プロジェクトには、1999年に開始されたスタンフォードリアルタイムプログラマブルシェーディングプロジェクトが含まれます。^[7] Imagineと呼ばれるプロトタイプは2002年に開発されました。^[8] Merrimacと呼ばれるプロジェクトは2004年頃まで実行されました。 ^[9] AT&Tも、グラフィックス処理ユニットが速度と機能の両面で急速に進化したため、ストリーム強化プロセッサの研究を行いました。 ^[1]これらの初期の頃から、数十のストリーム処理言語と専用のハードウェアが開発されてきました。

並列処理の分野で最も差し迫った課題は、使用するハードウェア アーキテクチャの種類ではなく、実際の環境で許容できるパフォーマンスで問題のシステムをプログラムすることがどれだけ簡単かということです。 Imagine などのマシンは、自動化された依存関係、メモリ割り当て、およびDMAスケジューリングを備えた単純なシングル スレッド モデルを使用します。 これ自体は、プログラマー、ツール、ハードウェア間のタスクの最適な階層化を見つけるための MIT とスタンフォードの研究の結果です。 プログラマーは、アルゴリズムを並列ハードウェアにマッピングすることに関してはツールに勝ち、ツールは最もスマートなメモリ割り当てスキームを見つけることなどに関してはプログラマーに勝ちます。 特に懸念されるのは、 Cellなどの MIMD 設計です。この設計では、プログラマーは複数のコアにわたるアプリケーションのパーティショニングや、プロセスの同期および負荷分散に対処する必要があります。

SIMD プログラミングの欠点は、構造体配列 (AoS) と配列構造体 (SoA)の問題でした。プログラマーは、次のように 3D 空間内の粒子の位置、ボールの色とサイズなど、エンティティの表現をメモリ内に作成することがよくあります。

 // 3次元空間の粒子。
struct particles_t { float x , y , z ; // 配列でもありません。unsigned byte color [ 3 ]; // チャネルあたり8ビット、ここではRGBのみを扱いますfloat size ; // ...その他多くの属性が続く場合があります... };  
                 
       
     
    

メモリ内にこれらの構造が複数存在する場合、それらは端から端まで配置され、構造配列(AoS) トポロジ内の配列を作成します。つまり、各粒子の位置に何らかのアルゴリズムを適用する場合、他の属性を含むメモリ位置をスキップする必要があります。これらの属性が必要ない場合、CPU キャッシュが無駄に使用されることになります。さらに、SIMD 命令では通常、操作するデータがメモリ内で連続していることが想定されるため、要素を揃える必要がある場合もあります。データのメモリ位置を構造の外に移動すると、ストリーム内での効率的なアクセスと SIMD 命令による操作のために、データをより適切に整理できます。以下に示す配列構造(SoA) を使用すると、これが可能になります。

struct particles_t { float * x 、* y 、* z ;符号なしバイト* colorRed 、* colorBlue 、* colorGreen ; float * size ; };  
       
        
     

構造体にデータを保持する代わりに、データのポインタ (メモリ位置) のみを保持します。欠点は、オブジェクトの複数の属性を操作する場合、それらの属性がメモリ内で離れているため、キャッシュ ミスが発生する可能性があることです。整列と必要なパディングにより、メモリ使用量が増加します。全体として、たとえば構造体が追加および削除されると、メモリ管理がより複雑になる可能性があります。

ストリーム プロセッサでは、構造体の使用が推奨されます。アプリケーションの観点からは、すべての属性をある程度柔軟に定義できます。GPU を参考にすると、使用可能な属性のセット (少なくとも 16 個) があります。各属性について、アプリケーションはコンポーネントの数とコンポーネントの形式を指定できます (ただし、現時点ではプリミティブ データ型のみがサポートされています)。その後、さまざまな属性がメモリ ブロックにアタッチされ、同じ属性の「連続する」要素間のストライドが定義され、インターリーブされたデータが効果的に許可されます。GPU がストリーム処理を開始すると、さまざまな属性がすべて単一のパラメータ セットに集められ(通常、これは構造体または「マジック グローバル変数」のように見えます)、操作が実行され、後で処理 (または取得) するために結果がメモリ領域に 分散されます。

より現代的なストリーム処理フレームワークは、データをリテラル ストリームとして構造化するための FIFO のようなインターフェイスを提供します。この抽象化により、データ依存関係を暗黙的に指定する手段が提供され、ランタイム/ハードウェアがその知識を最大限に活用して効率的な計算を行うことができます。現在までの C++ のストリーム処理方式の中で最も単純^{[引用が必要]}かつ最も効率的^{[引用が必要]なものの 1 つが}RaftLibです。これは、C++ ストリーム演算子を使用して、独立した計算カーネルをデータ フロー グラフとしてリンクできるようにします。例:

#include <raft> #include <raftio> #include <cstdlib> #include <文字列> 
 
 
 

クラスhi : public raft :: kernel { public : hi () : raft :: kernel () { output . addPort < std :: string > ( "0" ); }    


      
    
        
    

    virtual raft :: kstatus run () { output [ "0" ]. push ( std :: string ( "Hello World \n " )); return raft :: stop ; } };  
    
        
          
    


int main ( int argc , char ** argv ) { /** プリントカーネルをインスタンス化します **/ raft :: print < std :: string > p ; /** hello world カーネルをインスタンス化します **/ hi hello ; /** マップオブジェクトを作成します **/ raft :: map m ; /** カーネルをマップに追加します。hello と p は同時に実行されます **/ m += hello >> p ; /** マップを実行します **/ m . exe (); return EXIT_SUCCESS ; }    

    
       
    
     
    
     
    
        
    
    
     

ストリーミング アプリケーションを高級言語で指定する以外に、計算モデル (MoC) もデータフローモデルやプロセス ベース モデルとして広く使用されています。

歴史的に、CPU は、比較的ゆっくりと成長する外部メモリ帯域幅と比較してパフォーマンスが絶えず向上したため、さまざまなレベルのメモリ アクセス最適化を実装し始めました。このギャップが広がるにつれて、メモリ レイテンシを隠すために大量のダイ領域が割り当てられました。これらの少数の ALU に情報とオペコードを取得するのはコストがかかるため、実際の数学的機械に割り当てられるダイ領域はごくわずかです (大まかに見積もると、10% 未満と見なしてください)。

ストリーム プロセッサにも同様のアーキテクチャが存在しますが、新しいプログラミング モデルのおかげで、管理専用のトランジスタの量は実際にはごくわずかです。

システム全体の観点から見ると、ストリーム プロセッサは通常、制御された環境に存在します。GPU はアドイン ボード上に存在します (これは Imagine にも当てはまるようです)。CPU は、システム リソースの管理、アプリケーションの実行などの仕事を引き続き行います。

ストリーム プロセッサには通常、高速で効率的な独自のメモリ バスが装備されています (クロスバー スイッチは現在では一般的ですが、過去にはマルチバスが使用されていました)。メモリ レーンの正確な数は、市場の範囲によって異なります。この記事の執筆時点では、64 ビット幅の相互接続がまだ存在しています (エントリー レベル)。ほとんどのミッドレンジ モデルは、高速の 128 ビット クロスバー スイッチ マトリックス (4 または 2 セグメント) を使用し、ハイエンド モデルは、256 ビット幅のやや遅いクロスバーを使用して大量のメモリ (実際には最大 512 MB) を展開します。対照的に、Intel Pentiumから一部のAthlon 64までの標準プロセッサには、64 ビット幅のデータ バスが 1 つしかありません。

メモリ アクセス パターンははるかに予測可能です。配列は存在しますが、その次元はカーネルの呼び出し時に固定されます。複数のポインター間接参照に最も近いのは間接参照チェーンですが、これは最終的に特定のメモリ領域 (ストリーム内) から読み取りまたは書き込みを行うことが保証されています。

ストリーム プロセッサの実行ユニット (ALU クラスター) の SIMD 特性により、読み取り/書き込み操作は一括して発生することが予想されるため、メモリは低レイテンシではなく高帯域幅に最適化されます (これは、たとえば RambusやDDR SDRAMとの違いです)。これにより、効率的なメモリ バス ネゴシエーションも可能になります。

ストリーム プロセッサの作業のほとんど (90%) はオンチップで実行され、メモリに保存する必要があるグローバル データは 1% のみです。カーネルの一時データと依存関係を把握しておくと、ここで役立ちます。

内部的には、ストリーム プロセッサには巧妙な通信および管理回路がいくつか備わっていますが、興味深いのはストリーム レジスタ ファイル(SRF) です。これは概念的には、ストリーム データが外部メモリに一括転送されるために保存される大きなキャッシュです。さまざまなALUに対するキャッシュのようなソフトウェア制御構造として、SRF はさまざまな ALU クラスタ間で共有されます。スタンフォードの Imagine チップで実現された重要な概念と革新は、コンパイラがメモリを自動化し、最適な方法で割り当てることができ、プログラマに完全に透過的であることです。カーネル関数とデータ間の依存関係はプログラミング モデルを通じて認識され、これによりコンパイラはフロー分析を実行し、SRF を最適にパックできます。通常、このキャッシュと DMA 管理はプロジェクトのスケジュールの大部分を占めますが、ストリーム プロセッサ (少なくとも Imagine) はこれを完全に自動化します。スタンフォードで行われたテストでは、コンパイラは、多大な労力をかけて手動で調整した場合と同等かそれ以上にメモリのスケジュール設定を行えることが示されました。

証拠があります。クラスター間の通信はまれであると想定されるため、クラスターの数は多くてもかまいません。ただし、内部的には、クラスター内の通信が一般的であり、非常に効率的である必要があるため、各クラスターははるかに少ない量の ALU を効率的に利用できます。

これらの ALU にデータをフェッチし続けるために、各 ALU にはローカル レジスタ ファイル (LRF) が装備されています。これは基本的に使用可能なレジスタです。

この 3 層のデータ アクセス パターンにより、一時データを低速メモリから遠ざけることが容易になり、シリコン実装の効率と電力消費が極めて少なくなります。

1 桁の高速化は当然期待できますが (ストリーミング方式で計算する場合の主流の GPU からでも)、すべてのアプリケーションがこの恩恵を受けるわけではありません。通信遅延が実際に最大の問題です。PCI Express は全二重通信でこれを改善しましたが、GPU (およびおそらく汎用ストリーム プロセッサ) を動作させるには長い時間がかかる可能性があります。つまり、小さなデータセットに GPU を使用することは通常逆効果です。カーネルの変更はかなりコストのかかる操作であるため、ストリーム アーキテクチャは小さなストリームに対してペナルティも招きます。この動作はショート ストリーム効果と呼ばれます。

パイプライン処理は、ストリーム プロセッサで広く普及し、頻繁に使用される手法です。GPU のパイプラインは 200 ステージを超えます。設定の切り替えにかかるコストは、変更する設定によって異なりますが、現在では常に高価であると考えられています。パイプラインのさまざまなレベルでこれらの問題を回避するために、「ユーバー シェーダー」や「テクスチャ アトラス」などの多くの手法が採用されています。これらの手法は、GPU の性質上ゲーム向けですが、その概念は一般的なストリーム処理にも興味深いものです。

• Commodore AmigaのBlitterは、16 個のコンポーネント ビット ベクトルの 3 つのソース ストリームを 256 通り組み合わせて、16 個のコンポーネント ビット ベクトルで構成される出力ストリームを生成する機能を持つ、初期 (1985 年頃) のグラフィック プロセッサです。入力ストリームの合計帯域幅は最大 4200 万ビット/秒です。出力ストリームの帯域幅は最大 2800 万ビット/秒です。
• スタンフォード大学のウィリアム・ダリー教授が率いるイマジン^{[10]は、高速かつエネルギー効率の高い柔軟なアーキテクチャです。1996年に考案されたこのプロジェクトには、アーキテクチャ、ソフトウェアツール、VLSI実装、開発ボードが含まれており、} DARPA、インテル、テキサス・インスツルメンツの資金提供を受けていました。
• スタンフォード大学のもう一つのプロジェクトであるメリマック^[11]は、ストリームベースのスーパーコンピュータの開発を目指しています。メリマックは、ストリームアーキテクチャと高度な相互接続ネットワークを使用して、同じ技術で構築されたクラスターベースの科学コンピュータよりも単位コストあたりのパフォーマンスを向上させることを意図しています。
• スタンフォード大学のImagineプロジェクトから派生したStream Processors, Incの Storm-1 ファミリーが、ISSCC 2007の特別プレゼンテーションで発表されました。このファミリーには、30 GOPS から 220 16 ビット GOPS (1 秒あたり数十億回の演算) までの 4 つのメンバーが含まれており、すべてTSMCで 130 ナノメートル プロセスで製造されています。このデバイスは、ビデオ会議、多機能プリンタ、デジタルビデオ監視機器など、 DSP市場のハイエンドをターゲットにしています。
• GPUは広く普及している消費者向けストリームプロセッサ^{[2]で、主に}AMDとNvidiaによって設計されています。ストリーム処理の観点から注目すべきさまざまな世代があります。
  • R2xx/NV2x 以前: ストリーム処理に対する明示的なサポートはありません。カーネル操作はAPIに隠されており、一般的な使用には柔軟性が低すぎます。
  • R2xx/NV2x: カーネル ストリーム操作は、頂点処理のみに明示的にプログラマーの制御下に置かれました (フラグメントは依然として古いパラダイムを使用していました)。分岐サポートがないため柔軟性が大幅に低下しましたが、一部の種類のアルゴリズムは実行できました (特に、低精度の流体シミュレーション)。
  • R3xx/NV4x: 実行される操作の数、厳密な再帰の深さ、および配列操作には依然としていくつかの制限が存在しますものの、柔軟な分岐をサポートします。
  • R8xx: バッファの追加/消費とアトミック操作をサポートします。この世代は最先端です。
• HPC をターゲットとした製品ラインのAMD FireStreamブランド名
• Nvidia、 HPC をターゲットとした製品ラインのブランド名をTesla に変更
• ソニー・コンピュータエンタテインメント、東芝、IBMの連合企業であるSTIのCellプロセッサは、適切なソフトウェア サポートがあればストリーム プロセッサのように機能できるハードウェア アーキテクチャです。制御プロセッサである PPE (Power Processing Element、IBM PowerPC ) と、それぞれが独立したプログラム カウンタと命令メモリを備えた SPE (Synergistic Processing Elements) と呼ばれる一連の SIMD コプロセッサで構成されており、実質的にはMIMDマシンです。ネイティブ プログラミング モデルでは、すべての DMA とプログラム スケジューリングはプログラマに任されています。ハードウェアは、ローカル通信用にプロセッサ間に高速リング バスを提供します。命令とデータ用のローカル メモリは限られているため、このアーキテクチャを効果的に活用できるプログラムは、小さなメモリ フットプリントを必要とするか、ストリーム プログラミング モデルに準拠するかのどちらかです。適切なアルゴリズムを使用すると、Cell のパフォーマンスは純粋なストリーム プロセッサに匹敵しますが、これにはほぼ常にアルゴリズムとソフトウェアの完全な再設計が必要になります。

ストリーム プロセッサ用のプログラミング言語のほとんどは、Java、C、または C++ で始まり、アプリケーション開発者がカーネルやストリームにタグを付けられるように特定の指示を提供する拡張機能が追加されています。これは、ある程度ストリーム プログラミング言語と見なすことができる ほとんどのシェーディング言語にも当てはまります。

ストリーム プログラミング言語の非商用の例には次のものがあります。

• Ateji PX Free Editionは、ストリームプログラミング、アクターモデル、およびJVM上のMapReduceアルゴリズムの簡単な表現を可能にします。
• Auto-Pipe は、セントルイスのワシントン大学Stream Based Supercomputing Lab の製品で、ストリーミング アプリケーション用のアプリケーション開発環境です。異機種システム (CPU、GPGPU、FPGA) 用のアプリケーションの作成が可能です。CPU の場合は C、C++、Java の任意の組み合わせでアプリケーションを開発できます。FPGA の場合は Verilog または VHDL です。Nvidia GPGPU には現在 Cuda が使用されています。Auto-Pipe は、複数のマシン間の TCP 接続の調整も処理します。
• ACOTES プログラミング モデル: OpenMPに基づくカタルーニャ工科大学の言語
• BeepBeep は、ケベック大学シクーティミ校のフォーマル コンピュータ サイエンス ラボが開発した、シンプルで軽量な Java ベースのイベント ストリーム処理ライブラリです。
• スタンフォード大学のブルック言語
• CAL アクター言語: データ オブジェクト (トークン) の入力ストリームを出力ストリームに変換するステートフル オペレーターである (データフロー) アクターを記述するための高水準プログラミング言語。
• Cal2Many は、スウェーデンのハルムスタード大学のコード生成フレームワークです。CAL コードを入力として受け取り、シーケンシャル C、Chisel、Epiphany アーキテクチャをターゲットとする並列 C、Ambric アーキテクチャをターゲットとする ajava および astruct など、さまざまなターゲット固有の言語を生成します。
• ミュンヘン工科大学とデンバー大学のDUP言語
• HSTREAM: 異種ストリームコンピューティングのためのディレクティブベースの言語拡張^[12]
• RaftLib -セントルイスのワシントン大学のストリーム ベース スーパーコンピューティング ラボが開発したオープン ソースの C++ ストリーム処理テンプレート ライブラリ
• SPar -リオグランデドスル・ポンティフィカルカトリック大学のアプリケーションモデリンググループ (GMAP) による、ストリーム並列性を表現するための C++ ドメイン固有言語
• ウォータールー大学のShライブラリ
• Shallows、オープンソースプロジェクト
• ハートフォードシャー大学のS-Netコーディネーション言語は、コーディネーションとアルゴリズムプログラミングの分離を提供します。
• MITの StreamIt
• WSO2の Siddhi
• WaveScript 機能ストリーム処理も MIT 発です。
• 関数型リアクティブプログラミングは、広い意味ではストリーム処理と考えることができます。

商用実装は、汎用的なものか、ベンダーによって特定のハードウェアに結び付けられているもののいずれかです。汎用言語の例には、次のようなものがあります。

• MATLAB用GPUエンジンを商品化したAccelelerEyesのジャケット
• ストリームプログラミング、アクターモデル、MapReduceアルゴリズムのシンプルな表現を可能にするAteji PX Java拡張機能
• Embiot、Telchemy の軽量組み込みストリーミング分析エージェント
• Floodgate は、 PlayStation 3、Xbox360、Wii、PC 用のGamebryoゲーム エンジンに付属するストリーム プロセッサです。
• OpenHMPP、メニーコアプログラミングの「指示的」ビジョン
• PeakStream ^[13]ブルックプロジェクトのスピンアウト（ 2007年6月にGoogleに買収）
• IBM Spade - ストリーム処理アプリケーション宣言型エンジン (B. Gedik 他 SPADE: システム S 宣言型ストリーム処理エンジン。ACM SIGMOD 2008)
• RapidMind 、 Shの商用化(2009 年 8 月にIntelが買収)
• TStreams、^{[14] [15]}ヒューレット・パッカード・ケンブリッジ研究所

ベンダー固有の言語には次のものがあります。

• AMD / ATIのBrook+ (AMD ハードウェアに最適化されたBrookの実装)
• NvidiaのCUDA (Compute Unified Device Architecture)
• スループットコンピューティングのためのIntel Ct - C
• Stream Processors, Incの StreamC は、スタンフォード大学の Imagine 研究の商業化です。

イベントベースの処理

• Apama - Software AGによる複合イベントとストリーム処理エンジン
• ワラルー
• WSO2による WSO2 ストリーム プロセッサ
• アパッチニフィ

バッチファイルベースの処理（実際のストリーム処理の一部をエミュレートしますが、一般的にパフォーマンスははるかに低くなります^{[説明が必要] [引用が必要]}）

• アパッチカフカ
• アパッチストーム
• アパッチアペックス
• アパッチスパーク

連続オペレータストリーム処理^{[説明が必要]}

• アパッチフリンク
• ウォルマートラボMupd8 ^[16]
• Eclipse Streamsheets - ストリーム処理用のスプレッドシート

ストリーム処理サービス:

• Amazon Web サービス - Kinesis
• Google Cloud - データフロー
• Microsoft Azure - ストリーム分析
• Datastreams - データストリーミング分析プラットフォーム
• IBMストリーム
  • IBM ストリーミング分析
• SQLStreamBuilder イベント