Ruby 3.2 Released With WebAssembly Support, Production-Grade YJIT

[phoronix]

Phoronix: Ruby 3.2 Released With WebAssembly Support, Production-Grade YJIT

Ruby programming language developers have issued a Christmas release of the latest iteration of this language focused on simplicity and productivity...

https://www.phoronix.com/news/Ruby-3.2-Released

[gosh000]

It seems that Ruby project has written Ruby interpreter in WASM what can run code written in Ruby. Is this correct?

This is original article with examples - https://www.ruby-lang.org/en/news/20...-2-0-released/

[guglovich]

X9ulfac.png
- Unlike CRuby, YJIT code is written in Rust and requires the rustc 1.58.0+ compiler to compile, so the YJIT build is disabled by default and is optional. When using YJIT, a 41% performance increase in the yjit-bench test was recorded compared to using interpretation.

- Additional protection against denial of service attacks on external data processing in inefficient and long running regular expressions (ReDoS) has been added. Significantly improved mapping algorithm, which uses memoization technique. For example, the execution time of the expression '/^a*b?a*$/ =~ "a" * 50,000 + "x"' was reduced from 10 to 0.003 seconds. The price of optimization is an increase in memory consumption, the consumption of which is about 10 times higher than the size of the input data. The second protection measure is the ability to define a timeout (e.g., "Regexp.timeout = 1.0"), during which the regular expression must have time to be processed.

- The proposed Ruby_vm/mjit/compiler is a variant of the old JIT compiler MJIT rewritten in Ruby. It allows to execute MJIT in a separate process instead of executing it in a MJIT worker thread.

- Bundler 2.4 features the PubGrub version identifier for dependency handling, also used in the pub package manager for the Dart language. The previously used Molinillo algorithm continues to be used in RubyGems, but will also be replaced by PubGrub in the future.

- Updated versions of built-in and included in the standard library gem modules.

[Michael_S]

Interesting. At my new job we have a huge Ruby on Rails monolith, I'm curious to see how this affects performance.

...but then again, most of our performance issues come from tons of sequential synchronous operations that are unrelated. Someone could probably pick the slowest language in common use today, rewrite the stuff to be spawned all at once async, and get faster page views than reimplementing the existing synchronous blocking behavior in C.