You will be able to
- Design a benchmark with matched correctness and workload.
- Separate steady-state kernel time from end-to-end cost.
Correctness comes first
Compare implementations on the same shapes, dtype, layout, batch and output convention. Validate against a reference with stated absolute/relative tolerances. A faster calculation with wrong normalisation, missing work or lower precision is not an equivalent speedup. Include setup, transfers and compilation only under a declared measurement scope.
Measure the distribution
Warm up when relevant, use repeated trials and report variability and hardware/software versions. GPU launches are asynchronous: host enqueue time is not device execution time. Use suitable device events or synchronisation. Avoid selecting only the fastest trial. Reproducibility requires code, inputs, seeds, environment and a clear inclusion policy, not just a number.
Worked example
A reference takes 10 ms and a candidate 5 ms under identical scope: speedup=2. If an omitted 8 ms transfer is required by the candidate, end-to-end candidate time is 13 ms, which changes the conclusion.
A common trap
There is no site-generated GPU benchmark here; the traffic lab is a planning tool until real disclosed hardware measurements exist.
Predict, then experiment
Does lowering estimated global-memory traffic guarantee lower end-to-end latency? Before touching the controls, say or write your prediction.
Interactive experiment
Count traffic before timing it
How much data could a stage-by-stage FFT move?
Radix-2 complex FP32 model: each stage reads and writes the whole buffer once. The ideal column counts only one input read and output write. Neither is a measured runtime or a complete convolution pipeline.
Your experiment
Compare several transform sizes and batches. List one overhead the byte model omits and explain why small and large workloads may have different bottlenecks.
Change one parameter at a time. Compare what you observed with your prediction and record an explanation in your notes.
Check your understanding
Try from memory first. Hints and feedback are part of learning, not a penalty. These checks are for self-study, not a graded qualification.
Reference answers (after your attempt)
- submission overhead, not necessarily execution time — Correct: use an appropriate device timing/synchronisation method.
- 3× — 12/4=3.
Apply it: Write a reproducible benchmark protocol
Use paper, your notes, or a local notebook/editor. Code examples are Python 3 starting points to run yourself; this page does not execute code or automatically assess the practical task.
- Specify inputs, layouts, precision, versions and correctness tolerances.
- Describe warm-up, repetitions, timing and synchronisation.
- Report both scoped and end-to-end costs with limitations.
Reference solution & review criteria
A complete protocol fixes the workload, validates outputs, records hardware/software, includes repeated measurements with spread and discloses transfer/setup inclusion. Do not extrapolate one device or shape to all deployments.
Your notebook
Notes and progress stay in this browser. They are not sent to the server; ordinary web-server request logs still operate. Export a backup from the course page.
Completion requires both correct checks and your practical-task acknowledgement.
Go deeper
- Dive into Deep Learning: computational hardware
- PyTorch: CUDA asynchronous execution and timing
- Related visual essay
Sources support further study; the worked examples and questions here are original. Browser experiments are small, disclosed models—not evidence of production-model quality or hardware performance.