It may not be desirable, but I think it's expected. The relevant comment in
inference.jl says:
# don't consider more than N methods. this trades off between
# compiler performance and generated code performance.
# typically, considering many methods means spending lots of time
# obtaining poor type information.
# It is important for N to be >= the number of methods in the error()
# function, so we can still know that error() is always None.
# here I picked 4.
In this case, performance is 20% worse because the compiler can't infer the
return type of intersect if there are >4 possible matching methods. You can
restore it to the same level if you add a typeassert to the call to
intersect.
OTOH, the performance you're losing to failed type inference is nothing
compared to the performance you're losing to dynamic dispatch. You don't
know the type of object at compile time (it could be Sphere, Cube, or
Plane), so the compiler can't optimize the call to intersect into a direct
call. The following code does not have this problem, and is a little over
150x faster on my system.
f(object, objects...) = intersect(object) + f(objects...)
f() = 0.0
function main()
objects = (Sphere(1.0), Cube(2.0), Plane(3.0))
ss = 0.0
for i in 1:40000000
ss += f(objects...)
end
println("Sum: ",ss)
end
On Saturday, May 31, 2014 12:04:02 PM UTC+2, Mike Innes wrote:
>
> You should definitely open an issue about this – if your timings are right
> it's definitely not desirable behaviour.
>
> https://github.com/JuliaLang/julia/issues?state=open
>
>
> On 31 May 2014 11:00, mike c <coolbut...@gmail.com <javascript:>> wrote:
>
>> I've narrowed down the problem. It's not a profiling problem. Julia
>> seems to have a step-change in speed when there are too many functions of a
>> similar signature.
>>
>> I've made a short example that reproduces this slowdown:
>> http://pastebin.com/iHAa2Cws
>>
>> Run the code once as-is, and then uncomment the intersect() function
>> which is currently disabled and run it again. I see a 20% drop in speed.
>> Note: This intersect function is NEVER actually being called. And the type
>> it is related to is NEVER INSTANTIATED.
>>
>> I think this probably qualifies as a bug, but it may just be the price to
>> pay for multiple dispatch when there are too many functions (in this case 5
>> functions) to choose from.
>>
>
>
