-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
Improving broadcasting performance by working around recursion limits of inlining #41139
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
Improving broadcasting performance by working around recursion limits of inlining #41139
Conversation
I must confess it's always a challenge for me to understand the existing recursive magic whenever I look at this file. I can often get there, but it makes my head hurt a bit. I understand the motivation here, but the indirection makes this intractable for me. 🤯 |
I still don't understand how |
Bump? |
Bump |
I think we need triage to decide whether the performance gain is worth the added complexity. |
end | ||
|
||
for UB in [Any, RecursiveInliningEnforcerA] | ||
@eval @inline function (bb::RecursiveInliningEnforcerB{TMT,TMH,TT,TH,TF})(args::Vararg{Any,N}) where {N,TMT,TMH<:$UB,TT,TH,TF} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this need two methods? Doesn't the Any
bound cover everything?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC the compiler currently has problems with inlining recursive method calls, so by having two different methods doing the same thing there is less recursion to handle. There is no other reason to having two methods there. I don't know how exactly this works so I may be wrong though -- but it works.
Triage thinks this is a bit too dependent on current details of how the compiler works. It basically just names the types of the returned functions and adds unnecessary extra methods. From looking at the code, there is no good reason why that should have any effect. So we should try to improve the compiler instead. |
Similar to JuliaLang#41139, but avoid unnecessary extra methods.
Similar to JuliaLang#41139, but avoid unnecessary extra methods.
Similar to JuliaLang#41139, but avoid unnecessary extra methods.
Similar to JuliaLang#41139, but avoid unnecessary extra methods.
Similar to JuliaLang#41139, but avoid unnecessary extra methods.
This PR implements the changes proposed in #41090 . All it does is duplicating the two methods that are marked as deletions in this PR. Benchmarks that motivate this change are available here: #41090 (comment) .