大江戸Ruby会議06での発表です。 Presentation at: https://asakusarb.github.io/oedo06/ Moved from: https://niconare.nicovideo.jp/watch/kn2388

1. Rationalを（もうちょっと）最適化してみた
斎藤ただし Tadashi Saito
Asakusa.rb

2. ●
作業の歴史
●
過去のLT復習
●
最適化終了後の成果
●
とっても速い話
●
まとめ
御品書

3. （もうちょっと）？
●
RubyKaigi 2015のLTで最初の発表

4. 斎藤のRational(C拡張)最適化の歴史
●
2015年度Ruby Association助成金プロジェクトに応募
●
採択、CRuby本体へのマージを目指して作業
●
RubyKaigi 2015のLTで中間発表
●
なんとかギリギリ2016年末のRuby 2.4に入った
●
mrknさん & 関係コミッター皆さんのおかげ
●
そして今日のTalk

5. ふりかえってみる
●
まずRubyKaigi 2015のスライドを（ざっくり）
復習
●
LTを引用するのでスライドのスピードが
上がります

6. Rational

7. 有理数ライブ
ラリ

8. 1
2
+
2
3
=?

9. Floatでは表現
できない（有限
精度、2進数）

10. BigDecimalで
も表現できない
（物理メモリは
有限）

11. Rational

12. 1/2r + 2/3r

13. 1/2r + 2/3r
#=> (7/6)

14. 直感的な結果

15. Ruby 1.0か
ら存在

16. 注: rational.rb
原作者&メンテナー
今日いらっしゃる石塚さん
（大きな拍手）

17. Ruby 1.9で
組み込みクラ
スに

18. Ruby 1.9.2で
はTimeの内部
表現に使用

19. Ruby 2.1で
はリテラルが
導入（1/2r）

20. どんどん重要
なクラスに

21. それほど速く
ない

22. rb_funcall()

23. C拡張なのに
Rubyレベルのメ
ソッド呼び出し
をしている

24. ●
移植スピード?
●
Cで多態を実装する
のが大変だった?

25. Rubyレベルのメ
ソッド呼び出し
が存在していた

26. prof(1)でプ
ロファイルを
取ってみる

27. rb_funcall()
がたくさんの
時間を消費

28. Cレイヤーのみで
の素直な計算で置
き換えたい

29. Ruby
Association 助
成金プロジェク
トに応募
http://www.ruby.or.jp/ja/news/20150803.html

30. Ruby
Association 助
成金プロジェク
トに採択!!1
http://www.ruby.or.jp/ja/news/20151116.html

31. ●
2015-10-30 採択結果の公表
●
2016-1-4 中間報告
●
2016-3-4 最終報告

32. ●
2015-10-30 採択結果の公表
← HERE! #ragrant2015
●
2016-1-4 中間報告
●
2016-3-4 最終報告

33. どのくらい速く
なったか?
(作業中)

34. Integer#gcd +
+
huge
rational
+
float
+
fixnum
+
bignum -
- huge
rational
- float
- fixnum
- bignum *
* huge
rational
* float
* fixnum
* bignum /
/ float
/ huge
rational
/ fixnum
/ bignum
0.000
0.500
1.000
1.500
2.000
2.500
3.000
3.500
4.000
ｆ
ａ
ｓ
ｔ
ｅ
ｒ

35. 最大で3倍以上
速くなった!

36. Ruby 3x3!!!

37. 復習おしまい
●
ここまでがRubyKaigi 2015時点での成果
●
スライドのスピードが落ちます

38. その後
●
2016年3月にRuby Association助成金プロジェ
クト最終報告を提出（終了）
●
バグを潰しつつBTSにissueを登録、色々あり
つつマージされる
●
2016年クリスマスにRuby 2.4.0リリース
●
作業の成果は既に皆さんの手元に

39. 最終的には
●
どこまで速くなったか?
●
リリース済みの2.3.3 と2.4.0で比較

40. 2.3.3 vs 2.4.0（比）

41. 分かること
●
最大で3.6倍前後の高速化
●
手を入れた部分全体の平均でも1.6倍弱の
高速化
●
60メソッド（場合分け）の広範囲で高速化
●
触った部分でとても遅くなった所はなかった

42. 広範囲の高速化の方法
●
基本的にrb_funcall()を置き換えただけ
●
引数を伴う場合(Rational.+(Integer)など)、
地道にクラスの数だけ場合分け
– 忘れると即SEGV
●
クラスに応じた関数を直に呼び出し
– 必要なら既存関数をexport

43. なんで一部だけ3倍以上も速く?
●
rb_funcall()の置き換えに加えて
●
約分の回避
●
既存の有理数関数を利用するため、(整数)を
(整数/1)という有理数として足し算・引き算していた
●
約分が可能か? チェックが毎回走る
●
最初から自力で通分して回避

44. グラフその2

45. とても速い(?)
●
140倍近く速い(?)
●
ところでベンチマークの方法
●
1秒間全力で計算を繰り返す
●
それを5回やる
●
全体では5秒ちょっとかかる、はず

46. 実行の様子

47. とても速い(?)
●
なぜ……

48. 2.4.0のバグでした
●
Bug #13084: String cast to Rational on 2.4.0p0 results in
SegFault with Mathn required
●
実行途中でSEGV…… (String#to_r)
●
�
●
気づくとn0kadaさんが直してくださった
●
報告から9時間でfix (!)
●
mathnとRationalを使う人は2.4.1に期待

49. まとめ
●
斎藤のRational最適化は無事終了
●
2.4.0でマージ
●
60パターンの広範囲で、最大3倍超・
平均1.6倍速の高速化
●
うっかり入ったバグは2.4.1で直ります
● �

50. Questions?