VMに手を加えずRubyを高速化するJITコンパイラ「YARV-MJIT」の話 - k0kubun's blog
先日のRubyKaigi 2017のLTではLLVMベースのCRuby向けJITコンパイラLLRBの話をしました。 5分はちょっとJITの話をするには短かかったですね。 LLRBをふまえた、Cのコード生成への軌道修正 さて、上記の資料にある通り、CRubyのJITにおいてはメインの高速化対象が既に存在するCのコードになるため、 開発の早い段階でパフォーマンスにインパクトを持てるとすればLLVM Passの順番を変えるくらいで、 LLVM IRを直接生成しても最適化上のメリットがほとんどないのでその部分はMJIT と同じくCのコードを生成するように変更したい、という話をした*1。 で、LLRBはC拡張として作るべくちょっと不思議な努力をいろいろやっており、 それらの設計はやってみた結果(コアに直接変更を加えるのに比べ)デメリットの方が大きいと思ったので、 LLRBの失敗を全て生かしつつ、今回
CRuby向けのLLVMベースのJITコンパイラを書いている話 - k0kubun's blog
LLRBというRuby向けのメソッドJITコンパイラを書いている github.com RubyKaigi 2015の最後のキーノートで@evanphxが「LLVMでCRubyのコードをインライン化するメソッドJITを実装したら速いんじゃね」みたいな発表をしていたのを覚えているだろうか。 LLRBというのはまさにそれを実装しているプロジェクトであり、少なくとも現時点で「LLVMでCRubyのコードをインライン化するメソッドJIT」と言える状態まで実装でき、ものによっては効果が出る状態になったので公開した。 なんで書いてるの 言語を自分で実装するとその言語に関する理解が大分深まる、というのをHamlの実装とかCコンパイラとかで体験していて、僕が一番好きな言語はRubyなのでRubyでもそれをやっておきたい、というのがあった。また、Rubyは遅いと言われがちだが、どこに改善可能な点が眠っている
Hamlを3倍速くした - k0kubun's blog
Hamlコミッターになった RubyKaigi 2015で「Hamlは遅いしメンテされてないので使わない方がいい」と言ったところ、じゃあ自分でメンテして速くしろということになりコミッターになった*1。 当時から2年ごしなのは、当時のHamlのオーナーがあまりアクティブではなく、最近a_matsudaさんがオーナーになったため。 HamlのTemple化・高速化を行った Templeというのは、テンプレートエンジンをパイプライン的に構築するためのフレームワークで、テンプレートエンジン用の中間表現とその最適化エンジンを持つ。実装をTempleベースにすると、SlimやHamlitに使われているような中間表現を使った最適化を適用しやすくなる。 コミット権をもらったので、RubyKaigi 2015でマージされないと言っていたパッチを自分でマージし、コード生成とattributeのコンパイルをTe
Linux デスクトップ環境 2017 - k0kubun's blog
Linux デスクトップ環境 2016 - eagletmt's blogの人に影響を受けて自作PCでLinuxデスクトップを使い始めてから約1年半が経ち、僕の使う環境が一通り満足な状態になったので今どういう構成なのか書いておく。 僕はKeynoteを使う時とか会社のマシンでmacOSも割と使う都合、基本的に操作性がmacOSに近くなるようにしているので、macOSからLinuxに移行したい人の参考になるかもしれない。 *1 そもそも何故Linuxデスクトップを使っているのか 「苦労してmacOSに近づけるくらいなら最初からmacOS使えばいいじゃん」と言われそうだが、今この瞬間は大体以下の理由でLinuxデスクトップを使っている。 趣味で作ったスペックが高めの自作PCにmacOSが入れられない *2 最新のmacOSではKarabinerが使えないが、Linuxでは自作のキーリマッパーが
RubyConf 2016 で話してきた & MItamae v1.0.0をリリースした - k0kubun's blog
RubyConf 2016で登壇してきた 2016/11/10〜11/12にアメリカのオハイオ州シンシナティでRubyConfというイベントがあって、Ruby DSLによって設定できるCLIツールをRubyインタプリタやgemの存在に依存しないシングルバイナリとして実装するための知見を「Evaluate Ruby Without Ruby」というタイトルで発表してきた。 発表資料 発表動画 RubyConfってどうなの RubyConfはRubyKaigi並に規模が大きいもののあまりRubyのDeepな部分には期待できないカンファレンスなんだけど、当時行ったことがなかったアメリカに行ってみたいという思いがあって去年も参加していた。あと、RubyKaigiとは違った層の海外のエンジニアと話せる *1 のも良い点だと思う。 去年はRubyKaigi 2015で話したものと同じ内容のCFPをRu
ErgoDoxを2枚買ってキースイッチを交換した - k0kubun's blog
ErgoDox始めました pic.twitter.com/lm2kCCwj3K— 体調悪太郎 (@k0kubun) 2016年5月2日 なぜErgoDoxを2枚買ったのか 直近で使っていたキーボードは1300円で買える奴で、金に余裕ができたらいい奴を買おうと思っていた。HHKBとRealforceは以前所持していたことがある*1ので、Kinesisとかを検討していたけど47kするしもう少し安いErgoDoxから試すことにした。会社まで持ち歩くのは面倒なので2枚買った。 買ったErgoDoxたち 値段は実際にクレジットカードで支払った額 (送料込み) ErgoDox EZ Bundle: Blank: 36,190円 リストレストとTilt/Tentキット(傾けるアーム)がついてる キースイッチはGateron Red FalbaTech + pimpmykeyboard: DSA PBT/
Slimより高速なHaml実装「Hamlit」をリリースしました - k0kubun's blog
slim-template/slimのcompiled benchでオリジナルのhamlに比べ8倍高速に動作するhaml実装をリリースしました。 github.com なぜ高速なHaml実装を作ったのか 個人的にhamlのシンタックスのほうが好きなので、「hamlは遅いからslimを使う」みたいな人を減らしたかったから。以前slimの普及に貢献したんだけど、気が変わったのでhamlを応援することにした。 実は他にも既にeagletmt/famlという高速なHaml実装が存在していたんだけどベンチを走らせたらslimより遅かったので、slimを打倒するべく再実装した。 どのくらいHamlより速いのか 自分の実装に都合のいいベンチマークを作るのは簡単なので、公平性を期すためにslim-template/slimのcompiled benchと同じものを使い、誰でも同じ環境が使えるtravisで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
