\section{ 本手法の利点と欠点}

CbCという特殊な処理系を使うことになるので、ソースの変更が
必要となる。現状では、C++には対応していない。

コードセグメントのテストをSingle core上とMulti core 上の
両方でテスト出来るので、Multi coreになれていなくても、
動作のテストが容易である。また、Multi core になれるための
準備、教育的ツールとして使うことも出来る。アルゴリズム
の正しさを並列実行とは別にテスト出来るのが利点である。

CellはヘテロなMulti Coreであり、
SPU では、その性能を活かすためには、特殊なアセンブラ命令、
例えば4つの浮動小数点の値の同時演算などを使用する必要がある。
これらは、gcc の拡張あるいはasmステートメントなどで使用する
ことができるが、他のアーキテクチャ上では動作しない。
従って、同じ機能を持つコードセグメントで代用してテスト
することになる。異なるアーキテクチャでの異なるコードセグメント
の同等性を直接テストすることは出来ない。

Many Core 向けのデータ分割、コード分割は自動ではないので、
試行錯誤することになる。必要な性能が出るかどうかは、
分割のために生じるコピーのコストなどの要素が関係し、
アーキテクチャに依存するのでSingle Core上のテストで
見積もることは難しい。

データ分割、コード分割が手動なので間違いが入りやすい。
FIFOスケジューラレベルで、Single Coreと同等な動作を
する場合は、このようなエラーを見つけるのは容易である。

しかし、非決定的な動作をする場合は、自明な動作比較をする
ことは出来ず、モデル検査などのコストの高い方法を使う
必要が出て来る。コードセグメントレベルのモデル検査は
実機上の同期動作との差があるので、正確ではない。

モデル検査のコストが重い場合は、スケジューラを挟む
部分を大まかにして状態数を減らす手法が使える。正確さは
落ちるが、高速に検査することが出来る。

スケジューラを挟む部分の変更は手動であり、マクロあるいは
スクリプトで生成する必要がある。