[個別ミーティング]2010.09.27(Mon)

1. IC2010カメラレディ原稿の修正、提出
2. 全体ミーティング(2010.10.06(Wed))について
2.1. StreamSRについて紹介
2.2. 論文について簡単に（サマリーで）紹介。1論文あたり1スライド
2.3. 自分の興味について、その後の研究テーマを踏まえて

StreamSR : IC2010論文修正メモとか

冷静に考えると一括処理は逐次処理より優れているわけではない。

よく考えてみれば大事なのは「スレッド数」に対するスループットではなく「コア数」に対するスループットですし、逐次処理で1スレッド辺りのCPU使用率が下がるのならば、それに応じて1ノード（or1コア）に対するスレッド数を増やせばいいだけなので、「逐次処理はCPU使用効率が悪い」は明らかに誤りでした。

実際のところ、一括処理を選んだ理由はそのほうが実装が楽だったからにすぎない。
（libjuliusとSPADEの兼ね合いとか、ひとつの音声を複数タプルにわけて管理する面倒さとか）

可能ならば逐次処理で実装するべき。その方法としては、
1. libjuliusを使う
1.1. 認識処理をSPADE外部で実行し、source/sinkあるいはsource/UDOPなどで認識処理エンジンとやり取り
1.2. libjulius自体を大きく改造し、UDOP内でうまく連携できるようにする（困難）
2. libjuliusを使わず自前で認識エンジンを実装（困難）
など。

1.1. が割と楽な方法。
認識エンジンの管理をUDOPにさせるなどすればよい。
認識エンジンの出力はsourceなどで受け取る。

---

とりあえず、一括処理を採用した理由を論文中にどう書くべきか、うーむ。