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
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
Hi, | 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? When you say "slower" wrt 3.1 on LLVM and the same speed for clang, could you put some rough time numbers on things for some fixed testcode for your DSL? Obviously they won't have an absolute meaning, but the order of magnitude relative to the normal execution times might guide the ideas about what it could be. Cheers, Dave