鈴村グループ (旧・鈴村研究室) : 10月 2009

2009年10月31日土曜日

pin@clip: AR実証実験＠渋谷

http://pinaclip.jp/
このデータが研究用途として使えないかどうか、交渉しようと思います。

StreamAR

StreamAR (Augmented Reality) というカテゴリ＆プロジェクトを作りました。

中身はないですが、構想をいろいろ練っていきましょう

SPSS 2010 (Scalable Stream Processing System)

http://research.ihost.com/ssps/dates.html
締め切りはDecember 14, 2009, 　IPDPS の併設ワークショップという位置づけだが、ストリーム関連の研究者が一同に介するので、結構良いでしょう。何を出しましょうね？１０ページ分の Full Paper が要求されているので、それなりにまとまったテーマが必要ですね。まだ、結果は出ていませんが、StreamGPU のネタを出したいですね。

Submission Deadline: December 14, 2009

Notification of Acceptance: January 15, 2010

Camera-Ready Copy Due: February 1, 2010

Workshop: April 23, 2010

2009年10月30日金曜日

あと４日

某国際学会、論文締め切りまであと４日。ここまで短期間で書くのは初ですが、まあ、とりあえず、やれるところまでやりましょう。

テロリストとTwitter

FAS (Federation American Scientists) が出す調査報告書(PDF URL)に Twitter のテロリストの悪用のシナリオが書かれていて、話題にな　っているようですね。報告書の１１ページに書かれています。

2009年10月29日木曜日

緯度経度情報

StreamTwitter

老木君、もうご存知だとは思いますが、US の City 名からの緯度経度情報は以下から取れるようです。
http://www.realestate3d.com/gps/latlong.htm

ワッサー

http://wassr.jp/
Twitter のクローンらしい

SACSIS 2010

SACSIS 2010、来年は奈良（５月２７日から開催）です。１月１９日登録締め切りで、２６日が論文アップロード。ちょうど卒論のテーマがまとまるころだと思うので、森田君、松浦君と共に、これに出しましょう。国内ではレベルが高い学会なので、ちゃんとした成果が求められます。トラックは C ですね。
http://www.hpcc.jp/sacsis/2010/

ICWS 2010

http://conferences.computer.org/icws/2010/
によると、来年の ICWS (International Conference on Web Services) は７月に Florida で開催されるらしい。ICWS 2005 にも行ったが、そこと同じ会場でしょう。

論文投稿のスケジュールは以下のとおり。
Paper Submission Due Date: Feb. 15, 2010
Decision Notification (Electronic): April 15, 2010

LoadShedder を Twitterアプリに適応するところまでちゃんとできていたら、出したいですね。

鈴村自身は、Ajax アプリの高速化の話（２，３年前に考えていたアイデア）を論文化していないので、それを出す予定。

高速 JavaScript エンジン

StreamTwitter に関して

老木君、

ポストメッセージが多くなると、JavaScript による描画がボトルネックとなるとおっしゃっていましたが、Google Chrome の Browser で表示すると若干改善しませんか？
http://news.cnet.com/8301-1001_3-10030888-92.html

また、先日も言いましたが、JavaScript の JIT コンパイラがあり、最新の Firefox (3.5) にはそれが搭載されていると思います。
http://www.computerworld.jp/topics/browser/119609.html

ただ、それでも限界があると思われるので、Flash を試してみたいですね。開発環境 Adobe Flash CS4 Professional が良いようですが、Academic Editionはここによると３万ぐらいみたいですね。もし、本気でこちらの方に興味があるなら、これを購入したいと思いますが、まあ、どれだけ、GUI にこだわるかですね。

日本の Twitter ユーザー数はわずか全体の 0.71%

老木君、以下の統計データに注目してください。すごく参考になりますよ。

http://tweeter.jp/2009/08/14/twitter-743.html
http://tweeter.jp/2009/08/14/twitter-731.html

下図は国別データです。０９年６月のデータで１１５０万人のユーザーを対象にしたものらしいです。やはり、圧倒的に US が多いですね。日本はわずか 0.71%。まだまだですね。

所在地を記載している人の割合。

