According to the "performace tips" section of the Julia manual it is not advisable to go crazy with multiple dispatch. I've run into a situation where it seems I need 3 parameters for a type I'm defining. This is related to my question about using only 1 parameter for 2 possible types. I realize I could solve the difficulty presented there by simply using another parameter but then my type looks like
type mytype{R<:Real, S<:Any, T<:Any}
x::Matrix{R}
y::Dict{Int64, Vector{S}}
z::Dict{T, Vector{Int64}}
end
Is this inadvisable interms of performance for having several parameters to dispatch on. Functions on mytype would then dispatch on the 3 parameters and the function arguments is that correct?
It's fine. Do as much multiple dispatch on Types, as you want. That is what it is for.
What you don't really want to do; and what that part of the docs is getting at, is too much dispatch on Values. Which you can do, by using a Value, as a type parameter.
Doing dispatch on values tends to have the problem that it (often) results in dynamic dispatch. Which means a function calling a function that has a value as a type parameter, can not specialize, by knowing which function it will call. This is closely related to type instability. It can kill a lot of the optimiser, and make julia run slow like python.
Here is an example of some of my code that arguably goes "too far" with dispatching on value.
It makes extensive use of the Val{T}
type, which exists only for allowing dispatch on value.
It is very expressive, and very succinct, but it is not going to run as fast as the same code, using conditionals, or dictionary lookups instead.
(And that is a trade-off I am willing to make, in this case)
The docs are also getting at that you shouldn't be storing values as type parameters on your custom types. Particularly if you are not even going to dispatch on them. That is what fields are for.
That's fine. Note you can just write this as:
type mytype{R<:Real, S, T}
x::Matrix{R}
y::Dict{Int64, Vector{S}}
z::Dict{T, Vector{Int64}}
end
In most cases where you're doing a non-trivial amount of calculations, strict typing (on types) will be good for performance. If the small functions you're calling inline (in many cases it will do so automatically in v0.5, but you can help it with @inline
), then there's no cost to function calls anyways and you're worrying about nothing.
As always, benchmark it and see for yourself. Mostly the problem here comes from a large number of value types.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With