
Ruby 2.6.0-preview1 Released - petercooper
https://www.ruby-lang.org/en/news/2018/02/24/ruby-2-6-0-preview1-released/
======
petercooper
Three worthwhile reads for anyone interested in the new (M)JIT:

[https://medium.com/@k0kubun/the-method-jit-compiler-for-
ruby...](https://medium.com/@k0kubun/the-method-jit-compiler-for-
ruby-2-6-388ee0989c13)

[https://medium.com/square-corner-blog/rubys-new-
jit-91a5c864...](https://medium.com/square-corner-blog/rubys-new-
jit-91a5c864dd10)

[https://www.johnhawthorn.com/2018/02/playing-with-ruby-
jit-m...](https://www.johnhawthorn.com/2018/02/playing-with-ruby-jit-mjit/)

~~~
igravious
Thank you for the links sir, for anyone short on time the first link is from
the patch committer themselves. Definitely worth a read to get an insight into
what's going on.

Optcarrot has gone from 37.2 fps with Ruby 2.0.0 to potentially 59.2 fps with
2.6.0-dev. Wow!

------
ksec
119 points, I mean HN doesn't care about Ruby anymore.

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.

------
geraldbauer
FYI: I collect articles about all things 3x3 at Planet Ruby (incl. the new jit
(mjit), of course), see
[https://planetruby.github.io/calendar/ruby3x3](https://planetruby.github.io/calendar/ruby3x3).
Cheers.

------
jhoechtl
Don't hold your breath:

> 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

~~~
pjmlp
I doubt LuaJIT is better than Common Lisp or JavaScript JIT compilers.

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.

~~~
bjoli
LuaJIT is probably faster than the modern JavaScript engines. I don't know how
it compares to something like SBCL, but as a JIT for dynamic languages it's
pretty much the bee's knees. I have had it beat carefully written PyPy code by
an order of magnitude several times

~~~
pjmlp
Actually when I think in Common Lisp compilers, I think about Allegro Common
Lisp and LispWorks.

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.

~~~
marmaduke
I think it’s not so much that the effort invested is better (though Pall has
strong reputation) but in large part that Lua’s semantics make for easier JIT.

------
sadiqmmm
Thanks, awesome :)