ちなみに、これらの統計情報は、Sysomos(http://www.sysomos.com/)という企業の Twitter に関する調査 (元ページ) が提供しているものですが、そこの冒頭を見ると、面白いことが書いてあります。

72.5% of all users joining during the first five months of 2009
85.3% of all Twitter users post less than one update/day
21% of users have never posted a Tweet
93.6% of users have less than 100 followers, while 92.4% follow less than 100 people
5% of Twitter users account for 75% of all activity (see the report on analysis of top-5% users)

特に一番下のデータは、やはりパレートの法則が成り立っており、5% の Twitter ユーザーが 75% のアクティビティを行っているのだそうです。

また、この記事によると、０６年の全世界のユーザー数は 4450万人だそうで、今年になって急激に伸びているようです。

他にも以下の URL に統計データがあります。
http://www.sysomos.com/insidetwitter/

時間ごとのアクティビティ。昼時が一番でしょうか。

土日はやはり少なめ。

１日のつぶやき回数
"85.3% of Twitter users update less than once/day; while 1.13% Twitter users update more than average of 10 times a day" だそうだ。

2009年10月28日水曜日

Google Wave サーバークローン

最近注目されている Google Wave のサーバークローンがあるんですね。
http://code.google.com/p/pygowave-server/

Twitter Streaming API を使ったアプリケーション

http://blog.hidekiy.com/2009/06/twitter-live-streaming.html
に Twitter の Streaming API を用いたアプリケーションが公開されています。

そこで面白いのは、Orbited というサーバーデーモンを使っているところです。
Orbited: Real-time communication for the browser (URL)

2009年10月27日火曜日

StreamGPU - SVD 実装

StreamGPU プロジェクトに関して

森田君の実験によって、1次元に関しては行列サイズ 500 程度から GPU によりアクセラレーションされることがわかりました。

次のステップですが、結局、多次元を扱うには、CULA では期待されるパフォーマンスが得られません。やはり、SVD (Singular Value Decomposition) を CUDA 上で自分で実装することが後々、さまざまな制御ができるので、とりあえず自分たちで作ってしまうのがいいのではないかという方向性に行きつつあります。以下が、既存の C で書かれた SVD の実装のリンクです。Numerical Recipes という有名な本がありますが、3番目の TINA に含まれるものはそれそのもので最もシンプルです。

とりあえず、われわれとしては、正方行列の密行列のSVD のみが必要なので、CLAPACK などはオーバースペックで大変ですね。

- SVDPACK : 大規模疎行列用 http://www.netlib.org/svdpack/
- CLAPACK : netlib の有名ライブラリ http://www.netlib.org/clapack/
- SRC/sgesvd.c が SVD の C ソースだが、Fortran からの自動変換のため、
　大変読みずらい
- TINA: Open Source Image Analysis Environment:
http://www.tina-vision.net/tina4/
http://www.tina-vision.net/tina4/doxygen/html/svd_8c-source.html
上記のはほとんど "Numerical Recipes" に書いてあるアルゴリズムと同一

論文としては、以下の論文があります。
Singular Value Decomposition on GPU using CUDA, Sheetal Lahabar, IPDPS 2009
http://web.iiit.ac.in/~sheetal/NN.pdf

PyMW

Python のマスターワーカー用のライブラリ。昨日の計算機アーキテクチャの阪大の学生がこれを使って、Python の MapReduce 実装を発表していた。

http://pymw.sourceforge.net/

CUDPP - GPU 用データ並列のプリミティブ

Parallel Sorting, Prefix Sum など, データ並列のプリミティブを用意する GPGPU 用ライブラリ
http://gpgpu.org/developer/cudpp
ソースも公開されている

2009年10月24日土曜日

工大祭 2009

皆さん、工大祭、お疲れ様でした。お陰様で、多くの見学者が来てくれましたし、「ストリームコンピューティング」の面白さを伝えられたのではないかと思います。

3年生の老木君、石井君には感謝、感謝です。とてもインパクトの高いデモだったと思います。研究としても、お互いに良い方向にいけそうなので、これからも頑張りましょうね。

4年生の松浦君、森田君、ポスター作り、設営、そして説明など大変だったと思いますが、本当にお疲れ様です。

そして、GSIC の佐藤さん、ポスターの件で強引に呼び出してしまってすみません。また、研究の議論しましょう。

セカイカメラと Twitter の連動

http://www.atmarkit.co.jp/news/200908/21/twitter.html

今日の工大祭で、東工大付属の高校生が iPhone を持っていて、セカイカメラを見せてくれました。私の環境では、iPhone OS 3.1 にすると支障が出るので試せないのが残念なのですが、カメラから写しだされた映像にふわふわ”タグ”が浮いているのが見えました。

2009年10月23日金曜日

拡張現実のライブラリ

なんと、セカイカメラのような拡張現実 (Augmented Reality) を実現するオープンソースライブラリがあるらしい。これを使って何か面白いことをやりたいですね。

http://blog.sohaya.com/2009/08/03/arkit-for-iphone/

セカイカメラと Twitter の連動

http://plusd.itmedia.co.jp/mobile/articles/0910/01/news114.html

IDDY

IDDY http://iddy.jp/
プロファイルの一元管理

2009年10月22日木曜日

CUDA Visual Profiler

CUDA の Visual Profiler があるではないか。これは使えそうだ。
http://gpu.fixstars.com/index.php/CUDA_Visual_Profiler%E3%82%92%E4%BD%BF%E3%81%86

上記のものは基本的に GUI ですが、松岡研究室の丸山さんから便利なプロファイルスクリプトをもらえそうです。

StreamGPU -次元数を高くしたときの性能劣化の問題

http://www.culatools.com/html_guide/index.html#thread-safety
の API を見ると、

typedef enum
{
  culaNoError,                       // No error
  culaNotInitialized,                // CULA has not been initialized
  culaNoHardware,                    // No hardware is available to run
  culaFeatureNotImplemented,         // The requested feature has not been implemented
  culaInsufficientComputeCapability, // Available GPUs do not support the requested operation
  culaInsufficientMemory,            // There is insufficient memory to continue
  culaArgumentError,                 // An invalid argument was passed to a function
  culaDataError,                     // An operation could not complete because of singular data
  culaBlasError,                     // A blas error was encountered
  culaRuntimeError                   // A runtime error has occurred
}culaStatus;

と status が見えるので、NoError 以外のときはこれをデバッグで
まずは表示すべき

StreamGPU 実験

GPU 上での予備実験結果

[1次元でのデータ]

SVD に与える正方行列の行/列数 -- 10回の合計処理時間(秒数）
129 -- 8.07
229 -- 9.42
329 -- 12.32
429 -- 16.55
529 -- 19.39

行列サイズ 529 で1回につき2秒あたりなので、CPU だと1分以上かかっている
ので、非常によい結果となった。

[行列サイズ129での2次元以上の結果]
2次元にした結果： 22.31, 22.85 がそれぞれの時間
3次元にした結果：　一部は失敗
4次元にした場合: 48.12, 39.71, 37.52, 43.30 (1次元が8秒なので、大体5倍になっている)

次元数を大きくしても実行時間は線形で増加しないことが期待されるが、きれいに増加してしまっている。そもそも SPADE プログラムが、次元数を高くしたときに、各オペレータが各次元を独立に SVD 計算をしているのだが、各オペレータにすべての次元のデータが送信しているところも問題。

まずはこの問題を解決してみたが、それでもやはり実行時間の増加は変わらず。現在は、各オペレータがプロセスとなって、複数プロセスから CULA の SVD 関数を呼び出している形式。一応、遅いながらも結果は同時にはかれている。 GPU デバイスの状態をやはり、プロファイラで精査する必要があるだろう。

CULA のドキュメントによると、マルチスレッドからのアクセスは可能と書いてあるが、本質的には同じ。
更なる調査が必要です. CUDA Visual Profiler を使って、System S のスタンドアローンバージョンを実行してみましたが、うまく動作せず。まあ、これは System S なしで確認できる事項なので、マルチスレッド・マルチプロセスにおいて同時に CULA の SVD にアクセスしたときに、やはり線形に増加してしまうかを調査してください

→森田君（工大祭のあとね）

大規模知識処理特論２

大学院の「大規模知識処理特論２」で、3人がストリームコンピューティングの演習を選択してくれた。トップダウンにテーマを与えるよりも、彼らの創造性に期待しよう。

データストリーム処理における適応的なウィンドウ処理

以下、StreamGPU に関係するアイデア。森田君、注目。

以下は、GPU がなくても成立する研究テーマではあるのだが、GPU を使ってストリーム処理が高速化できたというのは、今の状態だと、CULA のライブラリに頼っているだけ。方向性としては、特異値分解のように如何にも効果がありそうなアプリケーションではないところに適応すること、もしくは、以下のような数理的なモデルを用いて味付けするかどちらかだ。

タイトル：　データストリーム処理における適応的なウィンドウ処理

[前提条件]
- アプリケーションは異常検知などレイテンシが critical なものを想定するが、あらかじめ何秒以下に反応すべき、という情報が与えられているものとする。
- また、レイテンシも重要だが、異常検知の精度も重要であり、それがウィンドウサイズとウィンドウのスライドサイズに依存する
- システムは動的に、ジョブや到着タプル数などが変化するものと仮定し、すべてのノードを使えるものとは限らない
- システムは異機種混在環境で複数ノード、複数コアから成り立つ。また、いくつかのノードには GPGPU などのアクセラレータが搭載されているとする

[我々の提案手法]
システム全体の利用可能なリソース状況（ジョブ数、ネットワーク、到着タプル数）
によって、アプリケーションによって与えられたレイテンシを満たす中で、異常検知の精度を最大化する、つまり、
- 動的にウィンドウサイズを最大化し、かつ、
- スライドサイズを小さくする
ことを動的に行う仕組みを構築する。

[実装方法：　数理的モデルの構築と更新]

まず、重回帰分析によって数理的なモデルを構築する。
変数 Y = f(x1, x2) (a1*x1 + a2*x2)

- Y : 1回の平均処理時間（レイテンシ）（平均だけでなく、最大値も見たいが）
- x1: ウィンドウサイズ (大きくできれば長いスパンでのトレンドが見れるので、大きい方が良い。SST の場合、CPU と GPU とで 512 以上のとき平均処理時間に大きな差が現れるので、もし 512 以上のときには GPU が使用できる場合にはそちらを用いる)
- x2: ウィンドウをスライドさせるサイズ（細かい粒度で異常がわかるので、サイズは小さい方がよい）

このモデルは以下に与える外部の制約条件（特に動的情報）によって、変化するので、実行時に定期的に更新する。

外部から与える制約条件は以下の通り
- 1秒間に到着するタプル数（1タプルのバイト数）
- 1回の計算処理時間
- クラスタ全体のジョブの数他のジョブがどのぐらい走っているか
- クラスタに関するスペック情報(静的に取得可能)
(ノード数、コア数、GPU あり/なし、ネットワーク、ストレージ）

また、上記のモデルは CPU と GPU でそれぞれ数理的なモデルを構築する

[ 最適なウィンドウサイズ・スライドサイズを調節し、動的にシステム状況が変化する中でスループットを最大化する]

重回帰分析によって、CPU 使用率、ウィンドウサイズ、スライドサイズ, GPU の使用有無を指定すると、得られるスループットが予測できる。 T = f(CPU utilization, Window Size, Slide Size、GPU or CPU)

グラフとしては、
CPU Utilization と GPU/CPU は与えられるものなので、上記のグラフができれば、最大のスループットをえる

パラメータとして、
- GPU が使えるか否か (0/1)
- 他のジョブが使用しているCPU 使用率はいくつか？
という制約条件が与えられているときに、最大のスループットを出すために、
ウィンドウサイズ、スライドサイズを動的に調節し、かつ、GPU を使うか否かを
動的に選択する。

目的関数: T (スループット) ＋SW + 1/SS
ウィンドウサイズ SW →最大化 (1024 ぐらいまでの中で最大化) 、スライドサイズ SS →最小化

制約条件:
- レイテンシ L < α（ある値以下）
- ウィンドウサイズ SW < 1024 で最大
- その他のジョブのCPU 使用率
- GPU が使用できるか否か

機械学習リンク

機械学習リンク。オンラインの線形回帰の内積計算には GPU が効果があるはず。
http://ibisforest.org/index.php?%E6%A9%9F%E6%A2%B0%E5%AD%A6%E7%BF%92

Bitonic Sort

並列マシン用の並列ソーティングアルゴリズム"Bitonic Sort"
http://www.tools-of-computing.com/tc/CS/Sorts/bitonic_sort.htm
StreamGPU のアプリケーションとして
CUDA の実装がここからダウンロードできる. StreamGPU 用のアプリケーションとして、いくつか模索中。

2009年10月21日水曜日

StreamGPU 実験

以下の実験をやってみましょう

SST-G (System S の SST GPU 版)
SST-C1 (System S の SST CPU 版, Matrix Compression なし)
SST-C2 (System S の SST CPU 版, Matrix Compression あり)

の３つを以下で比較してください

[前提]
- 今 5000 個のデータがありますが、600個ぐらいのデータに削減しましょう
(500個の時系列データを取るので、実際に計算するのはこれだと100回になります）

[1次元データのみ]
- SST-G : 1回の処理で1秒だとすると、大体100秒ぐらいで終わりますね。
　全体の総実行時間を処理回数で割って、1回の処理時間の平均、最大、最小を計算してください。

- SST-C1, SST-C2 でも SST-G と同様のことを行ってください。

- SST-G, SST-C1, SST-C2 の1回の平均処理時間の比較データを作成してください。
　リアルタイムの異常検知が1秒だとして、SST-C1, SST-C2 においてはその条件が満たせないことを
　示してください

[他次元データの場合]
- SPADE のプログラムを用いて、多次元で計測してください。まずは3次元データですね。
- SST-G :
　　- 次元数を 1 から最大 130 まで増加させていって、平均処理時間を観測してください。
　　- これで、あまり変わらないことが言えればベストです。１つの次元に対して、
　　　転送する行列サイズが 500x500 で float だと 1MB 程度。130次元でも
　　　GPU 上のメモリにのるはずです。

- SST-C1, SST-C2 において、ノード数（３つ）に増やすことによって、スケールすることを確認してください
- ただし、ノード数には限界があるので、SST-C1/SST-C2 が扱えるのは、うちの環境では8次元ぐらいまでですね

- 「次元数が多くても、GPU の場合はレイテンシを保ちつつ、スケールすることが可能」というメッセージが言えればいいですね。

まずは、上記の実験を完了させて、次はウィンドウサイズを可変 (512 ぐらいまで) にして同様の
実験を走らせて、グラフ化すればいいでしょうね。

Mixi API

http://developer.mixi.co.jp/

Borealis Project

2008年版のソフトウェアリリースがありソースが見れますので、 System S/SPADE と比較してみてください。GSIC 佐藤君が少し論文を読んでくれましたが、また、続きをやりましょう。
http://www.cs.brown.edu/research/borealis/public/#software

StreamGPU

森田君の System S なしの、CPU vs GPU の SVD の結果が出てきました。行列サイズ256 ぐらいから差が出てきて、行列サイズ 512 ぐらいだと、CPUが12秒、GPU が1秒以内と明らかな差があります。

次は System S ですが、Matrix Compression なしのバージョンで測定しますが、ウィンドウサイズをそのぐらいにすればさっくりと高速化できることが期待されますね。

しかも、センサーの次元数が今は130ぐらいまでデータとしてはありますが、現実的には CPU では 3までしかやっていません。GPU を使えば、130 ぐらいの次元数まで扱えることが期待されます。プログラミングモデル的にもそれは容易に書け、ただ単に SVD を呼び出す UDOP を呼び出すだけですね。

2009年10月20日火曜日

Quantum Leap

最近、良くメディアの登場する MIT の Media lab の石井教授が使っていた言葉。"Innovation", "Smarter ..." などより、遥かに含蓄のある良い言葉だ。

CULA に関する質問

CULA の SVD に関するドキュメントが少ないので、メールを打ってみた（ここは本当は私がやるべきではないのだが。。。）。重要なのは、culaSVD がやはりブロッキングという点だ。

-----
Hello, to answer your questions
1) These are job codes which control what the routine calculates singular vectors and where they are returned. The code 'A' says to calculate the full U/Vt matrices. Users will typically use the code that calculates the minimum required results in order to lessen computation time.

CULA routines follow closely the LAPACK standard for routine naming and arguments. Full documentation of the routines will be in CULA 1.1, but in the meantime we can use this: http://www.intel.com/software/products/mkl/docs/webhelp/lse/functn_gesvd.html Note that our routines have cut the work and info parameters from the list.

2) culaSgesvd blocks. You will find that runtimes are sufficiently long that the blocking will not impair performance.

3) Yes, CULA is thoroughly threadsafed. The only function that can be adversely affected is culaGetErrorInfo() which returns the most recent Info code triggered by any thread (which may be a different thread from the one currently executing.) Info codes are normally errors in your data or arguments, so these can be debugged in a single-threaded environment most of the time.

For each thread you have three options -
1) Pre-bind each thread with a call to cudaSetDevice, using the CUDA toolkit. This is the most flexible, allowing you to choose which GPU each thread binds to.
2) Bind by calling culaInitialize() in each thread. CULA will bind to the GPU it determines is best, but this will result in each thread binding to the same GPU.
3) Do neither #1 nor #2 and accept CUDA's default binding, which is always device zero. Note that in order to use CULA, your first thread will still need to call culaInitialize().

