[llvm-dev] MCJit Runtine Performance

[Morten Brodersen via llvm-dev]

Hi Lang,

 > can you share your EngineBuilder configuration lines?

Sure.

The 3.5.2 version use:

         llvm::ExecutionEngine* ee =
             llvm::EngineBuilder(module)
                 .setEngineKind(llvm::EngineKind::JIT)
.setOptLevel(llvm::CodeGenOpt::Aggressive)
                 .create();

module->setDataLayout(ee->getTargetMachine()->getDataLayout());

And the 3.7.1 version use:

         llvm::EngineBuilder builder(move(modulePtr));

         builder.setEngineKind(llvm::EngineKind::JIT);
         builder.setErrorStr(&error);
builder.setOptLevel(llvm::CodeGenOpt::Aggressive);

         llvm::ExecutionEngine* ee = builder.create();

module->setDataLayout(*ee->getTargetMachine()->getDataLayout());

Cheers
Morten

On 05/02/16 19:13, Lang Hames wrote:
> Hi Morten,
>
> Something else just occurred to me: can you share your EngineBuilder 
> configuration lines? 
> (http://llvm.org/docs/doxygen/html/classllvm_1_1EngineBuilder.html)
>
> In particular - are you explicitly setting the optimization level? The 
> old JIT may have had a different default.
>
> - Lang.
>
>
>
> Sent from my iPad
>
> On Feb 4, 2016, at 10:54 PM, Jim Grosbach via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>> I agree with Lang and Keno here. This is both unexpected and very 
>> interesting. Given the differences in defaults between the two, I 
>> would have expected the new JIT to have better performance but longer 
>> compile times. That you are seeing the opposite implies there is 
>> something very wrong and I'm very interested to help figure out what 
>> it is.
>>
>> Sent from my iPad
>>
>> On Feb 4, 2016, at 9:12 PM, Morten Brodersen via llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>>> Hi Keno,
>>>
>>> I am talking about runtime. The performance of the generated machine 
>>> code. Not the time it takes to lower the IR to machine code.
>>>
>>> We typically only JIT once (taking a few secs) and then run the 
>>> generated machine code for hours. So the JIT time (IR -> machine 
>>> code) doesn't impact us.
>>>
>>> Cheers
>>> Morten
>>>
>>> On 05/02/16 15:58, Keno Fischer wrote:
>>>> Actually, reading over all of this again, I realize I may have made 
>>>> the wrong statement. The runtime regressions we see in julia are 
>>>> actually regressions in how long LLVM itself takes to do the 
>>>> compilation (but since it happens at run time in the JIT case, I 
>>>> think of it as a regression in our running time). We have only 
>>>> noticed occasional regressions in the performance of the generated 
>>>> code (which we are in the process of fixing). Which kind of 
>>>> regression are you talking about, time taken by LLVM or time taken 
>>>> by the LLVM-generated code?
>>>>
>>>> On Thu, Feb 4, 2016 at 11:44 PM, Rafael Espíndola 
>>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>>
>>>>     On 4 February 2016 at 22:48, Morten Brodersen via llvm-dev
>>>>     <llvm-dev at lists.llvm.org <mailto: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
>>>>     _______________________________________________
>>>>     LLVM Developers mailing list
>>>>     llvm-dev at lists.llvm.org <mailto: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 <mailto: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 <mailto: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/20160208/47292485/attachment.html>