Kawasaki.rb #001 第1回ミートアップを開催しました #kwskrb

6/26にKawasaki.rbの第1回ミートアップを開催しました。

Kawasaki.rb #001

ありそうで以外となかった、川崎でのRubyの勉強会です。
初心者からコアな人までざっくばらんに話が出来ればと思って始めました。
Doorkeeperの参加者を見ていただくとわかるのですが、予想以上に豪華な顔ぶれでhomeなはずなのに、ドキドキが止まりませんでした。(参加者の2割近くコミッターとか！！！)

当日、NKT77さんとたるいさん(@taru)にトークをしてもらいました。

@kishimaさんによるtogetterまとめはこちら。

01. NKT77さん 「Hadoop with Ruby-僕がPythonを選んだ理由」

このタイトル自体は僕が付けた釣り仮題なのですが、内容としてはRubyをHadoop Streamingで使うときにHashが遅いという事例の紹介でした。(モリスさんを釣ってしまって恐縮したのはここだけの話)

(2013/07/04 資料を追加しました)

ざっくりまとめると

• Hadoop streamingでRubyを使うときに、Stringで100万程度のkeyのHashを作ると結構遅い
• HashのLookupも非線形に速度が増えている
• Pythonにしたら10倍速くなった(AWSのEMR料金も10分の1に！) という内容です。しかし、AWSのおかげで処理時間=お金に換算できる世界になったのが、改めてインパクトが大きいですね…。

なお、HashがPythonと比較して遅い原因としては、

1. GC
2. Hash関数がsiphashなため
3. rehashの際の閾値がRubyの方が保守的 といった理由が考えられるとのことでした。(間違いがあればご指摘ください)

02. たるいさん(@taru) 「メモリアロケーションからみた拡張ライブラリに大切なこと」

資料を見ていただければ内容はわかると思います。

• 初めての拡張ライブラリの作り方
• ArrayがGCされないようにRB_GC_GUARD()しましょう
• GC.stress = trueすると、GC強制的に走らせて再現しにくいバグを潰せる
• NKT77さんが報告していたGCのせいでHashが遅いのはtrunkでは改善しました！(凄い！) 最後の、Hashの速度向上については田中哲さんも確認されたようです。

kawasaki.rb #001 であった、GC のせいで Hash が遅いが trunk は問題ないというのを追試してみた。たしかにそんなそういう感じになっている。 pic.twitter.com/mrtKNViEsq

— Tanaka Akira (@tanaka_akr) June 28, 2013

当日は散々、「Rubyの集まりじゃないのかよ！」とか「Pythonを宣伝する場所かよ！」とか突っ込まれていましたが、これで皆さん安心してHadoop StreamingでRubyを使ってもらえますね。

今後は、初心者にやさしいネタも考えつつ進めて行きたいと思います。（いらないのかな？)

次回は、7/24(水)に居酒屋LT(というか焼肉LT)をやりますので、準備ができましたら有る方はメーリングリストとDoorkeeperで告知しますので、興味があれば登録していただければと思います。