RubyのGC改善による私のエコライフ

4,658 views

Published on

Published in: Technology
  • Be the first to comment

RubyのGC改善による私のエコライフ

  1. 1. RubyのGC改善による 私のエコライフ レジ袋は結構ですよ(2009夏) nari ネットワーク応用通信研究所 Powered by Rabbit 0.6.1
  2. 2. 先に
  3. 3. お詫び いまからCRuby内部の 大変マニアックな 話をします
  4. 4. しかも30分も
  5. 5. m(_ _)m
  6. 6. 今日話す内容 CRubyのGCを改善しましたというお話し GC = ゲームキューブ? 今日の話にはついていけません 5/148
  7. 7. 今日話す内容 GC改善 = ゴミ処理機性能アップ なんとなくエコっぽい 流行ってるし なんとなくタイトルに 6/148
  8. 8. アジェンダ 1. 自己紹介 2. CRubyのGC改善とエコ 3. 現在のCRubyGC概要 4. 問題点 5. エコ活動 6. CRubyGCの今後 7/148
  9. 9. アジェンダ 1. 自己紹介 2. CRubyのGC改善とエコ 3. 現在のCRubyGC概要 4. 問題点 5. エコ活動 6. CRubyGCの今後 8/148
  10. 10. 自己紹介
  11. 11. 自己紹介 nariと申します id:authorNari(はてな) nari3(twitter) 量産型中村 10/148
  12. 12. 自己紹介 ネットワーク応用通信研究所に所属 島根の方から来ました 元アイス工場勤務,現NaCl勤務 注:NaClにアイス工場支社はない 「RailsのWebアプリを受託開発」などなど お仕事募集中 11/148
  13. 13. 自己紹介 無類のGC好き 「CRubyGCについて考えたりするコミッタ」 12/148
  14. 14. 宣伝(1)
  15. 15. 絶対復習というサービス Railsで作ってます 復習を促進するサービス 復讐は促進しません>< 詳細は割愛 15/148
  16. 16. 続きはWEBで 16/148
  17. 17. 宣伝(2)
  18. 18. GCは作らない
  19. 19. 巻末 GCはこれほど知られているのに 日本語でGCについて執筆された本がない 20/148
  20. 20. 数少ない GCファンに朗報!!
  21. 21. なんとGC本 執筆中
  22. 22. 内容 アルゴリズムの話 実装の話 Pythonの.. androidの.. v8の.. rub..niusの.. 監修は超大物 23/148
  23. 23. 問題 誰が買うの? 今のところ笹田研のささだ先生が有力候補 24/148
  24. 24. 宣伝はこれくらいで..
  25. 25. 恒例のアンケート
  26. 26. GCに興味ある方? ノシ
  27. 27. gc.cを読んだ事がある 方? ノシ
  28. 28. GC本が出たらかうよ!っ て人? ノシ
  29. 29. 予想...5人
  30. 30. アジェンダ 1. 自己紹介 2. CRubyのGC改善とエコ 3. 現在のCRubyGC概要 4. 問題点 5. エコ活動 6. CRubyGCの今後 31/148
  31. 31. CRubyのGC改善とエコ
  32. 32. GCとエコの密着した関 連性をお話ししましょう
  33. 33. GCとエコの関連性 CRubyGCを改善する 世界の RubyHacker のPCの熱量が1%下 がるとする Rubyに費やす1ヶ月の電気使用量100円 1円分お得 => 1円分エコ 34/148
  34. 34. GCとエコの関連性 世界にはRubyプログラマ何人くらいいるだ ろう? まぁ,100万人くらいとしよう 100万人 X 2円 => 月間200万円エコ 年間2400万円エコ 35/148
  35. 35. ルピィに換算 ルピィに換算(インドの通貨) 3円 => 1ルピィ 年間約800万ルピィ 36/148
  36. 36. GCを改善すれば 年間約800万ルピィ分の エコができますね!
  37. 37. アジェンダ 1. 自己紹介 2. CRubyのGC改善とエコ 3. 現在のCRubyGC概要 4. 問題点 5. エコ活動 6. CRubyGCの今後 38/148
  38. 38. 現在のCRubyGC概要
  39. 39. 現在のCRubyのGC
  40. 40. マークスイープ方式
  41. 41. CRubyのヒープ構造 malloc にて 16Kバイト のメモリ領域を確保 ヒープスロット 42/148
  42. 42. CRubyのヒープ構造 オブジェクトの配列を作成 オブジェクトサイズの20バイトでアラインメント オブジェクトはそれぞれフリーリストでつながっ 43/148 ている
  43. 43. オブジェクトの割り当て 1. 処理系から割り当て要求 2. フリーリストからオブジェクトを一つ取り出し 3. 取り出したオブジェクトを初期化 44/148
  44. 44. マーク処理 1. フリーリストが尽きるとマーク処理開始 2. プログラムから見える範囲のオブジェクトを 再帰的にマーク 3. マーク処理は各オブジェクト内フラグのマー クビットを1にする 4. 全てのルートに対してマークを終えるとマー ク処理終了 45/148
  45. 45. スイープ処理 1. ヒープ内のすべてのオブジェクトを走査 2. マークされているオブジェクトはそのマーク を消す 3. マークされてないオブジェクトはゴミと見な し,スイープ処理を行う 4. ヒープ内を全て走査し終わるとスイープ処 理終了 46/148
  46. 46. シンプルな マークスイープの実装
  47. 47. マーク(印付け)して スイープ(掃除)する
  48. 48. ここは雰囲気だけ つかんで貰えば
  49. 49. アジェンダ 1. 自己紹介 2. CRubyのGC改善とエコ 3. 現在のCRubyGC概要 4. 問題点 5. エコ活動 6. CRubyGCの今後 50/148
  50. 50. 問題点 その1
  51. 51. CopyOnWrite
  52. 52. CopyOnWrite 多くのLinux環境では子プロセス作成時 (fork)のメモリは共有領域に置かれる 書き込みがあった際に,それぞれのプロセス の私有領域にコピーされる (注)Rubyの機能ではない 53/148
  53. 53. 子プロセス生成時のメモリ領 域 54/148
  54. 54. 実際にはコピーしない 読み込みをする時はそれでも充分 55/148
  55. 55. 書き込み(write)が発生 56/148
  56. 56. そのタイミングで私有領域に Copy 57/148
  57. 57. Writeの時に
  58. 58. Copyする
  59. 59. CopyOnWrite
  60. 60. 実はCRubyGCと CopyOnWriteは相性が 悪い
  61. 61. 無駄なコピーの発生 CRubyGCではマークの際に生存している 全てのオブジェクトに対して印付けする つまりWriteする forkしたプロセスの場合,CopyOnWriteが 効いて無駄なコピーが.. 62/148
  62. 62. 無駄なコピーの発生 63/148
  63. 63. アジェンダ 1. 自己紹介 2. CRubyのGC改善とエコ 3. 現在のCRubyGC概要 4. 問題点 5. エコ活動 6. CRubyGCの今後 64/148
  64. 64. エコ活動 その1
  65. 65. BitmapMarkingGC オブジェクトの印付け用bitのみを別の領域 に移す これをビットマップと呼ぶ オブジェクトの生存,死亡はビットマップにて 管理 マーク時に直接オブジェクトを操作する事が なくなる 無駄なコピーが発生しにくい 66/148
  66. 66. Bitmap領域を確保 Bitmapは非常に小さいサイズ 67/148
  67. 67. そこに印付けする Copyが発生しない 68/148
  68. 68. BitmapMarkingGC導入前 例 RubyEnterpriseEditionというRuby実装 (REE) Hongli Laiさん達によって作成 REEと呼ばれる 69/148
  69. 69. REEとは? Apache+passenger 用のRuby処理系 ruby1.8.6ベース Apache が fork() してリクエスト捌いてる GCをBitmapMarkingGC 70/148
  70. 70. REEでの改善 RubyOnRails+REE+Apacheで動作させた リクエスト毎秒 22% が高速化 総メモリ使用量が 31% 削減した 71/148
  71. 71. じゃあ,これを本家に取り 込んじゃおうよ!
  72. 72. ちょっと問題が…
  73. 73. ビットマップ位置探索 それぞれのヒープスロットにビットマップ領域がある 74/148
  74. 74. ビットマップ位置探索 75/148
  75. 75. ビットマップ位置探索 オブジェクトのアドレス->Rubyのヒープスロット 76/148
  76. 76. ビットマップ位置の探索をど うしよう? オブジェクトのアドレスしか渡ってこない アドレスから紐付くヒープスロットを見つけな ければならない. 77/148
  77. 77. 単純に考える オブジェクトにスロットを指すポインタをもうける 78/148
  78. 78. 駄目,絶対 ヒープ領域が大きくなりメモリ消費量が大き くなってしまう せっかく1.9でオブジェクトをダイエットした のに.. 色んな人から怒られる 79/148
  79. 79. REEはどうするか
  80. 80. 線形探索 ちょ,線形探索ですか>< 81/148
  81. 81. 問題点:遅い ビットマップ位置探索に線形探索を使用して いる forkしないプログラムの場合,GCがビット マップマーキング処理の分遅くなる 82/148
  82. 82. REEは1.8系なのでセーフ 1.8系のRubyヒープスロットは1.8倍で大きくな る ヒープスロットはまぁ増えても20個とかそのくら い 83/148
  83. 83. 1.9系ではアウト 1.9系はRubyヒープスロットのサイズが固定 84/148
  84. 84. 1.9系ではアウト Rubyヒープスロット自体を増やす 1.8系で10個 => 1.9系だと357個 これだと線形探索はつらくなってくる 1.9に適した探索法を見つける必要がある そのまま取り込めないね… 85/148
  85. 85. アイデア
  86. 86. アライメントを利用すれば いいじゃないか
  87. 87. 基本的なアイデア ヒープスロットサイズは16KB 16KB = 2の14乗 0b100000000000000 88/148
  88. 88. 基本的なアイデア 下位14bitが全て0のアドレスがヒープスロット内の どこかに存在するはず 89/148
  89. 89. 基本的なアイデア 90/148
  90. 90. ビットマップ位置探索 アドレスが 0b10101010111010000 91/148
  91. 91. ビットマップ位置探索 マスクする 0b10101010111010000 & 0b11100000000000000 0b101000000000000000 92/148
  92. 92. ビットマップ位置探索 ビットマップ位置が探索可能 93/148
  93. 93. 問題解決 O(n)からO(1)へ 大分早くなった 94/148
  94. 94. ただしやっぱり少しだけ 遅い
  95. 95. ベンチマーク結果 skk.rb ベンチマーク(自作) 96/148
  96. 96. 詳細は論文で! http://www.narihiro.info/ まつもとさんと連名! 97/148
  97. 97. このパッチの行方 一応まつもとさんのパッチ袋へ そのまま永眠かな.. fork()なんて..別にいいし.. 98/148
  98. 98. (´・ω・)...
  99. 99. さぁ,気を取り直して 他の問題点を探そうじゃ ないか!
  100. 100. ちなみにAndroid DalvikVM これと全く同じ問題がある マルチタスク => いっぱい fork() BitmapMarkingが必要になる 101/148
  101. 101. アジェンダ 1. 自己紹介 2. CRubyのGC改善とエコ 3. 現在のCRubyGC概要 4. 問題点 5. エコ活動 6. CRubyGCの今後 102/148
  102. 102. 問題点 その2
  103. 103. 長寿命 オブジェクト問題
  104. 104. RubyOnRailsの Rubyヒープ使い方を 調査してみた
  105. 105. 結果 106/148
  106. 106. 構文木オブジェクトが 半数を占めていた
  107. 107. 構文木オブジェクトって?
  108. 108. 何かがおかしい… YARV命令列にしたら構文木オブジェクトは いらない 自然にGCされるはず ずっと生きているのは何でだろう? 113/148
  109. 109. さらに調査 以下の種類の構文木オブジェクトが多かった 1. NODE_WHILE 2. NODE_METHOD 3. NODE_FBODY 4. NODE_CFUNC 114/148
  110. 110. メソッドで使われる構文木 NODE_METHOD,NODE_FBODY,NODE _CFUNC これらはメソッド生成時に使用&保持 長寿命 115/148
  111. 111. NODE_WHILE YARV内のインラインキャッシュ(最適化)に 使用 長寿命 116/148
  112. 112. 長寿命なオブジェクトが半数 を占める 半分は無駄なマークになる スイープはあんまり関係ない 117/148
  113. 113. アジェンダ 1. 自己紹介 2. CRubyのGC改善とエコ 3. 現在のCRubyGC概要 4. 問題点 5. エコ活動 6. CRubyGCの今後 118/148
  114. 114. エコ活動 その2
  115. 115. まず,まつもとさんに相談 昔は構文木オブジェクトはGCの対象じゃな かった どこかで面倒になってGCの対象にしちゃっ た 構文木の部分だけ世代別にしたらどう? 120/148
  116. 116. おぉ!なるほど!
  117. 117. 長寿命GC (勝手に命名)
  118. 118. 長寿命GC 123/148
  119. 119. 長寿命GC 124/148
  120. 120. メリット マークするオブジェクトが減る ベンチマークが遅くならない make benchmark 125/148
  121. 121. デメリット ベンチマークがぐんと早くはならない make benchmark ちょっぴり早い 126/148
  122. 122. ライトバリア問題もクリア 構文木オブジェクトはRubyレベルから参照 出来ない ライトバリアを入れるのがコア内部で完結 Cの拡張ライブラリとか考えなくていい 127/148
  123. 123. 効果のあったベンチマーク ao-bench id:hogelogさん,id:miura1729さんに測ってい ただきました 128/148
  124. 124. パッチのその後 trunkに無事取り込まれた 色々改良してきたけど初採用 感激(T.T) 131/148
  125. 125. が,,
  126. 126. 反応 この辺の インラインキャッシュ やら ノードとかその辺 は,GC 対象外領域にしてしまおうと思っています. by ささださん 133/148
  127. 127. (´・ω・)...
  128. 128. Rejectされる日は近い
  129. 129. 話の続き
  130. 130. 昨日の懇親会 この辺はGC対象外にしたよ! あれはバグを生むし,とっちゃおうよ by ささださん 137/148
  131. 131. (´・ω・)...
  132. 132. 早めにReject しますね!
  133. 133. カバレッジも100%に!
  134. 134. アジェンダ 1. 自己紹介 2. CRubyのGC改善とエコ 3. 現在のCRubyGC概要 4. 問題点 5. エコ活動 6. CRubyGCの今後 141/148
  135. 135. CRubyGCの今後
  136. 136. 個人的にやりたい事(1) 色々な処理系のGCいいとこ取り 執筆の関係で色々なGCを読んでいるので CRubyに使えそうなのはメモってる 143/148
  137. 137. 個人的にやりたい事(2) BoehmGCを適用してみる運動 一応動くようにした すごく遅くなった ちょっとチューニングする必要があるかな... 144/148
  138. 138. まとめ エコ活動しました なんやかんやで何も成果がありませんでした 先生の次回作にご期待ください 145/148
  139. 139. 提供 (株)ネットワーク 応用通信研究所
  140. 140. ご静聴 ありがとうございました
  141. 141. 質疑応答 タイム

×