precompile is useless in lots of situations anyway, because it can't generally compile all methods that might be called from the function you want to precompile. You will always have to check if your function calls methods that can not be exactly determined compile time based on the types of the arguments, and check that those gets compiled also.
kl. 18:38:35 UTC+2 torsdag 12. juni 2014 skrev Cristóvão Duarte Sousa følgende: > > 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 > <javascript:>> wrote: > >> Wait, so precompile does less during system image generation right now? >> >> >> On Thu, Jun 12, 2014 at 11:54 AM, Keno Fischer < >> kfis...@college.harvard.edu <javascript:>> 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 >>> <javascript:>> 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 < >>>> kfis...@college.harvard.edu <javascript:>> 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 < >>>>> cri...@gmail.com <javascript:>> 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? >>>>>> >>>>> >>>>> >>>> >>> >> >
