5 ms·

Huh? Multiple-dispatch is what makes the language really shine. I miss it in pretty much every other language I use. I am utterly puzzled by how you can see th

Huh? Multiple-dispatch is what makes the language really shine. I miss it in pretty much every other language I use. I am utterly puzzled by how you can see this killer feature as a downsides. Single dispatch is an arbitrary restriction which should not exist. It only exists in most languages as a performance optimization because until Julia came along nobody could do multiple dispatch fast.

enriquto 5y ago
> I am utterly puzzled by how you can see this killer feature as a downsides. It depends on the usage that you make of the language. I don't use Julia as a general-purpose programming language, but only for doing numeric computations. For that usage, the multiple dispatch feature is not necessary (all my variables are matrices of the same numeric type), and indeed it has downsides. For example, the infamous "time to first plot" is so large in Julia precisely due to the need to support multiple dispatch. If this benchmark is becoming faster is only due to a huge and complex effort in optimization. I would prefer if this effort could be spent in improving support for sparse matrices, for example. I acknowledge that "time to first plot" may be a useless benchmark for many, even for most, people. But you can also acknowledge that multiple dispatch is a useless feature for a few graybeards like me, for whom multiple dispatch is the main reason why Julia feels slow. Indeed, when you use Julia as an interpreted language (e.g., write a Julia script), execution is very slow due to the complexities introduced by multiple dispatch, that force essentially to recompile all libraries upon each execution of my tiny script.
- adgjlsfhk1 5y ago
  Multiple dispatch isn't useless for you. It's the reason the numerics are so good even when everything is the same type. Multiple dispatch makes it way easier to write generic code which means that all the libraries you use are about 10x easier to write.
  - ChrisRackauckas 5y ago
    Their point is that they're not trying to write generic code. In that case, Julia should act like an interactive Fortran, which would be nice, but then it needs to fix latency and binary building for the "this is pure Float64 and we know it" case. The only gain one really gets here is that type inference means you can write a bit simpler code, but that's not a huge win. That's a valid criticism that should hopefully be addressed soon, with https://github.com/JuliaLang/julia/pull/41936 https://github.com/JuliaLang/julia/pull/41936 being one of the biggest steps to getting there, along with the more precompilation stuff.
    - ted_dunning 5y ago
      Chris, Not to second-guess you (you know far more about Julia than I) but my experience is that people who think that their code is completely uniformly typed still win massively from Julia. It starts with "just dense matrices with Float64" and then, like the poster above, "but with some nice sparse matrix support" and then "oh and special handling for Vandermonde matrices", "oh and tridiagonals" and eventually "my matrices are hyper-<mumble>-<mumble>-symmetric and I can compute vector dot products really fast". At that point, they have been using multiple dispatch for months without knowing it. In my own case it was "I don't need multiple dispatch" until it was "oh... it surely is nice that the H3 geo-hashes work transparently with LibGEOS even though the underlying C libraries don't work together." The point is that Julia makes using things work together far better than anything else I have seen. It even makes completely asocial C libraries talk to each other.
      - Tarrosion 5y ago
        Can you say more about making H3 and LibGEOS work together?
      - enriquto 5y ago
        Thanks for your answer! I'm the one who sees everything as "just float matrices". Do you have a simple example of a numeric algorithm where multiple dispatch really makes an difference? (as opposed to simply allowing to pass different types of numbers to your functions). I have trouble imagining that. In octave/matlab I can already use the "sum" function over dense and sparse matrices, but you wouldn't say that the language is multiple dispatch. It doesn't seem like a big deal. More importantly, I want the "sum" function to have exactly the same meaning regardless of the data type. I abhor the idea of hiding algorithms into types, on a very fundamental level. Allowing an algorithm to behave differently depending on the type of the input data seems totally wrong to me. The famous Stefan Karpinski talk at JuliaCon 2019 is one of the most horrifying videos I've ever seen. I still wake up at night trembling and with cold sweat when I dream about this talk.
