Repository navigation
[BUG]: RadixSortKeys benchmark contains an unexpected cudaMalloc in the critical benchmark region #9132
Description
As part of #8765 I got two profiles. One on current main:
and one before we changed the benchmark to use the new tuning API (which calls straight to Device instead of the Dispatch layer as we used):
The benchmark was recently changed last in #7949. Let's check if the big cudaMalloc was introduced by accident in #7949.
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
- Status
Activity
bernhardmgruber commentedon May 28, 2026
I am on
upstream/main(d083f97) and I can only see a singlecudaMallocAsyncas part of the first call toDeviceRadixSort:Every call afterwards, does not perform an allocation.
gonidelis commentedon May 29, 2026
@bernhardmgruber does that contradict my profile? i am confused. wasn't the initial cudamalloc the problem at hand for this issue?
bernhardmgruber commentedon May 29, 2026
I would need to look at your complete profile. Did you create your profile while running the benchmark with
--profileor--run-once? Because then maybe you only see warmup runs which always include thecudaMalloc.gonidelis commentedon Jun 5, 2026
twas a false alarm
after using @oleksandr-pavlyk 's new feature of
stopping-criterion sample-countwe saw that this is the original malloc that is being called once when the first kernel invocation happens and is being used throughout all subsequent kernel invocations without further allocations happening.