StreamGPU の落としどころとしては (A) と (B) の２つを考える。
(A) http://morita-k.blogspot.com/2009/10/sst-v2.htmlによると、GPU は 1024 に対して、圧縮なしの CPU と比較して 10倍くらいの差があるので、10倍の性能の コプロセッサが搭載されていると考えられる。ウィンドウサイズ 1024 の場合、１次元だと大体５秒以内で実現できているので、１分という異常検知の許容範囲があるとすると、１２次元ぐらいまではリアルタイム（１分）の検知が可能になる。ただし、これらのデータは既に示されているので、さらに (B) により, Contribution を突詰める
(B) CPU と GPU の性能の非対称差、および CPU の有効活用を考える。つまり、たとえば、１分という異常検知の許容範囲を考えると、GPU では 1024 というウィンドウサイズを１２次元測定でき、比較的長期間の異常検知の観測が可能になる。この間、CPU は、データを受信したり、CPU から GPU へのメモリ転送などの仕事があるのだが、基本的にはマルチコアの時代なので、アイドル状態のプロセッサが存在するので、それらを有効に活用したい。この空いた CPU を利用して、よりウィンドウサイズを小さくして、短期間および低レイテンシが要求される異常検知を行う。
次にやるべきことだが、 GPU 側は CULA で既に実現できてしまっているので、CPU を使った SST (IBM 高橋さんが実装済み）と合体して稼動させてみて性能特性を見る。CULA の SVD はブロッキングコールだと思われるので、スレッドから呼び出すように改良する。ただし、System S を使えば、CULA 呼び出し用 UDOP と CPU 上の SST 呼び出し UDOP ２つを独立に動かせば良いので、1つのストリームから Split させて同じデータを流し、Aggregate でためるウィンドウサイズを変え、両 UDOP に渡す実装にするだけで OK。まずは、これを実装する（両UDOP ができているので、基本的には実装コストは低いはず）。次に、性能特性を見る。特に、CPU 側の CPU 使用率を測定する。ここまではすぐに終わらせたい。肝心なのが次の実装と実験で、一番の Contribution と言える。
最適なウィンドウサイズの自動化。SLA (Service Level Agreement) で規定されている異常検知の許容最大値を L 秒 (例:60秒）、１台で検知しなければならない次元数を D 次元とする. L と D はパラメータであり、可変。あらかじめ、学習モードによって、http://morita-k.blogspot.com/2009/10/sst-v2.htmlで得られるような数値データを取得し、１次元あたりに L/D 秒 以下で抑えられる最大のウィンドウサイズを GPU 側と CPU 側、両者で決定する。この学習は実行時前に行うことによって、ウィンドウサイズを自動的に決定し、1CPU+1GPU で処理できるようなウィンドウサイズを決定して、実行する。これらをすべて自動的に行う。
以上。あとは、口答で説明します。
