RJIT: RubyでRubyのJITコンパイラを書いた - k0kubun's blog
僕はRustでRubyのJITを書く仕事をしているのだが、去年の12月くらいから、趣味ではRubyでRubyのJITを書いている。 それまではC言語でコード生成を行なうMJITを5年くらいメンテしていたのだが、先月、Rubyで機械語を直接アセンブルするRJITに差し替えた。 github.com なので、今Rubyのmasterブランチには、会社で業務として開発しているRust製のYJITと、僕が趣味で開発しているRuby製のRJITの2つのJITコンパイラが存在している。余談だが、JITの開発をしすぎてRubyの作者であるまつもとさんのコミット数を最近抜いた。 なぜMJITをやめたのか MJITも結構がんばっていて、去年開発していたRuby 3.2ではMJITのコンパイラの実装をCからRubyにフルスクラッチした上、バックグラウンド処理をpthreadからfork + SIGCHLDで行
リモートでアメリカの大学院に通い始めた - k0kubun's blog
今年春に出願、夏に合格して秋学期からオンラインのコンピュータサイエンス修士コースで勉強している。ちょうど秋学期が終わって成績が返ってきたので、どういう感じだったか書いておく。 I've been officially admitted to Georgia Tech's OMSCS (Online Master of Computer Science). I'm excited for being a student again. I chose the online course to take it without quitting my job, but due to COVID-19 it's probably not that different from other people's experience.— k0kubun (@k0kubun) July 31, 2020 ど
US移住とブートストラップ問題 - k0kubun's blog
USに移住して4か月経った 入社直後から希望していたUS移籍を会社にサポートしていただき、去年の9/21にビザつきの状態で入国して、その後出張で出国は挟みつつもシリコンバレーで生活し始めてかれこれ4か月経った。 移住後の最初の2か月は右も左もわからず大変だったが、色々な人に助けられて今では落ちついて暮らせる状態になった。 自分用のメモを兼ねつつ、運が良ければ識者から知見が集まるよう、僕がどこで困ったか本記事に書いておく。US移住に興味がある人の参考にもなると思う。これはUSだとスーパーでかなり安く手に入る Ribeye ステーキ。 cooked 🥩 by myself for the first time pic.twitter.com/0UjWrlUlzu— k0kubun (@k0kubun) January 13, 2020 US生活ブートストラップ問題 クレジットヒストリー US
RubyのJITに生成コードのメモリ局所性対策を入れた話 - k0kubun's blog
昨日、RubyのJITの性能改善のためのパッチを入れた。 github.com JITすればするほどRailsが遅くなる問題 Rubyの次期バージョンである2.6には、バイトコードをCのコードに変換した後、gcc/clangでコンパイルして.soファイルにしdlopenすることで生成コードのロードを行なう、MJITと呼ばれるJITコンパイラが入っているのだが、マージしたころのツイートにも書いていた通り、Railsで使うとより多くのメソッドがJITされるほど遅くなってしまうという問題があった。 結果、"MJIT slows down Rails applications"というチケットが報告されることとなり、昨日までの5か月の間閉じることができなかった。 元の構成 対策を始める前のMJITは大雑把に言うとこういう感じだった。メソッド1つごとに1つの.soファイルが作られ、ロードされる。 無制
個人で運用するKubernetesクラスタ - k0kubun's blog
Kubernetesの使用感に興味があってaws-workshop-for-kubernetesというのを先週やり、ちょうどEKSがGAになった直後だったのでEKSが試せたのだけど、まあ最初からマネージドだとあまり面白みがないし金もかかるので、個人のVPSで動かしてた奴を全部Kubernetes上で動かすようにしてみている。 まだ本番で運用した知見みたいなのが貯まってるわけではないのだが、公式のドキュメントを中心に読んでいても単に動かし始める段階で結構ハマって時間を消費したので、これから同じようなことをやろうとしている人向けに備忘録を兼ねて使用感や知見をまとめておくことにした。 Kubernetesは今でもalphaやbetaの機能が多く、今後この記事の内容も古くなることが予想されるので、なるべく公式のドキュメントへのリンクを置くのを意識して書いてある。 構成 現時点で、ConoHaで借り
Ruby 2.6にJITコンパイラをマージしました - k0kubun's blog
The English version of this article is available here: medium.com 2/4(日)に、去年のRubyKaigiが終わった直後の新幹線で開発を始め10月に公開したJITコンパイラをRubyのtrunk (2.6.0-dev) にマージし、昨日TD Tech Talk 2018で以下のような内容の発表をしました。 speakerdeck.com まだそれほど速くできていないということもあり、私はTwitterでのみ共有して満足していたのですが、海外の方がいくつか記事を書いてくださいました。 Playing with ruby's new JIT: MJIT - John Hawthorn Ruby’s New JIT – Square Corner Blog – Medium とても丁寧に書かれているので、私の記事がわかりにくければ
GraphQLは何に向いているか - k0kubun's blog
今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ
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は遅いと言われがちだが、どこに改善可能な点が眠っている
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では自作のキーリマッパーが
RailsでN+1 countクエリを潰すactiverecord-precountを作った - k0kubun's blog
追記: 2017/09/06 少しAPIが冗長なもののActiveRecordへのモンキーパッチが少ないバージョン activerecord-precounter というのを作りました。こちらの方がバグりにくいはずなので、現在はactiverecord-precounterの方を使うことが推奨されます。 github.com 概要 N+1 countクエリを最大11.7倍速くできるactiverecord-precountというgemを作った。 *1 k0kubun/activerecord-precount N+1 countクエリ Tweet.all.each do |tweet| p tweet.favorites.count end # SELECT `tweets`.* FROM `tweets` # SELECT COUNT(*) FROM `favorites` WHERE
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で
私のpeco活用事例 - k0kubun's blog
pecoというインタラクティブに入力をフィルタして出力するコマンドがあって、使い始めてからシェルの操作方法が大幅にかわり、だいぶライフチェンジングだった。 最近このへんが流行ってるのでやたら記事あるけど、せっかくなので僕も使い道を紹介しようと思う。 pecoをzshで使う 1. peco ghq ghqを使ったローカルリポジトリの統一的・効率的な管理についてのこと。 僕も$GOPATHは$HOMEにしていて、今のところ別に困ることはない。 go getしたりghq getしたりして美しくディレクトリ切った上で、pecoに割り当てておいたC-sですぐ目的のディレクトリ開けるようにしてあるので、めちゃくちゃソース管理が楽になった。 function peco-src() { local selected_dir=$(ghq list | peco --query "$LBUFFER") if
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
