Possible dispatch enhancements

[smartalecH]

@stevengj we had a conversation (at meepcon) about some of the potential pitfalls of the current implementation of GeometryPrimitives.jl compared to the C version of libctl.

You mentioned the primary issue had to do with dispatch. libctl has a custom dispatch routine that is rather optimized for many function calls, whereas the current GeometryPrimitives.jl implementation tries to generalize for multiple dispatch (but I may be misremembering...).

Could you talk a bit more about that here and maybe discuss what it would take to overcome some of these issues?

I read a recent article by @ChrisRackauckas that describes how they cut down on compile times by limiting dispatch flexibility. The issue here isn't with compile time, but I'm wondering if there are similar lessons to be learned.

[stevengj]

See the discussion here: https://discourse.julialang.org/t/allocation-and-slow-down-when-of-types-involved-increase-slower-than-c-virtual-methods/87656/3

A possible workaround is https://github.com/YingboMa/Unityper.jl

[stevengj]

The literal way to emulate C++'s vtables in C would be to use a table of function pointers inside the struct. e.g. we do this in FFTW here: https://github.com/FFTW/fftw3/blob/9426cd59106ffddde1f55131c07fa9c562fa2f8e/kernel/ifftw.h#L497-L507

[smartalecH]

@stevengj I'm happy to take this on.

I've been doing some reading. It seems that Julia's union splitting has come a long way over the years, such that the compiler should be able to produce the equivalent of a manually-dispatched switch block.

In theory, we should be able to define a union type of all possible shapes, right? (There aren't that many). In which case, the overhead of the dynamic dispatch should be optimized away.

It should be straightforward to write a quick test for this...

[stevengj]

Note also that Symbolics.jl uses https://github.com/YingboMa/Unityper.jl (via SymbolicUtils.jl), which is another vote of confidence in using this to express a finite type union.