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
先日、次のような Tweet を見かけました TIL I discovered that TensorFlow.js uses an interesting trick to sniff your CPU architecture in WebAssembly. pic.twitter.com/LVyywIM48I — Robert Knight (@robknight_) January 4, 2023 面白かったので、なぜこうなるのかの解説と、ついでにこのテクニックを使った JIT 検知方法などについて紹介します。 JavaScript における低レイヤーの扱い JavaScript においては、挙動が比較的しっかりと仕様に定められているために、環境による振る舞いの違いはあまり発生しません。しかし、低レイヤーに降りるほど振る舞いは実装依存になり、環境差が発生する余地が出てきます。 一番
2022-09-09改訂： gcc バージョンが古すぎたのと、C が内部計測でなかった点を改め計測しなおしました。結果、Rust は C より速くはなくなりました。紛らわしいことで、ごめんなさい。また、gcc のバージョンアップに伴い、Python および Ruby についてはビルドと計測をしなおしたので、これらも少し速い値に変わっています。この点もどうぞあしからず。 2022-09-10追記：ご要望のあった Python numba.njit 使用時と Go の結果を追加しました。PHP は JIT 有効化が面倒だったので断念しました^^; 2022-09-10追記2：C の計測で clock() を使うのはフェアではないという指摘がありましたので、念のため clock_gettime() を使用したコードに差し替えました。結果に大きな差はありません。 2022-09-10追記3：PHP
国分崇志（@k0kubun）と申します。プログラミング言語Rubyのコミッターとして活動しています。2019年からシリコンバレーで働いており、2022年からShopifyという会社でRubyのJust-In-Time（以下、JIT）コンパイラをフルタイムで開発しています。 長い間趣味でやっていたコンパイラの開発を仕事にしたのは、現職が初めてでした。この記事では、趣味を仕事に変えた経緯や、どのようにして業務経験のない分野にキャリアチェンジしたのかを紹介します。 仕事で分散システム、趣味でコンパイラを書くキャリア 楽しく稼げる仕事を求めてたどり着いたRubyエンジニア 研究で分散システムと言語処理系の両方に興味を持つ 分散ミドルウェアを仕事で、JITコンパイラを趣味のOSS活動で やっぱりコンパイラを仕事にした複合的なきっかけ 働きながら大学院に通い、コンパイラが一番好きなことに気付いた コン
回答 (13件中の1件目) JIT方式は中途半端なものではありません。もちろん万能でなんでも優れているわけでもありませんが以下の利点があります。 * プログラムは単一の機械独立、OS独立の形式で配布できる(実行時に実行環境の機械語に変換できる) * 配布形式が小さくなる。マシン中立なバイナリ表現にした場合は特に。 * 全体をネイティブコンパイルするのではなく、速度にシビアに関わる最内周ループや何度も実行される場所に限ってネイティブコンパイルすることで実行に必要なメモリフットプリントを減らすことができる。 * 実行時だけわかる情報を元にした最適化やコード生成が可能。例えば、 *...
Chrome の JavaScript はとても高速なことでも有名ですが、その実行エンジンは V8 と呼ばれます。V8 自体は独立したモジュールであり、Node.js 等にも使われております。 V8 が JavaScript を高速に実行する技術の一つが JIT (Just In Time) コンパイルです（一般的に JIT と呼ばれます）。これは、そのまま実行すると遅い JavaScript を実行中にリアルタイムに直接マシンコードに変換し（これが Just In Time と呼ばれる所以です）、途中からそのコードに入れ替えて実行することで高速化を達成しています。特に何度も実行される関数で効力を発揮します。 JIT という名前は聞いたことがあろうとも、実際に JIT がどのようなコードを実行しているのかを確認する機会は滅多にないでしょう。この記事では、実際に V8 の JIT の出力を確
JITからのコペルニクス的転回か 筆者はサプライチェーンのコンサルティング会社に属している。コロナ禍以前と以後では、問い合わせの内容が異なっている。以前は、「働き方改革」「人工知能（AI）／RPA（Robotic Process Automation）の活用」といったテーマが多かった。 それがコロナ禍以後は、「働き方改革」はピタリとなくなった。それまで遅々としてテレワークなどは進まなかったのに、コロナ禍では背に腹は代えられないと、議論や手法論をすっ飛ばしてただちにテレワークの実践が進んだ。この日本人の火事場の転換力には感心した。一方でAIもRPAも現実的な応用に限界があると企業が感じたのか、次のデジタル・トランスフォーメーション（DX）にテーマが移っていった。 そして、コロナ禍以後に増えたのがコスト削減の相談や、在庫に関わる相談だ。コロナ禍が始まった直後はコスト削減についての相談が多かった
WebAssemblyで、JITコンパイラに迫る高速なJavaScriptエンジンを実装へ。Bytecode Allianceが技術解説。JavaScript以外の言語でも 「Bytecode Alliance」は、WebAssemblyをWebブラウザだけでなく、デスクトップPCやサーバ、IoTデバイスなどあらゆる環境で、セキュアに実行することを目指している団体です。 Fastly、Mozilla、Arm、Google、マイクロソフト、インテルをはじめとする企業や団体が名前を連ねています。 参考：WebAssemblyをあらゆるプラットフォームでセキュアに実行できるようにする「Bytecode Alliance」発足。インテル、Mozilla、Red Hatなど 同団体は「WASI」と呼ばれる、どのOSやホストシステムでWebAssemblyモジュールが実行されたとしても、安全かつ透過的
これらの JavaScript エンジンのうち、以下では特に JavaScriptCore を扱います。 最適化の基本戦略 JavaScript をはじめとする動的言語は、主にインタープリタにおいて実行されます。しかし、インタープリタはコンパイルされたコードと比較して実行に時間を要するという欠点があります。そこで、インタープリタの最適化では、バイトコードの JIT コンパイルが最初に行われます。 しかし、コンパイルには当然時間がかかります。少しでも高速化されたコードを生成するには、より多くの時間をコンパイルにかけなければなりません。コンパイルによる速度向上とコンパイルのレイテンシはトレードオフの関係にあります。 そこで、多くの JavaScript エンジンは、インタープリタと多階層の JIT コンパイラの組み合わせで構成されています。次の図は、主要な JavaScript エンジンの設計
estie でソフトウェアエンジニアをしている徳永(@yTo_9)です。 estie では Ruby を書いたりTypeScriptを書いたりしています！ estie 夏のブログ祭りにかこつけて、せっかくなら普段は追わない部分だけど、気になっていたYJITなるものを深掘りしてみようと思い、「YJITがなぜRailsアプリケーションの高速化を実現できたのか」を調べてみたので紹介したいと思います。 「どうせ難しいんでしょ？」と思いながら調べてみたのですが、講演や論文の説明がわかりやすく、意外に概要を把握することは難しくありませんでした。 YJIT の核となっているのは Lazy Basic Block Versioning (LBBV) という手法で、これはRubyだけに限らず動的言語全般に適用可能な強力なアプローチであることがわかりました。 「あるタイプの条件分岐は、ほとんどの場合で片側しか
どうも、趣味でOpenJDKのコミッタをしてます。 とあるブログを読んでいたら気になる点があったので検証してみました。 JITと暖気 Javaプロセスはアプリケーションを動かしながら必要に応じてバックグラウンドでバイトコードをネイティブコードにコンパイルします。このコンパイル時にはCPUリソースを使用します。 コンパイルにはいくつかのレベルがありますが、コンパイルされる前やレベルの低いコンパイルのコードはCPUのリソース効率が悪かったり、アプリケーションの処理中にコンパイルが実行されるとCPUリソースを奪いあったりなどが問題になります。 そのため、Java のアプリケーションで性能を気にする要件がある場合、本番に近いリクエストを投げてコードをJITコンパイルする事があります。これをよく暖気と言います。これにより本番のリクエストが来る前にコードを最適化し、よりCPUリソース効率の高いコードで
はじめに こんにちは。ニコニコ漫画の開発をしているyotaとtukiyoです。 この記事はペアブロギングによって執筆しています。 本記事ではニコニコ漫画で利用しているRubyのバージョンを3.2.0へ更新したこととYJITの有効化によるパフォーマンスの変化について紹介します。 ニコニコ漫画のインフラ構成についてにある通り、ニコニコ漫画は4つのプロダクトによって運用されています。 このうち本記事の対象となるのは、Rubyを利用している「新バックエンド」と「課金サブシステム」になります。 今回、Rubyのバージョンが3.2.0になったことでYJITが実験段階ではなくなりました。*1 ニコニコ漫画のバックエンドシステム内では複雑な処理も多く、恩恵に与ることを期待して更新を行いました。 結果として大きなパフォーマンスの向上が見られました。 はじめに 更新に関する作業 更新前後のパフォーマンス比較
次期Python、ついにJITコンパイラ搭載の見通し。「copy-and-patch」と呼ばれる新たなJITコンパイラの仕組みとは？ 機械学習やAI処理の分野を中心に非常に高い人気のプログラミング言語である「Python」の次期バージョンに、処理速度の向上を目指したJITコンパイラが搭載される見通しです。 このJITコンパイラは、PythonコアデベロッパーのBrandt Bucher氏が提案し、実装しています。 そしてPython Software FoundationのフェローであるAnthony Shaw氏がブログ「Python 3.13 gets a JIT」で、このJITコンパイラについて解説しています。 これらの情報を元に、PythonのJITコンパイラがどのように実装されようとしているのか、少し紹介していきましょう。 RubyもJavaScriptもJITが高速化を実現してき
アリスは驚きと興奮を抑えきれませんでした。彼女はすぐに新しいコードを試し、その速さに目を見張りました。今まで数時間かかっていた計算が、ほんの数分で終わったのです。 翌日、アリスはこの発見を友人たちに話しました。友人たちも同じように魔法の本を使い、彼らのコードを高速化しました。こうして、プログラミング王国全体で「JITの魔法の本」が広まりました。 やがて、アリスは王国のプログラミング大会で優勝し、JITの魔法の本の力をさらに広めることになりました。彼女は「JITの守護者」として称えられ、プログラミング王国はかつてない繁栄を迎えました。 アリスはいつも心に誓いました。どんなに強力なツールも、それを使う人々の努力と情熱があってこそ、本当の力を発揮するのだと。彼女の言葉は次世代のプログラマーたちに伝わり、JITの魔法の本は永遠に受け継がれていくのでした。 前回のあらすじ。 Python count
RubyのYJITコンパイラをShopifyが本番に投入、Railsアプリを高速化。Rubyも本格的にJITの時代へ ECサイト構築サービスを提供するShopifyは、Ruby 3.2に搭載されているYJITコンパイラを同社の本番環境に投入し、Railsベースで構築された同社サービスの性能改善を実現したと明らかにしました。 YJITコンパイラはShopifyが開発を進めてきたRubyのJITコンパイラで、大規模なRailsアプリケーションにおいてより高い性能向上を目指して開発されたものです。 一昨年末のRuby 3.1でメインラインにマージされ、昨年末に登場したRuby 3.2ではさらに改善が進められて本番環境にも耐えるようになったと説明されており、今回Shopify自身がそれを実証した形になりました。 If you’re a keen Rubyist, you may have hear
Ruby 3.3がリリースされた。YJITには非常に多くの改善が含まれたリリースだったが、 NEWS解説記事やリリースパーティーでは 2点しか触れられなかったので、この記事ではRuby 3.3でYJITがどう改善されたかについて解説する。 YJITは既に実用段階 YJITはRuby 3.1で導入されたが、Ruby 3.2の時点でexperimentalのマークが外れ、実用段階となった。 Ruby 3.2では、以下のような企業で性能改善が報告された。 DeNA: 40% 高速化 GMOペバボ: 18% 高速化 STORES: 6.5-7.5% 高速化 Timee: 10% 高速化 メドピア: 2.8% 高速化 BOOK☆WALKER: 20-30% 高速化 Discourse: 15.8-19.6% 高速化 Lobsters: 26% 高速化 CompanyCam: 20-40% 高速化 弊
Posted by naruse on 25 Dec 2022 Ruby 3.2.0 が公開されました。Ruby 3.2では多くの機能を追加するとともに、様々な改善が行われています。 WASIベースのWebAssemblyサポート WASIベースのWebAssemblyへのコンパイルがサポートされました。これにより、ブラウザやサーバーレスエッジ環境、その他のWebAssembly/WASI環境でCRubyのバイナリが利用できるようになります。現在この移植版はThread API以外のbasic testとbootstrap testをパスしています。 Background もともとWebAssembly (Wasm)が導入されたのは、プログラムをブラウザの上で安全かつ高速に実行するためでした。しかし、様々な環境で安全かつ効率的にプログラムを実行するという目的は、Webだけでなく一般的なアプ
RubyのJITコンパイラYJITを開発している弊社Shopifyでは、社内で最もトラフィックが多いストアフロントのアプリにRuby 3.3 (master) をデプロイして平均レスポンスタイムが16%高速化、社内で最も大きなアプリであるモノリスにRuby 3.2をデプロイして平均レスポンスタイムが9%高速化している。他の会社でも、YJITを本番で有効にしたら高速化したという事例をちらほら目にした。 一方で必ずしも良い報告ばかりではなく、YJITを有効化したらメモリを使い切ってしまったりだとか、遅くなったみたいな報告も目に入ることがある。こういった問題は我々も多かれ少なかれ経験しており、それぞれ適切に対処することで解決できたため、その知見を共有する。*1 メモリを使い切ってしまった時 zenn.dev YJITを有効化すると、YJITが生成する機械語に加えて、それに関するメタデータもメモリ
僕は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で行
はじめに こんにちは。Blockchain Labの高橋です。 以前、同じくBlockchain Labに所属している高瀬がスマートコントラクトとWebAssemblyの親和性について記事を公開しました (Web 以外でも期待される WebAssembly – Blockchain との親和性について)。 その中でも少し述べられていたようにWebAssembly Runtime を組み込んで VM として使用し、WebAssembly 形式でのスマートコントラクトをサポートするブロックチェーンが登場しつつあります。 そこで、今回は WebAssembly 形式でのスマートコントラクトをサポートしているブロックチェーンがどのような WebAssembly Runtime を VM に組み込んでいるのかを紹介します。 標準化の取り組み - WASI - ブロックチェーンで使われている WebA
Firefoxに搭載されている実行時コンパイラ(JIT)が、11月にリリース予定のバージョン83から大幅に高速化されることがわかりました。バージョン83は記事作成時点ではNightly版で提供されています。 Dogfooding Warp https://groups.google.com/g/mozilla.dev.platform/c/1PHhxBxSehQ Firefox's JIT is getting significantly faster | Hacker News https://news.ycombinator.com/item?id=24590174 JITとは、頻繁に実行するコードをあらかじめコンパイルしておくことで、コードの実行速度を向上させる技術のこと。ウェブブラウザはJITを備えることでJavaScriptを高速に実行し、快適なウェブブラウジングを実現しています
TOP500、HPCG、HPL-AI、Graph500での世界1位獲得、新型コロナウイルス対策を目的とした試行利用など、話題に事欠かないスーパーコンピュータ「富岳」。そのディープラーニング処理を高速化するには、あるOSSの存在が必要不可欠でした。それが、サイボウズ・ラボ（株）の光成滋生氏が開発したx86/x64向けC++ JITアセンブラ「Xbyak」の設計思想をベースに、光成氏の助言のもと（株）富士通研究所が開発したArm向けのC++ JITアセンブラ「Xbyak_aarch64」です。Xbyak_aarch64は、富岳上でのディープラーニング処理を実現するキー技術のひとつです。 本記事では、Xbyakの開発者である光成氏を中心に、（株）富士通研究所の上席研究員であり、Linuxカーネルへのコアコミッターでもある小崎資広氏を聞き手役として、同研究所シニアリサーチャーの川上健
コンパイラ基盤であるLLVMについて、全く知識がない私が、 javascriptソースコードをパースしLLVMでコンパイルできるようになりました。 LLVMの記事は数多くありますが、初心者向けの記事が少なく感じたため、 本記事では、できる限り分かりやすくLLVMについて紹介できる記事を書こうと思います。 ソースコードは、こちらに置いています。 自己紹介 ふだん、javascriptやpythonなどインタプリタ言語を使うエンジニアです。 LLVMについて、全く知識がなかった人間です。 背景 過去に、おもちゃのブラウザ自作をやってみました。 HTMLとCSSを解析し、レンダリングするところを書き、基本的な動作を知ることができました。 HTMLとCSSとくれば、次はJSだと思い、JSを実行するエンジンを書いてみたくなりました。 ただし、WebブラウザのAPIとJS実行エンジンをバインディングす
まずV8は普段自分たちが書いたコードをいくつかのスレッド上で実行するっぽい。 1つはソースコードを取ってきてそれを実行するやつ。それ以外に最適化を行うためのスレッド、プロファイラ、GCなどがあるようだ。 この最適化というのが今回調べたいJITってやつ。 そもそもインタプリタとの差を把握したい。 今の自分の把握の中では、インタプリタは逐次実行をするもの、JITは実行よりも前の段階でコンパイルをしてコンパイル済みのコードを実行すると言った差があるように思える。 このため一般的にはJITが効いたものの方がパフォーマンスが良いとされており、V8もインタプリタで実行するのではなくJITをベースに実行して行っているっぽい
js実行環境であるnodeはV8を使っている jsエンジンはソースコードをどうやって実行しているのか ここからが本題です。jsエンジンの裏側をのぞいてみましょう👀 全体像 下記が基本的な流れ V8って書いてあるけど、下記の基本的な流れはエンジンによらずほとんど同じはず もちろんそれぞれのフェーズで実装の違いは在る。“Optimize & Compile it”の具体的な実装などはエンジンにより異なる Benedikt Meurer; “An Introduction to Speculative Optimization in V8”; jsの面白いところは、ASTから直接コンパイルして実行されるわけでもなく、単純なインタプリタのようにコンパイルを挟まずに実行しているわけでもないところ。それに、なんだか見慣れない”Get feedback”というフェーズさえある……！ここがJIT com
RubyKaigi 2023でRuby JIT Hacking Guideというタイトルで発表してきた。 speakerdeck.com JITコンパイラを書くチュートリアル 今回の発表ではJITコンパイラが書ける人間を増やすことをゴールにしていたが、 30分という短い発表枠内では雰囲気を知ってもらうことにフォーカスし、 実際に手を動かしたい人たちにはそれ用のチュートリアルを触ってもらう形を取った。 github.com JITコンパイラは実は初心者向き 独学でコンパイラの作り方を学ぶ人は、Cコンパイラなどを実装することが多いように思う。 C言語は実装対象として一見シンプルそうに見えて実は結構機能が多いので、C11をゴールに始めてもC89の範囲すら実装しきらないままエターなる人も多いのではないか。 そんな僕みたいな堕落した人間にお勧めなのがJITコンパイラ。 インタプリタと併走する特性上、
Kernel/VM探検隊は、カーネルやVM、およびその他なんでもIT技術の話題ジャンルについて誰でも何でも発表してワイワイ盛り上がろうという会です。monochrome氏は、Ruby処理系「monoruby」について発表しました。 高速な実行が可能なRuby処理系「monoruby」 monochrome氏（以下、monochrome）：monochromeといいます。今日は「機械語で書くRuby処理系のその後」ということで、前回の発表のその後を報告いたします。 自己紹介です。monochromeといいます。（スライドを示して）Twitterはこれです。最近、Twitterは治安が悪いので、Mastodonにアカウントを作りました。RustでRubyの処理系を作っています。プログラミング処理系、言語処理系が好きな人の集まりのSlackとか、最近はこの「Zulip」というアプリに移動して、こ
Ruby 3.3’s YJIT Runs Shopify’s Production Code 15% Faster
Ruby 3.2 YJIT is Battle-Tested Shopify deploys YJIT on business-critical services in production, such as Storefront Renderer, the software that powers all online storefronts on Shopify’s platform, and Shopify’s Monolith. As of the Ruby 3.2 release, YJIT sped up our Storefront Renderer by 10% on average. Storefront Renderer is a complex application. Your more reasonable-sized app might get better/w
This post is all about speculative compilation, or just speculation for short, in the context of the JavaScriptCore virtual machine. Speculative compilation is ideal for making dynamic languages, or any language with enough dynamic features, run faster. In this post, we will look at speculation for JavaScript. Historically, this technique or closely related variants has been applied successfully t
Ruby 3.1はここに注目！ 新しいJITとは？ デバッガ、エラーメッセージ、そして未来！ リリースマネージャーに聞いた 2021年12月25日にリリースされたばかりのRuby 3.1では、どのような機能がどういった経緯で採用されているのでしょう。リリースマネージャーのnaruseさんと、フルタイムコミッターのmameさん、ko1さんに詳しくうかがいました。 プログラミング言語Rubyでは2013年の2.1.0以降、毎年クリスマス（12月25日）にメジャーバージョンアップが行われています。2021年も無事にバージョン3.1.0がリリースされました。 ▶ Ruby 3.1.0 リリース Ruby 3.1は、言語機能の面では全体的に穏やかなリリースにも見えますが、新しい方式のJIT（just in time）コンパイラ、標準の新デバッガー、事前アナウンスでも好評だったエラーメッセージの改善な
Rust.Tokyo 2022
Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
https://ginza-rails.connpass.com/event/178203/
YJIT の Rust 実装がマージされました。いまのところ今年の Shopify からの代表作ではと見ています (YJIT 自体は Ruby 3.1 で C 実装導入されている機能です) 。 github.com そういうわけで、現在の Ruby 3.2.0dev で YJIT を有効にする場合は、Rust の処理系 (1.60.0 1.58.1 以上) が必要になります。Rust のインストールに使う rustup については以下の公式ページなどを参照してください。 www.rust-lang.org YJIT はデフォルトではビルドされません (なので YJIT を使わないビルドであれば Rust 処理系は不要です) 。 デフォルトの YJIT なしの Ruby をビルドしている場合は --yjit オプションを渡しても、ruby: warning: Ruby was built w
サーバーサイドエンジニアの内藤(@naitoh) です。 Rails で構築された小規模な APIサーバー(Rails の API モードで構築したもの)で、Ruby 3.2 の YJITを有効化する事で性能アップすることができましたので、喜びを分かち合いたく共有させて頂きます。 shopify.engineering We’re able to measure real speedups ranging from 5% to 10% (depending on time of day) on our total end-to-end request completion time measurements. YJIT を開発した Shopify では 5%から10%の処理速度の改善があったという事で、以前から弊社でも本番で運用を開始したかったのですが、比較的検証のし易い APIサーバーで
Ruby開発チームは、新たなJITコンパイラであるYJITを実験的に搭載したRuby 3.1プレビュー1を公開しました。 Ruby言語は以前から実行速度の向上を重要な改善項目として挙げており、Ruby 2.6では「MJIT」と呼ばれるJITコンパイラを搭載、昨年リリースされたRuby 3.0では目標としていたRuby 2の3倍の性能を達成しています。 参考：Ruby 3.0正式版リリース。「Ruby 2の3倍速」到達、型の記述、スレッドセーフな並列処理など新機能 一方でMJITはその機構上、Railsの大規模アプリケーションなどでの性能向上に十分な効果が発揮できていないとの評価もありました。 今回Ruby 3.1プレビューでマージされたのは、ECサイト構築サービスで知られるShopifyが開発を進めてきた「YJIT」と呼ばれるJITコンパイラです。 YJITは現在のところ20％から40％程
本エントリでは、PHP の内部実装（php-src）から OPcache のオペコードキャッシュの仕組みを見ていきます。 OPcache にはいくつかの機能がありますが、ここでは共有メモリへのオペコードキャッシュと preload が対象です。ファイルベースのキャッシュと JIT については触れません。 サマリ オペコードキャッシュ preload オペコードキャッシュと preload の比較 オペコードキャッシュ キャッシュデータレイアウト グローバル変数、マクロ キャッシュデータ構造体 オペコードキャッシュ: ZCSG(hash) キャッシュエントリ: zend_accel_hash_entry キャッシュデータ初期化 OPcache 処理の有効化 PHP ファイルコンパイル処理でのキャッシュ制御 persistent_compile_file() の主な処理 zend_accel_
Ruby開発チームは、2021年12月25日にRuby 3.1.0の正式リリースを発表しました。 Rubyは毎年12月25日に新バージョンをリリースすることが恒例となっています。今回も一昨年のRuby 3.0に続いて新バージョンが登場しました。 Ruby 3.1でもっとも注目すべき新機能は、JITコンパイラの「YJIT」がメインラインにマージされたことでしょう。 大規模なRailsアプリでの性能向上を目指したYJIT RubyのJITコンパイラとしてはRuby 2.6から登場した「MJIT」がありますが、今回Ruby 3.1でマージされたYJITはMJITとは別のものです。 YJITは、ECサイト構築サービスで知られるShopifyが開発を進めてきたもので、Shopify自身が構築している大規模なRailsアプリケーションにおいて、より高い性能向上を目指して開発されてきました。 同社のブロ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ruby 3.1正式リリース。Shopify開発のJITコンパイラ「YJIT」をメインラインにマージ