yarv2llvmの作り直しの検討 MethodBehaviorクラス - miura1729の日記
yarv2llvmを作成していて、メソッド呼出毎にさまざまにコンパイルの仕方を変える必要があることがわかりました。 例えば、eachは多くの場合インライン化する必要があるし、String#packは第1引数のテンプレートを見て型推論を行う必要があるし、newはエスケープ解析の結果でどこにアロケートするか変えないといけないわけです。 現状のyarv2llvmはこの辺をアドホックにテーブルを作って対応していたのですが、メソッドごとの振る舞いをちゃんとクラスにまとめたほうがいいなと気付きました。 振る舞いの異なるメソッドごとに用意する MethodBehaviorクラスは次のような動作をおこなうメソッドを用意する 初期トラバース 型推論 コード生成 MethodBehaviorDefaultクラスを用意し、普通のメソッドはそれを利用する。また、他のクラスは、MethodBehaviorDefau
面白そうなソフトウエアのメモ - miura1729の日記
deliciousに面白そうなソフトウエアがブックマークされていたのでメモ Cをllvmのbitcodeに落として、それをアプリケーションに特化したプロセッサのVHDLに落とすそうです！ とりあえず究極と思っていたコンパイラの形態が既にあるとは驚きです。 http://tce.cs.tut.fi/ http://tce.cs.tut.fi/user_manual/TCE/ 追記 よく読んでみたら、プロセッサとその上で動く機械語に生成されるみたいです。全部VHDLに変換されると思ってびっくりしましたが、プロセッサと機械語だと商用だとあったような気がします。でも、すごいです。
on-stack replacement メモ - miura1729の日記
今、LLVMのソースを読んでいます。そしたら、recompileAndRelinkFunctionなるメソッドを見つけました。後は、実行中のフレームを書き換える目処が付いたらLLVMでon-stack replacementできそうです。フレームを書き換えるところは、GC APIが有望そうなのですが、果たしてどうなることか・・・。 この日記は、Wikiみたいにすると後でいろんなページに飛ばなくて済むから便利かなと思って、新しいエントリーを起さずに更新を繰り返しています。更新履歴を書くようにしました。最後に更新した小項目を前に持ってくるようにしました。ただし、更新履歴, yarv2llvmへの応用のまとめは常に先頭です。 更新履歴 2009/04/06 ShadowStackについて更新しました。 2009/04/06 更新履歴を作りました。 yarv2llvmへの応用のまとめ 結局、gcr
LLVM勉強会でささださんたちと話したこと - miura1729の日記
LLVM勉強会の途中で笹田さんたちと話した内容です。 さ ささださんたち み 私(みうら) 互換性をUPさせる方策 さ トップレベル環境はあえてコンパイルしないようにすると互換性が取りやすいのではないか。例えば、 if $debug then def foo デバッグバージョン end else def foo リリースバージョン end end という感じのプログラムはコンパイルせずにインタープリタで実行すると却って効率がよさそう み メソッドが再定義される場合はトップレベルじゃなくてもありえるから結局再コンパイルは必要。だからトップレベルでもコンパイルして必要なら再コンパイルしたほうがすっきりすると思う。 on stack replacement さ 再コンパイルするとon stack replacement(実際にはこの言葉私は知らなかったので呼び出し元を書き換えられるかという感じで
LLVM勉強会のスレッドに関する間違えの訂正 - miura1729の日記
LLVM勉強会でyarv2llvmでrb_thread_createで作ったスレッドが、マルチコアで並行にスレッドが動いているか、いないかの話の続きです。 既にささださんはじめ皆様から指摘されているように、ジャイアントロックが掛かっているので並行には動いていないことをソースで確認しました。間違えはnative_thread_create関数より先を見ずに、th->first_funcがそのままスレッドになると思い込んでいたのが原因です。嘘を言ってしまい参加者の皆様に大変迷惑を掛けました。申し訳ありません。 今後、スレッドをrb_thread_createでは無くCreateThread APIを生で使い、排他制御の必要なところにCAS命令を使ったスピンロックを生成するような並行対応をつくろうかなと思っています。
LLVM 2.5がリリースされました - miura1729の日記
いつの間にかLLVM 2.5がリリースされました。今、バージョンアップすると勉強会で動かなくなると困るのでバージョンアップはしないけどリリースノートで興味深いところをメモします。 http://llvm.org/docs/ReleaseNotes.html#whatsnew ClangでObjective-CのGCをサポート。実現方法が見てみたい Clangでエラーチェックが賢くなったみたいです Boehm GCと併用できるようになった？ 整数のオーバフローのハンドリングがサポートされたみたいです！！！ Bignumがサポートできるかも！X86のみ SSE命令でシフトがサポートされた Thread Local Storageがサポートされた。でもLinuxのみ(涙) 個人的に一番うれしいのは、やっぱりオーバフローハンドリングですね。欲しい欲しいと思っていたのですが、まさか本当に出てくるとは
AOベンチを移植した - miura1729の日記
yarv2llvmにAOベンチを移植しました。AOベンチはSyoyo Fujitaさんが作成したレンダラでベンチマークに使うため色々な言語に移植されています。詳しくは、http://lucille.atso-net.jp/aobench/を参照してください。 今回移植したyarv2llvm版はRuby1.9でも動くのですが、yarv2llvmに合せているため、もっといい書き方があるのにーって思うことと思います。特に、ファイルのopenをまだ作っていないので、イメージファイルを標準出力に出すという暴挙に出ています。 ベンチマークのソースはこれです。 http://github.com/miura1729/yarv2llvm/blob/a888d8ce6855e70b630a8673d4cfe075a8e44f0e/sample/ao-render.rb yarv2llvmとruby1.9で動
Inside yarv2llvm(その6) - miura1729の日記
イテレータ(ブロック付メソッド呼び出しの方が正確なのかな？)の説明です。yarv2llvmではイテレータに渡すブロックはクロージャーとして実現しています。言い換えると、イテレータは無名のクロージャーを引数に渡すメソッドであるといえます。例えば、 class Fixnum def times i = 0 while i < self yield(i) # 1 i = i + 1 end self end end i = 1 10.times do |n| # 2 p n + i i = i + 1 end p i とすると、イテレータに渡すブロック do |n| p n + i i = i + 1 end の部分が、あたかもメソッドのようにコンパイルされ、そのポインタがtimesに渡されます。そうすると、iの参照ってどうするの？という疑問が生じるかもしれません。ここで注意すべきは、ブロックを
Inside yarv2llvm(その5) - miura1729の日記
えらく更新が遅くなりました。今回は3回くらい書いている途中で消してしまい(戻るボタンを押したりして)、悲しい思いをしていました。結局、エディタで書いています。 イテレータの説明をすると予告したのですが、イテレータを説明するには変数の説明をしないといけないことに気づき、変数の説明を書くことにします。 ところで、変数アクセスの性能は重要です。ちょっと考えると普通メソッドコールより数が多いのだから、全体の性能にも大きく係ってくるなと判るのですが、どうもメソッドコールの性能ばっかり気になって変数アクセスの性能のことをないがしろにしてしまいます。でも、load/store一発のローカル変数だけを使ったfibではRuby1.9に比べて30倍以上のスピードが出ますが、アクセスにハッシュ検索が必要なインスタンス変数を多用したnbodyでは5倍くらいのスピードしか出ません。 こんなことから、変数アクセスは遅
Inside yarv2llvm (その4) - miura1729の日記
型推論の続きです。RubyType.resolveはRubyTypeのクラスメソッドですべてのRubyTypeのインスタンスの型推論を行います。RubyTypeクラスには@@type_tableというクラス変数があり、それにすべてのRubyTypeのインスタンスが入っています。RubyTypeは@@type_tableから1つづつインスタンスを取り出し、各インスタンスに対して次のような処理を行います。手始めにすべてのインスタンスの@@resolveedをfalseにします。 インスタンス(src)の@resolveedをチェックします。これがtrueなら何もしません。 srcの@same_typeの要素に対して次の処理を行います。@same_typeは前回説明したとおり、同じ型であるはずのRubyTypeのインスタンスが入っています。@same_typeの各要素をdstとします dstの@
Inside yarv2llvm (その3) - miura1729の日記
今回は型推論の話の簡単なところです。Rubyは素直に型推論できるようにできていないので、yarv2llvmではいろいろad-hocな例外を組み込んでいますが、今回はそれらは一切無視です。素直に型が一意に決まり、決まらないときはエラーで弾く場合を想定しています。 型の管理を行うため、yarv2llvmでは扱うすべてのデータに対して、１つづつRubyTypeクラスのオブジェクトを用意しています。扱うデータとは、例えば変数、リテラル、引数、戻り値などがありますが、それだけではなくブロック、if、whileの値などもそうです。RubyTypeは次のようなインスタンス変数・クラス変数を持っています。 @name データの名前(変数名とかリテラルの値そのものとか)、デバッグ・エラーメッセージ用 @line_no データが定義されたファイル名・行番号、デバッグ・エラーメッセージ用 @type 型オブジェ
Inside yarv2llvm(その2) - miura1729の日記
yarv2llvmは2パスです。Rubyの言語仕様では1パスで実現することが可能です(と思います、ちょっと自信ないです)が、型推論で後に来る情報も利用したいので２パスにしています。2パスにしてうれしい例を挙げます。 def foo(a) a end foo 1 ここで、fooを定義したところだけだと、aの型は決められません。関数型言語だと型変数が出てきて foo: 'a -> 'aとか型推論するのでしょうが、その情報ではllvmに落とすのには役に立たないです。そこで、プログラムの全体を見回して、fooがどう使われているか調べています。この例では、foo 1という使い方からfoo: Fixnum -> Fixnumと推論します。これだと、Fixnum(llvmではInt32TyかInt64Ty)の命令を生成すればいいことがわかります。こういうことで、全体を見回して型が決定するまで、fooの命
Inside yarv2llvm(その1) - miura1729の日記
yarv2llvmがとりあえず１段落しました。今後しばらくは、大きな新機能は追加せず、こまごました機能追加とBug fixを行おうと思います。安定してきたら、多相メソッド起動を作りたいと思います。なんか思いついたら、新機能を入れるかもしれないですが。 yarv2llvmの内部構造のドキュメントが無いので、内部構造の説明を書いていこうと思います。今日はyarv2llvmの大まかな概要です。 yarv2llvmは、Ruby1.9のVM(かってYARVと呼ばれていました。以下、Ruby1.9のVMのことをYARVと(おそらく間違っていますが便利なので)呼びます)のバイトコードをllvmのbitコード列に変換するソフトウエアです。YARVとllvmはどちらも仮想計算機と呼ばれる種類のソフトウエアですが、大きな違いがあります。 YARV スタックベース 動的型付け 命令が高機能(ほぼRubyの1命令
Threadをサポートした - miura1729の日記
@llvm.atomic.swap.* 使いたい！ っていう変な理由でThreadをサポートしました。 遊ぶのが主目的で信頼性はどうでもいいので注意が必要です。といっても、yarv2llvm全体もそういうスタンスなので問題ないと思います。rb_thread_createという目的にぴったりと思われる(かなり自信は無いのですが・・・)、APIがあったのでこれを使いました。インタフェースはRubyに合せてあります。こんな感じで動いているのですが、GCとか大丈夫かは判りません。これで、@llvm.atomic.swap.*で遊べそうです。 プログラム YARV2LLVM::compile(<<-EOS) def tthread Thread.new { 10.times do |i| p i end } print "END" 10.times do |i| puts sprintf("foo%
yarv2llvmの進捗状況 - miura1729の日記
今回は(も？)、あまり面白くない変更ですが自分用にメモします。 式が定数だった場合畳み込みをするようにしました 比較の結果(Booleanまたは(TrueClass/FalseClass))をサポートしました Fixnum#timesをサポートしました。これをサポートするに当たってインライン化するイテレータが簡単に書けるようにリファクタリングしました。 組み込みメソッドやインライン化されるメソッドの再定義が出来るようになりました。まだ不完全です。 最初の定数の畳み込みについては、補足がいるかなと思います。もちろん、最適化の強力なLLVMは定数の畳み込みは朝飯前です。でも、こんな場合はどうでしょう？ FOO = 1 + 1 p FOO 一見、p 2というコードを出力すればいいように見えますが、定数の畳み込みをLLVMに任せてしまうと、次のようなコードができてしまいます。 1 + 1の計算をす
LLVMが拡張されてる - miura1729の日記
ちょっと見ない内にLLVMが拡張されていました。これがLLVM 2.5(2009/2/11リリース予定らしい)の仕様なのかもしれないです。なかなか、というかすごく面白そうな機能があります。 http://llvm.org/docs/LangRef.html#int_atomics と http://llvm.org/docs/LangRef.html#int_stackprotector に心惹かれました。この辺を見るとLLVMもマルチスレッドやマルチコアを目指しているのかも知れないなと思います。この辺の機能を使ってlock-freeなライブラリをいち早く揃えるとかっこいいですが無理です。とりあえず、yarv2llvmでマルチスレッドを実現する方法を考えてみようかなと思いました。
自分用メモ(yarv2llvm) - miura1729の日記
llvm.frameaddressを使うとsetdynamic, getdynamicが実現できそう フレームにはサイズの違うデータが混在するから、フレームの構造を表すStructの定義を生成して、llvm.frameaddressの戻り値をそのStructでキャストする必要があるような気がする。
すごそうです - miura1729の日記
InfoQの記事にコメントが入っていて、Ludicrous JIT Compiler なるものが紹介されていました http://rubystuff.org/ludicrous どうもかなり完成度が高そうです。 ソースがgithub(http://github.com/cout/ludicrous/tree/master)にあるので、見てみました。型推論はやってないだろうなー、と思ったらなんかやってるみたいだし、ひょっとしてyarv2llvmいらない？ みたいな 追記 型推論かなと思ったところ、(lib/native_functions.rbのrb_typeメソッド) は型推論じゃなさそうです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「天才になれる秘密」について - miura1729の日記