Thanks for the explanation, Keno. I'm trying to implement a simulation of rigid body dynamics (a robot in this case) in (almost) real time, so I'm planning to put the integration algorithm inside a Timer which would repeat with a small period (not much more than 1ms, preferably). Hence, it would be better to have both the integration function and the dynamic equation function ready when the timer starts. In this case, it would be nice to do not have to actually run a function to have it fully ready, especially with functions which mutate their arguments.
Thanks again. On Thu, Jun 12, 2014 at 5:10 PM, Stefan Karpinski <ste...@karpinski.org> wrote: > Wait, so precompile does less during system image generation right now? > > > On Thu, Jun 12, 2014 at 11:54 AM, Keno Fischer < > kfisc...@college.harvard.edu> wrote: > >> During sysimage generation it doesn't make a difference. I believe we >> still generate LLVM IR (if we don't that really needs to be fixed), which >> gets dumped and compiled into sys.so accordingly. The only question is in >> REPL usage. >> >> >> On Thu, Jun 12, 2014 at 11:52 AM, Stefan Karpinski <ste...@karpinski.org> >> wrote: >> >>> It would be nice if you could precompile something to do the actual code >>> gen. I understand why we didn't do it before when we couldn't save >>> generated code, but now we do save generated code in sys.so, wouldn't >>> making precompile generate machine code be helpful? >>> >>> >>> On Thu, Jun 12, 2014 at 11:42 AM, Keno Fischer < >>> kfisc...@college.harvard.edu> wrote: >>> >>>> By way of explanation what precompile does is reduce the julia function >>>> to an intermediate representation suitable for final binary generation. It >>>> is mainly used when building the system image, as what basically happens at >>>> the end of system image generation is that all functions in intermediate >>>> representation get collected and then collectively assembled into the final >>>> binary. In JIT operation, both steps usually happen when you call the >>>> function, though in your example precompile does the first step. The reason >>>> you don't see much of an impact of what precompile does is that your >>>> function is relatively simple so type inference and codegen don't have to >>>> work very hard as compared to the actual binary generation. >>>> >>>> Maybe precompile in REPL mode should also do the final compilation, but >>>> I hope that explanation is at least useful. >>>> >>>> >>>> On Thu, Jun 12, 2014 at 10:47 AM, Cristóvão Duarte Sousa < >>>> cris...@gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> With Julia 0.3.0-prerelease+3609 (Commit 664cab5 (2014-06-10 05:18 >>>>> UTC)) in Arch Linux x86_64, >>>>> precompile() doesn't seems to effectively improve functions first call >>>>> time. >>>>> For example, this code: >>>>> >>>>> N = 10 >>>>> A = rand(N,N) >>>>> B = rand(N,N) >>>>> >>>>> >>>>> function f(a, b) >>>>> c=a+b >>>>> c >>>>> end >>>>> >>>>> >>>>> @time precompile(f, typeof((A,B))); >>>>> @time f(A,B); >>>>> @time f(A,B); >>>>> @time f(A,B); >>>>> >>>>> usually outputs something like >>>>> >>>>> elapsed time: 0.001388013 seconds (21972 bytes allocated) >>>>> elapsed time: 0.001305722 seconds (1008 bytes allocated) >>>>> elapsed time: 7.486e-6 seconds (1008 bytes allocated) >>>>> elapsed time: 7.128e-6 seconds (1008 bytes allocated) >>>>> >>>>> >>>>> Isn't precompile supposed mitigate the first call time overhead? >>>>> Am I missing something? >>>>> >>>> >>>> >>> >> >
