[LLVMdev] LLVM 3.3 JIT code speed

[Stéphane Letz]

Le 18 juil. 2013 à 23:51, Stéphane Letz <letz at grame.fr> a écrit :

> 
> Le 18 juil. 2013 à 21:05, "Kaylor, Andrew" <andrew.kaylor at intel.com> a écrit :
> 
>> I understand you to mean that you have isolated the actual execution time as your point of comparison, as opposed to including runtime loading and so on.  Is this correct?
> 
> We are testing actual execution time yes :  time used in a given JIT compiled function.
>> 
>> 
>> One thing that changed between 3.1 and 3.3 is that MCJIT no longer compiles the module during the engine creation process but instead waits until either a function pointer is requested or finalizeObject is called.  I would guess that you have taken that into account in your measurement technique, but it seemed worth mentioning.
> 
> OK, so I guess our testing is then correct since we are testing actual execution time of the function pointer.
>> 
>> 
>> What architecture/OS are you testing?
> 
> 64 bits OSX (10.8.4)
>> 
>> With LLVM 3.3 you can register a JIT event listener (using ExecutionEngine::RegisterJITEventListener) that MCJIT will call with a copy of the actual object image that gets generated.  You could then write that image to a file as a basis for comparing the generated code.  You can find a reference implementation of the interface in lib/ExecutionEngine/IntelJITEvents/IntelJITEventListener.cpp.
> 
> Thanks I'll have a look.
>> 
>> -Andy
>> 
> 
> Stéphane
> 


And since the 1) DSL  ==> C/C++  ===> clang/gcc -03 ===> exec  code chain has the "correct" speed, there is no reason the JIT based one should be slower right? 

So I still guess something is wrong in the way we use the JIT and/or some LTO issue possibly?

Stéphane