[ANN] DispatchDoctor.jl 🩺 – offers you a prescription for type stability

[MilesCranmer]

@gdalle

I have not followed the performance optimization thread, so could you explain in terms accessible to a metaprogramming layperson how this is even possible?

So, because the Julia compiler infers return type of a function given the input types. All DispatchDoctor does is, for a function f1:

1. Puts f1’s body into a separate function definition, with an identical signature, but a different name. Let’s call it f2.
2. From the original function f1, it removes the original body, and inserts code that will checks the compiler-inferred type of f2 given the types of args.
3. f1 runs Base.isconcretetype on that inferred type, and if false, throws an error.
4. Otherwise, f1 calls f2(args…), and returns the result.

So because the inference of f2 and isconcretetype are in “type space”, it can do that at compile time. Thus, if things are type stable, Julia should just remove the error message from the code altogether.

Basically this if-statement’s first term only depends on input types:

MilesCranmer/DispatchDoctor.jl/blob/788284f8c8439f08f8bef5f8cbdccf478ae808fc/src/DispatchDoctor.jl#L290

And if type_instability(T) evaluates to false, it should compile to

if false && ...
    error()
end

f2(args...)

and then we assume LLVM will remove that if statement.

@gdalle

And whether we can be 100% certain that the check compiles away every time?

Well, I don’t want to say 100%. I haven’t found an example otherwise but with the Julia compiler and LLVM I never really feel 100% confident about an optimization taking place or not. It “should” compile away that if statement, but people should share examples otherwise.

I guess we could make ourselves 100% confident if we turn the checker function into a @generated function, so that we can explicitly remove the if statement from the code. But I’m assuming the Julia compiler will do that for us.