Ruby 3.3.0 的消息

也是有點奇特,年底的慣例長假反而釋出 Ruby 3.3.0:「Ruby 3.3.0 Released」。

整體看起來比較大的改變有兩組,一塊是 parser 相關的消息,包括了 GNU Bison 換成 Lrama,兩個都是 LALR parser,但後者是 Ruby 寫的。

另外一塊是 JIT 相關的消息,包括了 YJIT 的持續進步,以及 RJIT 的引入。

看起來有在用 Ruby 的大型站台都跳進去幫 YJIT 發展了,這邊應該是正循環,會有更多的 feedback 與實作進來改善 YJIT。

而 RJIT 看起來是個實驗性質的東西,目前只會在 x86-64 上生效,不知道目標會是什麼:

Introduced a pure-Ruby JIT compiler RJIT and replaced MJIT.

Ruby 3.3 的速度再次提升

在「Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster」這篇提到了 Ruby 3.3 的速度再次提升的消息。

Shopify 上面的測試,3.3.0-preview2 的速度已經比 3.2.2 (兩者都有開啟 YJIT) 快了 13%,而且 p50/p90/p99 都有對應的改善:

不過有提到一些要注意的點,像是記憶體的用量又會再更高 (本來開 YJIT 的時候就已經有增加了),如果是對記憶體比較敏感的環境,會需要注意這點:

Since Ruby 3.3.0-preview2 YJIT generates more code than Ruby 3.2.2 YJIT, this can result in YJIT having a higher memory overlead. We put a lot of effort into making metadata more space-efficient, but it still uses more memory than Ruby 3.2.2 YJIT. We’re looking into skipping compilation of paths that are less frequently executed.

但 server 端應該是還好 (記憶體給多一點),整體是個可以期待的方向...

Ruby 再引入另外一套 JIT 實做:RJIT

Hacker News Daily 上看到「RJIT #7448」這個,Ruby 上一套新的 JIT 實做。

這次的 RJIT 取代掉先前的 MJIT:

This PR replaces the current implementation of MJIT with a new JIT called "RJIT"

有些特點,其中一個是 RJIT 在 buildtime 與 runtime 都不需要 compiler,這是因為 RJIT 直接用 Ruby 實做:

RJIT uses a pure-Ruby assembler to generate native code

  • MJIT requires a C compiler at runtime. YJIT requires a Rust compiler at build time. RJIT doesn't require them.
  • This means that RJIT's warmup could be slower than YJIT, but it's still much faster than MJIT's.

另外值得注意的是,RJIT 的作者 k0kubunYJIT 的作者 Maxime Chevalier-Boisvert 都是 Shopify 的員工,可以看出 Shopify 對於 Ruby 效能的痛?決定直接自己養人改善效能。

回到 RJIT 這邊跑的測試,可以看到他是用 YJIT 的測試套件測,這也就不會太奇怪了。

跟這次取代掉的 MJIT 相比,RJIT 在 Headline 這包測試都 OK,在 Other 這包則是有來有回,而在 Micro 這包則是有不少項目輸掉 (相比於前兩者):

這樣整體看起來算是有進步,下一版 Ruby 更新應該就會有了。

Ruby 3.2.0 把 YJIT 列為穩定功能了

去年有寫過 RubyYJIT 帶來的效能提昇:「YJIT 帶給 Ruby 大量的效能提昇」。

在這次的 Ruby 3.2.0 發布就把 YJIT 列為穩定功能了:「Ruby 3.2.0」。

  • YJIT is no longer experimental
    • Has been tested on production workloads for over a year and proven to be quite stable.

另外就是支援的平台,看起來是多了 arm64 這邊的支援,所以馬上列表就多了一堆新機器:

  • YJIT now supports both x86-64 and arm64/aarch64 CPUs on Linux, MacOS, BSD and other UNIX platforms.
    • This release brings support for Apple M1/M2, AWS Graviton, Raspberry Pi 4 and more.

另外是每個程式語言幾乎都會遇到的 regexp 類的問題,這次 Ruby 3.2.0 利用 Memoization 的方式降低某些 regexp 的消耗:

# This match takes 10 sec. in Ruby 3.1, and 0.003 sec. in Ruby 3.2
/^a*b?a*$/ =~ "a" * 50000 + "x"

