Force specialization on operator arguments for mapfoldl_impl
#33917
Conversation
Eliminates dynamic dispatch.
|
Is the second change, on L54, actually necessary? There the arguments are just passed through. I also asked on discourse, but might as well do it here: the |
|
Maybe the first one isn't necessary, but I don't think it hurts either. The one on L54 is clearly important, as profiling will show you. |
| @@ -36,7 +36,7 @@ mul_prod(x::Real, y::Real)::Real = x * y | |||
|
|
|||
| ## foldl && mapfoldl | |||
|
|
|||
| function mapfoldl_impl(f, op, nt::NamedTuple{(:init,)}, itr, i...) | |||
| function mapfoldl_impl(f::F, op::OP, nt::NamedTuple{(:init,)}, itr, i...) where {F,OP} | |||
There was a problem hiding this comment.
Migth be worth a comment, as the where {F,OP} is here purely for this unusual reason of forcing specialization, which may not be evident to the next person touching these lines (who might as well, with good intentions, revert this PR unknowingly :) )
There was a problem hiding this comment.
We might want to do that broadly across Julia's code base. Grep string in #32761 (comment)
There was a problem hiding this comment.
Ah right! Would it stretch too much the meaning of @specialize to extend this macro to formalize this technique? E.g. @specialize(f), @specialize(op) in this case, even if no @nospecialize was active?
There was a problem hiding this comment.
I think it would be great if @specialize did this. I didn't even realize we had it! There's a discourse post from a while back making this exact suggestion.
Eliminates dynamic dispatch. Ref https://discourse.julialang.org/t/slow-custom-digits-iterator/31367
Eliminates dynamic dispatch for a more than 10x gain in this benchmark.