On 0.4 there are some pretty good solutions to this problem, but nothing has 
yet been "wrapped up" into something very convenient. (There are a few 
nontrivial issues left to figure out, since it involves automatic generation of 
types.)

I don't have time to find it for you right now, but you can search for old 
posts here (or perhaps julia-dev) on stagedfunctions and call overloading. 
(Mauro was involved in that thread.) Also see 
https://github.com/JuliaOpt/Optim.jl/issues/102#issuecomment-74658825

--Tim


On Wednesday, February 18, 2015 09:25:11 PM [email protected] wrote:
> Hi all,
> 
> Using Julia v0.3.x, there appears to be a significant performance hit when
> using functions as variables or using anonymous functions. I asked a
> StackOverflow question about it here
> <http://stackoverflow.com/questions/28356437/julia-compiler-does-not-appear-> 
> to-optimize-when-a-function-is-passed-a-function>, and, as I understand it,
> the problem is that the compiler is currently unable to determine the type
> of the output of a function when that function is itself a variable or an
> anonymous function - consequently, a big performance hit. I run into this
> issue on an (almost) daily basis, so I was wondering what the best
> work-around is at this point. Thus far, there are three solutions I'm aware
> of:
> 
> 1) Suffer the slower performance: If the function-as-variable/anonymous
> function is itself a fairly big function, then the slow-down associated
> with the unknown output type is not such a big deal when overall run-time
> is taken into consideration. However, frequently the function in question
> is simple, and so this option is not really tenable in these cases.
> 
> 2) Use Tim Holy's very cool FastAnonymous
> <https://github.com/timholy/FastAnonymous.jl> package: For the case of
> anonymous functions, this package speeds things up quite a bit. However, my
> understanding is that it is still a bit of a work-around. Moreover, there
> are some cases in my code where there was still a fairly significant
> performance hit relative to the in-lined case (if anyone wants more detail
> on this I'm happy to provide it)
> 
> 3) Write in-line code: This results in the best possible speed, but there
> ends up being quite a lot of code duplication in my function. For example,
> my code might look something like this:
> if method == "Method1"
>     for n = 1:N
>         y[n] = Method1Function(x1[n], x2[n])
>     end
> elseif method == "Method2"
>     for n = 1:N
>         y[n] = Method2Function(x1[n], x2[n])
>     end
> elseif etc....
>   .
>   .
>   .
> end
> Most of the time the loops are more complicated than just simply iterating
> from 1:N, so the code gets really long and is mostly duplication. Moreover,
> if you want to allow for an arbitrarily large class of functions to be
> applied within the loop, this solution is not tenable.
> 
> I understand the core development team is currently aiming to deal with
> this by v1.0, although there was some noise here
> <https://github.com/JuliaLang/julia/issues/1864>  about trying to get
> things working by the v0.4 stable release. In the meantime, I'm interested
> in the best work-around that other members of this user-group have come up
> with.
> 
> Cheers,
> 
> Colin

Reply via email to