2010年10月27日水曜日

全体ミーティング

Query-Aware Partitioning for Monitoring Massive Network Data Streams の紹介

2010年10月15日金曜日

今期取る授業


5,6 W833 村田 ★機械学習
7,8 W531 古井 ★音声情報処理特論


1,2 W831 渡辺 オペレーティングシステム特論
3,4 W831 米田 フォールトトレラントシステム論
7,8 S321 原崎ほか (他専攻)通信システム論

2010年10月13日水曜日

[全体ミーティング]2010.10.13 (Wed.)

(個人的な話)
やはり練習していない発表では説明がしどろもどろになってしまう。
練習する機会がある発表はともかく、そうでない場合でもうまく発表できるようになりたい。

(StreamSR)
もっと詳しく説明すべき点はノートにまとめておいた。

(論文紹介)
もっとちゃんと読もう。次回発表続き。
Query-Aware Partitioning for Monitoring Massive Network Data Streams
Chain: Operator Scheduling for Memory Minimization in Data Stream Systems

2010年9月27日月曜日

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

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

2010年9月21日火曜日

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などで受け取る。

---

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

2010年8月30日月曜日

Springer LNCS camera-ready format

DASFAA2011で使用。
下記のURIからダウンロード可能。

www.springer.com/computer/lncs?SGWID=0-164-6-793341-0
LNCS Proceedings and Other Multiauthor Volumes - Using LaTeX2e

2010年8月2日月曜日

今後の研究を始める前に

今回の研究(StreamSR)は,自分の中ではもともと単なる演習であって,これ自体を研究として発表することになるとはまったく考えていなかった.そのため,十分に関連研究を調べたりしていないため,既存研究との位置づけおよび研究の価値について今一把握しにくいことになってしまった.

今後は,研究室で始めるあらゆることについて,それが研究につながる可能性が『少しでも』あれば,行動を始める前にとにかく関連研究を調べ,わからなければまずどのような研究があるか伺うところから始めたい.そしてこれから始めることが既存の研究に対してどのような位置づけになっているのか把握すること.

何もわからないまま実際に手を動かしてみるところから始めるのはとにかく避けたい

(さもないと論文で「研究の背景」や「関連研究」を書くときに苦労することになるので)