RubyのJITコンパイラYJITを開発している弊社Shopifyでは、社内で最もトラフィックが多いストアフロントのアプリにRuby 3.3 (master) をデプロイして平均レスポンスタイムが16%高速化、社内で最も大きなアプリであるモノリスにRuby 3.2をデプロイして平均レスポンスタイムが9%高速化している。他の会社でも、YJITを本番で有効にしたら高速化したという事例をちらほら目にした。 一方で必ずしも良い報告ばかりではなく、YJITを有効化したらメモリを使い切ってしまったりだとか、遅くなったみたいな報告も目に入ることがある。こういった問題は我々も多かれ少なかれ経験しており、それぞれ適切に対処することで解決できたため、その知見を共有する。*1 メモリを使い切ってしまった時 zenn.dev YJITを有効化すると、YJITが生成する機械語に加えて、それに関するメタデータもメモリ

LLVMやSwiftを作ったChris LattnerがCEOをやっている会社が、Pythonの使用感とC言語並の性能を併せ持つ言語としてMojoをアナウンスした。 まだ手元で試せる状態でリリースされてはいないが、最大35000倍Pythonより速いという。 Mojo🔥 combines the usability of Python with the performance of C, unlocking unparalleled programmability of AI hardware and extensibility of AI models. Also, it's up to 35000x faster than Python 🤯 and … deploys 🏎 pic.twitter.com/tjT09U4F80— Modular (@Modular_AI) May

去年8年ぶりに vimrc を書き直した時はLSPの体験があんまりよくなくてLSPなしでNeovimを使い続けていたのだが、様々な言語のOSSをメンテする都合で用途に応じてIntelliJとVSCodeとNeovimの三刀流で暮らしていた結果、可能ならNeovimに寄せたいけどそれならLSPを使いたいなということになり、今回LSPの所を真面目に設定し直して、かなり良い体験になっている。 正直Neovimの設定はVSCodeのそれに比べたら面倒なんじゃないかという印象がありサボっていた節があるが、実際にやってみるとVSCodeと同程度に簡単に済む方法もあったので紹介したい。 何故Neovimなのか LSPの話の前に、タイトルだけ見た人がそもそも単にVSCode使えばいいじゃんと言いそうなので、どうしてIntelliJやVSCodeではなくNeovimに揃えようと思ったのかについて書いておく。

最近は個人開発は自分のOSSのメンテで手がいっぱいになってしまったのでサービス開発のようなものは普段あまりやらないのだが、大学院*1で今学期、何作ってもよいという感じの授業を取ってWeb/iOS/Androidアプリ*2を全て作るという体験をする中で、たまたま個人開発のコストを抑える活動をしたので、その時に調べたり考えたりしたことを書いておく。 Herokuで無料にする Herokuでは毎月550時間free dynoが使え、クレジットカードを登録しておくと更に450時間、合計1000時間無料で使える。Herokuは30分アクセスがないと一旦停止するが、今回授業で作ったサービスでこれを使い切らないことは明らかだったので最初はこれでセットアップした。セットアップも簡単だし、PostgreSQLも無料でついてくる。 ただ、コールドスタートに10秒くらいかかり、これがこのサービスではUX的に致命

僕はRubyで開発をする時は毎回Pryを使うくらいの熱狂的Pryユーザーだったのだが、PryはGemfileに書いてないと binding.pry できなくて不便。任意のgemをdefault gem化するgem default コマンドも作ったのだが、これをやるのすら面倒だと思っていた。 ある日、nobuさんがRubyに binding.irb という機能をいれた。Pryがdefault gemになるのを待つよりPryで僕が使う機能をIRBに全部移植してしまった方が早いのではないかと思い、4年前からPryの機能の移植活動を始め、今日僕がよく使う機能を全て移植し終えた。 その記念に、この記事ではIRBのPry互換の機能を紹介する。昔 今更聞けないpryの使い方と便利プラグイン集 という記事を書いたんだけど、この中で僕が毎日のように使うコマンドは全てIRBに移植したので、それを紹介する本稿を

