Adding performant runtime dispatch to Julia

General Usage
,
1

While Julia’s compile-time dispatch serves Julia users well, in some cases, runtime dispatch is needed. Runtime dispatch in Julia is not designed to be performant. This proposal attempts to add a limited dispatching (including multiple dispatches) capability to Julia. The proposal is as follows:

  1. Base dispatch on binary traits.
  2. There can be at most 64 traits.
  3. Store these traits as bits in a 64-bits integer.
  4. Whenever using, mask the relevant bits needed for dispatch, then do a perfect hash to get the value.

This was inspired by the magic bitboard
There can also be many tricks, for example, you could allocate the first 32 bits for the first object, and the last 32 bits for the second object, and then when they “collide”, you OR the bits together to get the full 64-bit set, then you do the dispatch.

Combined with the FunctionWrappers.jl, this could be used to create virtual functions with high flexibility.

However:

  • Bits manipulation is to be abstracted away from users, but how do I expose all the capabilities of the system to the user?
  • How would you handle the edge cases? While 64 bits stored and 16 bits dispatch is enough for many applications, how would you make an error or fallback system in case it fails?

How would I abstract this into a package? I want to give Julia a runtime dispatch it deserves.
Thank you, for reading. This is probably going to be my first package.

2

By the way, I think GitHub - SymbolicML/DynamicExpressions.jl: Ridiculously fast dynamic expressions. addresses a similar need in the case of numeric functions built from primitives.

1 Like
3

Yes, there can be multiple ideas on “dynamic dispatch”. But this one is more concerned with deciding which method of a function to use, not changing functions over time. Thank you by the way, but I was talking about a different thing.

1 Like
4

To clarify a bit, there are many ways you can efficiently change the function/method called if you know which method is to be called, but the problem is knowing which method is to be called. Traditional OOP languages typically use a virtual method table that decides the method based on the runtime type ID of the object. This proposal is intended to be more general than that solution.