- celrod 5y ago
  I don't think latency is multiple dispatch's fault. Certainly, compilation caching failures aren't.
  - adgjlsfhk1 5y ago
    It kind of is. Multiple dispatch means that a static binary has to deal with most of the downsides of heavily templated C++ code (but much worse since everything is templated). Fixing this is highly non-trivial.
Someone 5y ago
> until Julia came along nobody could do multiple dispatch fast Is that correct/can you give a reference? Reading https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_practice https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_pract..., julia uses it more in its standard library, but I don’t find indication that Julia is doing multiple dispatch better than, say, CLOS (https://en.wikipedia.org/wiki/Common_Lisp_Object_System https://en.wikipedia.org/wiki/Common_Lisp_Object_System) or Cecil (https://en.wikipedia.org/wiki/Cecil_(programming_language) https://en.wikipedia.org/wiki/Cecil_(programming_language)).
- adgjlsfhk1 5y ago
  TLDR is Julia does a much better job than previous systems of de-virtualizing multiple dispatch. Most earlier systems (definitely CLOS, not sure about Cecil) allowed types of dispatch that were very hard to remove at compile time. When combined with Julia's willingness to generate lots of code, this means that most programs in Julia don't have significant amounts of dynamic dispatch which new.
  - Someone 5y ago
    So, where’s the long version? I can believe generating more code is cheaper now that we have gigabytes of memory, but does that make things faster, given that more code ≈ more cache misses? Also, what types of dispatch does Jukai disallow that others allowed? Just curious.
    - johnbcoughlin 5y ago
      Addressing the first point: It certainly does make it faster on the happy path. Instruction cache performance is not a major concern when you're running in a tight loop.
    - adgjlsfhk1 5y ago
      CLOS has :before, :after, and :around qualifiers which Julia doesn't support, and CLOS supports multiple inheritance. Both of these make de virtualization much harder. https://arxiv.org/pdf/1411.1607.pdf https://arxiv.org/pdf/1411.1607.pdf is a pretty good general resource for info about Julia's design decisions and has a section on multiple dispatch. The reason that generating more code can be faster is that more code can actually result in fewer cache misses. Julia is so fast because it is really good at inlining, constant prop, and automatic vectorization. These optimizations all increase the amount of generated code, but remove conditionals that decrease code locality.

enriquto 5y ago

> I am utterly puzzled by how you can see this killer feature as a downsides. It depends on the usage that you make of the language. I don't use Julia as a general-purpose programming language, but only for doing numeric computations. For that usage, the multiple dispatch feature is not necessary (all my variables are matrices of the same numeric type), and indeed it has downsides. For example, the infamous "time to first plot" is so large in Julia precisely due to the need to support multiple dispatch. If this benchmark is becoming faster is only due to a huge and complex effort in optimization. I would prefer if this effort could be spent in improving support for sparse matrices, for example. I acknowledge that "time to first plot" may be a useless benchmark for many, even for most, people. But you can also acknowledge that multiple dispatch is a useless feature for a few graybeards like me, for whom multiple dispatch is the main reason why Julia feels slow. Indeed, when you use Julia as an interpreted language (e.g., write a Julia script), execution is very slow due to the complexities introduced by multiple dispatch, that force essentially to recompile all libraries upon each execution of my tiny script.

adgjlsfhk1 5y ago
Multiple dispatch isn't useless for you. It's the reason the numerics are so good even when everything is the same type. Multiple dispatch makes it way easier to write generic code which means that all the libraries you use are about 10x easier to write.
- ChrisRackauckas 5y ago
  Their point is that they're not trying to write generic code. In that case, Julia should act like an interactive Fortran, which would be nice, but then it needs to fix latency and binary building for the "this is pure Float64 and we know it" case. The only gain one really gets here is that type inference means you can write a bit simpler code, but that's not a huge win. That's a valid criticism that should hopefully be addressed soon, with https://github.com/JuliaLang/julia/pull/41936 https://github.com/JuliaLang/julia/pull/41936 being one of the biggest steps to getting there, along with the more precompilation stuff.
  - ted_dunning 5y ago
    Chris, Not to second-guess you (you know far more about Julia than I) but my experience is that people who think that their code is completely uniformly typed still win massively from Julia. It starts with "just dense matrices with Float64" and then, like the poster above, "but with some nice sparse matrix support" and then "oh and special handling for Vandermonde matrices", "oh and tridiagonals" and eventually "my matrices are hyper-<mumble>-<mumble>-symmetric and I can compute vector dot products really fast". At that point, they have been using multiple dispatch for months without knowing it. In my own case it was "I don't need multiple dispatch" until it was "oh... it surely is nice that the H3 geo-hashes work transparently with LibGEOS even though the underlying C libraries don't work together." The point is that Julia makes using things work together far better than anything else I have seen. It even makes completely asocial C libraries talk to each other.
    - Tarrosion 5y ago
      Can you say more about making H3 and LibGEOS work together?
    - enriquto 5y ago
      Thanks for your answer! I'm the one who sees everything as "just float matrices". Do you have a simple example of a numeric algorithm where multiple dispatch really makes an difference? (as opposed to simply allowing to pass different types of numbers to your functions). I have trouble imagining that. In octave/matlab I can already use the "sum" function over dense and sparse matrices, but you wouldn't say that the language is multiple dispatch. It doesn't seem like a big deal. More importantly, I want the "sum" function to have exactly the same meaning regardless of the data type. I abhor the idea of hiding algorithms into types, on a very fundamental level. Allowing an algorithm to behave differently depending on the type of the input data seems totally wrong to me. The famous Stefan Karpinski talk at JuliaCon 2019 is one of the most horrifying videos I've ever seen. I still wake up at night trembling and with cold sweat when I dream about this talk.
celrod 5y ago
I don't think latency is multiple dispatch's fault. Certainly, compilation caching failures aren't.
- adgjlsfhk1 5y ago
  It kind of is. Multiple dispatch means that a static binary has to deal with most of the downsides of heavily templated C++ code (but much worse since everything is templated). Fixing this is highly non-trivial.

Someone 5y ago

> until Julia came along nobody could do multiple dispatch fast Is that correct/can you give a reference? Reading https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_practice https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_pract..., julia uses it more in its standard library, but I don’t find indication that Julia is doing multiple dispatch better than, say, CLOS (https://en.wikipedia.org/wiki/Common_Lisp_Object_System https://en.wikipedia.org/wiki/Common_Lisp_Object_System) or Cecil (https://en.wikipedia.org/wiki/Cecil_(programming_language) https://en.wikipedia.org/wiki/Cecil_(programming_language)).

adgjlsfhk1 5y ago
TLDR is Julia does a much better job than previous systems of de-virtualizing multiple dispatch. Most earlier systems (definitely CLOS, not sure about Cecil) allowed types of dispatch that were very hard to remove at compile time. When combined with Julia's willingness to generate lots of code, this means that most programs in Julia don't have significant amounts of dynamic dispatch which new.
- Someone 5y ago
  So, where’s the long version? I can believe generating more code is cheaper now that we have gigabytes of memory, but does that make things faster, given that more code ≈ more cache misses? Also, what types of dispatch does Jukai disallow that others allowed? Just curious.
  - johnbcoughlin 5y ago
    Addressing the first point: It certainly does make it faster on the happy path. Instruction cache performance is not a major concern when you're running in a tight loop.
  - adgjlsfhk1 5y ago
    CLOS has :before, :after, and :around qualifiers which Julia doesn't support, and CLOS supports multiple inheritance. Both of these make de virtualization much harder. https://arxiv.org/pdf/1411.1607.pdf https://arxiv.org/pdf/1411.1607.pdf is a pretty good general resource for info about Julia's design decisions and has a section on multiple dispatch. The reason that generating more code can be faster is that more code can actually result in fewer cache misses. Julia is so fast because it is really good at inlining, constant prop, and automatic vectorization. These optimizations all increase the amount of generated code, but remove conditionals that decrease code locality.