Can you build the code with llc? Try with the large code model. I think that is the default for MCJIT and can be less efficient. Cheers, Rafael On 4 February 2016 at 22:26, Morten Brodersen via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Hi Hal, > > We are using the default register allocator. I assume the greedy one is > default? > > As for other target machine optimizations: > > I have tried: > > llvm::TargetMachine* tm = ...; > > tm->setOptLevel(llvm::CodeGenOpt::Aggressive); > > And it doesn't make much of a difference. > > And also: > > tm->setFastISel(true); > > (previous email). > > Is there anything else I can try? > > > On 05/02/16 11:16, Hal Finkel 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 >>> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hi Rafael, Not easily (llc). Is there a way to make MCJit not use the large code model when JIT'ing? Cheers Morten On 05/02/16 14:28, Rafael Espíndola wrote:> Can you build the code with llc? Try with the large code model. I > think that is the default for MCJIT and can be less efficient. > > Cheers, > Rafael > > > On 4 February 2016 at 22:26, Morten Brodersen via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi Hal, >> >> We are using the default register allocator. I assume the greedy one is >> default? >> >> As for other target machine optimizations: >> >> I have tried: >> >> llvm::TargetMachine* tm = ...; >> >> tm->setOptLevel(llvm::CodeGenOpt::Aggressive); >> >> And it doesn't make much of a difference. >> >> And also: >> >> tm->setFastISel(true); >> >> (previous email). >> >> Is there anything else I can try? >> >> >> On 05/02/16 11:16, Hal Finkel 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 >>>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On 4 February 2016 at 22:48, Morten Brodersen via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Hi Rafael, > > Not easily (llc). > > Is there a way to make MCJit not use the large code model when JIT'ing? >I think Davide started adding support for the small code model. Cheers, Rafael