Skip to content

Handle duplicate allocation labels during replay - #53

Open
daxmawal wants to merge 4 commits into
mainfrom
fix/replay-duplicate-labels
Open

daxmawal wants to merge 4 commits into
mainfrom
fix/replay-duplicate-labels

Conversation

@daxmawal

@daxmawal daxmawal commented Sep 9, 2026

Copy link
Copy Markdown
Member

Kokkos allocations can share the same label. Previously, replay allocations and reference outputs were indexed by label, so one allocation could hide another and make output comparison unreliable. This change preserves each allocation separately and matches inputs with their reference outputs using the captured allocation pointer and memory space. The new get_allocations API exposes these pairs through ReplayAllocation descriptors. New compare_views overloads accept a descriptor and support explicit dimensions or a flat view whose size is inferred from the recorded byte count.

Label-only lookups report an error when the label is ambiguous.
Tests cover duplicate labels, reordered references, empty allocations, and comparison size validation.

P.S. I encountered this issue in a Dyablo Kokkos kernel where multiple views shared the same label.

Match input allocations and reference outputs by captured allocation pointer
and memory space. Expose allocation descriptors for unambiguous comparisons,
including flat views whose extent is inferred from the recorded byte count.

Reject ambiguous label-only lookups and cover duplicate labels, reordered
references, empty allocations, and comparison size validation.
Signed-off-by: daxmawal <jeanfrancoismanutea@gmail.com>
Comment thread src/krepe/replay/kernel_replayer.cpp Outdated
const SnapshotAllocation& snapshot) {
// The captured allocation pointer includes its Kokkos header, so empty
// allocations remain distinct even when their data pointers are null.
return std::find_if(

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I compared the current implementation with a temporary hash-index prototype. Results below are median times over 11 samples, using GCC 13 with -O3 on an Intel Core i9-13950HX.

Allocations Current implementation (µs) With index (µs)
16 0.55 1.21
64 2.53 4.67
256 18.98 19.63
1,024 242.86 108.04
4,096 4,263.91 375.43
16,384 69,257.30 1,981.76

The vector is faster for small allocation counts, while the index helps with larger captures.

Signed-off-by: daxmawal <jeanfrancoismanutea@gmail.com>
Signed-off-by: daxmawal <jeanfrancoismanutea@gmail.com>
@daxmawal
daxmawal marked this pull request as ready for review September 14, 2026 13:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant