Repository navigation
Don't allocate when building signature types on Julia 1.14 - #1025
Merged
Merged
Conversation
On Julia 1.14, signature_type_by_tt maps dispatch_key over the parameters
of the tuple type. That builds a Vector, which keeps the signature from
being folded to a constant, so every methodinstance call (i.e., every
launch of a cached kernel) allocated proportionally to the number of
arguments, regressing KernelAbstractions' POCL launch-allocation test.
Splat the parameters directly when none of them is a Type{...}, which is
also what's cheapest for a non-constant tuple type, and use a generator
otherwise, which folds just like splatting does.
Fixes #1024
Member
Author
|
CI failure unrelated, JuliaGPU/CUDA.jl#3408. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Julia 1.14,
signature_type_by_ttmapsdispatch_keyover the parameters of the tuple type. That builds aVector, so even for a constant tuple type the signature isn't folded andmethodinstanceallocates on every launch of a cached kernel, proportionally to the number of arguments. This breaks KernelAbstractions' POCL "launch with many arguments" test on nightly.This PR splats the parameters as-is when neither the callee nor any argument is a
Type{...}, the only case wheredispatch_keychanges anything. Otherwise it splats a generator, which folds just like plain splatting does.Using the generator in both cases would also fix the allocations, but for a tuple type that's only known at run time it's 2-3x slower than
map. The split version is faster thanmapthere too:methodinstanceon 1.14.0-DEVtt, 5 paramstt, 41 paramsttwith aType{Int}argumenttt, 5 paramstt, 41 paramsWith the KA reproducer on nightly, a POCL launch now allocates 96 B both with 40 arguments (528 B before) and with 4 (240 B before).
The new test fails on nightly without the fix (432 B and 240 B) and passes on 1.11 through 1.14, also with
--code-coverage=user --check-bounds=yes. It's skipped on 1.10, wheremethodinstanceis the generic lookup.Fixes #1024