サンフランシスコベイエリアでのITエンジニアの給料は東京より高いが、税金や物価も高いと言われている *1 。ではどちらに住む方がより多くの金が手元に残るのだろうか。 僕がベイエリアに移住してからちょうど1年が経ったので、僕が東京とベイエリアそれぞれにいた頃の出費やタイトルでどのくらい家の収支に差が出るのかということをまとめてみる。なお、この記事を書いている時点で 105.60 円/ドル なので、ドル円の変換をする際はこのレートを用いる *2 。 収入 基本給 ベイエリア 東京 $153,600 913万円 GitLabは同社の世界各地での待遇計算基準を 公開 しており、地域間の差異を公平に計算するには割とよくできたベンチマークなのでここの年収をそのまま使う。計算に使われる location_factors.yml では、日本の給与はサンフランシスコの 56.3% になっている。 Calcu

HamlitというRubyで使うテンプレートエンジンをメンテしてて、ちょっと前に思いついたけどこれまで実装してなかった最適化のアイデアを昨日それに実装したので、それについてちょっと書きたい。 github.com StringTemplate というテンプレートエンジン amatsuda/string_template というテンプレートエンジンがあって、 これは "the fastest template engine for Ruby" であると主張されている。 I think I just invented the fastest template engine for Ruby (Rails). Please enjoy! https://t.co/N056SReLh2 https://t.co/74MdR5DINj— Akira Matsuda (@a_matsuda) Dece

rack-user_agent を作った rack-user_agentという、User-Agentに応じていろいろな判定ができるメソッドを生やすRack::Request拡張を作った。 tagomorisさんのWootheeを使ってRack middlewareでUser-Agentをパースしておいて、 その結果に応じてrequestから簡単にいろいろな情報を得られるようにしてある。 たとえばRailsだとGemfileにgem "rack-user_agent"と書くだけで以下のように使うことができる。 class ApplicationController < ActionController::Base before_action :set_request_variant def index # example request.user_agent #=> "Mozilla/5.0

RubyのJIT開発でやろうと思ってることが大体 @_ko1 さんの作業待ちでブロックしていて暇なので何かを書こうと思い、JVMを書くことにした。 まだその辺のアプリを気軽に動かせるレベルでは全然ないが、別に秘密裏に開発する必要もないと思ったので公開した。 github.com これの紹介と、現時点で学べたことをこの記事に記録しておく。 何故JVMなのか 仕事でJVM言語を使っている 僕が所属しているTreasure Dataでは、大雑把に言うと本番サーバーのサービスは大体Ruby, Java, Scala, Kotlinで書かれている*1ので、既にRubyのVMはある程度わかる*2ことを考えると、JVMさえ理解してしまえば社内の主要な言語評価系を抑えたことになり、運用面で活躍の機会が増える気がしている。 また、自分が最近一番書いているのはKotlinなのだが、JVMで動かしていることに由