Regards,
John

コールセンターにおけるリアルタイム検知

良く引き合いに出すコールセンターの例
http://09197218.at.webry.info/200905/article_71.html

ボットネット対策プロジェクト

総務省、経済産業省のボットネット対策プロジェクト
https://www.ccc.go.jp/

WWW 2010 CFP

Abstract は 10/26. ちょっと今年は難しそうかな。
http://www2010.org/www/authors/cfp/

StreamShedder 続き

松浦君の卒論テーマに関して。

このエントリの論文では、オンラインとオフラインのジョブの resource sharing 手法を提案しています。この論文との差異を述べてください。

Flickr API

http://www.flickr.com/services/api/

回帰分析によるストリームデータのクラスタリング

以下の論文を読むべし

「回帰分析によるストリームデータのクラスタリング」、日本データベース学会

http://www.dbsj.org/Japanese/DBSJLetters/vol2/no3/papers/motoyoshi.pdf

論文概要：　局所的に異なる傾向を持つストリームデータにおけるクラスタリングについて述べる．このようなデータはそれぞれのクラスタが異なる線形関数で回帰すると考えられる．そこで，結合の基準として回帰式のF検定統計値を用いた階層的クラスタリングの差分方法を提案する．本手法により，解釈可能な数のクラスタを抽出でき，かつストリームデータに適応できることを検証する

