-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
RFC: Do not consider inlining cost for precompilation #53547
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This does grow the sysimg a considerable amount: Master: However, I would argue, reliable precompilation is somewhat important. Is it possible this threshold could be adjusted instead? |
What are the cases where you need precompilation for an inlineable function but aren't calling it from a context where it's been inlined? |
I don't know. The behavior I am seeing seems to imply inlining is not strictly a function of the callee complexity, but also the caller. For example under the following contrived workload (run twice to allow downloads/resolve) I see:
precomp_mast.txt
|
Looks like the tests would need to be changed with this as well: https://buildkite.com/julialang/julia-master/builds/34254#018dfb82-9e51-4c92-a655-9d43f9b2dd9b/910-1671 |
This helps to minimize the amount of failed precompiles that occur by eliding the inlining cost check. It is likely this will lead to slightly larger sys/pkgimg sizes. However in practice it leads to more extensive and successful precompilation, which can minimize the number of JIT events which occur when using Julia.
361e211
to
650868e
Compare
The cases where this matters is that you have a dynamic dispatch that then dispatches to one of these functions that always gets inlined. |
Right — that was my assumption and at the root of my question. If there's dynamic dispatch, how does Julia know the argument types in order to do the precompile? I suppose there must be other — type stable — functions that happen to call (and then inline) these methods in other usages, so then the standalone versions happen to get precompiled on this branch? |
So if I am understanding correctly this is then indeed a bug in the current precompilation heuristic. Meaning there are such cases where something is in theory always able to be inlined, but is in fact not due to dynamic dispatch. Therefore this patch fixes the issue, but is inefficient because we exhaustively precompile every method instance, whereas we want something that knows if the calling context is a dynamic dispatch. This truth table may help articulate this better:
|
I think that's right, yes. It's basically using the fact that we had to infer and inline a function somewhere as a heuristic to find functions that are probably useful. Given that we had to analyze these functions anyway, it's nice to compile and save them. But I'm not sure it's really worth the extra space. Maybe we should enable this in compile=all mode though? |
This helps to minimize the amount of missed precompiles that occur by eliding the inlining cost check when julia is run under `--compile=all`. This will lead to slightly larger sysimage sizes. However, in practice it leads to more extensive and successful precompilation, which can minimize the number of JIT events in call sites with dynamic dispatch. This is an alternative to JuliaLang#53547, where removing the inlining cost check was made universal. However, that lead to ~15% larger sysimage sizes by default. This implements Jeff's suggestion that this mode be enabled under `--compile=all`.
Replacing with #53798 |
This helps to minimize the amount of missed precompiles that occur by eliding the inlining cost check when julia is run under `--compile=all`. This will lead to slightly larger sysimage sizes. However, in practice it leads to more extensive and successful precompilation, which can minimize the number of JIT events in call sites with dynamic dispatch. This is an alternative to #53547, where removing the inlining cost check was made universal. However, that lead to ~15% larger sysimage sizes by default. This implements Jeff's suggestion that this mode be enabled under `--compile=all`.
…ang#53798) This helps to minimize the amount of missed precompiles that occur by eliding the inlining cost check when julia is run under `--compile=all`. This will lead to slightly larger sysimage sizes. However, in practice it leads to more extensive and successful precompilation, which can minimize the number of JIT events in call sites with dynamic dispatch. This is an alternative to JuliaLang#53547, where removing the inlining cost check was made universal. However, that lead to ~15% larger sysimage sizes by default. This implements Jeff's suggestion that this mode be enabled under `--compile=all`.
This helps to minimize the amount of failed precompiles that occur by eliding the inlining cost check. It is likely this will lead to slightly larger sys/pkgimg sizes. However in practice it leads to more extensive and successful precompilation, which can minimize the number of JIT events which occur when using Julia.