Ruby Core Development 2019というタイトルでRubyKaigiのCFPにプロポーザルを書いたのだが、 もう一つ書いた方の話が採択されたのでその話はしなかった。 さて、今日はRubyコア*1の開発がSubversionからGitに移った節目でもあったので、そっちのトークで言いたかったことの一部を記事にしておこうと思う。 Subversion → Git 移行 [Misc #14632] 去年くらいから @hsbt さんが cgit というGitフロントエンドを使ってGitリポジトリの準備を始め Misc #14632、ついに今日正式にcgitの方がupstreamになった。平成の時代でSubversionでのtrunkのRubyコア開発は幕を閉じた。 この辺を進めているのは主に @hsbt さんな中、僕がこれを偉そうに書いたり今回のRubyKaigiで壇上でアナウンス

Armの福利厚生プログラム FlexPot 私が所属しているトレジャーデータは今年Armに買収され、福利厚生周りがArmのものに刷新された。 その中にFlexPotというものがあり、自己啓発にお金をつかってその領収書を会社に出すと、1年間の合計で上限XX万円まで会社が負担してくれるというもの。具体的な額の公開情報が見当らなかった*1のでふせておくが、割とがんばって使わないと損だなと感じる程度にはもらえる。 何に使うか考えたところ、私は主に家庭と自分の経済的な理由で大学院に行かず働き始めたものの、だんだん会社に給与的な意味で認めてもらえるようになり今は経済的に余裕ができたので、FlexPotも活用しつつちょっと大学院の授業受けてみようかなという気持ちになった。 スタンフォードの Non Degree Option アメリカに移住を考えている都合、日本ではなくアメリカの大学院に行った方がアメリ

昨日、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ファイルが作られ、ロードされる。 無制

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 とても丁寧に書かれているので、私の記事がわかりにくければ

先日のRubyKaigi 2017のLTではLLVMベースのCRuby向けJITコンパイラLLRBの話をしました。 5分はちょっとJITの話をするには短かかったですね。 LLRBをふまえた、Cのコード生成への軌道修正 さて、上記の資料にある通り、CRubyのJITにおいてはメインの高速化対象が既に存在するCのコードになるため、 開発の早い段階でパフォーマンスにインパクトを持てるとすればLLVM Passの順番を変えるくらいで、 LLVM IRを直接生成しても最適化上のメリットがほとんどないのでその部分はMJIT と同じくCのコードを生成するように変更したい、という話をした*1。 で、LLRBはC拡張として作るべくちょっと不思議な努力をいろいろやっており、 それらの設計はやってみた結果(コアに直接変更を加えるのに比べ)デメリットの方が大きいと思ったので、 LLRBの失敗を全て生かしつつ、今回

今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ

LLRBというRuby向けのメソッドJITコンパイラを書いている github.com RubyKaigi 2015の最後のキーノートで@evanphxが「LLVMでCRubyのコードをインライン化するメソッドJITを実装したら速いんじゃね」みたいな発表をしていたのを覚えているだろうか。 LLRBというのはまさにそれを実装しているプロジェクトであり、少なくとも現時点で「LLVMでCRubyのコードをインライン化するメソッドJIT」と言える状態まで実装でき、ものによっては効果が出る状態になったので公開した。 なんで書いてるの 言語を自分で実装するとその言語に関する理解が大分深まる、というのをHamlの実装とかCコンパイラとかで体験していて、僕が一番好きな言語はRubyなのでRubyでもそれをやっておきたい、というのがあった。また、Rubyは遅いと言われがちだが、どこに改善可能な点が眠っている

3月から Treasure Data で働いています。入社初日からタスクをアサインされ、RailsでAPIの開発をやりました。 なぜ Treasure Data に転職したのか 前職もやりたいことができて優秀な同僚に囲まれ文句ない環境だったのですが、アルバイト入社から数えるともう3年半が経っていたし、入社前にイメージしていたような仕事も大体経験できていました。 そのままいても良かったのですが、ある程度の間隔で新しいことに挑戦しないと成長は止まってしまうと思っているので職場ごと変えることも考え始め、以下のような観点から Treasure Data に転職することに決めました。 エンジニアがユーザーになる仕事をしてみたい 僕は開発者が使うツールを作るのが好きで、技術を売っている会社の方がそういうものを作る機会が増えそう 正直あまりエンジニアリング以外に興味がないので、一般の人を対象にしたサービ

高速なHTMLエスケープをするライブラリを作った ある日HTMLエスケープを速くしたくなって、hescapeというライブラリを作った。 github.com とにかく速いHTMLエスケープがしたい Railsアプリのビューのレンダリングにおいて、CGI.escapeHTMLを高速化*1することでRailsのデフォルトのテンプレートエンジンが大きく高速化されたり*2、GitHubでもHTMLエスケープが全体のパフォーマンスに影響が大きかった事例もある*3など、常に自動でHTMLエスケープが行なわれるRailsの環境ではHTMLエスケープの速度が割と大きな意味を持っている。 従って、Hamlitの最速性を維持するためにHTMLエスケープのパフォーマンスを極めておきたかった。 vmg/houdini を倒したい 前述したGitHubの人が既にhoudiniというかなり速いエスケープライブラリを作

クックパッドの社員が発表するCookpad TechConfというイベントの第一回が今日行われ、「Railsアプリ開発環境の高速化」というテーマで話してきた。 開発環境の改善について 僕が技術部に入る前、サービス開発をやる中で一番不満だったのが開発環境のパフォーマンスだったので、技術部に配属されたころからこの仕事をやりたいと思っていた。 今回は先輩方が既に行っていた開発環境のパフォーマンスチューニング - クックパッド開発者ブログの一部を紹介しつつ、その続きとして自分がやってきたことを発表した。 業務で出した成果のうちいままで外部で発表したのはbyebugの高速化くらいだったので、普段僕がどんな仕事をやっているのか紹介する良い機会になった。 発表内容の補足 思ったより15分の枠で話せたことが少なかったので、発表内で話し足りなかったことについて書く。 libsassおすすめです 急いでて全然