Ruby 2.6.0-preview1 Released
ruby-lang.org
ruby-lang.org
https://medium.com/@k0kubun/the-method-jit-compiler-for-ruby...
https://medium.com/square-corner-blog/rubys-new-jit-91a5c864...
https://www.johnhawthorn.com/2018/02/playing-with-ruby-jit-m...
Optcarrot has gone from 37.2 fps with Ruby 2.0.0 to potentially 59.2 fps with 2.6.0-dev. Wow!
But, I wanted to say Ruby MJIT, developed by Vladimir Makarov, and this base infrastructure variant merge from k0kubun, both doing do all on their own free time.
It isn't a company sponsoring any of them to work on it.
Sometimes I wonder if Ruby JIT somehow do save those companies millions, would they give donate some of them back to further develop Ruby.
> MJIT takes a block of ruby’s YARV bytecode and converts it into what is basically an inlined version of the C code it would have run when interpreting it.
> In some ways, this is the same as what other JITs do: they compile bytecode into machine code at runtime. I don’t know of another JIT which so directly shells out to an off-the-shelf C compiler.
This will never scale out (embedded?) and has tons of security issues.
The only high grade JIT solution anywhere available for a dynamically typed language is LuaJIT - I don't know of the social implications of all the involved here why this solution never took of and found more widespread use in other languages like Ruby or Python
On the other hand, if forking a C compiler for generating code is "fast", that tells a lot about the slowness of regular Ruby interpreters.
I don't think anyone claimed this, even the author report a 6 times slower boot time. However the generated code once loaded is "fast".
Also I haven't followed the projects that closely, but if I'm understanding correctly, that shell out to the compiler is a stub.
As for JavaScript, it is really hard to envision how it can beat the money spent by Mozilla, Apple, Google and Microsoft, including universities sponsored by them, in JavaScript JIT optimization research.
I can't find other things than one off microbenchmarks now (maybe my Google fu is off), but in those LuaJIT is still king.
The kind of complex prototypical inheritance that V8 has to deal with is a totally different issue to the goal of having a minimal, embeddable, C friendly scripting language like Lua.
https://www.lua.org/history.html
but Mike Pall did an extraordenary job to optimise his Jit
However. Let's look at this dispassionately. This is only enabled if you use the --jit option. This means that this option can be switched on for production runs and not for dev and test modes. That seems like a very easy switch to flick.
Also, from reading the pages @petercooper linked to it seems the infrastructure is pretty non-invasive so far and leverages a lot of the existing infrastructure. Bugs have been squashed and all tests are passing.
I'm excited to try this on my own machine and see how it compares to 2.5 w/ Bootsnap, as I've posted here before I'm itching to drop Bootsnap.
Also since I'm somewhat part of the Bootsnap creation, I'd be very interested to know why you're itching to remove it.
If Bootsnap is an opt cache I'm all for it. If it's some sort of `require' and `require_relative' hackage black-magic jiggery pokery then no.
I already ran into issues with my own app where I encountered a slight glitch because of Bootsnap. Bootsnap needs to be 100% bullet-proof before I go near it.
I hate all these optimizations like Spring and Bootsnap and Turbolinks that only end up causing headaches and are yet another thing you have to reason about if something is going wrong. Simpler is better. Less moving parts is better.
Now of the three: Spring and Bootsnap and Turbolinks–probably Bootsnap is the closest to being deployable with 0% hassle. I wouldn't touch Turbolinks with a 10 foot barge pole. Yet another recent confirmation of the wisdom of that decision for me is that it messes with Vue.js. No Turbolinks, no problem.
If Bootsnap and MJIT are more or less orthogonal then yay. There is startup time and execution time. Improving both would be awesome.
It does integrate with the ISeq API in recent MRIs to acts as an opt-cache yes. It's not what brings most of the performance gain though.
> If it's some sort of `require' and `require_relative' hackage black-magic jiggery pokery then no.
Well, there is no black magic, it's computers, they are machines, not magicians. And yes it's mostly what Bootsnap (and bootscale before it) does.
> Bootsnap needs to be 100% bullet-proof before I go near it.
The thing is it can't. There is a couple corner cases in Ruby's require semantic that just can't be replicated. So yeah, there is about a few dozen obscure gems out there that will break if used with Bootsnap, but for the vast majority of projects it's gonna be a drop in boot time gain without any headache.
It will not help too much for production or testing environments if you do not have specific timing requirements on startup.
It's a completely different type of shoe compared to things like spring which will result in a world of pain in specific situations if you're not constantly aware of what it does.
This is the Ruby implementation targeting embedded: https://github.com/mruby/mruby
> tons of security issues
Any examples?
http://mruby.sh/201703270126.html
The good thing is mruby is now pretty much battle tested.