オンライン線形回帰

StreamGPU プロジェクトの次の策を考えている。CULA だとブラックボックス化されているので、我々としては自分たちでCUDA 上で実装した方が良い。

System S + GPU の組み合わせで有効な機械学習のアルゴリズムとして、さくっとできそうなのがオンラインの線形回帰アルゴリズム。センサーデータが来たら、インクリメンタルにGPU デバイス上の行列データをアップデートして、内積計算すればよい

SDP (Socket Direct Protocol) を用いた高速通信

大規模クラスタにおけるソケットダイレクトプロトコルSDP の性能評価,　SWOPP 2005, 緑川先生(成蹊大学) (PDF)

ソケットダイレクトプロトコルSDP は，伝統的なソケットストリームAPIを提供しつつ，RDMA プロトコルに直接マッピングすることにより高性能な通信を可能にするプロトコルである．この論文では、Infiniband 上に実装された SDP の通信性能をクラスタ上で評価し、ギガビットネットイーサネットと IPoIB とを比較している。結論としては、SDP は小さなメッセージサイズに対しては優位性がないが、大きなメッセージサイズに対してはレイテンシおよびスループットで有利という。

ストリーム処理における高速データ転送に参考になる論文だ。

2009年10月19日月曜日

SVD の C実装

特異値分解の C 実装は以下にあります。

http://www.netlib.org/svdpack/

file    svdpackc.tgz
for     C version of SVDPACK for computing the SVD of large
,       sparse real matrices
by      Michael W. Berry et al.
ref     M. Berry et al., "SVDPACKC (Version 1.0) User's
,       Guide", Univ. of Tennessee Tech. Report CS-93-194,
,       April 1993 (Revised October 1996)

特異値分解 on GPU

名古屋大学の研究者の仕事のほかに、SVD の GPU 上での高速化の論文が IPDPS 2009 で発表されているようです。この論文によると、やはり、256x256 ぐらいまでの行列では、CPU 版の方が速く、それより大きな行列サイズでの GPU 版での高速化が見られています。我々の戦略としては、まず、Matrix Compression なしに、行列サイズをできるだけ大きくし、CPU 版と勝負しましょう。

また、複数のセンサーデータを同時に計算することによって、レイテンシ及びスループットを稼ぐこと。そのためには、ブロッキングしないようにすべき。現状の CULA を見ると、ブラックボックス化しているため、よくわからない。やはり、Next Step としては、CUDA API を使って実装すべきだろう。

Singular value decomposition on GPU using CUDA (PDF)
http://portal.acm.org/citation.cfm?id=1587556

Linear algebra algorithms are fundamental to many computing applications. Modern GPUs are suited for many general purpose processing tasks and have emerged as inexpensive high performance co-processors due to their tremendous computing power. In this paper, we present the implementation of singular value decomposition (SVD) of a dense matrix on GPU using the CUDA programming model. SVD is implemented using the twin steps of bidiagonalization followed by diagonalization. It has not been implemented on the GPU before. Bidiagonalization is implemented using a series of Householder transformations which map well to BLAS operations. Diagonalization is performed by applying the implicitly shifted QR algorithm. Our complete SVD implementation outperforms the MATLAB and Intel ®Math Kernel Library (MKL) LAPACK implementation significantly on the CPU. We show a speedup of upto 60 over the MATLAB implementation and upto 8 over the Intel MKL implementation on a Intel Dual Core 2.66GHz PC on NVIDIA GTX 280 for large matrices. We also give results for very large matrices on NVIDIA Tesla S1070.

Google Data API

Google 上のサービスに触る様々な API セット。例えば、Bloggerなどのブログをフェッチできる
http://code.google.com/intl/ja/apis/blogger/docs/2.0/developers_guide_protocol.html#RetrievingMetafeed

StreamShedder

松浦君が行っている StreamShedder の研究へのコメント

■ SSD にどのくらいデータを退避させれば良いか.
データ受信部の CPU とネットワークがぎりぎり耐えられるぐらいのデータ量が学習モードで把握できるはずなので、その分 SSD に退避させればよい

■ SSD に退避できないぐらいのトラフィックがきたときは
　どうするか？
- 捨てる？

■ 負荷情報はどのように具体的に何からとるか？
- 実装は何を使う？ vmstat ?
- 突発的な負荷の変化以外に、学習していけばどのような周期でデータレートが変化するかがわかるはずなので、それも活用すべき

