On Friday, April 24, 2015 at 2:03:07 AM UTC+10, Mauro wrote:
>
> > It's part of #3440, the compiler optimization metabug: "function-valued 
> > argument inlining" 
> > 
> > https://github.com/JuliaLang/julia/issues/3440 
>
> Thanks, and yes, I'm aware of that one.  For me it's a bit hard to tell, 
> will the "function-valued argument inlining" solve all the higher order 
> function problems?  And is the problem described below, not quite a bit 
> easier to solve? 
>
> > On Thursday, April 23, 2015 at 9:34:48 AM UTC-5, Mauro wrote: 
> >> 
> >> Thanks!  In that case, I'll file an issue then to get this noted. 
>  Also, 
> >> I think there is no (general) issue on the bad performance of higher 
> >> order functions.  Should I file that too? 
> >> 
> >> On Thu, 2015-04-23 at 15:52, Jameson Nash <[email protected] 
> <javascript:>> wrote: 
> >> > The short answer is that there is a certain set of optimizations that 
> >> have 
> >> > been implemented in Julia, but still a considerable set that has not 
> >> been 
> >> > implemented. This falls into the category of optimizations that have 
> not 
> >> > been implemented. Pull requests are always welcome (although I do not 
> >> > recommend this one as a good beginner / "up-for-grabs" issue). 
> >> > 
> >> > On Thu, Apr 23, 2015 at 9:18 AM Mauro <[email protected] 
> <javascript:>> wrote: 
> >> > 
> >> >> It is well know that Julia struggles with type inference in higher 
> >> order 
> >> >> functions.  This usually leads to slow code and memory allocations. 
> >> >> There are a few hacks to work around this.  Anyway, the question I 
> have 
> >> >> is: Why can't Julia do better with in-place functions? 
> >> >> 
> >> >> In short, a higher-order function like this: 
> >> >> 
> >> >> function f(fn!,ar) 
> >> >>     for i=1:n 
> >> >>         fn!(ar, i) # fn! updates ar[i] somehow, returns nothing 
> >> >>         nothing    # to make sure output of f is discarded 
> >> >>     end 
> >> >> end 


I'm curious how you would see it optimised? IIUC Julia doesn't know fn! at 
compile time, so it doesn't know if it returns something, or not, so it has 
to allow for a return value even if its to throw it away immediately.

 

>
> >> >> 
> >> >> has almost as bad a performance (runtime and allocation-wise) as 
> >> >> 
> >> >> function g(fn,ar) 
> >> >>     for i=1:n 
> >> >>         ar[i] = fn(ar[i]) 
> >> >>     end 
> >> >> end 
> >> >> 
> >> >> A in-depth, ready to run example is here: 
> >> >> https://gist.github.com/mauro3/f17da10247b0bad96f1a 
> >> >> Including output of @code_warntype. 
> >> >> 
> >> >> So, why is Julia allocating memory when running f?  Nothing of f 
> gets 
> >> >> assigned to anything. 
> >> >> 
> >> >> Would this be something which is fixable more easily than the whole 
> of 
> >> >> the higher-order performance issues?  If so, is there an issue for 
> >> this? 
> >> >> 
> >> >> Having good in-place higher order functions would go a long way with 
> >> >> numerical computations.  Thanks! 
> >> >> 
> >> 
> >> 
>
>

Reply via email to