In case anyone's wondering, the TruffleRuby project is still going strong. It undoubtedly would be going stronger were Chris still with us. But, some of us that worked with Chris in the early days of the project and others that joined later are still pushing the project forward.
If you're interested in the project, please give it a try. Or, if you just want to chat Ruby compilers, feel free to drop into one of our community channels (Slack or GitHub Discussions).
I exchanged some e-mails with him because I was writing a series on writing a Ruby compiler in Ruby at the time (now self-hosting but woefully buggy and incomplete still; I pick it up now and again, but it's very much a slow-burn hobby project) and met him at Brighton Ruby after that once. He seemed like a very nice guy (and his very kind - given the very incomplete state of it - overview of my compiler as part of reviewing other Ruby implementations is still something I cherish)
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.)
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.
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.)
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.
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?
GraalVM is genuinely great -- Native Image and the polyglot story are impressive.
I was put off by the earlier licensing - it was confusing, which wasn't great in a license. The GraalVM Free Terms and Conditions "GFTC" now seems better (curious if people agree?), but I wonder if it came too late.
The decoupling from Java SE was good in many ways, but it also made the future a little less clear too.
Apparently there tends to exist some attrition between both teams, now OpenJDK is having a Python and JavaScript support project, but by integrating CPython and V8, not by reaching out to GraalVM, Project Detroit.
Licensing was why I didn't adopt it, so glad to hear it's improved. Would sure love a non-custom license though. Will have to dive deeper into the GFTC
Just in case you were unaware, there is and was a 100% open source variant of the GraalVM referred to as the "Community Edition (CE)"¹. RedHat built their own distribution based on that source tree called Mandrel². The closed source version is faster in many cases, but the CE release in very capable.
I've used JRuby with some success in production fairly recently to bridge two codebases, one previously in MRI Ruby and another in Java. It honestly worked well, but I always wondered about TruffleRuby and how it would have played out if I had chosen that runtime instead. I may still give truffle a go, but it's on the back burner for now.
Anyone have personal experience with all both runtimes and which jvm interop works better? I kinda wish both had unified their interop APIs better, especially given they used to coexist in the same repo for a time...
I maintain a JRuby-based app. I looked into TruffleRuby a number of times but faced issues each time on that code base, so I could not get to the point where I was able to compare anything. YMMV!
Just curious, what issues did you encounter? With JRuby being a fairly well supported community project, most gems just work out of the box with it, so I'm curious how the other implementations deal with things like gem compatibility etc.
For me jruby is a lot more accessible, so I have been using jruby rather than TruffleRuby. GraalVM is pretty cool though - I don't quite feel it is 100% "ready yet", even if you can go very far with it (statically compiled binaries on linux worked well for me). Some things have a low priority such as swing-support; some got it to work, others did not. I understand that swing is legacy, but still it works out of the box, so IMO it should be supported too. It is only semi-supported and I think this is a problem with some of GraalVM, at the least with fewer-used parts of it.
I feel that this semi-friendly competition between the two projects is not good. I also understand neither wanting to "adjust", and in the process lose options; in particular if jruby would be assimilated, we may run the possibility to have jruby work as-is, without necessarily being tied to e. g. the larger java ecosystem. I use both ruby and java, but being able to function in a smaller way, is an advantage (for ruby; see also mruby). Nonetheless I think both projects should eventually curb down on their ego and present a unified java-centric ruby variant that includes all options that existed BEFORE that. Merging by losing features would be stupid - but remaining separate also is stupid, IMO.
I haven't really followed why the two projects split. They shared a repo at one point in time; I had assumed good intentions along with valid, technical reasons and not ego conflicts though.
In case anyone's wondering, the TruffleRuby project is still going strong. It undoubtedly would be going stronger were Chris still with us. But, some of us that worked with Chris in the early days of the project and others that joined later are still pushing the project forward.
If you're interested in the project, please give it a try. Or, if you just want to chat Ruby compilers, feel free to drop into one of our community channels (Slack or GitHub Discussions).
https://github.com/truffleruby/truffleruby.
Spoke to Chris in person at a conference shortly before he died. What a tragic loss. Rest in peace.
I exchanged some e-mails with him because I was writing a series on writing a Ruby compiler in Ruby at the time (now self-hosting but woefully buggy and incomplete still; I pick it up now and again, but it's very much a slow-burn hobby project) and met him at Brighton Ruby after that once. He seemed like a very nice guy (and his very kind - given the very incomplete state of it - overview of my compiler as part of reviewing other Ruby implementations is still something I cherish)
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.)
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?
I really enjoyed reading Chris's deep dives on Ruby internals.
This one to be specific.
https://chrisseaton.com/truffleruby/rubykaigi21/
Rest in peace.
Someone replied to his final tweets and ended with “#ChatGPT response”. It seems like the most sad and dystopian thing to me.
GraalVM is genuinely great -- Native Image and the polyglot story are impressive.
I was put off by the earlier licensing - it was confusing, which wasn't great in a license. The GraalVM Free Terms and Conditions "GFTC" now seems better (curious if people agree?), but I wonder if it came too late.
The decoupling from Java SE was good in many ways, but it also made the future a little less clear too.
GraalVM builds upon the research done previously at Sun with MaximeVM [0] and SquawVM [1] (SunSPOTs [2] before arduinos were even an idea).
The Graal folks have their own agenda servicing Oracle DB, Oracle serverless, and less trying to replace the OpenJDK.
See this interview with Thomas Wuerthinger, the founder and project lead of GraalVM.
https://www.youtube.com/watch?v=naO1Up63I7Q
Apparently there tends to exist some attrition between both teams, now OpenJDK is having a Python and JavaScript support project, but by integrating CPython and V8, not by reaching out to GraalVM, Project Detroit.
https://openjdk.org/projects/detroit/
[0] - https://en.wikipedia.org/wiki/Maxine_Virtual_Machine
[1] - https://en.wikipedia.org/wiki/Squawk_virtual_machine
[2] - https://sunspotdev.org/ (site still up, go figure)
[2] - https://jug-karlsruhe.de/assets/slides/sunspot-jugKa.pdf (technical overview)
Licensing was why I didn't adopt it, so glad to hear it's improved. Would sure love a non-custom license though. Will have to dive deeper into the GFTC
Just in case you were unaware, there is and was a 100% open source variant of the GraalVM referred to as the "Community Edition (CE)"¹. RedHat built their own distribution based on that source tree called Mandrel². The closed source version is faster in many cases, but the CE release in very capable.
¹ -- https://github.com/graalvm/graalvm-ce-builds
² -- https://github.com/graalvm/mandrel
I've used JRuby with some success in production fairly recently to bridge two codebases, one previously in MRI Ruby and another in Java. It honestly worked well, but I always wondered about TruffleRuby and how it would have played out if I had chosen that runtime instead. I may still give truffle a go, but it's on the back burner for now.
Anyone have personal experience with all both runtimes and which jvm interop works better? I kinda wish both had unified their interop APIs better, especially given they used to coexist in the same repo for a time...
I maintain a JRuby-based app. I looked into TruffleRuby a number of times but faced issues each time on that code base, so I could not get to the point where I was able to compare anything. YMMV!
Just curious, what issues did you encounter? With JRuby being a fairly well supported community project, most gems just work out of the box with it, so I'm curious how the other implementations deal with things like gem compatibility etc.
rest in peace Chris Seaton
Yeah, he was such a great guy. I hope his family is doing well.
Rest in peace.
He seemed like a kind and gentle man. I looked up to him. RIP
For me jruby is a lot more accessible, so I have been using jruby rather than TruffleRuby. GraalVM is pretty cool though - I don't quite feel it is 100% "ready yet", even if you can go very far with it (statically compiled binaries on linux worked well for me). Some things have a low priority such as swing-support; some got it to work, others did not. I understand that swing is legacy, but still it works out of the box, so IMO it should be supported too. It is only semi-supported and I think this is a problem with some of GraalVM, at the least with fewer-used parts of it.
I feel that this semi-friendly competition between the two projects is not good. I also understand neither wanting to "adjust", and in the process lose options; in particular if jruby would be assimilated, we may run the possibility to have jruby work as-is, without necessarily being tied to e. g. the larger java ecosystem. I use both ruby and java, but being able to function in a smaller way, is an advantage (for ruby; see also mruby). Nonetheless I think both projects should eventually curb down on their ego and present a unified java-centric ruby variant that includes all options that existed BEFORE that. Merging by losing features would be stupid - but remaining separate also is stupid, IMO.
I haven't really followed why the two projects split. They shared a repo at one point in time; I had assumed good intentions along with valid, technical reasons and not ego conflicts though.
[dead]