Rails 7.1 + Ruby 3.3 で YJIT を有効化してパフォーマンス改善を行った結果
この記事の概要 こんにちは。PharmaX でエンジニアをしている諸岡（@hakoten）です。 この記事では、薬局DX事業部のバックエンドで採用しているRuby on Railsのアプリケーションについて、Rubyバージョンを3.3にアップグレードし、YJITを有効化した結果、どのようにパフォーマンスが向上したかをご紹介します。 現在のRuby on Railsのバージョンは、「7.1.3」になります。 YJITについての簡単な説明 YJITとは、CRuby内部に組み込まれた軽量のJIT機能で、遅延コード生成を行い、必要なメソッドを部分的にコンパイルすることで高速化を図る仕組みです。 (処理系は詳しくないため、ざっくりになってしまいすみません。。) Ruby 3系列の主要な機能の一つであり、3.1で導入され、3.2で正式にサポートされ、3.3においてさらに安定化が行われています。 詳しい
Ruby 3.3 YJITのメモリ管理とRJIT 〜すべてが新しくなった2つのJITを使いこなす | gihyo.jp
Ruby 3.3リリース！ 新機能解説 Ruby 3.3 YJITのメモリ管理とRJIT 〜すべてが新しくなった2つのJITを使いこなす 2023年12月25日、Ruby 3.3.0がリリースされ、様々な新機能が加えられました。本連載では実際に携わった皆さんにその新しいRubyをご紹介いただきます。 RubyはJust-In-Time（JIT）コンパイラという機能を備えており、これを有効化すると実行時に機械語を生成して様々な最適化が行なわれ、実行が高速になります。Ruby 3.3にはYJITとRJITという2つのJITコンパイラがあり、デフォルトでは無効になっていますが、それぞれ--yjitと--rjitで有効化できます。 この回では、Ruby 3.3でYJITの性能特性が変化した点や、YJITに新たに追加された便利な機能、またRJITはどのように使うものであるかについて解説します。 YJ
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で行
かRuby 2.6のJITで実装か検討を行なった最適化集 - Qiita
これは言語実装 Advent Calendar 2018の25日目の記事です。 今日2018年12月25日は、Rubyに初めてJITコンパイラが搭載されたRuby 2.6のリリース日です。めでたい!! 進捗はRuby 2.6 JIT - Progress and Futureに書いてある通りですが、ハイライトとしては、CPU計算負荷の高いOptcarrotというNESエミューレータのベンチマークで、以下のような性能向上を達成しました。 Optcarrot Lan_Master.nes 2.6.0+JIT: 86.6 fps 2.6.0: 54.6 fps - 1.59x slower 2.5.3: 48.5 fps - 1.78x slower 2.0.0: 34.6 fps - 2.50x slower Ruby 2.6では、JITを有効にしなくても2.5に比較してそこそこ速くなっていま
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の失敗を全て生かしつつ、今回
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ruby 2.6 JIT / RubyConf 2018
