OPcache オペコードキャッシュの仕組み - Shin x Blog
本エントリでは、PHP の内部実装（php-src）から OPcache のオペコードキャッシュの仕組みを見ていきます。 OPcache にはいくつかの機能がありますが、ここでは共有メモリへのオペコードキャッシュと preload が対象です。ファイルベースのキャッシュと JIT については触れません。 サマリ オペコードキャッシュ preload オペコードキャッシュと preload の比較 オペコードキャッシュ キャッシュデータレイアウト グローバル変数、マクロ キャッシュデータ構造体 オペコードキャッシュ: ZCSG(hash) キャッシュエントリ: zend_accel_hash_entry キャッシュデータ初期化 OPcache 処理の有効化 PHP ファイルコンパイル処理でのキャッシュ制御 persistent_compile_file() の主な処理 zend_accel_
Ruby 3.3.2 (+YJIT) アップデートによるパフォーマンス改善レポート - inSmartBank
はじめに こんにちは！株式会社スマートバンクでサーバサイドエンジニアをしている @nagasawa です。 2024年6月より弊社では Ruby 3.3.2 を本番アプリケーションで稼働させ始めたため、バージョンアップ前と比較してどの程度パフォーマンスに変化が現れたのかをご紹介いたします。 また、今回を機に YJIT Metrics の可視化と YJIT の遅延起動にも取り組んだため、その手法や効果についてもこの記事内でシェアできればと考えています。 前提 下図のシステムアーキテクチャ図の通り、弊社では Ruby と Rails で開発されたいくつかのシステムを稼働させています。 この記事では core-api と呼ばれている私達が開発してる「家計簿プリカ B/43」の機能のほぼ全てを提供しているシステムのパフォーマンス変化をご報告いたします。 バージョンアップ前 バージョンアップ後 Ru
こわくないLLVM入門！ - Qiita
対象読者 LLVMを勉強し始めたけど何からして良いのかわからない方 アセンブリがちょっとわかる 目標 LLVMの基本的な文法がわかるようになる 環境 Mac Mojave 10.14.6 LLVM 8.0.0 clang 8.0.0 (trunk 348837) LLVMってなに...? LLVMは一言で言えば、プログラミング言語を作成する為の基盤です。プログラミング言語はコンパイラによってバイナリに変換され実行することができます。それを言い換えれば、自分が考えたプログラミング言語のコンパイラを作ることで自作プログラミング言語を作れます。 そして、コンパイラは通常フロントエンド、ミドルエンド、バックエンドに分けられ、各プロセスで様々な処理をしています。特にミドルエンド、バックエンドでは中間言語や各アーキテクチャに対するたくさんの最適化を施さなければなりません。この最適化を預けてフロントエン
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
YJIT: CRuby向けの新しいJITコンパイラを構築する（翻訳）｜TechRacho by BPS株式会社
概要 Shopify Engineeringの許諾を得て翻訳・公開いたします。本記事は公開前にShopify Engineeringにレビューをいただいています。 英語記事: YJIT: Building a New JIT Compiler for CRuby — Development (2021) 原文公開日: 2021/10/14 原著者: Maxime Chevalier サイト: Shopify Engineering 画像は元記事のものです（追記2021/11/04: 冒頭イラストを削除いたしました）。 本記事はTwitterにて@shiroemonsshiromemonsさまからのリクエストを受けて翻訳いたしました。リクエストありがとうございます！ なお、以下のissue #18229で、著者のMaxime Chevalierさんをコミッターに迎えるプロポーザルが出され、そ
セルフホストで学ぶJVM入門 - k0kubun's blog
RubyのJIT開発でやろうと思ってることが大体 @_ko1 さんの作業待ちでブロックしていて暇なので何かを書こうと思い、JVMを書くことにした。 まだその辺のアプリを気軽に動かせるレベルでは全然ないが、別に秘密裏に開発する必要もないと思ったので公開した。 github.com これの紹介と、現時点で学べたことをこの記事に記録しておく。 何故JVMなのか 仕事でJVM言語を使っている 僕が所属しているTreasure Dataでは、大雑把に言うと本番サーバーのサービスは大体Ruby, Java, Scala, Kotlinで書かれている*1ので、既にRubyのVMはある程度わかる*2ことを考えると、JVMさえ理解してしまえば社内の主要な言語評価系を抑えたことになり、運用面で活躍の機会が増える気がしている。 また、自分が最近一番書いているのはKotlinなのだが、JVMで動かしていることに由
GraalVMはどれだけ遅いか - きしだのHatena
GraalVM流行ってますね。 そして、多くの人はGraalをAOTとして使うnative-imageのことだけをGraalVMと言ってたりします。 ご安心を。このエントリではGraalをJITとして使うHotSpotモードとGraalをAOTとして使うnative-imageの両方が遅いという話です。 GraalVMは速い、と言われてますが、残念ながらHotSpotモードでC2より速い結果を手元では出せていません。 公式ブログでは1.7倍から5倍速くなると書いてますけど、手元では再現できてません。 Under the hood of GraalVM JIT optimizations - graalvm - Medium native-imageは速い、というのはよくありますが、これはネイティブ化によりJVMの起動時間や最適化の時間、最適化されずに動く時間が省略されるので起動が速い、とい
Ruby高速化の戦い@RubyKaigi2019 - バイセル Tech Blog
梅雨の季節と思いきや、清々しい天候の続くこの頃、皆様いかがお過ごしでしょうか？ Tech開発部アーキテクチャグループで色々やっております塚本と申します。普段はスクラムマスターやったりしています。 もうひと月以上経ってますが、先日参加してきたRubyKaigiのセッションの内容を掘り下げて記事にしてみます。 Kaigiの概要は村上さんの記事をご参照ください。 tl;dr; Rubyはよい 個人的にはコミッターがよい（失礼） 発表もよい 記事にしたいセッションが絞りきれず執筆が大変なことに Rubyコアの速度改善の話に絞りました 他はまた別途 Rubyist world map Rubyに対して 私のRuby歴は全部足して3年くらいで、関わってきたコミュニティの皆さんほど言語に対する思い入れもなく、Railsなんかツラい思い出が9割くらいなんですが、Rubyはいい言語だと思います。 端的にいう
よく知らない Graal/Truffle についてわかっているふりをして書く
AdventCalendar-2018.md これは高知工科大 Advent Calendar 2018の8日目の記事です． Graal/Truffle について紹介したかった 最近私の中で話題になっている，Graal/Truffle について書く． すごく抽象的なことしか述べない． 動的なプログラミング言語の高速化の辛さ JavaScript や Ruby ， Python などといった，動的なプログラミング言語の高速化が難しいことは よく知られている． 例えば，型がないので，式の実行時にデータの種類をチェックし，言語セマンティクスに従って処理を振り分ける （型ディスパッチ）必要がある． また，関数の定義を実行中に変えることができたりするため，関数呼び出しの際は，その前にどの関数を 実行するのかを調べてからその関数に処理をとばす必要がある． このような，処理の振り分け（ディスパッチ）にか
GitHub - rianhunter/wasmjit: Kernel Mode WebAssembly Runtime for Linux
Wasmjit Wasmjit is a small embeddable WebAssembly runtime. Its core is written in C90 and is easily portable to most environments. Its primary target is a Linux kernel module that can host Emscripten-generated WebAssembly modules. In this configuration it runs WebAssembly modules in kernel-space (ring 0) and provides access to system calls as normal function calls. This configuration avoids user-k
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 とても丁寧に書かれているので、私の記事がわかりにくければ
オンスタックリプレイスメント(on-stack replacement)の実装を進めなくちゃ - ユウキ木本のPerlテックブログ
SPVMでJITの実装を進めているだけれど、バージョン1.0に向けて、どうしても実装しておかないといけない機能がある。 それは、バイトコードのループの途中で、ループの回数が増えた時に、ループの途中でJITのコードをコンパイルして、そのまま処理を移し替えるオンスタックリプレイスメントだ。 JavaのHot Spotはもうとっくの昔に、実装している。 オンスタックリプレイスメントがないとどうなる もしループ処理が初回に1億回、回って終わるまで待つとしたら、それが終わるまでJITできない。サブルーチンが1万回実行したら、JITしようという実装は、ループに対応ができない。 だから、ループの途中で、バイトコードからJITでコンパイルされた機械語に切り替える処理が必要になる。 実装方法は、今考えている。 関数はデータ領域と処理からなる プログラムというのは、関数の集まりだ。関数というのは、「引数やロー
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の失敗を全て生かしつつ、今回
JITコンパイルでの冒険 パート2：x64 JIT | POSTD
このシリーズの最初のパート (訳注:POSTDの翻訳記事へのリンクです) で簡単にBFソース言語を紹介し、最適化レベルが高まる4つのインタプリタについて述べました。実際にJITをいじる前に背景を知る上で役に立つと思います。 さらに背景を知る上で有効なのが、2013年に私が書いた『 JITの方法 – 入門編 』という記事です。ここでは、実行時に実行可能なx64機械コードの生成と実際にLinux上で実行するために必要な基本ツールについて説明しました。初めての方はまずこれらの記事を読んでください。 JITの2つの段階 以前 にも書きましたが、JIT手法を2段階に分けて考えると理解しやすいと思います。 プログラム実行時に機械コードを作成する。 作成した機械コードもプログラム実行時に実行する。 BF JITの第2段階は前記事で説明した方法と全く同じ内容です。詳細は jit_utils の JitPr
JITコンパイルでの冒険 パート1：インタプリタ | POSTD
本記事は、JITコンパイラに関するシリーズの第1回目です。計画としては、シンプルな入力言語を使ってそのインタプリタとJITをいくつか開発し、段々と複雑なものにしていくつもりです。このシリーズが終わるまでに、JITコンパイラの開発に何が必要か、そのためにどんな支援ツールが使えるかを、読者の皆さんによく理解していただけるようになれば幸いです。 入力言語は Brainfuck です。本シリーズでは以後、BFと呼んでいきます。BFはプログラマビリティの本質を突き詰めるので、今回の目的に適した言語だと思います。BFは、プログラミングは非常に冗長ですが、なじみのC構造体に直接マップするメモリポインタやループのような概念を持つ点で、プログラミング言語としてはかなりの”メインストリーム”です。 実装言語にはC++を使います。”手始め”の言語としては一般的ではないかもしれません。とはいえ、私の知っている大部
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は遅いと言われがちだが、どこに改善可能な点が眠っている
R 3.4.0 のJITバイトコンパイラってどんくらい早くなるの？ - でーたさいえんすって何それ食えるの？
R3.4.0がリリースされましたね。 で、大きな変更点のひとつにJITバイトコンパイラがデフォルトでONになってるとのことです。 これによって、forループやfunctionは特に何もせずともバイトコンパイルが行われて高速化が行われることになります。 ※ただしbrowser()が入れられた関数はバイトコンパイル対象外になります。 ※コンパイルが不要なときは、compiler::enableJIT(0)または環境変数のR_ENABLE_JITを0にすればOKです 他にも色々アップデート情報の詳細はこちら R: R News で、RStudioもこのバイトコンパイル機能に対応したアップデートが行われたそうです。 cmpfun()使うとけっこう早くなるんだよなー。。。程度には覚えていたものの 具体的にどんだけ早いの？に対してはよく覚えてないので このバイトコンパイラでどんだけ早くなったのか？ を
Java Just-In-Timeコンパイラの実装技術
PPLサマースクール2016「商用Java処理系の研究開発」のパート2です． http://ppl.jssst.or.jp/index.php?ss2016 Java言語処理系の実装について詳説する．まずJava仮想マシンの概要について述べ，その主要な構成要素として，クラス管理とインタープリタ，ヒープ管理とガベージコレクション，スレッド管理と同期機構，JITコンパイラとの連携，などについて説明する．性能改善のために行った各種手法についても触れる． 他のパート 1 Javaの登場と発展 http://www.slideshare.net/Tamiya_Onodera/java-66081108 2 Java仮想マシンの実装技術 http://www.slideshare.net/KiyokuniKawachiya/java-66003903 3 Java Just-In-Timeコンパイラの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Why Ruby's JIT was slow / RubyKaigi Takeout 2021
mrubyのJIT
