Hacker News Reader

Comment by petercooper | Hacker News Reader

TruffleRuby is very capable and deserves to be promoted more. I recently made a JPEG encoder/decoder in Ruby and it's 2-3x times quicker on Truffle. Native dependencies is where you can get caught out, but for pure Ruby, TruffleRuby is fantastic and worth including in your test matrix. (More broadly I think Ruby performance is reaching a point where we should be spinning up pure Ruby alternatives to native libraries, but that's a story for another day.)

View on HN

I'd imagine you don't want to look like you're self-promoting, but I'd really love to read more about the JPEG project. I think it could be quite good for the community. As a whole, I believe Rubyists need to stop reaching for native extensions so quickly. Whether on YJIT, ZJIT, JRuby, or TruffleRuby, all of them will benefit from having more code in Ruby. Incidentally, Chris's final conference talk¹ made the case for moving to a Ruby-based implementation for the Ruby core library.

For those cases where you're writing a native extension to primary bridge over to a native library, you may find either FFI or Fiddle handle your use case quite well.

¹ -- https://youtu.be/-iVh_8_J-Uo?si=8uVFLiF3NtjWgfR1

It's at https://github.com/peterc/pure_jpeg .. and a lot of the recent speedups actually came from contributions by Ufuk/paracycle who, I'm guessing from your bio, you possibly work with? :-)

But yeah, I agree with your point about native extensions. Ruby has gotten so much faster in every form in the past couple of years that I think we could bring a lot more "in house". I think there have been some efforts with this regarding Psych in core as well?

I'm surprised it's only 2-3x times quicker w/Truffle? Is that because it only encodes/decodes a single image at the time and incurs higher startup costs? Or do you mean 2-3x vs. an MRI alternative that calls into a native extension?

I'm curious whether this reflects MRI's improvements closing some of the gap or something else.

I've not got the numbers to hand between versions, but YJIT in Ruby 4.0 did shift the needle a bit, so yes, some gap closing. I also forget what the warmup was like, but to get 2-3x somewhat more was needed than with YJIT.

(Both running identical pure Ruby code, no extensions, in a long-running test scenario, no setup each time.)

Thanks for the detail. That is really a testament to how much better MRI has gotten...

With truffle Ruby you don’t have to rewrite anything: Ruby code gets way faster and so does c code.

That is broadly my experience with pure Ruby, yes. In terms of C extensions, I know they were doing some work on this but it was a WIP last time I looked, although maybe I should refresh my knowledge on this if it's now all good to go!

Many native extensions just work with TruffleRuby, I'd estimate even the majority of the popular native extensions just work. Performance of native extensions is not always good, especially if they do a lot of back and forth between Ruby and native.

To give one example, DB adapters work just fine.

That's awesome news, and I can't get a more authoritative source than you! I'll do some tests and update my assumptions :-) I really do wish I saw more blog posts and things about TruffleRuby, but maybe that is just a sign I should make the effort myself.

Since I have you, if you could humor me at all, what do you think the biggest current sticking point to average Rubyists just flat out switching to TruffleRuby is nowadays? Or isn't there one?

Reply on news.ycombinator.com