2010年04月08日

KindleDX sucks-rocks

論文読みデバイスとしてKindle DXを購入しました。以下に「論文読みデバイスとして見た」sucks-rocksを並べておきます:

Sucks
・(物理的に)重い。片手で持ち続けると疲れる。
・(論理的に)重い。特に画面遷移が遅い。そのためこの22番ってどの文献……っていう見方が出来ない。
・UIはお粗末。ページ番号入力しか2ページ以上の遷移手段がない上、数字の入力はALTキー必須ってUIはどうよ!?
・タグを付けられるとか機能はあるんだけどUI的にない方がマシ。
・Documents/の下にフォルダを掘っても一覧表示は階層表示になってくれない。なのでpdf一杯入れると扱いが面倒に。
・高い。$500レベルはちょっといただけない。
・左側にnext/prevボタンがない。何を言っているのかわからねーかもしれないが使ってみると欲しくなる。
・ほとんど意味がない検索。

Rocks
・予想していたよりずっと解像度がよい。
・e-ink読みやすいです(^q^) 特に屋外。
・Wireless offで運用しておけば電池で困ることがまずない。というかこれとe-inkがなければノートPCで読んでる。
・USBからも充電できる。もちろんコンセントからも。

前から順番に読む分に於いては不便を感じることがないので、及第点かと思います。個人的にはASUS DR-900系列に期待しています。大いに。DR-950に開発キットが公開されるかどうかが目下最大の関心事です。
posted by chun at 10:49| 日記

2010年04月01日

そうだ京都行こう

というわけで京都に移りました。皆様本年度もよろしくお願いいたします。
posted by chun at 09:06| 日記

2010年01月10日

おめでとうございます>パズルの人

