3 ms·

> 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_dispat

> 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.
  - ChrisLomont 5y ago
    >given that more code ≈ more cache misses More code isn't randomly jumped around in, so there are not necessarily (or in practice) more cache misses. Hot paths in Julia compile down better than in many other languages (including C/C++/FORTRAN, where aliasing is much more of a problem), specifically since multiple dispatch gets resolved as much as possible (and often completely) at compile time. If anything, by making per type versions of things, there are less cache misses since things that are similar stay together, needing less instructions on hot paths to look up types and do other stuff that other systems do hit. The proof is in the pudding - write (or find) some good code doing similarly complex things, and test them. Julia has C/FORTRAN speeds (and better) for a lot of important tasks, with the development flexibility of Python.
fault1 5y ago
How about Dylan? :-) I think one of the nice thing about Julia's "just ahead of time" monomorphization/devirtualization is that it allows a level of dynamism that also works on GPUs/TPUs. This post and linked paper help me understand a little bit of it: https://discourse.julialang.org/t/julia-inference-lattice-vs-type-lattice-from-the-tpu-paper/18397/2 https://discourse.julialang.org/t/julia-inference-lattice-vs... Is this level of dynamism required for conventional ML? Probably not. For physics-informed ML and probabilistic languages? Probably more likely.

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.
- ChrisLomont 5y ago
  >given that more code ≈ more cache misses More code isn't randomly jumped around in, so there are not necessarily (or in practice) more cache misses. Hot paths in Julia compile down better than in many other languages (including C/C++/FORTRAN, where aliasing is much more of a problem), specifically since multiple dispatch gets resolved as much as possible (and often completely) at compile time. If anything, by making per type versions of things, there are less cache misses since things that are similar stay together, needing less instructions on hot paths to look up types and do other stuff that other systems do hit. The proof is in the pudding - write (or find) some good code doing similarly complex things, and test them. Julia has C/FORTRAN speeds (and better) for a lot of important tasks, with the development flexibility of Python.

fault1 5y ago

How about Dylan? :-) I think one of the nice thing about Julia's "just ahead of time" monomorphization/devirtualization is that it allows a level of dynamism that also works on GPUs/TPUs. This post and linked paper help me understand a little bit of it: https://discourse.julialang.org/t/julia-inference-lattice-vs-type-lattice-from-the-tpu-paper/18397/2 https://discourse.julialang.org/t/julia-inference-lattice-vs... Is this level of dynamism required for conventional ML? Probably not. For physics-informed ML and probabilistic languages? Probably more likely.