Blog post: Rust vs Julia in scientific computing

[ChrisRackauckas]

@Mo8it

I am wrong then in that point, I will edit my reply. It was something out of my head and I only quickly checked the Wikipedia article about multiple dispatch which says that it is done dynamically using a vtable.

I highly recommend reading that Jan Vitek article, or watching his JuliaCon talk:

JuliaCon 2021 | Day 1 Single Track | Prof. Jan Vitek Keynote

I don’t think it’s an exaggeration to say that the entire point of function specialization in Julia is to allow for call site devirtualization on multiple dispatch. The key here is that semantically dispatch is handled through look ups to the function table, though the compiler is allowed to optimize the dynamic behavior away if it can prove that the dispatch result is known at compile time. Then what is proven is that type-groundedness (or basically type-stability, in a clearer type-theoretic way) is exactly the property that’s required to correctly prove that dispatch results are known constants.

Therefore, the reason why Julia is fast is because function specialization + multiple dispatch allows for dynamic looking semantics to give the compiler enough information to prove and remove all dynamic dispatching.

In other words, Julia always looks like it has dynamic dispatch, though the compiled code (for “good code”) does not have dynamic dispatch and will statically dispatch. This of course is “under the hood” and not necessarily semantics of the language, it’s a compiler optimization, but it’s the important one that makes Julia code compile down to something like C. Because when this is done correctly, the compiled code is effectively static.

@Mo8it

I should be more specific in my subjective guessing. I did mean big projects that are not a library. At least from my experience with BenchmarkTools.jl, it was very hard to keep the time taken by the GC under 10%. It depends on the project.

Depends on the project, but at the same time the core numerical kernels don’t tend to be where the issue is. Making a code use in-place operations is straightforward, what is missing is enforcing that a kernel never allocates so that future maintenance of a code gets errors and test failures if that property is ever lost.

Note that while saying this, I am currently drafting ideas and designs for more static subsets of Julia and with more direct control over allocation behavior, so I definitely agree that there are currently some benefits of languages like Rust or C++ that I would like to see in a near future Julia. But you should be careful about where exactly this boundary is. Also the Julia allocator is a bit slower right now than it should be, but there’s discussions on how to address that by v1.11.