<story><title>The Ruby+OMR JIT</title><url>https://developer.ibm.com/open/2016/11/18/introducing-ruby-jit/</url></story><parent_chain><item><author>kweinber</author><text>Don&amp;#x27;t count on Ruby getting 10x faster anytime soon.  The meta-object model and method-missing reliance of many of the libraries make performance optimizations of JITs a very limited enterprise.</text></item><item><author>skeptic2718</author><text>I expected CPython to have something like this, especially in 3.x but nothing.&lt;p&gt;If Ruby can get faster than Python sooner, I&amp;#x27;d switch focus to Ruby (and somewhat make Go less of a priority for us).</text></item></parent_chain><comment><author>chrisseaton</author><text>Optimising method-missing and the rest of the meta-object model in a JIT is now a solved problem - I solved it for my PhD &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;chrisseaton.com&amp;#x2F;phd&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;chrisseaton.com&amp;#x2F;phd&amp;#x2F;&lt;/a&gt;&lt;p&gt;It is actually possible to completely remove the overhead of method-missing.</text></comment>
<story><title>The Ruby+OMR JIT</title><url>https://developer.ibm.com/open/2016/11/18/introducing-ruby-jit/</url></story><parent_chain><item><author>kweinber</author><text>Don&amp;#x27;t count on Ruby getting 10x faster anytime soon.  The meta-object model and method-missing reliance of many of the libraries make performance optimizations of JITs a very limited enterprise.</text></item><item><author>skeptic2718</author><text>I expected CPython to have something like this, especially in 3.x but nothing.&lt;p&gt;If Ruby can get faster than Python sooner, I&amp;#x27;d switch focus to Ruby (and somewhat make Go less of a priority for us).</text></item></parent_chain><comment><author>vidarh</author><text>It&amp;#x27;s true that many libraries would perform poorly because of a reliance on method_missing. But what &lt;i&gt;can&lt;/i&gt; be made quite fast is code that either uses define_method instead, or uses define_method on the first failed call.&lt;p&gt;In fact, a tracing jit could even make the method_missing case fast by automatically specialising and optimizing missing coupled with a vtable&amp;#x2F;dispatch table.&lt;p&gt;My forever-in-progress ahead-of-time Ruby compiler uses vtable based dispatch for every method name that&amp;#x27;s seen in the program at least once, and that&amp;#x27;s usually most of them (unless people e.g. construct method names dynamically at runtime).&lt;p&gt;To handle method_missing, it creates thunks for each method name and fills the missing vtable slots with those, which is similar to what I suggest above - the next step of dynamically optimising method_missing for called symbols and replacing the vtable thunks would be a relatively minor step in a JIT.&lt;p&gt;I don&amp;#x27;t think anyone expects Ruby to get dramatically faster in the very short term, but there&amp;#x27;s &lt;i&gt;lots&lt;/i&gt; of opportunity to make most Ruby code much faster in the medium term.&lt;p&gt;I think we&amp;#x27;ll also start seeing implementations that do things like JIT influence how people write Ruby, because a lot of things won&amp;#x27;t matter much for MRI performance but will be a huge deal for implementations that uses compilation techniques, so it&amp;#x27;s possible to get a lot more &amp;quot;compiler-friendly&amp;quot; Ruby while still writing clean Ruby that runs well on other implementations.&lt;p&gt;e.g. the above &amp;quot;define_method on method_missing&amp;quot; basically boils down to (pseudo code):&lt;p&gt;&lt;pre&gt;&lt;code&gt;    def method_missing sym, *args 
        raise suitable exception if sym doesn&amp;#x27;t meet right criteria
        define_method(sym, args...) do 
           ... whatever ..
        end
        send(sym,*args)
    end
&lt;/code&gt;&lt;/pre&gt;
If it lets an implementation speed up its (ab)use of method_missing enough, you&amp;#x27;ll see people adopt stuff like that.</text></comment>