Scenario: Occupancy Mystery

Scenario

A team increases block size to raise occupancy, but real throughput drops. Registers per thread and shared-memory pressure changed after a compiler update.

OBSERVED METRIC
kernel latency regresses despite higher theoretical occupancy

45-MINUTE INTERVIEW FLOW
0-5: scope workload and KPI
5-15: map SIMT/memory/scheduler mechanism
15-25: isolate first failing evidence
25-35: propose bounded fix with owner
35-45: state validation matrix + rollback

Common pitfalls

• Assume occupancy alone predicts performance

• Ignore register spilling and memory replay counters

• Skip instruction mix and dependency stall analysis

Scenario debrief

Score candidate response on workload framing, bottleneck proof, mitigation choice, and regression discipline.

kernel intent -> hardware execution -> measured outcome

throughput trend

Debrief prompts

1. Which resource bottleneck appears first in evidence?

2. What hardware or software lever changes the bottleneck?

3. What reproducible benchmark gate proves closure?

Key takeaways

• Always pair micro-kernel metrics with end-to-end workload impact.

• Lock toolchain, driver, and launch metadata before comparing performance results.

Common pitfalls

• Optimizing occupancy without checking memory-system saturation.

• Comparing profiler captures from different driver or compiler builds.

• Declaring wins without reproducible accuracy and performance gates.