観察日記 2010-07-09
とある日のデバッグ風景
んー、 ruby 1.9.2dev (2010-06-14 revision 28321) [i386-cygwin] が中々愉快な事になってるな…どこで躓いてるんだろ http://mzr.jp/ruby100615.txt
メンテナはさっき風呂に行きました
test3の中身がないと
ちょいお待ちを＜test3の中身
あー
fork?
http://mzr.jp/test3.txt
これかな
forkではないのか。
何行目か出ないもんだったっけ?
出てないですねぇ…何なのやら。
ミニマム再現ケースが作れるといいんだが
4月ぐらいの1.9.2系なら動くんですが、最近のだとダメみたいで
まあ見るからに危険が危ないけど。
socketとipaddrとyamlとdateとppとkconvは抜いても再現できそうな気はするな。
思わず見なかった事にしたくなるな>test3
timeoutもなくても再現できるかもだな。
cygwinは最近makeしてないから再現できないなあ
http://mzr.jp/test3_2.txt とりあえず、これでも再現する気配？
うむ
timeout必要でした?
おぉ、ちいさくなった
これから試してみます
timeout(60) { } を外しても時々出てますね…
メインスレッドの loop{loop{..}} は単にsleepでいいんじゃないか疑惑
あちゃ
http://mzr.jp/test3_3.txt これでもダメでした。
えっ
運がよかったら落ちる前に実行が終わりそう
この次にsleepというのが俺の想像するミニマム再現ケース
と言いながら貼ろうとしてた。
で、なんだろうな。
Segmentation fault (core dumped) するか、 CPU時間を浪費しまくってプロセスが固まってるかしてますね ＜ test3_3
ああ、終わるときに(Threadを回収しようとして)落ちるのかな。
つまりどうやっても落ちるみたいな。
ruby更新したせいじゃなくて実はcygwinを更新したとかないですか?
そうだったら僕ら嬉しいのに。
http://mzr.jp/mkruby.txt してから BUILD/ で make install してるだけな感じですねぇ＜cygwin更新してない
Mizar: そうですかー。まあそりゃそうですよねー。ちくしょう人のせいにしたかったのに...
まぁ、もう一度 2010-04-01 現在のソースでビルドしてみます
何が変わったかなあ。thread_pthread.cは見てないんだよな
bisectして犯人つるし上げを
r27789
r28183
どっちか?
後者は違う気がするな。
前者も多分違うよなあ。
2010-04-01 現在のソースでビルド完了。 http://mzr.jp/test3_3.txt でフリーズする事は無く、エラーも無く、すぐ終了しますね…謎。
cygwinでbisectしたくないですよねえ。
先に1.9.2が出ちゃうよ
メンテナが現れた
なかまを呼んだ
しかし 誰も現れなかった
あやしいrevision範囲の半分をおまえにやろう
バグのこうげき!
メンテナAはしんだ
メンテナBはしんだ
メンテナCはにげだした
しかし まわりこまれてしまった
trunk@27552 でも試してみますね
http://github.com/shyouhei/ruby/commit/a08cb1282f97c752cd1ec36bfda4212afb8de9e4 どうやらこのコミットが境みたい？
{util_mput} Commit a08cb1282f97c752cd1ec36bfda4212afb8de9e4 to shyouhei's ruby - GitHub http://tinyurl.com/2azfhc2
おお、例のやつですか
r27789
{util_mput} [ruby] Revision 27789 http://tinyurl.com/2a7oyqe
ふむ
スレッドのスタックサイズ間違えてる系かなぁ
俺はこの差分を一度チェックしたことがあるらしい。ブラウザのキャッシュによると。
ということは、以前から何らかの疑いは抱いてるんだな。
わたしもなんかこれ見覚えあるな
signal周りって鬼門なんだよな
5月13日ねえ。
UTCだから実質14日か。
Mizarさんが気づいたのが6月15日でしたな
ああ、そうか
その時に俺が犯人候補筆頭として挙げてるのか。
多分違うよなあとか言ってるけど。
この差分の何が原因なんだろう
ていうか、cygwinだとUSE_SIGNALSTACK定義されるのかな
定義されないと思っているんだがどうか
定義されないとすると犯人はthread_pthread.cだから、native_thread_init_stack
を戻せば動く、かもしれない
しかしそれが主役だったんじゃね?
とりあえず__CYGWIN__
なぬ
失敗するとはどういうふうに失敗するの？
上の場合、多くはフリーズしてCPU時間をめいっぱい消費する状態になりますが、たまにエラーメッセージを出してすぐ落ちる事もありますね
よわったもんですなあ
1.9.2 では revert する？
とりあえず __CYGWIN__ かな。
よくわからんので頼んだ
おれもわからんけど
Linux でレアケースで SEGV するのと
cygwin で通常ケースで SEGV するのと
どっちが重要か
cygwinはsignalまわりが中途半端に実装されてるので、分岐・実装が不完全なんだと思う
とりあえず、cygwinだとUSE_SIGNALSTACKが定義されていないと思うので、そこ確認していただけませんか
#ifdef USE_SIGNALSTACKの内側にコンパイルエラーになるような文字列書けばよい
個人的には、cygwinでなら死んでもいいのだが
なんか無意識のうちに私怨が入ってるかもしれない。
paste>
{ko1_ndk} http://www.atdot.net/sp/readonly/mdav4l_nurse
で、そのうえでこのパッチで通るんじゃないかなぁ
native_thread_init_stackをコメントアウトしたら100回やっても再現しなかった
というわけなので
それを入れたらrcでどうですか。
はい
では成瀬たんよろしく。
(勝手に仕切る)
ほい
{znz} biff: [ruby-changes:16516] Ruby:r28507 (trunk): * thread_pthread.c (thread_start_func_1): don't call - http://mla.n-z.jp/?ruby-changes=16516
{znz} biff: [ruby-changes:16517] Ruby:r28508 (ruby_1_9_2): merge revision(s) 28507: - http://mla.n-z.jp/?ruby-changes=16517
Rubinius 1.0
http://www.publickey1.jp/blog/10/rubyjit20rubinius_10.html
{util_mput} Rubyの実行速度をJITで最大20倍に高めたRubinius 1.0がリリース ... http://tinyurl.com/25rpsys
20倍
どこから数えて20倍かという
当社比
187から20倍なのだとしたらYARVだって50倍とか
言ってたんだしまあいい勝負かなあと。
結局50倍なんだっけ?
JRubyは結構頑張ってるけどしょせんRubiniusとかMaglevとかはターゲットが1.8なので
1.9なんて使ってるのは世間的に言えばマゾ
おー＞ダウンロード
そういえばIronRubyのベンチマークってどっかにあったかな
g> IronRuby ベンチマーク
{ko1_ndk} google web bot: InfoQ: IronRuby総まとめ - IronRuby 0.9.0とベンチマーク - http://www.infoq.com/jp/news/2009/08/ironruby-roundup (and 2,250 hits)
3441 files, 13544 examples, 41068 expectations, 1 failure, 0 errors
結構すごい
それ、MRIと共通のテスト?
だとすると驚愕
rubyspecじゃね
いや、違う
なんだ
焦ったぜ
いやrubyspecだったら十二分に凄いんだが
bin/mspec ci --background
rubyspec以外に41068expectationsもテスト書いてるはずがない
(ひどいいいがかり)
% rbx -v
rubinius 1.0.1 (1.8.7 release 2010-06-03 JI) [i686-pc-linux-gnu]
p RUBY_VERSION
1.8.7に決まってるか。
% rbx -e 'p RUBY_VERSION'
"1.8.7"
JIってなんだろ
irbxが見当たらない
sieve.rbでベンチマークしてみた
ruby1.8 sieve.rb 10000000 54.03s user 14.85s system 97% cpu 1:10.83 total
ruby-trunk sieve.rb 10000000 27.56s user 0.18s system 97% cpu 28.445 total
rbx sieve.rb 10000000 10.58s user 0.28s system 98% cpu 11.081 total
はええ
!
まあJITしてりゃ納得の速さ
10s切ってると驚くが、俺としては予想の範囲内だった
おー
でもやっぱ20倍は出てないね
ちょっと手元では遅いので一桁減らしてironrubyで試す
10倍(一桁)違うと見える世界が違ってくるんだけどねえ。
かえろ
3倍で勝てるのか
1.8 1.67sec, 1.9 2.27sec, ir 1.84sec
1.9おせえ
sieve.rb って trunk/benchmark/bm_so_sieve.rb と同じだろうか
なんでだ
だいぶ違うね
smaple/sieve.rb
また指が
sample/sieve.rb
http://github.com/evanphx/rubinius/tree/master/benchmark/
ああ
trunk/sample/なのか
あー，なるほど
ブロック呼び出しだなぁ
trunk/benchmark/bm_so_sieve.rb だとどうでしょうね
速すぎていまいち比較にならんな。
1.8=0.869, ir=0.694, 1.9=0.546
rbxさんどう?
数を増やす必要があるかな
COMPARE_RUBYに複数のrubyを指定する方法はあるだろうか
; か? ; なのか?
そのようだ。
1.9(vc10)=0.211
vc6のクソさが明らかになっただけだった。
おー
速すぎだな
vc9も0.214
なので、やっぱvc6だけ劇的に遅いな。
ruby1.8 benchmark/bm_so_sieve.rb 0.86s user 0.02s system 97% cpu 0.910 total
ruby-trunk benchmark/bm_so_sieve.rb 0.41s user 0.00s system 96% cpu 0.429 total
rbx benchmark/bm_so_sieve.rb 0.62s user 0.06s system 98% cpu 0.697 total
パラメータを1桁増やしてみてもらえませんか
これって8192全部書き換えるの？
それともnum?
num = 40
最近のマシンは速いなあ
ruby1.8 benchmark/bm_so_sieve.rb 400 8.82s user 0.17s system 98% cpu 9.163 total
ruby-trunk benchmark/bm_so_sieve.rb 400 4.01s user 0.02s system 98% cpu 4.104 total
rbx benchmark/bm_so_sieve.rb 400 2.30s user 0.08s system 97% cpu 2.437 total
傾向に変化はないな
とても JITっぽい挙動ですね
あ、大差あった
ひっくり返ったわけか
これを 2 倍速くするのは大変だな
そうそう＞ひっくり返す
VC10+DDKでruby作れなかった。なんでだろ。
どうでもいいか。
VC9+DDKでも作れなかった＞＜ set_abort_behaviorは却下すべきだったか。
rbxは起動するだけで0.5sかかる
そりゃ不利だな。
JRubyよりは速そうだ > 起動
see also [ruby-core:30968] ironruby vs ruby
git で svn cat 相当
gitで昔のバージョンを見るのってどうすりゃいいんだっけ
git cat-file -p REV:file
git show 8361149 eval.c でも見えた
へー。しらなかったです
showとcat-file -pじゃ指定するREVが違うみたいな
showはあるrevisionの中の単独のファイルか