■ 高頻度に、”高データレート”→”低データレート”、”低データレート”→”高データレート”のモードを
　を繰り返すときに、ナイーブに実装すると、処理が「ストリーム処理」と「バッチ処理」の切り替えが頻繁におきてしまう。どのように対処するか？　マクロ的なスケジューリングも大事

■ ストリーム処理→バッチ処理、バッチ処理→ストリーム処理にコンテキスト切り替えするときの、どのように状態を保存するか？特に、バッチ処理の途中で、モードが変化してはまずい

■ この階層型の Load Shedding がどのようなタイプのアプリケーションに効果的かをはっきりさせるべき。例えば、SSD による退避で、後か結果を知っても意味のないタイプのアプリケーションがあるはず。
どのようなアプリに効き、どのようなアプリに効かないかを明らかにすべき

■ この研究の定量的な評価をどのように行うか？アプリケーションとしては、Twitter のほかには何を使うか？

2009年10月18日日曜日

Google Trend

現在、もっともホットなキーワードを表示するアプリ、Google Trend.
http://google.co.jp/trends/hottrends?sa=X

インフルエンザの流行を検索キーワードから予測するサービス Google Flu Trend.
http://cotoha.jp/2009/10/google-flu-trend-jp.html

老木が今行っている Twitter を用いた降雨情報をより汎用化し、かつ Twitter だけでなく、様々な情報ソースを利用すれば、Google と同じようなサービスを提供できるはずですね。

最近は何でも Google ですが、我々のような公的機関からも、世界を変えるサービスを提供していきたいですね。

2009年10月16日金曜日

リアルタイム経済動向

例えば、以下のような求人情報を提供する RSS を用いれば、政府が出す失業率などの情報よりもいち早く、経済動向を提供することができるでしょうね。私としては、究極的にはリアルタイム GDP が実現できれば、非常にインパクトが強いと思っています。

http://rikunabi-next.yahoo.co.jp/rnc/docs/ci_s00910.jsp?html_nm=rss_guide/rss_guide.html

Web API をセンサーデータに

各企業の Web API も、使い方によってはセンサーに。単一のセンサーだけでなく、RSS や下記の Web API をセンサーと見立てれば、いろんなことができるでしょうね。

写真共有サイト Flickr の API
http://www.flickr.com/services/api/

Yahoo Web API
http://developer.yahoo.co.jp/webapi/map/

Amazon Web Services
http://aws.amazon.com/

RSSをセンサーに

ある程度リアルタイムに取得できる情報源としては、Twitter などもありますが、昨今、さまざまなサイトが RSS を公開しているので、世界のあらゆる RSS をストリームとして扱ったもいいでしょうね。

RSS ナビ
http://www.rssnavi.jp/

Twitter と SMS

Twitter がSMS 送受信に対応するようになるようだが、こうなると、そのメッセージ数も更に膨大になるであろう。
http://jp.techcrunch.com/archives/20091014striving-for-four-billion-mobile-users-twitter-strikes-sms-deal-with-largest-indian-carrier/

Facebook Streaming API

SNS サイト Facebook も Streaming API を以下のサイトで公開しはじめたようだ。こちらも我々のアプリケーションとして使えそうだ.

Facebook の Stream とは、Twitter のようなコメントの他に、写真のアップロードやプロフィールなどの
アップデートをさすらしく、Stream を受けるにはユーザーの許可が必要だそうだ。これでは、あまり使い物にならないですね。

http://wiki.developers.facebook.com/index.php/Using_the_Open_Stream_API
http://jp.techcrunch.com/archives/20090427facebook-opens-up-its-stream-api-to-developers/

Twitter の統計情報

