_ PTT
http://ptt.prosym.jp/arc/388/
タイトルに魅かれてひさびさに行ったら、すごい楽しかった! はじめて HTM 含む TM に価値があると思える話だった。未だに STM は信じてないけど、後の呑み会で STM が速くなりうるケースはあるよんと教えてもらって、なるほどなぁとかそういう。
ちょうどよくわかってなくて、なんとなく知りたいなーと思ってたあたりをわかりやすく、かつ詳しくはないけどなんとなく言葉は知ってる ruby の文脈で語ってくれたので、僕にとってわかりやすめでラッキーだったというのもあるとは思うけど、すごく良い話だったと思う。後でリクエストしようと思ってたけど忘れてたんだけど、発表資料どっかに上がるといいなー。
遅れて行って、最初の頃は発表より GSL っていう SC2 の大会の今日の動向の方が気になってたけど、後の方は GSL どうでもよくなっている程度には面白かった。聞いてる最中に色々疑問が出てきて、これは後の方で語られるかもな…と思いつつ質問リストをメモしつつ聞いてると、ほとんどの疑問がすぐ後で明解に語られる感じで、なにやら突っ込まれ慣れてそうな人の話ってのはいいなーとか思った。いくつか質問として聞いたこともあったけど、わりと些細なことばかり。そしてその僕の疑問に対する解答は、僕が明示的に聞いたものに対しても勝手に解答されたことに対しても、僕の期待以上によく考えられてる感じで明解に答えられて、感心な感じだった。
やーすごい人はそこらじゅうにいるもんだなぁとひさびさに思いました…
メモをとりあえずダンプ
- ハードウェアで TM やる時は eager HTM と lazy HTM てのがあってどっちがいいかってのは論争あるけど、とりあえず eager が実装ラクらしい (あんまよくわかってない)
- TM 中に競合があった時の retry 時に待ち時間は入れてるのかなーと思ったのだけど、 ruby のケースではあんま関係なかったらしい
- 件のメインフレーム CPU にはランダム時間待つ命令があるらしい
- TM に入る時の粒度は動的に調整するとよかったりなのかなーとか思いながら聞いてたら動的にやったらしい
- 動的にやるとそれが落ちつくまでロック取らないといけなくない? と質問したところ 1. 最初の 300 回くらいの結果で良しとするのでたいして問題ない 2.かつ実際のところ多少不正確でもいいのでロック取ってない、との解答
- inline method cache は無効化したとのこと。それも TLS に置いたら良くないの? て聞いたらめんどくさかったとのこと。あーそうかアレって命令列にひもづいてる感じだっけみたいな。ていうか inline ってそういう意味の inline なんかな
- cahce line が 256B とかあって false sharing 起きるから TLS ぽいものは 256B にアラインした
- だいたいメモリ管理、具体的には rb_newobj と gc_lazy_sweep で競合起きてた
- pthread_getspecific ってクソ遅いから __thread 使えないの? ってのはコンパイラツールチェインが対応してないとのこと。 pthread_getspecific で取ったポインタを後生大事に使いまわしたらいいんじゃ、って質問にはなるべく使いまわすようにはしてるとのこと。
- haswell でどうなんよ、と思ってたらあっちは件のメインフレーム CPU よりデバッグ情報少ないから大変そうだけどパラメータいじったら動くんじゃね的な
- 100 コアあったらどうよ、という質問に対しては 8 thread で既にグラフが寝始めてるからどうだろ、と。ただベンチマークに使ってるケースがイマイチバカ並列じゃないから、そのへんの特性もあるとのこと
- 競合起きた位置わかんるのかなーてかどうやってチューニングしたんだろ、と思ってたら、読み書き集合がぶつかった時の命令のアドレスと、ぶつかった物理アドレスはわかるとのこと。それじゃあ色々キツいわけだけど、 haswell だともっとキツいからキツそう的な。
あと呑み会でコンパイラの人の話を聞いてて覚えた略語
- PRE: partial redundancy elimination
- GVN: global value numbering
(02:41)