而另外一組 regexp 也可以看出類似的效果:

用一些記憶體空間換取效能,降低被 DoS 的一些機會。另外一方面,引入了 regexp timeout 的 workaround,緩解真的被打的時候的資源消耗上限:

The optimization above cannot be applied to some kind of regular expressions, such as those including advanced features (e.g., back-references or look-around), or with a huge fixed number of repetitions. As a fallback measure, a timeout feature for Regexp matches is also introduced.

YJIT 帶給 Ruby 大量的效能提昇

Hacker News 首頁上看到的消息,由 Shopify 贊助的 YJIT 被 Ruby 官方接受了:「Merge YJIT: an in-process JIT compiler (github.com/ruby)」。

YJIT currently provides average speedups of 23% over the CRuby interpreter on realistic benchmarks, and near-instant warm-up time.

實做 YJIT 的 Maxime Chevalier-Boisvert 在他自己的 blog 上有提到這次的實做:「YJIT: Building a New JIT Compiler Inside CRuby」,裡面選擇的方法是他的 PhD 論文:「Simple and Effective Type Check Removal through Lazy Basic Block Versioning」。

可以看到在六月寫文章的時候,改善其實還沒這麼大,而且作者提到有不少可以再提昇的空間:

That being said, according to our benchmarks, we’ve been able to achieve speedups over the CRuby interpreter of 7% on railsbench, 19% on liquid template rendering, and 19% on activerecord.

Currently, only about 50% of instructions in railsbench are executed by YJIT, and the rest run in the interpreter, meaning that there is still a lot we can do to improve upon our current results.

本來的 MJIT 看起來會慢慢淡出...

為線上環境而最佳化的 Ruby:Fullstaq Ruby

最近看到的「Fullstaq Ruby」,專為線上環境最佳化的 Ruby

Fullstaq Ruby is an MRI-based Ruby distribution that's optimized for server production use cases.

目前主要是使用 jemalloc (超萬用) 以及 malloc_trim patch:

It is compiled with the Jemalloc and malloc_trim patches, allowing lower memory usage and higher performance.

其中看了一下 malloc_trim patch 的介紹還蠻有趣的:「What causes Ruby memory bloat?」,這篇主要是在討論記憶體用量的問題,以及目前常見的 workaround。

這個 patch 是針對 Ruby 在 full mark GC 的情境後,增加呼叫 malloc_trim(0); 以釋放記憶體,作者發現這樣可以省下了大量的記憶體空間:

然後作者預期效能應該會有影響 (畢竟多做了一些事情),所以找了有在做 Rails benchmark 的人幫忙測試,結果發現反而變快了:

這樣看起來有可能官方會考慮把這個 patch 直接包進去?不過這看起來是在使用 jemalloc 的前提下?不知道如果使用標準的 glibc 會怎麼樣...

macOS 打算移除 Perl/Python/Ruby

從 beta 版的 release note 可以看到 macOS 打算在 10.15 移除 PerlPythonRuby:「macOS 10.15 Beta Release Notes」。

Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)

看起來會另外包一份出來... 不過這樣內建的工具就少了些,雖然 shell script 是 turing machine... :o

AWS Lambda 支援 Ruby 2.5 以及其他語言

AWS 宣佈 Lambda 支援 Ruby 2.5:「AWS Lambda Supports Ruby」。

另外宣佈可以透過 Layer 的方式讓任何程式語言在上面跑 (前面提到的 Ruby 看起來就是用這個方式支援的):「New for AWS Lambda – Use Any Programming Language and Share Common Components」。

The Runtime API is the future of how we’ll support new languages in Lambda. For example, this is how we built support for the Ruby language.

CodeDeploy 的 codedeploy-agent 總算支援 Ubuntu 18.04 的環境了...

先前在『在 AWSUG Taiwan 上講的「用 AWS CodeDeploy 解決程式佈署」』這邊有分享過 CodeDeployUbuntu 18.04codedeploy-agent 會認為系統內建的 rubycodedeploy-agent 不支援的版本:「Support for ruby 2.5 (Ubuntu 18.04) · Issue #158 · aws/aws-codedeploy-agent」。

剛剛總算看到修正後的版本被推出去了:

這樣就不需要自己修正惡搞了...