# HG changeset patch # User Shinji KONO # Date 1313051880 -32400 # Node ID 504aea3b42beb0fab0b048ef239eaa182268ead7 # Parent e62c3a6658138aba1ea1ceb52b8761d02f9fc05f fix diff -r e62c3a665813 -r 504aea3b42be paper/datasegment.ind --- a/paper/datasegment.ind Thu Aug 11 00:11:16 2011 +0900 +++ b/paper/datasegment.ind Thu Aug 11 17:38:00 2011 +0900 @@ -54,12 +54,24 @@ --C++ との相性 -Cerium の Task は、Cell のspuとppuで共通であり、同じ Task ID で管理されている。これは C++ のオブジェクトとは関係ない。Cerium の開発でわかったのは、Cerium のデータは、Actor の become 的\cite{Act3} に書き換えられるということである。 +Cerium の Task は、Cell のspuとppuで共通であり、同じ Task ID で管理されている。これは C++ のオブジェクトとは関係ない。Cerium の開発でわかったのは、Cerium のデータは、Actor の become 的\cite{Act3} に書き換えられるということである。C++のようなポインタを使い合わし、オブジェクトの内部の書き換えで状態を作るようなオブジェクト指向プログラミングと、細分化したTaskを並列に廻す Ceirum のようなシステムとの相性は良くない。 +Task の入力と出力は異なる場所に書かれる。処理は、常にダブルバッファを用いて行われているのでそのようになる。 + +--階層的パイプライン +プログラム中の自明な並列性は、データ並列とループのパイプラインの二つであり、パイプラインはプログラムの中で、様々なレベルで行われる。Task そのものは入力データから出力データを計算するだけなので単純だが、その入出力データをダブルバッファリングとして切替えたり、適切な並列度を得られるように徐々に生成するのは非常に繁雑になる。 +これらのデータの管理は、中心となるアルゴリズムとは別に並列実行を行うアーキテクチャに特化した処理が必要となる。例えば、分散環境で並列処理するのか、MPIなのか、Cell や Open CL なのかによって異なる。これらを、すべて Task という一括りで扱うと並列計算しない複雑なTaskができてしまう。 + +これらのデータ管理用の Task は、本質的には Data Segment に対する Iterator であり、ライブラリまたはコンパイラにより生成されるべきものだと考えられる。 --Data Segment を用いた Cerium の再設計 +Cell 用のTaskManager Cerium の再設計の方針としては以下のようになる。 + + CbCのCode segment の導入 + 定型的な Data 単位である Data + ---Data Segment の型 ---Data Segment のAPI