まぁこれで分かる人必要がある人だけ分かるでしょう(何
posted by chun at 00:02| 日記

2009年12月31日

2009年を振り返る

1月はいろいろとごたごたしていました。未だに出版できていない某研究の草稿を渡したりとか、oxy君からT. Taoの仕事を紹介されて読んだりしていた記憶があります。2月薬剤師国家試験の勉強とCell Challenge 2009でいっぱいいっぱいでした。毎日図書館に向かって電話帳を開き、一週間に1回cellの事実上アセンブラなコードを最適化するという健康で文化的な生活をしていました。3月Biophysical Society 53rd Annual meetingに出てきました。昔の研究内容の発表でしたが、結構マニアックな人が釣れて面白かったです。あと、D. E. Shaw Researchの桁違いっぷりが素晴らしかったです。その他試験本番、Cellチャレ結果発表などがありました。Cellの作り込みが甘いとか大それた事を発言したりとか。
4月は日記には書いていないですが奈良とか京都とかの先生を訪問してネタ出しをしてきました。この辺の研究アイディアは残念ながら未だに形になっていません。まぁ予算が付かないので仕方がないかと思います。5月はSACSISに行ってチームの呼び名で主催者を困らせたりしてきました。T社の方の発言にびっくり
6月は誰がなんと言おうとICFP-Cの月でした。結構良いところまで動く代物が出来たのですが、72時間のデスマではバグを取りきれず、悲惨な結果になってしまいました……。7月は代数関係の知識とか、信号処理とかの知識を貯め込んでいました。名前にMが付く数理系の研究者の方、是非アレの論文を出してください。このころとある理由から可積分系に興味を持ったので調べたりしています。
8月はICFP-Cの結果がわかってかなり凹んだりしていました。72時間でデスマなんて無理だよバーニィ! あと、研究との両立が完全に破綻を来したので、この月にPFIを退社しました。ブログで簡潔すぎる報告しかしなかったため、id:TAKESAKO氏に凄く勘違いされるという事態が発生しました。しかしデスマ自体がなかったとは言えないのが今日もPFIのみなさんは楽しく働いています!
9月は諸事情により東京を離れていたのと、論文の修正で忙しかったのであまり記録が残っていません。自然言語の生成を楽にする方法を誰か教えてください。10月は研究で新しいネタを少しずつ試したりとか、某m先生と密談を楽しんだりしたのですが、これもちょっと表に出せるネタが無かったりします。残念。
11月は事業仕分けの激震が走った月でした。結果的に科学技術予算はまんべんなくトータルで3%減額です。スパコンはよりgdgdな計画に置き換わりましたし、仕分けられていない事業もバーターで削減って泣いていいかなこれ。12月はついにD論を提出しました。後は審査だけなので綿密に準備をします!


皆様良いお年を! 来年もよろしくお願いします。
posted by chun at 20:14| 日記

2009年11月28日

仕分け雑感(2)

ポッポのしわけ! こうかは ばつぐんだ! 知り合いで有能な人が蜘蛛の子を散らすように日本を離れていくのが興味深いです。たった2週間なんだぜ、これ……。自分も興味深いとか言ってられる状況じゃなくなりつつありますが……。
  • 仕分けの問題点の1つは議論を置いて結果だけが一人歩きするところです。
  • 仕分けのもう一つの問題点は、専門性どころか合理性のかけらもない情緒的な議論で決定されることです。 例えば国立大の基盤経費。「天下りがあるから多数決で1/3削減」って、すいません天下りによって生じている無駄な人件費と出費はいくらで、どのようにすればこの日本でミスをしていない人をクビに出来るんでしょうか。 さらに言えば、「仕分け人の印象の多数決」のどこに合理性があるのかを小一時間問い詰めたいです。
  • その上で仕分けで評価できる点はいくつかあります。まず国民のガス抜きとしては非常に良く機能したと思います。次に、予算配分の透明性を形式的に高めた事は素晴らしい事です。特に、インターネット等で公開中継されたのは素晴らしいです。
  • なのになんで対象は全体の15%で、しかも継続的にやらないんですかね。しかも時間が金額に関わらず一定ですよね。グルーピングも謎ですよね。金額が一様になるように纏めているわけでもないですし。
  • スパコンですが、僕は継続を支持しません(復活するでしょうが)。でも、平木先生のIBM/Cray/Intelについての話は考慮に値すると思います(誰か1次ソース持ってません?)。今回のプロジェクトは研究開発ラインを止めないという目的を実は既に達成しているんでないかとごにょごにょ。
  • この件について某エラい先生が某学会で「他の学会も声明出してるから出そうぜ」とか言っててうんざりしました。このコピペじゃないんですから。
  • まぁ日本には流体系でほぼ独占状態のSX-9があるから、TOP500には決して出てこないだろうけど別にいいんじゃね? 的な思いもあったり。
  • 濱田先生の成果があるからスパコン要らないとか言う人は、あやまれ! アルゴリズムもコーディングも超頑張った濱田先生にあやまれ! 成果が正しく認識されないというのは悲しいことです。
  • 問題は若手と基盤、特別研究の削減です。特に特別研究・基盤の1/3はかなりまずいです。運営が立ちゆかない研究室が多数発生し、「運用でカバー」をする研究室が出るでしょう。で、辻褄合わせに失敗して不祥事になって何人か教授の首が飛ぶんじゃないかな、と予言。
  • ノーベル賞受賞者による緊急なんちゃらですが、これって図式としては権威主義で対抗しようとしてるんですよね。あまり嬉しくありません。いや、先生方がアクションを起こしてくれたことそのものはとても嬉しいのですが。ついでに、討論はgdgd杉でした。「マスコミvs研究者」「官僚vs研究者」という大変嬉しくない図式を作っていましたね。敵を作る意味が分かりません。
  • というか野依先生とそれ以外の先生の絶妙な温度差が面白かったです。野依先生「スパコン復活!」と森先生「小さく広く配分してイノベーションの芽を」。私は森先生派で。あと野依先生、お忙しいのは分かるのですが、仕分けの議論の展開をちゃんと聞いた方が良いと思います。
posted by chun at 13:09| 日記

2009年11月18日

仕分け雑感

身の回りで激震が続いております。色々言いたいことがあるのですが、以下、3点だけ。

  • この手の議論の度に「研究の重要性を小学生にも分かるように伝えれなきゃダメだ」とか言う人がいます。さて、理系の研究者の皆様は線型代数の有用性を否定することは無いと思いますが、この現代の基盤となった数学の重要性は、どうやったら小学生に伝えられるでしょうか。それも、5分や10分といった短い時間で。これ、ここ4日間ずっと考えて居るんですが、未だに良い説明を思いつきません。
  • 若手研究予算がどうもニート生活支援(しかも更正支援ではない)と思われているふしがあります。というか、3-13の議事録読むとよく分かるんですが、学振あたりはどうもセーフティネットと見なされているようです。
  • 各所で言われているスパコンですが、あの答弁では正直仕方がないと思います。もちろん、1時間、一人だけの答弁で全額というのは非常に拙速であるという点には同意しますが。このまま共同計算機センターが存在しなくなると色々苦しいでしょうから、形を変えて(安いヤツを)作って欲しいとは思います。

とりあえず、文科省のほうでも意見を募集していますので、こちらにメールを出すことにします。

posted by chun at 04:56| 日記

2009年10月20日

perfコマンドを試してみる(3) annotateとperformance counterの実装

さて、perfコマンドの能力はこれだけではありません。perf annotateによって、プログラムの中のどの行が時間を食っているかが一目で分かるようになります。

% perf annotate
------------------------------------------------
Percent | Source code & Disassembly of saa
------------------------------------------------
:
:
:
: Disassembly of section .text:
:
: 0000000000407710 <sais_main>:
:
: /* find the suffix array SA of T[0..n-1] in {0..k-1}^n
: use a working space (excluding T and SA) of at most 2n+O(1) for a constant alphabet */
: static
: int
: sais_main(const unsigned char *T, int *SA, int fs, int n, int k, int cs, int isbwt) {
0.00 : 407710: 41 57 push %r15
0.00 : 407712: 41 56 push %r14
0.00 : 407714: 41 89 ce mov %ecx,%r14d
0.00 : 407717: 41 55 push %r13
...
: for(j = p + 1; (j < n) && (c0 == (c1 = chr(j))); ++j) { }
0.23 : 407942: 41 8d 40 01 lea 0x1(%r8),%eax
5.08 : 407946: 41 39 c6 cmp %eax,%r14d
0.07 : 407949: 7e 3b jle 407986
:
...
: for(i = 0, m = 0; i < n; ++i) {
8.29 : 4079a4: 4c 39 cf cmp %r9,%rdi
0.04 : 4079a7: 0f 85 73 ff ff ff jne 407920
0.00 : 4079ad: 44 89 54 24 18 mov %r10d,0x18(%rsp)
...

ちなみに、対応するコンソールを使えば色つきで表示されます。(例えば5.08%は赤色で、他の割合は青色で表示され、どこが最も重いのか一目瞭然です。)行単位でボトルネックを探すにはperf annotate -lが便利です。


Sorted summary for file /home/shun/work/saa/saa
----------------------------------------------

8.29 /home/shun/work/saa/sais/sais.c:198
7.23 /home/shun/work/saa/sais/sais.c:261
7.08 /home/shun/work/saa/sais/sais.c:261
6.52 /home/shun/work/saa/sais/sais.c:259
5.38 /home/shun/work/saa/sais/sais.c:242
5.08 /home/shun/work/saa/sais/sais.c:201
2.72 /home/shun/work/saa/sais/sais.c:180
2.70 /home/shun/work/saa/sais/sais.c:180
...

ボトルネックが一目瞭然です。198行目を書き換えればちょっと速くなるかなーなどと分かるわけです。これで速度が増えるよ やったねタエちゃん!

注意点とperfの実装



さて、よくよく見てみますと8.29%の処理時間を取っているのはレジスタ間cmp命令です。レジスタ同士の比較でなんでこんなに時間を取っているんでしょう? それを説明するためにはperfの実装を知る必要があります。

perfはハードウェアの持つパフォーマンスカウンタを利用します。パフォーマンスカウンタはある一定のイベントが起きるごとに加算され、指定された回数のイベントが起きるごとに割り込みを掛けます。perf recordでは、この割り込みを掛けたときのIPレジスタの値を保存することができます(perfシステムコールにPERF_SAMPLE_IPを指定)。perf reportではこの値を読み出し、対応するアドレスを逆算して行番号などに割り付けます。

さて、我々が現在使っているCPUは、大抵がアウトオブオーダー実行です。CPU内で発行されるμOPsは命令の字面とは異なる長さ、規模、順序で発行されます。そのため、実際の割り込みが起きた時点でのIPカウンタは必ずしも実際のCPU命令の実行箇所を意味しません。IPカウンタの値なんて飾りです。偉い人にはそれがわからんのです。ですので、この処理時間は「このへんにボトルネック」という意味でしかないことを理解してプロファイルを取ると良いと思います。Atom CPUならまた話が変わるかもね!

このほかperfはpidを指定してattachしたり、perf statで偏差を含めてカウントしたり、その他今回紹介しなかった様々な機能を持ちます。皆さん是非遊んでみてください。

どうでもいいこと



今使っているブログシステムは<を入力するのに&lt;と入力しなければならず、またタグも全部手打ちと大変使いづらいです。
近いうちにはてなあたりに引っ越すかもしれません。はてな記法万歳。
posted by chun at 23:37| 日記

perfコマンドを試してみる(2) 関数ごとのオーバーヘッド

perfコマンドでおそらく一番良く使われることになるのはこれでは無いかと思います。
perf recordコマンドでコマンド実行の際のデータを収集し、

% perf record -- ./saa build chr22.txt
[ perf record: Captured and wrote 20.376 MB perf.data (~890258 samples) ]

perf reportコマンドで結果を出力します。

% perf report
# Samples: 386487
#
# Overhead Command Shared Object Symbol
# ........ ....... ......................... ......
#
56.26% saa ./saa [.] induceSA
39.16% saa ./saa [.] sais_main
0.57% saa ./saa [.] suffix_array::build_buffer(std::vector<unsigned c
0.54% saa [kernel] [k] copy_user_generic_string
0.29% saa [kernel] [k] clear_page_c
0.18% saa ./saa [.] getBuckets
0.11% saa /lib/libc-2.10.1.so [.] memset
...


この例ではSA-ISを使って遊んでいたので、saisの関数が表示されれています。どこで時間を使っているかが一目瞭然ですね。

call graph付きでプロファイルを取ることもできます。この場合、-g付きでrecordを走らせ、reportも-g付きで実行します。ただ、この場合ユーザープログラムの側のcall graphは見えません。理由はちょっと謎なので後で調べてみようと思います。

% rm perf.data
% perf record -g -- ./saa build chr22.txt
% perf report -g
55.16% saa ./saa [.] induceSA

38.59% saa ./saa [.] sais_main

0.59% saa [kernel] [k] copy_user_generic_string
|
|--85.17%-- generic_perform_write
| generic_file_buffered_write
| xfs_write [xfs]
| xfs_file_aio_write [xfs]
...


しかし、perfはただのCPU時間プロファイラではありません。perf listをするとperfで取れるパフォーマンスカウンタの一覧が分かります。cache miss, branch miss, TLB miss, page faults, kernel page allocationなども取ることができます。(回数ではなく、オーバーヘッドを計測するものと思われます。この辺はprefの実装にも関係してくるのですが、後ほど時間があれば調べて書きたいです)
% perf record -e branch-misses -- ...
% perf report


常日頃からCPUに必要なのは良いプロファイラだと言っている(嘘)私ですが、perfは素晴らしいです。このご時世にC/C++をわざわざ使っているようなプログラマはこの恩恵が分かるはずです。みなさん進んで2.6.31のヒトバシラーになりましょう!!!1121!

(次回に続く)

おまけ
前回のやり方だとmanが入らないので、追加で
sudo aptitude install asciidoc
make doc && make install-doc

しておくと良いです。
posted by chun at 06:09| 日記

2009年10月19日

perfコマンドを試してみる(1)

Ubuntu 9.10 (Karmic)はLinux kernel 2.6.31が入れられています。2.6.29-2.6.31はいろいろと面白い変更が入っているのですが、その一つにperformance counterの導入があります。これを使って遊んでみます。

sudo aptitude install linux-source-2.6.31 libelf-dev binutils-dev
tar xjf /usr/src/linux-source-2.6.31.tar.bz2
cd linux-source-2.6.31/tools/perf
make && make install

すると、勝手に$HOME/binにperfコマンドをインストールしてくれます。インストールが終わったら

sudo ~/bin/perf top

とかすると、ちゃんとkernel 2.6.31以降が入っていればperformance counterが動く様子を見ることが出来ます。

(次回に続く)
posted by chun at 10:22| 日記

連続値最適化

たまにはまともな話を書いて真面目なふりをしようかと。

SEA2009のInvited talkに出てきた
Experimental Differentiation-free Optimization Algorithm Comparison
http://dx.doi.org/10.1007/978-3-642-02011-7_3
(pdf / slide: http://hal.inria.fr/inria-00397334/en/ のfull text / appendices)
が面白いです。このtalkでは微分を用いることが出来ない連続値最適化問題のアルゴリズムを比較しています。
扱っているアルゴリズムは
BFGS
NEWUOA
CMA-ES
PSO
DE
などです。BFGS以外は90年代以降と、新しいです。

なかでもpresenterのイチオシはCMA-ESです。条件数が高い状況にも強く、また安定にglobal optimumを発見することができます。コストもBFGSのたかだか70倍程度ということで、global optimumを探せるという能力でお釣りが来ます。

実装も単純なので遊んでみようと思います。まずは衛星回収あたりで。
posted by chun at 07:45| 日記