Scenario: Memory-Bound Kernel

Scenario

A stencil kernel scales with SM count until memory traffic rises; profiler shows high global load transactions and low L2 hit rate under realistic data sets.

OBSERVED METRIC
achieved bandwidth stays below 45% of peak on HBM GPU

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

• Quote peak HBM bandwidth without coalescing evidence

• Optimize ALU code while memory transactions dominate

• Ignore NoC and controller queue contention at scale

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.