4 ms·

Thanks, here you presented an example that actually makes sense to me. In case of octave/matlab, of course computing the sum() of sparse matrices does not trav

Thanks, here you presented an example that actually makes sense to me. In case of octave/matlab, of course computing the sum() of sparse matrices does not traverse all the zeros. But the result is the same as if it did, just much faster. There are also many types of sparse matrices, I wonder how does it work internally, it must have a similar mechanism. Probably, since it is interpreted in real time, each time that the "sum" function is called, it checks the type of the arguments and it calls the appropriate function. > most numerics libraries that aren't in Julia make ad-hoc and slow implementations The word "slow" has a relative meaning here... if you take into account the time of the first compilation. For example, calling an octave script that performs a matrix product is faster than the equivalent julia script.

adgjlsfhk1 5y ago
>the result is the same as if it did This isn't quite true. Differently ordered operations can lead to different results due to floating point math, but in general, the point of multiple dispatch isn't to produce different results for different types. The example from Stefan's talk does this when contrasting with operator overloading because it's easier to show a difference in results than a difference in performance. I don't know the specifics of how Matlab/Octave do this, but you're probably right about runtime checks. It's true that compilation time will make Julia slower than Octave for a single multiplication, but if you are doing a bunch of them (especially if they are small), Julia can perform the computations with much lower overhead since it doesn't have to do type checks for stable programs. Also, Julia lets you define specialized matrix types which can be asymptotically faster than Octave for specific circumstances. A great example of this is BandedBlockBandedMatrix from https://github.com/JuliaMatrices/BlockBandedMatrices.jl https://github.com/JuliaMatrices/BlockBandedMatrices.jl which are extremely useful solving of PDEs quickly, but aren't implemented in any of the other languages because they have to write all their dispatch systems manually for each algorithm.

adgjlsfhk1 5y ago

>the result is the same as if it did This isn't quite true. Differently ordered operations can lead to different results due to floating point math, but in general, the point of multiple dispatch isn't to produce different results for different types. The example from Stefan's talk does this when contrasting with operator overloading because it's easier to show a difference in results than a difference in performance. I don't know the specifics of how Matlab/Octave do this, but you're probably right about runtime checks. It's true that compilation time will make Julia slower than Octave for a single multiplication, but if you are doing a bunch of them (especially if they are small), Julia can perform the computations with much lower overhead since it doesn't have to do type checks for stable programs. Also, Julia lets you define specialized matrix types which can be asymptotically faster than Octave for specific circumstances. A great example of this is BandedBlockBandedMatrix from https://github.com/JuliaMatrices/BlockBandedMatrices.jl https://github.com/JuliaMatrices/BlockBandedMatrices.jl which are extremely useful solving of PDEs quickly, but aren't implemented in any of the other languages because they have to write all their dispatch systems manually for each algorithm.