LLVM勉強会でささださんたちと話したこと

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

型推論をがりがりやると重い。Tracing JITなんかを使ってさくっとコードを生成した方がよいのでは、またJavascriptなんかはそれが主流だよね。
型推論重いよー。再コンパイルすると何回もやらないといけないし。でも、yarv2llvmの型推論ってPrologのユニフケーションだからPrologの高速化テクニック、もっというとネイティブコード生成ができると思う。

(後で冷静に考えたらネイティブコード生成してたら型推論できちゃうよ)

インスタンス変数のキャッシュ

yarv2llvmのインスタンス変数のキャッシュってモジュールが出てくると破綻しない?

例えば、

           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

とやると、A#asdの@fooはどうコンパイルするの?

うううっ、オブジェクトのレイアウトとかインスタンス変数の初期化の順番とか工夫するとうまくいくんじゃないかなー。(根拠無し)

Fixnum considered harmful

PythonはFixnumをポインタに埋め込んでいたんだけど、Python3ではBOXINGするように変更になった。ポインタに埋め込むと必ずFixnumかのチェックが入るから重いんだよね。
確かにRails使うんならfixnum遅くてもいいからBOXINGして他を速くするのも手だよね。