Web サイトの統計情報を提供するサイト Alexa では、Twitter のアクセス数は、13位。ちなみに、40% が US からのトラフィックで Japan はわずか 3% (http://www.alexa.com/siteinfo/twitter.com).
Top 10 は、Google, Facebook, Yahoo, YouTube, WindowsLive, Wikipedia, Blogger.com Microsoft Network, Baidu, Yahoo カテゴリ, MySpace, Google India 、そして Twitter. 日本は、
http://www.alexa.com/topsites/countries/JP　を参照。

Twitter 社自身が提供する統計情報サイト
http://twittercounter.com/

- "Featured User" としてお金を払えば、そのユーザーがこのサイトで Feature される。目的としては、たとえば、現在トップに表示されているのは、不動産屋の人。口コミなどでの、マーケティングや広告効果があるのであろう.
- 超有名人、たとえば、Britney Spears Barack Obama なども存在。Follower 数は３００万人以上
　http://twittercounter.com/britneyspears
- CNN や New York Times などのニュースサイトなどもサイトへの誘導などにあるのか。
Follower 数 360万人　http://twittercounter.com/cnnbrk

Twitter100: ある特定の Follower の Top 100 を表示するアプリ
http://twitter100.com/

Twitter の自分の発言を時間軸に表示する Web アプリ
http://teahut.sakura.ne.jp/timeline/twitter/?user=takemaru_jp

2009年10月15日木曜日

PHPグラフ化ツール

PHPでかっこよくグラフ化するツール
http://www.maani.us/charts/index.php

セカイカメラ

- 非常に気になるのは、セカイカメラのサーバーアーキテクチャと仕様。まだユーザー数は少ないだろうが、これが爆発的に流行りだすとそれなりの台数が必要だろう。

- 位置の取得は、屋内では、WiFi からのシグナル強度（3点）から推定しているらしい。

- Open Air API というものが11月に公開されるらしい。ストリームとの組み合わせで何か面白いことができそうかもしれない

TAG A Tiny Aggregation Service

TAG A Tiny Aggregation Service, OSDI 2002
http://db.csail.mit.edu/madden/html/madden_tag.pdf

この論文は読むべし

Live E! プロジェクト

http://www.live-e.org/wgroup/index.html
12カ国に設置された計 100台を超えるセンサー（気温、温度、気圧、雨量、風向き、
風速, CO2 濃度など）がリアルタイムに取得可能。奈良先端の砂原先生などがリード.
利用方法は以下
- 雨量センサ情報をリアルタイムに流通させ、コンビニエンスストアへの
　利用促進と書かれている
- ヒートアイランド現象の解析
- ゲリラ豪雨の検出
- 大気汚染の実態把握
- データの呼び出しインタフェースは
http://www.live-e.org/pdf/live-e-spec_dataprovider200901.pdf
に記載されている。
- SOAP の Web インタフェースが用意されているので、実際のデータを取得することができる

このように専用のセンサーデバイスを分散させるのが国家プロジェクトとして多いが、Twitter や iPhoneのアプリなどの集合知を利用する方法が個人的には好きだ

経営戦略

下記エントリ「ミドルウェアの任務」に関係します。

私はご存知の通り, IBM に勤めていますが、IBM はできるだけ汎用のミドルウェアを作って、それを横展開することで業を営んでいます。IBM の顧客としては、金融、通信、電機、航空宇宙、製造などあらゆる業界を相手にしていますが、大事なのは、汎用的なミドルウェア（これには莫大な投資をするが）を作るが、あとの業界に特化した知識なりその処理アルゴリズムは、顧客（もしくは顧客が雇うソフトウェアベンダー）に書かせるという戦略を取っています。若い人はご存知ないかもしれませんが、IBM は1990年代初頭に会社がつぶれるくらいに業績が落ち込んだ時期があり、その頃何千人ものリストラをしています。しかし、その後、「アプリケーションには手を出さない」「利益が少ないコモディティハードウェア」は売らないという思い切った経営戦略を取ることで、見事に復活しました（ハーバードビジネススクールなどの MBA などのプログラムでは、その復活劇が教科書に出てくるらしいです）。この戦略が功を奏してか、IBM におけるソフトウェアビジネスの全体の利益に対する貢献は年々高くなっていっています。

ミドルウェア屋の任務

　国立情報学研究所の佐藤先生の「クラウド時代の到来でコンピュータサイエンスは終わった」(URL) というセンセーショナルな記事がありますが、佐藤先生が言わんとしているところは、情報科学は、社会の現実社会の問題をちゃんと解く研究をするべきだ、ということを言っています。これは正に念頭に置くべきで、我々ミドルウェア屋さんの任務は、それらの要件を徹底的にまずは調べて (インタビューしたり）、それを汎用化したときにどのようなソフトウェア処理系が必要か、プログラミングモデルが必要かを考えることです。なので、最近停滞気味ですが、前、楽天に行ったようにいろいろなユーザーの声を聞いていきたいと思います（研究に支障のない程度に）。

　このように、現実的なアプリケーションを見据えた処理系の拡張、および性能最適化を行っていくことが極めて重要であると感じるので、この１、2年は実際のアプリケーションを Twitter だけでなく、他にも増やしたいと思います。ただ、バイオの例にあるように、我々がアプリケーション分野にどっぷり漬からないことが味噌かもしれません。どちらかというと、ユーザー（アプリケーションの知識を持っている人）をこちらのミドルウェアを使ってもらうというスタンスがベストですね。

2009年10月14日水曜日

来年以降の研究テーマ一覧

今卒論でやっているもの以外に、データストリーム処理周辺の研究ネタをいくつか書いてみます。ストリームコンピューティングに特化した研究室にするつもりはないのですが、ある程度のまとまった成果が出るまでは、この分野に注力していきたいと思っています。

[システムソフトウェアよりの研究]

- 仮想マシンを用いた Elastic なデータストリーム処理システム: Xen や KVM などの仮想マシン上でデータストリーム処理システムのインスタンスを稼動させ、負荷に応じてインスタンスの数を増減させる仕組み

- 動的なスケジューリングの最適化: 複数のクエリ・ジョブが稼動している状況でのダイナミックなオペレータ配置機構

- GPGPU などのアクセラレータを用いた更なる最適化: CPU と GPU を組み合わせたストリーム処理

- ポータブルな軽量データストリーム処理システムの実装. 現在の System S は様々なパッケージ（特に PerlやCORBA) に依存しており、かつシステムが巨大である。我々の足回りを軽くするためにも、Java などのポータブルな処理系を用いて実装する。Engineering 的な側面が高いのが難点

- 簡便なプログラミングモデル: PHP, Python, Ruby などのスクリプト言語や統計言語 R などで Agile にストリームアプリケーションを簡便に記述できるようにする. UDOP のようなカスタマイズコードもささっと書くことができる

[アプリケーションよりの研究]
- 音声データからのキーワード検出 (古井研・西井君に期待) : 演習の時間

- データストリーム処理用ベンチマークシステム
- StreamDNA/StreamBIO: ストリーム処理の科学技術計算への応用

[アルゴリズムよりの研究]
- ストリームアルゴリズムの研究: 　処理系の研究ばかりでなく、アルゴリズムの研究も. Click Fraud Detection などが応用例。
- データストリーム処理における Privacy Preserving Data Mining

Twitter 関連

Twitter のタグクラウドが表示されるページ
http://www.twitscoop.com/

Twitter 統計

Harvard Business School の記事によると、10％のユーザーが９０％のトラフィックを生んでいるんだそうです。
http://blogs.harvardbusiness.org/cs/2009/06/new_twitter_research_men_follo.html

松浦君卒論

松浦君の卒論ですが、

今3年生が精力的に進めている Twitter をアプリケーションとして、

Load Shedding SSD/RamDisk への退避 + (Online+Offline の融合)

をやっていくことになりました。金曜日に彼に詳細を話してもらいます。

参考エントリ
http://suzumura-lab.blogspot.com/2009/08/offline-online-sharing.html
http://suzumura-lab.blogspot.com/2009/06/blog-post_17.html
http://suzumura-lab.blogspot.com/2009/05/power-law.html

卒論の方向修正

松浦君の卒論テーマですが、方向修正することになりました。

　といっても、StreamDNA や StreamBIO 関係のプロジェクトが終焉するという意味ではなく、このプロジェクトに並々ならぬ興味を持つ4年生が入ってくるか、もしくは、我々の研究室以外のバイオ系の学生で興味がある学生がいたら、是非やってもらいたいとは思っています。
　
　

SST

森田君が見ている高橋さんの DPS コードに関する説明

- Input.csv の見方

- 各行は、センサーデータそのものをあらわす。一応 130 次元まで対応するように、130個あるが、実際に高橋さんが実験をしたのは 16, 32 次元ぐらいまで
-第1列目が到着する間隔をあらわす。5 だったら、
　5秒待つという意味. ０だったら待たない
- System S のバグで、第1列目は読み込んでもらえない
- vstream inputDatStream は使う次元数をあらわす。この場合だと次元数は 4
- for_begin でセンサーの各次元に対する計算
- Aggregate は、49 個（49行）のセンサーデータを集めて、Col(data@i)
で @i 次元目のデータをすべて出力ストリームで返す。なので、型は FloatList

- CPU のスケールアウト数を変える方法
- GeneralPool[] の 1 とノード数に変更する
- Makefile のノード数を変更する必要あり
- 時間は、開始時刻と最終時刻の引き算を実行

2009年10月13日火曜日

Dolly+の特徴

Dolly+ の特徴は以下の通り。高速化の要点は以下の３つ。

(1) コピー対象ホストをマスターホスト(コピーされるイメージを持つホスト) を先頭としたリング状に接続し、パイプライン転送をおこなう。

(2) マスターホストでのボトルネック発生を回避し、送信と受信を同時に行える全2重通信 (Full Duplex) のネットワークスイッチの性能を最大限に活かす (** 我々の Linux クラスタで Full duplex 通信可能なように設定する必要あり)

(3) ネットワークからデータを受け取るスレッド、データをディスクに書き込むスレッド、データをネットワークに書き出すスレッドの3スレッドを同時に実行し、かつ、巨大なファイルを 4MB ずつのチャンクに分けてコピーすることによって、高速化。
(詳細は http://matsu-www.is.titech.ac.jp/paper/takamiya/sacsis2003.pdf　の3.3.1 章参照)

データ配信最適化

松浦君に関係するものです。

- 以下の論文、要チェックです。

A Stable Broadcast Algorithm, Kei Takahashi, CCGrid
A pipeline technique for dynamic data transfer on a multiprocessor grid
トポロジを考慮しソース選択を行うデータ転送スケジュラー(PDF)
FastReplica: Efficient Large File Distribution with Content Delivery Network , USENIX, 2003
A Fast Topology Inference - A building block for network-aware parallel computing, HPDC 2007
Exploiting Hiearchy in Parallel Computer Networks to Optimize Collective Operation Performance, 200
Modeling and Performance Analysis of BitTorrent-Like Peer-to-Peer Networks, SIGCOMM 2004
An approach to communication-efficient data redistribution, 1994,
グリッド環境におけるクラスタ間データ転送の評価　（松岡研　小倉）
Spring-8 からの画像転送。2003年のスライドだが、我々と少し関係がある
http://www.biogrid.jp/project/j/event/seminor/inoue/pdf/biogrid2003Telescience.pdf

- ネットワークのチューニングに関してはもちろん、いろいろあります。

イーサネットのジャンボフレーム (9000-16000バイト) での送信
http://www.psc.edu/networking/projects/tcptune/
http://www.kagoshima-ct.ac.jp/kenkyu/kenkyu_houkoku2004/2kajisa.pdf

Quantitative Comparison of Xen and KVM

オープンソースのハイパーバイザとしては Xen と KVM (Kernel-Based Virtual Machine) が有名だが、その定量的比較を行った論文。
"Quantitative Comparison of Xen and KVM" (PDF)

以下、論文の中身。

- benchvm というオープンソースのハイパーバイザ用のベンチマークソフトが存在

- Linux のカーネルのコンパイルが CPU も I/O も程よく使うので、この手の世界ではコンパイル時間で比較を行っている。KVM も Xen も仮想化なしに比べて半分以下の性能。仮想化なしを 1.0 とすると、Xen は0.487, KVM は 0.384 という結果。

- CPU のみを使う場合は、仮想化なしに比べて Xen も KVM もほとんど変わりなしで、やはり I/O が一番仮想化のオーバーヘッドが効いている。

- また、複数の VM が実行される状況で、 Performance Isolation (互いに性能への影響を与えない）がうまくいっているかどうかのテストをしている。メモリや Fork, CPU Disk, そしてネットワークの送信、受信それぞれの比較を行っているが、ネットワークに関しては Xen も KVM に関してもどちらもよろしくない。 System S のようなデータストリーム処理で使用するには不向きだが、逆に言うと、いろいろ最適化ポイントがありそうだ。

- 最後に何個の VM を立ち上げられるかをテストしているが、Xen の方が圧倒的に上回っており、KVM は散々たる結果となっている。

2009年10月11日日曜日

StreamTwitter の研究課題

StreamTwitter に関して、パブリックに取得できる莫大なデータとして、データストリーム処理の研究を行う上での絶好のアプリケーションと言える。ブログやその他の Web ページからの抽出と比較して、１３０文字という制約があるので、システム的に解析がしやすいという特徴も持っている。

老木君、石井君が今まさに実装している
「リアルタイム降雨情報」
「類似ユーザー検索」

などの他に

「リアルタイム地震検知」
「最もホットなキーワード Top 10」
「リアルタイム経済指標」（消費者物価指数、失業者数。。。）
「リアルタイム選挙速報」
「リアルタイムな商品情報」→販売戦略の見直し
「リアルタイムな企業情報」→株価への反映→投資銀行などの自動売買への利用
...
など Twitter のデータを用いて、様々なリアルタイム解析が可能になるだろう。

ストリームコンピューティングの研究としては、如何にこれらのアプリケーション用の汎用プログラミングモデル（すなわち汎用オペレータ）を定義し、Bursty な状況でも適切に有用な答えを返すかが重要な研究課題となる。

特に、上記の複数の解析が混在する可能性があり、それぞれの解析のプライオリティも異なるはずであろう。Bursty な状況で、ただ単に解析をストップするだけでなく、確率的に処理を行い、ある程度の精度を持って解析をすることによって負荷を小さくしたり、類似度計算に必要なベクトル計算などは GPGPU を用いることもできる。

また、さらに、Twitter だけのデータを用いるのではなく、より信頼性のあるデータソースと組み合わせることで、結果の精度を高めることもできるであろう。

来年以降のテーマであるが、期待したい

2009年10月9日金曜日

高速データ転送システム

高速データ転送システム Dolly+
http://corvus.kek.jp/~manabe/pcf/dolly/index_J.htm

松岡研究室の滝澤さんの研究
http://matsu-www.is.titech.ac.jp/slides/takizawa/swopp04slides_takizawa.pdfMHg

工大祭

工大際まで約2週間となりました。そろそろ何を展示するかを考えていきましょう。

(0) 鈴村研究室概要 (by 鈴村)
- 研究室概要
- ストリームコンピューティング概要

(1) StreamBIO プロジェクト (by 松浦君)
- スライドを完成させてください. 1枚 Version と Long Version を作成してください。
- Long Version に関しては、韓国の学会でも使用することを想定して作ってください
　　　（英語でもいいです）
- 「データストリーム処理におけるデータ配信技術の最適化」という情報科学としての技術的な貢献も書くと良いと思います。
- できるだけ間に合う

(2) StreamGPU プロジェクト (by 森田君)
- スライドを完成させてください. 1枚 Version と Long Version を作成してください
- GPU に詳しくない人も来るはずなので、その説明チャートも用意しておいてください。
- 頑張って、「GPU を使うとこれだけ速くなるんだ」という性能評価結果を載せてください

---- 以下は Optional です。非常に面白いものとなるので、できれば、展示してくれるとうれしいです。

(3) プロジェクト雨流 (by 老木君)
- （間に合えば）デモと概要スライドをお願いします。
- せっかくなので、IBM の Intern で行った「System S を用いた Web サーバーの構築」も　概要スライドを張っておきましょう。

(4) Twitter上の類似ユーザ探索bot　(by 石井君)
- (間に合えば) デモと概要スライドをお願いします。
- System S へのポーティングが間に合えばそれを、間に合わなくても現状のも石井君が創作演習で作ったものを見せてくれれば良いと思います。

データストリーム処理における大規模データ配信技術

　松浦君のテーマは「データストリーム処理における大規模データ配信技術に関する研究」という技術的なコアを基盤にして、たんぱく質の立体構造解析、次世代 DNA シーケンサー, 電波天文学、そして街中の監視カメラなどから出力される大量（画像）データへの高速処理に寄与する、といった研究のまとまりができつつある。

　ただ、これに関しては、グリッドやネットワーク、画像配信, CDR (Contents Delivery Network) などでの豊富な研究があるので、如何にデータストリーム処理ならではの問題を掲げ、それに対する解決策を提案しないと　”情報科学”としての新規性や進歩性にかける。今考えている、「リレー方式によるデータ配信」、「UDP によるマルチキャスト配信」などがあるがこれらは既知の技術であるので、我々としての技術的な貢献を考えていきましょう。

まず既知の技術の性能評価をするのが First Step ですが、その次に以下のことを考えていきましょう。
(1) ゼロコピー通信
(2) 実行環境に応じて、最適な配信方式、トポロジーを（プロファイルデータなどから）自動的に決定する仕組み

Next Step for StreamGPU

森田君のStreamGPU プロジェクトに関して、そろそろ CULA 版が動き出しそうな感じなので次のステップを書こう。

(1) CULA SST (CULAの SVD 関数を使うバージョン) を完成させる(あともうすぐ)

(2) SST (高橋さんのオリジナルバージョン) と (1) の CULA SST の性能比較を行う。このとき、ウィンドウサイズをいろいろ変更していって、どのような性能差が得られるかをグラフ化する。このとき、SST 版は1ノードだけでなく、多ノードを用いてスケールアウトのデータを出す。
- データに関しては、スループットだけでなく、1データあたりのレイテンシを求められるようにする
- また、newmat の Matrix 型から 1次元配列、そしてその反対のコストがパフォーマンスのボトルネックになることを確かめるため、スタンドアローンバージョン (-T でコンパイル)で実行し、oprofile でプロファイルを取る。translate/detranslate の関数が CPU をあまり使用していないことを確認する

(3) SST は特異値分解が重いため、高橋＆井手バージョンでは、 Matrix Compression をして、与える行列サイズを小さくしている。GPU を用いることにより、そのような Compression をしなくても、それなりの性能が得られる可能性が得られるため, そのバージョン（これは高橋さんから既に頂いている）を再び CULA の SVD 関数を使うように移植し、(2) との比較を行う。結果として、Matrix Compression などの工夫を行わなくても、GPU を用いれば十分に高速化できることを示す

(4) 以下の状況下において最適な条件を数理的なモデルを用いて自動的に決定できるようにする。
- 1ノードのみ (CPU と GPU)
- 複数ノードと 1GPU
- 複数ノードとマルチ GPU (マルチGPU は松岡研究室の GPU クラスタを使用させてもらう）
また、モデルを用いて、どのような条件下では GPU を使うか、

(5) System S / SPADE において、GPU のようなアクセラレータを使用する汎用的なオペレータはどのような形で提供すべきかを考察する

2009年10月8日木曜日

SWOPP

http://www.hpcc.jp/swopp/
毎年8月開催
査読なし

情報処理学会全国大会

http://www.ipsj.or.jp/10jigyo/taikai/72kai/index.html
2010年3月　東大本郷キャンパスで開催。
発表申し込み締め切りは11月27日。

SC (Super Computing)

Super Computing に関する学会および巨大な展示会
http://sc09.supercomputing.org/

来年は是非ここでデモンストレーションをやりたい。

ACS 論文誌

http://www.hpcc.jp/acs/

電気情報通信学会　データ工学研究会

http://www.ieice.org/iss/de/jpn/
いまいちアクティブではない（？）

WebDB Forum 2009

http://db-event.jpn.org/webdbf2009/index.html

情報処理学会データベースシステム研究会

http://www.ipsj-dbs.org/

査読なし。毎年3回開催。

以下、Webページから抜粋。

データベースシステム研究会は、主に、DBMS (Database Management System) 技術、データモデリング、情報検索、ハイパーテキスト・ハイパーメディア、マルチメディアデータベース、データベース高度応用などの分野を対象として研究会活動を行ってきております。データベース系の他の団体との共催イベントを毎年 3 回程度（7月，11月，3月）開催しています。

インターネット・イントラネットとマルチメディア技術の進展により、データベースシステム技術の重要性と関心が一層大きくなるとともに、ネットワーク・マルチメディア時代の新しい情報共有の基盤ソフトウェアとしての新しいデータベースシステム像が求められています。実際、これに関する研究活動が活発化しており、研究会としても積極的にこの分野を取り上げていきたいと考えています。データベース技術の需要は増える方向にあり、今後も学会活動に積極的に取り組んでいきたいと考えております。

日本データベース学会

http://www.dbsj.org/Japanese/event/index.html

CIDR

CIDR(The biennial Conference on Innovative Data Systems Research)
http://www.cidrdb.org/cidr2009/

学会開催は1月。論文締め切りは毎年9月ごろ

INSS International Conference on Networked Sensing Systems

ストリーム関係の国際学会
INSS（International Conference on Networked Sensing Systems）
http://www.inss-conf.org/2009/cfp.shtml
2010 年は1月中旬が締め切り

2009年10月6日火曜日

Twitter を用いた研究

国際会議 WWW などを調べてみたが、Twitter いわゆる Microblogging を使った研究はまだまだ手をつけられていない。自然言語処理または Web データマイニングの方面から攻めるか、データストリーム処理との組み合わせでシステムソフトウェア＋パフォーマンスの方面から攻めるか。

前者だと、通常のブログのマイニングが盛んに研究されているため、マイクロブログならではの性質を活かした新たな手法を提案する必要があるであろう。後者は、新規性十分なので、ちゃんと実験して書けば通るでしょう。

以下、ざっと調べた結果。

Twitter のトラフィックに関する記事
http://blog.compete.com/2008/05/15/twitter-traffic-growth-usage-demographics/
http://siteanalytics.compete.com/twitter.com/?metric=uv

Why we twitter: understanding microblogging usage and communities
International Conference on Knowledge Discovery and Data Mining (KDD 2007)
(Download PDF) : この論文の参考文献も参考になります

「Twitterとパンデミックデマに関する研究
http://www.geekpage.jp/blog/?id=2009/8/28/1

Beyond Microblogging: Conversation and Collaboration via Twitter
(Download PDF)

2009年10月3日土曜日

Personal Genome Project (PGP)

Personal Genome Project (http://www.personalgenomes.org/)

パーソナルゲノム医療を加速化するために１０万人の個人のゲノム情報を収集するプロジェクト

以下の YouTube のビデオが興味深いです。

GENOME : The Future is NOW WEBISODE 1

2009年10月2日金曜日

StreamTwitter

とりあえず命名。石井君は類似ユーザーの自動検索プログラムをポーティング、老木君はアメダスを System S で実装することになりました。非常に面白いですね。楽しみにしてます。

2009年10月1日木曜日

Google Charts API

Google が提供するグラフ作成サービス。URL にパラメータを指定すると、作成された PNG グラフが返される。System S の最終結果を可視化するためのツールとして使えるだろう。
http://code.google.com/intl/ja/apis/chart/#chart_type

Bootchart

http://www.bootchart.org/
基本的には、サーバ起動時の負荷状況やプロセスの推移をグラフ化するためのツールだが、多分、boot 時でなくてもできるはず。割ときれいな可視化ができそうです。

登録: 投稿 (Atom)