1. 22
  1.  

  2. 3
    1. 1

      These docs continually say “cruby” – was this work all done by pythonists? :)

      1. 1

        I think “CRuby” is a more informative name than “MRI”, if that’s what you’re referring to.

        1. 2

          Except that no one calls it “cruby” so calling it that is confusing at best…

          1. 0

            This statement is misinformed at best. What would you have them call it? YARV? That’s more of an implementation detail. MRI usually refers to the pre-YARV interpreter. About Ruby lists both.

    2. 1

      Is the Ruby interpreter a lot faster than last time I looked? It was much less than half the speed of a moderately optimised bytecode interpreter so the speedups from the JIT look very small. I’d generally expect closer to a factor of 10 speedup going from even a fairly optimised interpreter to a fairly modest JIT.

      1. 3

        Ruby 3.0.0 (2020-12-25) was about 3x faster than Ruby 2.0.0 (2013-02-24), so maybe it is faster than when you last looked.

        1. 1

          From what I know about YJIT, it’s focused on speedup stability and quick warmup time, more like Erlang’s new JIT, as opposed to JITs like V8 that focus on reaching raw speed on benchmarks. And Ruby has a lot of dynamism in it. I expect YJIT will get faster and better over time.

        2. 1

          Does anybody know what the “y” in yjit stands for? Maybe my google-fu has gone stale, but I couldn’t find anything to answer this.