Rubyのプロファイリング

カーネル読書会でmallocの話をしていただいたのだが、そのときの質疑でRubyの実装の話がでた。そこで思い立ちRubyをoprofileでプロファイルして見た。（matzさんにトラックバックを張っておく）

# cd /usr/src/ruby-1.8.4/test
# opcontrol --start; ruby runner.rb; opcontrol --stop

適当なRubyアプリケーションをしらなかったので、テストプログラムを実行してベンチマークとした。実行したマシンは1700MhzのPentium M、メモリ１GBのノートPC。

# opreport -l
CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
samples  %        app name                 symbol name
21380    29.7896  vmlinux                  acpi_processor_idle
17321    24.1340  libcrypto.so.0.9.7a      (no symbols)
3137      4.3709  ruby                     os_each_obj
1828      2.5470  ruby                     rb_eval
1407      1.9604  ruby                     ruby_yyparse
1198      1.6692  ruby                     st_lookup
1058      1.4742  ruby                     gc_mark_children
1009      1.4059  ruby                     rb_call0
1008      1.4045  ruby                     rb_thread_save_context
988       1.3766  libc-2.3.4.so            _int_malloc

ノートPCなのでacpi_processor_idelが出ているのと思うのだけど、libcrypto.soが出てくるのはなんでだろう？
まあ、気にしないことにする。CPUを回しきれていないのはチューニングの余地が大きいということだと思う。

# opreport -l|grep libc
17321    24.1340  libcrypto.so.0.9.7a      (no symbols)
988       1.3766  libc-2.3.4.so            _int_malloc
809       1.1272  libc-2.3.4.so            malloc_consolidate
436       0.6075  libc-2.3.4.so            free
300       0.4180  libc-2.3.4.so            _int_free
252       0.3511  libc-2.3.4.so            memcpy
233       0.3246  libc-2.3.4.so            malloc
127       0.1770  libc-2.3.4.so            strcmp
109       0.1519  libc-2.3.4.so            __ctype_b_loc
86        0.1198  libc-2.3.4.so            msort_with_tmp

libcを見てみると、malloc関係にコストがかかっていることがよくわかる。mallocかfreeかというとfree系の方がコストがコストがかかっている。malloc_consolidateというのはfreeするときにメモリをくっつけるという操作なので、free系である。

Rubyの大きめなアプリケーションがあるとそれをプロファイリングして見ると面白いと思う。何かいいベンチマークはないだろうか？

それとわたしのノートPCではキャッシュミスを測定できないので、Xeonのマシンでキャッシュミスを測定すると面白いと思った。GCの時ぼろぼろキャッシュミスが発生するということだが、それを巧みに減らすというのが課題になる。

Comments

[投稿： kosaki]

ささださんからの質疑にもありましたが、malloc_consolidateは遅延併合戦略によって小さいサイズはmalloc時にまで遅延されまする。
スクリプト言語だと、こっちにはまる事のほうが多いんじゃないでしょうか。
あと、わたし、Rubyは全然詳しくないのですが os_each_objがGCでのオブジェクト一周ちゃうんかいね。名前的に・・・
しかし、libcryptが大きすぎるのでベンチの選択に改良の余地アリとオモタ(^-^/

[投稿： hyoshiok]

kosakiさん、コメントありがとうございます。libcryptが大きすぎるのはわたしの環境のせいかもしれないのですが、よくわかりません。なんか変なデーモンが動いているのかなあ？とほほ。

[投稿： hyoshiok]

http://d.hatena.ne.jp/hyoshiok/20061002#p2
でRubyのキャッシュミスの計測結果を出しました。
ソースを見たら、これはprefetchでレイテンシーを隠蔽できるパターンなのでパッチを作ると面白いかも。（忙しい時に限って遊びたくなる）