https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112021-09-30T18:41:27ZRuby Issue Tracking SystemRuby master - Misc #18233: Intermediate Representation for Ruby's JIThttps://bugs.ruby-lang.org/issues/18233?journal_id=939592021-09-30T18:41:27Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/93959/diff?detail_id=60892">diff</a>)</li></ul> Ruby master - Misc #18233: Intermediate Representation for Ruby's JIThttps://bugs.ruby-lang.org/issues/18233?journal_id=939632021-09-30T23:38:07Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul></ul><blockquote>
<p>MIR is designed to be used for different languages, including C. Standard ruby methods implemented on C, e.g. times, can be translated into MIR and user-defined Ruby block called by times can be translated into MIR too (may be through intermediate C translation), then MIR for times and the block can be intermixed (inlined) and optimized. So MIR permits optimization of code written on different languages.</p>
</blockquote>
<p>When <code>#times</code> calls a Ruby block, how does MIR associate a <code>vm_yield</code> call from the C function of <code>#times</code> with the MIR of the Ruby block? When it just calls a C function that does direct-threading with the iseq of the Ruby block, it's not necessarily straightforward to inline the MIR of the block iseq, which is just a pointer used by a C function. I guess you need to rely on a MIR-specific C language extension guarded by <code>#ifdef</code>? At least the approach doesn't seem to work for pure C code or MJIT.</p>
<p>However, if it's possible to inline Ruby methods called from a C method (called from a Ruby method) without rewriting the C method with Ruby, that would be fantastic. The performance impact of rewriting <code>#times</code> with Ruby seems trivial <a href="https://github.com/ruby/ruby/pull/3656" class="external">https://github.com/ruby/ruby/pull/3656</a>, but it seems a bit harder to keep the interpreter performance when you rewrite <code>#each</code> and <code>#map</code> with Ruby <a href="https://github.com/ruby/ruby/pull/3658" class="external">https://github.com/ruby/ruby/pull/3658</a> <a href="https://github.com/ruby/ruby/pull/3666" class="external">https://github.com/ruby/ruby/pull/3666</a>, which allows you to look at invokeblock and inline the iseq. If we have a tier-1 JIT that is enabled by default on all platforms and compiles all methods early, we could eventually ignore the interpreter performance and rewrite them with Ruby as long as JIT-ed performance (without inlining a block) is comparable to the original C code though.</p> Ruby master - Misc #18233: Intermediate Representation for Ruby's JIThttps://bugs.ruby-lang.org/issues/18233?journal_id=947782021-11-19T17:35:18Zk0kubun (Takashi Kokubun)takashikkbn@gmail.com
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul>