2009-03-28
LLVM勉強会でささださんたちと話したこと
|- さ
- ささださんたち
- み
- 私(みうら)
互換性をUPさせる方策
- さ
- トップレベル環境はあえてコンパイルしないようにすると互換性が取りやすいのではないか。例えば、
if $debug then def foo デバッグバージョン end else def foo リリースバージョン end end
という感じのプログラムはコンパイルせずにインタープリタで実行すると却って効率がよさそう
on stack replacement
- さ
- 再コンパイルするとon stack replacement(実際にはこの言葉私は知らなかったので呼び出し元を書き換えられるかという感じで判りやすく説明してもらった)が、必要になるが、LLVMで可能だろうか
- み
- LLVMの枠内では不可能だと思う。LLVMでは最適化を可能にするためスタックフレームの構造は決まっていないから。あるいは効率を落としてコンテキスト情報を一杯残すようにすれば・・・。いずれにしてもバックエンドに手を入れる必要があると思う。X86機械語を生で使えばできると思うけど
- さ
- それは判る。でも、どのくらいの手間が掛かるのかわからない
- み
- そうですねー
型推論 vs Tracing JIT
- み
- 型推論重いよー。再コンパイルすると何回もやらないといけないし。でも、yarv2llvmの型推論ってPrologのユニフケーションだからPrologの高速化テクニック、もっというとネイティブコード生成ができると思う。
(後で冷静に考えたらネイティブコード生成してたら型推論できちゃうよ)
インスタンス変数のキャッシュ
例えば、
module A def asd @foo end end class B include A def initilaize @foo = "B" end end class C include A def initilaize @bar = "BAR" @foo = "C" end end
Fixnum considered harmful
- み
- 確かにRails使うんならfixnum遅くてもいいからBOXINGして他を速くするのも手だよね。
トラックバック - http://d.hatena.ne.jp/miura1729/20090328/1238251519
リンク元
- 21 http://www.rubyist.net/~kazu/samidare/
- 4 http://reader.livedoor.com/reader/
- 3 http://atnd.org/events/381
- 2 http://a.hatena.ne.jp/fujita-y/
- 2 http://d.hatena.ne.jp/
- 2 http://d.hatena.ne.jp/keyworddiarymobile/Ruby?date=20090328
- 2 http://steps.dodgson.org/
- 2 http://www.google.co.jp/reader/view/
- 2 http://www.google.co.jp/reader/view/?hl=ja&tab=wy
- 2 http://www.google.com.br/reader/view/?tab=my
ご指摘ありがとうございます。