Benoit Daloze
@eregon.me
Expert in dynamic language runtimes and JIT compilation, TruffleRuby lead, Rubyist.
https://eregon.me
https://eregon.me
Yeah that's pretty shady behavior, seems worth reporting. I usually leave a comment to let people know the spam they are causing in such cases. Pretty weird to copy issues like that.
January 16, 2026 at 7:12 AM
Yeah that's pretty shady behavior, seems worth reporting. I usually leave a comment to let people know the spam they are causing in such cases. Pretty weird to copy issues like that.
Not entirely sure because I haven't tried in a while but worth a shot. It might also depend on which parts you use so I'd suggest to try it and see.
January 15, 2026 at 1:54 PM
Not entirely sure because I haven't tried in a while but worth a shot. It might also depend on which parts you use so I'd suggest to try it and see.
@statitudes.com Maybe you could try running the full benchmark or even the full app on TruffleRuby?
January 15, 2026 at 12:23 PM
@statitudes.com Maybe you could try running the full benchmark or even the full app on TruffleRuby?
I ran your benchmarks from bugs.ruby-lang.org/issues/21824 on TruffleRuby with a slight tweak to use benchmark-ips for warmup and the result is 2.42x faster than CRuby 3.4.8 on the first benchmark and 4.66x faster on the second/minimal benchmark!
See gist.github.com/eregon/e3692... for details.
See gist.github.com/eregon/e3692... for details.
January 15, 2026 at 12:23 PM
I ran your benchmarks from bugs.ruby-lang.org/issues/21824 on TruffleRuby with a slight tweak to use benchmark-ips for warmup and the result is 2.42x faster than CRuby 3.4.8 on the first benchmark and 4.66x faster on the second/minimal benchmark!
See gist.github.com/eregon/e3692... for details.
See gist.github.com/eregon/e3692... for details.
See bugs.ruby-lang.org/issues/21830, so it seems require overrides are ignored.
January 9, 2026 at 2:29 PM
See bugs.ruby-lang.org/issues/21830, so it seems require overrides are ignored.
Mention in the title and social post, if it wasn't clear.
January 9, 2026 at 2:13 PM
Mention in the title and social post, if it wasn't clear.
Is this intentionally misleading? Because you should clearly mention this only benchmarks `java -version` and not any relevant benchmark.
January 9, 2026 at 2:12 PM
Is this intentionally misleading? Because you should clearly mention this only benchmarks `java -version` and not any relevant benchmark.
Koichi gave a talk at VMIL about it: youtu.be/pqDMne677Ww?...
The code is at github.com/ko1/astro
naruby uses the Prism C API for parsing: github.com/ko1/astro/tr...
The code is at github.com/ko1/astro
naruby uses the Prism C API for parsing: github.com/ko1/astro/tr...
youtu.be
January 7, 2026 at 1:52 PM
Koichi gave a talk at VMIL about it: youtu.be/pqDMne677Ww?...
The code is at github.com/ko1/astro
naruby uses the Prism C API for parsing: github.com/ko1/astro/tr...
The code is at github.com/ko1/astro
naruby uses the Prism C API for parsing: github.com/ko1/astro/tr...
And regardless of that, I think this is still a bug of Ruby::Box, it needs to support redefining require. I think the way it works is Zeitwerk gets called first and then doesn't super in the original Kernel#require.
January 4, 2026 at 11:15 AM
And regardless of that, I think this is still a bug of Ruby::Box, it needs to support redefining require. I think the way it works is Zeitwerk gets called first and then doesn't super in the original Kernel#require.
It sounds good to make require more flexible but OTOH it seems like a big design space and lots of work. I like the idea in bugs.ruby-lang.org/issues/16848..., though it doesn't address that code expects that $LOAD_PATH only contains Strings.
January 4, 2026 at 10:55 AM
It sounds good to make require more flexible but OTOH it seems like a big design space and lots of work. I like the idea in bugs.ruby-lang.org/issues/16848..., though it doesn't address that code expects that $LOAD_PATH only contains Strings.
Doesn't Ruby::Box respect overrides of require, like done by Zeitwerk?
January 4, 2026 at 9:48 AM
Doesn't Ruby::Box respect overrides of require, like done by Zeitwerk?
Regarding that last thought, it'd be pretty cool if a published gem would have the necessary metadata to recompile it on a different Ruby version or different Ruby implementation.
January 3, 2026 at 9:16 PM
Regarding that last thought, it'd be pretty cool if a published gem would have the necessary metadata to recompile it on a different Ruby version or different Ruby implementation.
Nice summary post!
By "universal" I thought you meant compile once (per platform), run on any Ruby and it just works, i.e., this is something that HPy has with universal binaries.
So then we wouldn't have to recompile e.g. on 4.0.0, or the next best thing it would be automatic.
By "universal" I thought you meant compile once (per platform), run on any Ruby and it just works, i.e., this is something that HPy has with universal binaries.
So then we wouldn't have to recompile e.g. on 4.0.0, or the next best thing it would be automatic.
January 3, 2026 at 9:16 PM
Nice summary post!
By "universal" I thought you meant compile once (per platform), run on any Ruby and it just works, i.e., this is something that HPy has with universal binaries.
So then we wouldn't have to recompile e.g. on 4.0.0, or the next best thing it would be automatic.
By "universal" I thought you meant compile once (per platform), run on any Ruby and it just works, i.e., this is something that HPy has with universal binaries.
So then we wouldn't have to recompile e.g. on 4.0.0, or the next best thing it would be automatic.