Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Julia: Efficiency of Multiple Parameters

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?

like image 386
mv3 Avatar asked Dec 19 '22 12:12

mv3


2 Answers

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.

like image 194
Lyndon White Avatar answered Dec 27 '22 00:12

Lyndon White


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.

like image 42
Chris Rackauckas Avatar answered Dec 27 '22 00:12

Chris Rackauckas