On Saturday, 31 May 2014 21:07:58 UTC+10, Simon Kornblith wrote:
>
> It may not be desirable, but I think it's expected. The relevant comment
> in inference.jl says:
> 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.
>
Thanks. So return types are inferred when there's up to 4 functions with
similar signatures. After that there's the performance drop off.
>
> 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.
>
Unfortunately, my example to demonstrate the performance drop off, doesn't
really encapsulate what the intersect methods are doing. The intersect()
functions are returning values dependant upon the inputs. It's more like.
function intersect(self::Sphere, i)
return self.a + i
end
where the same "i" is being sent to each intersect(). And instead of
summing, I'm really finding the minimum i.e. min( intersect(object, i) )
In reality, it's even more complex than that, with the input "i" really
being a random-ish vector representing a light ray.
>
> f(object, objects...) = intersect(object) + f(objects...)
> f() = 0.0
> ...
> ss += f(objects...)
>
In this simple case, is this just pre-calculating the sum of intersect()s
once and then using it repeatedly?
Thanks for the info & code. Changing objects to a tuple speeds up that
original code I posted by a factor of 3!
Mike.
