[llvm-dev] MCJit Runtine Performance

[Lang Hames via llvm-dev]

Hi Keno,

> ... I didn't realize we had a choice there...

You do, though I don't think the dials and levers have been plumbed up to
the interface. I'm happy to take a look at doing that. I'd be very happy
for clients to have more options here.

Cheers,
Lang.

On Thu, Feb 4, 2016 at 4:56 PM, Keno Fischer <kfischer at college.harvard.edu>
wrote:

> We are using the same IR passes. We did not look at the the backend passes
> other than fast isel, because I didn't realize we had a choice there, do
> we? In our profiling, nothing in MCJIT specifically (relocations, etc.) are
> taking any significant amount of time. As far as we could tell most of the
> slow down was in ISel, with a couple additional percent in various IR
> passes.
>
> On Thu, Feb 4, 2016 at 7:52 PM, Lang Hames <lhames at gmail.com> wrote:
>
>> 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:
>>
>> 1) The legacy JIT used a custom instruction encoder, whereas MCJIT uses
>> MC.
>> 2) (Related to 1) MCJIT needs to perform runtime linking of the object
>> files produced by MC.
>> 3) MCJIT does not compile lazily (though it sounds like that's not an
>> issue here?)
>>
>> Keno - did you ever look at the codegen pipeline construction for the
>> legacy JIT vs MCJIT? Are we choosing different passes?
>>
>> Morten - Can you share any test cases that demonstrate the slowdown. I'd
>> love to take a look at this.
>>
>> Cheers,
>> Lang.
>>
>> On Thu, Feb 4, 2016 at 4:16 PM, Hal Finkel via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> ----- Original Message -----
>>> > From: "Keno Fischer via llvm-dev" <llvm-dev at lists.llvm.org>
>>> > To: "Morten Brodersen" <Morten.Brodersen at constrainttec.com>
>>> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
>>> > Sent: Thursday, February 4, 2016 6:05:29 PM
>>> > Subject: Re: [llvm-dev] MCJit Runtine Performance
>>> >
>>> >
>>> >
>>> > Yes, unfortunately, this is very much known. Over in the julia
>>> > project, we've recently gone through this and taken the hit (after
>>> > doing some work to fix the very extreme corner cases that we were
>>> > hitting). We're not entirely sure why the slowdown is this
>>> > noticable, but at least in our case, profiling didn't reveal any
>>> > remaining low hanging fruits that are responsible. One thing you can
>>> > potentially try if you haven't yet is to enable fast ISel and see if
>>> > that brings you closer to the old runtimes.
>>>
>>> And maybe the register allocator? Are you using the greedy one or the
>>> linear one? Are there any other MI-level optimizations running?
>>>
>>>  -Hal
>>>
>>> >
>>> >
>>> > On Thu, Feb 4, 2016 at 7:00 PM, Morten Brodersen via llvm-dev <
>>> > llvm-dev at lists.llvm.org > wrote:
>>> >
>>> >
>>> > Hi All,
>>> >
>>> > We recently upgraded a number of applications from LLVM 3.5.2 (old
>>> > JIT) to LLVM 3.7.1 (MCJit).
>>> >
>>> > We made the minimum changes needed for the switch (no changes to the
>>> > IR generated or the IR optimizations applied).
>>> >
>>> > The resulting code pass all tests (8000+).
>>> >
>>> > However the runtime performance dropped significantly: 30% to 40% for
>>> > all applications.
>>> >
>>> > The applications I am talking about optimize airline rosters and
>>> > pairings. LLVM is used for compiling high level business rules to
>>> > efficient machine code.
>>> >
>>> > A typical optimization run takes 6 to 8 hours. So a 30% to 40%
>>> > reduction in speed has real impact (=> we can't upgrade from 3.5.2).
>>> >
>>> > We have triple checked and reviewed the changes we made from old JIT
>>> > to MCJIt. We also tried different ways to optimize the IR.
>>> >
>>> > However all results indicate that the performance drop happens in the
>>> > (black box) IR to machine code stage.
>>> >
>>> > So my question is if the runtime performance reduction is
>>> > known/expected for MCJit vs. old JIT? Or if we might be doing
>>> > something wrong?
>>> >
>>> > If you need more information, in order to understand the issue,
>>> > please tell us so that we can provide you with more details.
>>> >
>>> > Thanks
>>> > Morten
>>> >
>>> > _______________________________________________
>>> > LLVM Developers mailing list
>>> > llvm-dev at lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> >
>>> >
>>> > _______________________________________________
>>> > LLVM Developers mailing list
>>> > llvm-dev at lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> >
>>>
>>> --
>>> Hal Finkel
>>> Assistant Computational Scientist
>>> Leadership Computing Facility
>>> Argonne National Laboratory
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160204/01d4bf56/attachment.html>