3 ms·

*JRuby A lot of good things going on in this space like Helix (http://blog.skylight.io/introducing-helix/ http://blog.skylight.io/introducing-helix/) The conc

by mtkd 10y ago

*JRuby A lot of good things going on in this space like Helix (http://blog.skylight.io/introducing-helix/ http://blog.skylight.io/introducing-helix/) The concept of using Ruby with external optimisations using Rust or whatever feels a lot like C with inline ASM - really like where it's going

chrisseaton 10y ago
The thesis was that you can't make Ruby fast by implementing, for example, a fast sort routine as an extension in C or Rust, because that extension is then a big black box to any optimisation that the VM might want to do. You might be able to make a standalone sort fast, but you really need to be able to make a sort followed by an index fast (or followed by a reverse, or any other endless combinations you can't plan for), and if your sort is an external routine, your VM can't simplify it with the knowledge that it's going to be followed by an index operation. That's particularly important in idiomatic Ruby code, because so much of it is just calls to the core library. This is what makes Ruby slow, and is what needs to be addressed to make it fast. I use JRuby as an example, but it also applies to Rubinius and MRI.
- matthewrudy 10y ago
  I guess that was the key takeaway from your talk: Ignore local optimisations in favour of more global ones. The fact that you parse C extensions was really unexpected. Given something like Object#blank? using the Ruby implementation vs Sam Saffron's "fast_blank", after JRuby+Truffle has done it's work, which implementation ends up more performant? And would a future JRuby+Truffle (given both the Ruby and C implementation) make an intelligent decision of which one to use? https://github.com/SamSaffron/fast_blank https://github.com/SamSaffron/fast_blank
  - chrisseaton 10y ago
    Truffle at the moment wouldn't make #blank? fast, because it uses a regex, and at the moment that's still a black box to our optimiser (which is a shame).
    - matthewrudy 10y ago
      I see, so that's the next another future optimisation path, parse regexps in a way that grall can optimise. Exciting!

by mtkd 10y ago

chrisseaton 10y ago

The thesis was that you can't make Ruby fast by implementing, for example, a fast sort routine as an extension in C or Rust, because that extension is then a big black box to any optimisation that the VM might want to do. You might be able to make a standalone sort fast, but you really need to be able to make a sort followed by an index fast (or followed by a reverse, or any other endless combinations you can't plan for), and if your sort is an external routine, your VM can't simplify it with the knowledge that it's going to be followed by an index operation. That's particularly important in idiomatic Ruby code, because so much of it is just calls to the core library. This is what makes Ruby slow, and is what needs to be addressed to make it fast. I use JRuby as an example, but it also applies to Rubinius and MRI.

matthewrudy 10y ago
I guess that was the key takeaway from your talk: Ignore local optimisations in favour of more global ones. The fact that you parse C extensions was really unexpected. Given something like Object#blank? using the Ruby implementation vs Sam Saffron's "fast_blank", after JRuby+Truffle has done it's work, which implementation ends up more performant? And would a future JRuby+Truffle (given both the Ruby and C implementation) make an intelligent decision of which one to use? https://github.com/SamSaffron/fast_blank https://github.com/SamSaffron/fast_blank
- chrisseaton 10y ago
  Truffle at the moment wouldn't make #blank? fast, because it uses a regex, and at the moment that's still a black box to our optimiser (which is a shame).
  - matthewrudy 10y ago
    I see, so that's the next another future optimisation path, parse regexps in a way that grall can optimise. Exciting!