[#45530] [ruby-trunk - Feature #6311][Open] memmem()によるrb_memsearch()の高速化 — "Glass_saga (Masaki Matsushita)" <glass.saga@...>

12 messages 2012/04/17

[#45554] [ruby-trunk - Bug #6344][Open] 1.9.3 p125, p194 ruby causes SEGV with test_massign.rb on ppc/ppc64 — "mtasaka (Mamoru Tasaka)" <mtasaka@...>

14 messages 2012/04/23

[ruby-dev:45513] [ruby-trunk - Feature #6289][Closed] メソッドのインライン化について

From: "ko1 (Koichi Sasada)" <redmine@...>
Date: 2012-04-13 22:50:18 UTC
List: ruby-dev #45513
Issue #6289 has been updated by ko1 (Koichi Sasada).

Status changed from Open to Closed

Feature request は決意表明の場とは違うので,とりあえず閉じます.
頑張って下さい.

ちなみに,Rubinius という実装が LLVM で JIT compiler を実装しており,inline 化もやっていると思います.

以下,コメントです.
- 「インライン化できるメソッドの条件」は間違い
- 「四則演算や配列操作は明らかにクラス定義、メソッド定義を呼ばないので、インライン化できます」は間違い(厳密には説明が面倒なので略)
- 「これは先ほど作ったメソッドのリストを見て、定義が書き換わったかどうかを判定できます」そう思います.
- 「チェックをループの外に出すのって最適化の基本かなと」そう思います.
- 「分岐予測テーブルを汚染しそう」そう思わなくもないですが,他で散々汚しているし,最近の CPU は BTB もでかいし.
- 「もしかしてRuby1.9で既にやられてるのかな」やっていません.

あとは,on stack replacement (JVM のほうで資料が豊富)とか,inline 化の戦略(一般的なコンパイラの文献で色々あります)とか,調べてみると良いと思います.

Ruby だと,Proc(と eval,binding)があるので,環境について考えるのが面倒だったりします.

参考になれば幸いです.

# redmine で返事を書くと,返信が書きづらい.

----------------------------------------
Feature #6289: メソッドのインライン化について
https://bugs.ruby-lang.org/issues/6289#change-25889

Author: watashinoid1 (moe info)
Status: Closed
Priority: Normal
Assignee: 
Category: 
Target version: 


Rubyはメソッド呼び出しが重いです。
一方でC++などはmov数個とcall一個で終わりますね?

そこでインライン化を考えてみようと思ったのですが、C++と違って動的なクラス定義が許されている言語なので安易にインライン化はできません。

----------------------------
安全にインライン化するためには

インライン化できるメソッドの条件
・インライン化されるメソッドはクラス定義、メソッド定義を呼ばない
・インライン化できるメソッドしか呼ばない

四則演算や配列操作は明らかにクラス定義、メソッド定義を呼ばないので、インライン化できます。
するとそれらのみを使うメソッドはインライン化できます。
こうしてボトムアップでインライン化できるかどうかを全てのメソッドに対して決めることができます。

ここでついでにそのメソッドから呼ばれる可能性のあるメソッドを列挙してリストにしておきます。

------------------------------------------
次の問題はインライン化されたあとにその内部で呼ばれるメソッド定義が書き換わった場合に、インライン化をやり直さないといけないのですが
これは先ほど作ったメソッドのリストを見て、定義が書き換わったかどうかを判定できます。

分かりやすく言えば、"メソッドの飛び先のチェックがループの外に出たら速い"ってことです
------------------------------

四則演算とか、オーバーライドされる可能性のせいで遅くなるのはもったいなあと。99.9999%のケースでオーバーライドされないんだから・・・
99.9999%側なのか0.00001%側なのかのチェックをループの外に出すのって最適化の基本かなと

bignumへの移行を考えると、add jcc sub jcc みたいにコンディショナルジャンプを一個ごとに挟まないといけなそうですが
分岐予測テーブルを汚染しそう

実際の実装はLLVMでやってみようかな
-------------------------------------------------
最近Ruby開発に興味が出たひよっこですが。こんなことやってみようかなと、とりあえずつぶやいてみます
もしかしてRuby1.9で既にやられてるのかな?ISEQとか怪しい


-- 
http://bugs.ruby-lang.org/

In This Thread

Prev Next