<div dir="ltr">These are some pretty extreme slowdowns. The legacy JIT shared the code generator with MCJIT, and as far as I'm aware there were really only three main differences:<div><br></div><div>1) The legacy JIT used a custom instruction encoder, whereas MCJIT uses MC.</div><div>2) (Related to 1) MCJIT needs to perform runtime linking of the object files produced by MC.</div><div>3) MCJIT does not compile lazily (though it sounds like that's not an issue here?)</div><div><br></div><div>Keno - did you ever look at the codegen pipeline construction for the legacy JIT vs MCJIT? Are we choosing different passes?</div><div><br></div><div>Morten - Can you share any test cases that demonstrate the slowdown. I'd love to take a look at this.</div><div><br></div><div>Cheers,</div><div>Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 4, 2016 at 4:16 PM, Hal Finkel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Keno Fischer via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
> To: "Morten Brodersen" <<a href="mailto:Morten.Brodersen@constrainttec.com">Morten.Brodersen@constrainttec.com</a>><br>
> Cc: "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
> Sent: Thursday, February 4, 2016 6:05:29 PM<br>
> Subject: Re: [llvm-dev] MCJit Runtine Performance<br>
><br>
><br>
><br>
> Yes, unfortunately, this is very much known. Over in the julia<br>
> project, we've recently gone through this and taken the hit (after<br>
> doing some work to fix the very extreme corner cases that we were<br>
> hitting). We're not entirely sure why the slowdown is this<br>
> noticable, but at least in our case, profiling didn't reveal any<br>
> remaining low hanging fruits that are responsible. One thing you can<br>
> potentially try if you haven't yet is to enable fast ISel and see if<br>
> that brings you closer to the old runtimes.<br>
<br>
</span>And maybe the register allocator? Are you using the greedy one or the linear one? Are there any other MI-level optimizations running?<br>
<br>
 -Hal<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> On Thu, Feb 4, 2016 at 7:00 PM, Morten Brodersen via llvm-dev <<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> > wrote:<br>
><br>
><br>
> Hi All,<br>
><br>
> We recently upgraded a number of applications from LLVM 3.5.2 (old<br>
> JIT) to LLVM 3.7.1 (MCJit).<br>
><br>
> We made the minimum changes needed for the switch (no changes to the<br>
> IR generated or the IR optimizations applied).<br>
><br>
> The resulting code pass all tests (8000+).<br>
><br>
> However the runtime performance dropped significantly: 30% to 40% for<br>
> all applications.<br>
><br>
> The applications I am talking about optimize airline rosters and<br>
> pairings. LLVM is used for compiling high level business rules to<br>
> efficient machine code.<br>
><br>
> A typical optimization run takes 6 to 8 hours. So a 30% to 40%<br>
> reduction in speed has real impact (=> we can't upgrade from 3.5.2).<br>
><br>
> We have triple checked and reviewed the changes we made from old JIT<br>
> to MCJIt. We also tried different ways to optimize the IR.<br>
><br>
> However all results indicate that the performance drop happens in the<br>
> (black box) IR to machine code stage.<br>
><br>
> So my question is if the runtime performance reduction is<br>
> known/expected for MCJit vs. old JIT? Or if we might be doing<br>
> something wrong?<br>
><br>
> If you need more information, in order to understand the issue,<br>
> please tell us so that we can provide you with more details.<br>
><br>
> Thanks<br>
> Morten<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>