20 ms·

Proposal to Merge YJIT into Ruby

259 points by ciconia 5y ago

pjmlp 5y ago
Great news. For those curious about what it brings to the table, just follow Maxime's link to RubyKaigi 2021.
- rattray 5y ago
  https://www.youtube.com/watch?v=PBVLf3yfMs8 https://www.youtube.com/watch?v=PBVLf3yfMs8 30min talk. Slides are here: https://rubykaigi.org/2021-takeout/data/slides/Maxime-YJIT-RubyKaigi-2021-slides.pdf https://rubykaigi.org/2021-takeout/data/slides/Maxime-YJIT-R...
  - noneeeed 5y ago
    I watched that last night, it was a great talk. Enough technical details to understand the how without getting bogged down in the intricate details. Although it did remind me that I've not touched assembler in about 20 years and now I feel oooold :) I'm really quite optimistic that this will see some good improvements in the next few years as they work through some of the CRuby bottlenecks that he mentioned.
- Scarbutt 5y ago
  Didn't expect to see you here excited about a dynamic language with a slow runtime ;)
  - pjmlp 5y ago
    Some part of me still hopes to see something like Dylan becoming mainstream, and Ruby is probably the closest to it (alongside Julia). Noticed for a while, before Swift was even an idea, Apple toyed with Ruby as the next Mac OS X language. Things did not worked out as planned and the main designer created RubyMotion out of that effort.
WJW 5y ago
Pretty cool. Tbh, the benchmark result improvements are not as big as I'd expect (ie, the biggest improvement is "only" 41% compared to non-JITted code) but speedups are speedups and this is pretty nice considering you can get it for (almost) free with a single command line flag.
- kawsper 5y ago
  Maxime explains in the video[0] that they have other optimizations planned but haven't implemented them yet. It will be very interesting to see the impact :) [0] https://www.youtube.com/watch?v=PBVLf3yfMs8 https://www.youtube.com/watch?v=PBVLf3yfMs8
- jaynetics 5y ago
  biggest improvement is 68% for optcarrot (ruby-based NES emulator). not bad at all!
  - m12k 5y ago
    I imagine an emulator will have hot paths in tight loops in a way that web apps don't, so it makes sense that it sees the biggest benefit from jit'ing
  - pjmlp 5y ago
    JRuby also runs it quite fast, although I think does require some warmup measured in minutes, until it is almost C like.
    - lf-non 5y ago
      We used to run a production service written in JRuby until a year or so ago (at which point it was rewritten in kotlin). It was a minimal pure ruby service deployed as a tomcat servlet. Despite not using any heavy weight framework (eg. rails etc.) its performance (after warmup) was nowhere close to "almost C like". JVM gives you true multithreading etc. but claiming that JRuby performance is C like is just misleading.
oriettaxx 5y ago
+1 by Matz. great!
- irjustin 5y ago
  That man wields such power. Super glad that he's such an awesome, wholesome guy.
xutopia 5y ago
I keep seeing small incremental speed improvements and overall these changes amount to a compounded effect over time. Yet we keep hearing that ruby is dead or rails is dead and the very fact that we have large companies like Shopify or Stripe working hard to make the language and tools faster is proof that this is not dead...
- deleted 5y ago
  [deleted]
- defaultname 5y ago
  No one says that Ruby is dead, beyond in the rhetorical "as the cool new thing" angle. But sure, there are companies that were started with Ruby back when it was the cool thing (2008 - 2011ish), and inertia, along with a heavy dose of cargo culting, has them doubling down. If those companies started in 2019 they'd be all in on Go. Today...I don't know...Rust? I posted a couple of weeks back that it is remarkable that almost all Ruby advocacy/development comes from Shopify, and here is yet another example. Similarly, recent claims about Ruby's growth among the "top N websites" was more than 100% accounted for purely by a quirk in the way Shopify implements their storefront (as a subdomain which allowed Shopify's choice of technology to trojan horse in the metrics onto hundreds of thousands of domains). Clearly people make solutions with it, in the same way that people made remarkable solutions with PHP.
  - freewilly1040 5y ago
    I would be curious to hear what someone who’s written both go and Ruby with a type system (forget what it’s called) is. My view from the outside is that while Rubyists have correctly figured out that being strongly typed is an advantage, it’s an awkward retrofit, and just starting with a language that has a native type system would be better. To your point, the calculation as a N-thousand person profitable company is very different from what those companies would pick today were they starting from scratch.
    - maherbeg 5y ago
      I worked on Ruby code at Stripe using Sorbet and currently work in a Go code base full time now! Sorbet is pretty incredible and IMO was a huge benefit in a massive code base. Not having to worry about nil checks and always knowing the shape of the input data to functions was immensely valuable. It made data transformations really easy. I'm also a big fan of sum types which is available in Sorbet. It made expressing failure conditions with data really easy to do, and obvious to users of your code. This wasn't a pattern used everywhere though which is understandable given that it came much later in the Stripe code base. Go is actually a pretty nice language. It really is easy to pick up and be pleasantly productive in it. The built in libraries are extremely good, and the eco-system seems to favor using as many of the standards where possible (e.g. http middlewares all use the same patterns, no matter which framework you choose). I really dislike error handling in Go though. It's hard to actually know what errors you're receiving from functions you're calling, especially as they trickle their way up. For instance, if you're wanting to display certain error types to your users, you have to hope you've enumerated all of the potential errors returned and handle them in a janky manner (errors.Is / errors.As). I also really dislike that lots of things can be nil, and the compiler won't really help you there. You just have to know that some things are interfaces vs others being structs. The way interfaces are defined and used in Go are quite nice and it ends up being really easy to refactor something slightly to make it easier to test. edit: summary, I think I would agree with you that starting with Go is likely the better option for many types of backend services. Ruby on Rails is still really hard to beat for productive web oriented services though, and I think you could do pretty well mixing the two together.
kureikain 5y ago
I'm still learn about JIT but what happen if we JIT everything as in every single line of a Ruby app? Will it be way faster? So we don't have to wait for the JIT to compile during production?
- gavinray 5y ago
  This is called AOT ;^) You may want to look into TruffleRuby from Graal, with the "--native" flag. Particularly some of the writings Chris Seaton (project lead/founder) from Shopify has about it: https://github.com/oracle/truffleruby https://github.com/oracle/truffleruby
deedubaya 5y ago
Yeah, but your db is still the bottleneck of your web application ducks

259 points by ciconia 5y ago

pjmlp 5y ago

Great news. For those curious about what it brings to the table, just follow Maxime's link to RubyKaigi 2021.

rattray 5y ago
https://www.youtube.com/watch?v=PBVLf3yfMs8 https://www.youtube.com/watch?v=PBVLf3yfMs8 30min talk. Slides are here: https://rubykaigi.org/2021-takeout/data/slides/Maxime-YJIT-RubyKaigi-2021-slides.pdf https://rubykaigi.org/2021-takeout/data/slides/Maxime-YJIT-R...
- noneeeed 5y ago
  I watched that last night, it was a great talk. Enough technical details to understand the how without getting bogged down in the intricate details. Although it did remind me that I've not touched assembler in about 20 years and now I feel oooold :) I'm really quite optimistic that this will see some good improvements in the next few years as they work through some of the CRuby bottlenecks that he mentioned.
Scarbutt 5y ago
Didn't expect to see you here excited about a dynamic language with a slow runtime ;)
- pjmlp 5y ago
  Some part of me still hopes to see something like Dylan becoming mainstream, and Ruby is probably the closest to it (alongside Julia). Noticed for a while, before Swift was even an idea, Apple toyed with Ruby as the next Mac OS X language. Things did not worked out as planned and the main designer created RubyMotion out of that effort.

WJW 5y ago

Pretty cool. Tbh, the benchmark result improvements are not as big as I'd expect (ie, the biggest improvement is "only" 41% compared to non-JITted code) but speedups are speedups and this is pretty nice considering you can get it for (almost) free with a single command line flag.

kawsper 5y ago
Maxime explains in the video[0] that they have other optimizations planned but haven't implemented them yet. It will be very interesting to see the impact :) [0] https://www.youtube.com/watch?v=PBVLf3yfMs8 https://www.youtube.com/watch?v=PBVLf3yfMs8
jaynetics 5y ago
biggest improvement is 68% for optcarrot (ruby-based NES emulator). not bad at all!
- m12k 5y ago
  I imagine an emulator will have hot paths in tight loops in a way that web apps don't, so it makes sense that it sees the biggest benefit from jit'ing
- pjmlp 5y ago
  JRuby also runs it quite fast, although I think does require some warmup measured in minutes, until it is almost C like.
  - lf-non 5y ago
    We used to run a production service written in JRuby until a year or so ago (at which point it was rewritten in kotlin). It was a minimal pure ruby service deployed as a tomcat servlet. Despite not using any heavy weight framework (eg. rails etc.) its performance (after warmup) was nowhere close to "almost C like". JVM gives you true multithreading etc. but claiming that JRuby performance is C like is just misleading.

oriettaxx 5y ago

+1 by Matz. great!

irjustin 5y ago
That man wields such power. Super glad that he's such an awesome, wholesome guy.

xutopia 5y ago

I keep seeing small incremental speed improvements and overall these changes amount to a compounded effect over time. Yet we keep hearing that ruby is dead or rails is dead and the very fact that we have large companies like Shopify or Stripe working hard to make the language and tools faster is proof that this is not dead...

deleted 5y ago
[deleted]
defaultname 5y ago
No one says that Ruby is dead, beyond in the rhetorical "as the cool new thing" angle. But sure, there are companies that were started with Ruby back when it was the cool thing (2008 - 2011ish), and inertia, along with a heavy dose of cargo culting, has them doubling down. If those companies started in 2019 they'd be all in on Go. Today...I don't know...Rust? I posted a couple of weeks back that it is remarkable that almost all Ruby advocacy/development comes from Shopify, and here is yet another example. Similarly, recent claims about Ruby's growth among the "top N websites" was more than 100% accounted for purely by a quirk in the way Shopify implements their storefront (as a subdomain which allowed Shopify's choice of technology to trojan horse in the metrics onto hundreds of thousands of domains). Clearly people make solutions with it, in the same way that people made remarkable solutions with PHP.
- freewilly1040 5y ago
  I would be curious to hear what someone who’s written both go and Ruby with a type system (forget what it’s called) is. My view from the outside is that while Rubyists have correctly figured out that being strongly typed is an advantage, it’s an awkward retrofit, and just starting with a language that has a native type system would be better. To your point, the calculation as a N-thousand person profitable company is very different from what those companies would pick today were they starting from scratch.
  - maherbeg 5y ago
    I worked on Ruby code at Stripe using Sorbet and currently work in a Go code base full time now! Sorbet is pretty incredible and IMO was a huge benefit in a massive code base. Not having to worry about nil checks and always knowing the shape of the input data to functions was immensely valuable. It made data transformations really easy. I'm also a big fan of sum types which is available in Sorbet. It made expressing failure conditions with data really easy to do, and obvious to users of your code. This wasn't a pattern used everywhere though which is understandable given that it came much later in the Stripe code base. Go is actually a pretty nice language. It really is easy to pick up and be pleasantly productive in it. The built in libraries are extremely good, and the eco-system seems to favor using as many of the standards where possible (e.g. http middlewares all use the same patterns, no matter which framework you choose). I really dislike error handling in Go though. It's hard to actually know what errors you're receiving from functions you're calling, especially as they trickle their way up. For instance, if you're wanting to display certain error types to your users, you have to hope you've enumerated all of the potential errors returned and handle them in a janky manner (errors.Is / errors.As). I also really dislike that lots of things can be nil, and the compiler won't really help you there. You just have to know that some things are interfaces vs others being structs. The way interfaces are defined and used in Go are quite nice and it ends up being really easy to refactor something slightly to make it easier to test. edit: summary, I think I would agree with you that starting with Go is likely the better option for many types of backend services. Ruby on Rails is still really hard to beat for productive web oriented services though, and I think you could do pretty well mixing the two together.

kureikain 5y ago

I'm still learn about JIT but what happen if we JIT everything as in every single line of a Ruby app? Will it be way faster? So we don't have to wait for the JIT to compile during production?

gavinray 5y ago
This is called AOT ;^) You may want to look into TruffleRuby from Graal, with the "--native" flag. Particularly some of the writings Chris Seaton (project lead/founder) from Shopify has about it: https://github.com/oracle/truffleruby https://github.com/oracle/truffleruby

deedubaya 5y ago

Yeah, but your db is still the bottleneck of your web application ducks