Incremental GIM-V デバッグ中

igimv/proto3

submit_stream, ctcp_trigger.pyを実行
⇒ WorkerのprocessInput1 (stage==1) で、最初のmessageWW実行の後、処理が止まっている？

(追記)
PE の fusion を分けたらうまく動きそう。

(追記2)
4頂点5辺からなるグラフで、ページランクの計算に成功。

TODO:
・Managerの出力をみると、どこかでエラーが生じているらしい？要確認
・インクリメンタルに動作するかチェックする

(追記3 : 20110404 Mon.)
>Managerの出力をみると、どこかでエラーが生じているらしい？要確認
switch 文で break の書き忘れ。ログが冗長になるだけだったので、大した影響はなかった。
>インクリメンタルに動作するかチェックする
できた。

TODO:
・大きなグラフで実験（人工データ？作り方は、恣意的なものでよい？）
・igimv.dps をもとに gimv.dps を作成。動作比較

(追記4 : 20110404 Mon.)
頂点数10K, 辺数 448Kのグラフを、ワーカーノード4台で実行したところ、処理ができなかった。

理由を推測してみると、UDOPからUDOPに送るタプルが多すぎて、バッファが「デッドロック」のような状態に陥っているものだと思われる。

各Worker UDOPは同時に処理を開始し、一度の処理ブロックで最大で辺の数と同数のタプルを送る。
このとき、UDOPが送り先のオペレータの入力バッファが一杯になると、これ以上タプルを送れないので、バッファに空きができるまで待とうとする。
しかし、タプルを受け取ったオペレータはバッファの処理を行うことはない。
なぜならば、受け取った側のオペレータもまた、他のオペレータにタプルを送ろうとしている段階だからである。

===
MapReduceでは、MapとReduceが別スレッドで実行されている。
現状のigimv.dpsでは、Mapに相当する部分も、Reduceに相当する部分も、一つのUDOPにまとめてしまっているので、分けてしまうことで解決できるかも。