Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • Architecture Metrics Reference
  • Workload Taxonomy for Architects
  • Architecture Glossary
  • Computer Architecture Cheatsheet
  • Pipeline Fundamentals14
  • Memory Hierarchy15
  • NoC and Interconnect Architecture6
  • Coherency and Memory Ordering9
  • Performance Analysis9
  • Accelerator Architectures6
  • SoC Architecture Tradeoffs9
  • Architecture Interview Prep14
    • Interview Method and Worked Scenarios
    • Architecture Interview Q&A Bank
      • Pipeline and Out-of-Order Questions
      • Caches and Virtual Memory Questions
      • Interconnect Fabric Questions
      • Coherence and Ordering Questions
      • Performance Method Questions
      • Accelerator Questions
      • System Tradeoff Questions
      • Behaviour and Method Questions
Loading lesson

‹Architecture Interview Q&A Bank
  1. Topics
  2. Computer Architecture
  3. Architecture Interview Prep
  4. Architecture Interview Q&A Bank
  5. Performance Method Questions

Computer Architecture · All levels

Performance Method Questions

Counters, bottlenecks, roofline, Amdahl and tuning guardrail questions with worked speedups.

On this page

    Counters you can trust

    A trustworthy counter has stable semantics, a validated collection path and repeatable correlation with traces. Unchecked overflow, aliasing or window bias turns data into noise.

    The first action on a sudden drop is freezing the workload and runtime envelope. Only then do counter and trace deltas against the last known-good run mean anything.

    Check yourself What makes a performance counter trustworthy for decisions?

    Stable event semantics, a validated collection path, and repeatable agreement with independent traces. Counters that cannot be explained on a timeline are not evidence.

    Check yourself Throughput dropped suddenly. What is the first action?

    Freeze workload revision, firmware, clocks and thermal state, then diff counters and traces against the last known-good run. Changing knobs before alignment destroys the baseline.

    Check yourself Why is tail latency essential in tuning?

    Averages hide queueing and interference that high-percentile latency exposes. A design that passes on means can still fail every deadline.

    Check yourself Why can IPC mislead as a headline metric?

    Equal IPC can hide very different stall mixes and resource stress. IPC without a stall breakdown cannot distinguish a healthy core from a balanced bottleneck.

    Bottlenecks and queues

    Primary and secondary bottlenecks separate through falsification. Relieve the suspected limiter in a model or experiment and watch global throughput, not local utilization.

    Queues reveal the true cap through depth, service rate and backpressure timing together. Occupancy without service rate cannot distinguish a busy stage from a blocked one.

    Bound symptom

    Confirming evidence

    Wrong fix

    Frontend stalls dominate

    Fetch bandwidth and MPKI flat while decode starves

    Wider issue width

    Backend stalls dominate

    Full queues with slow service rate

    Larger reorder buffer alone

    Memory stalls dominate

    MPKI times penalty matches the CPI gap

    Higher core frequency

    Check yourself How do you separate primary from secondary bottlenecks?

    Constrain or relieve one candidate at a time and measure global impact. The primary limiter is the one whose relief moves end-to-end throughput, not the block with the highest local utilization.

    Check yourself The roofline says memory-bound. What is the fix?

    Raise arithmetic intensity through locality and tiling, cut bytes through compression or layout, add usable bandwidth, or prefetch accurately. Wider issue width cannot feed a starved core.

    Check yourself A PMU shows an L3 miss storm. What is the action?

    Profile working set against capacity, check page allocation and sharing for false patterns, then consider partitioning or policy change. Blindly growing L3 repeats the capacity reflex.

    Diagram
    Little law queue cover from stated parameters
    formula:  outstanding = throughput x latency
    example:  2 instructions retired per cycle, 90-cycle average DRAM latency
    result:   2 x 90 = 180 concurrent misses needed to hide the latency

    Roofline and Amdahl without self-deception

    Roofline bounds performance by the lower of peak compute and bandwidth times intensity. Using nameplate bandwidth or assumed intensity turns the model into decoration.

    Amdahl bounds whole-program speedup by the unenhanced fraction. A large local win on a small fraction stays a small global win.

    Check yourself When does roofline analysis mislead teams?

    When it plugs peak nameplate bandwidth or assumed intensity instead of measured production behavior. A slide-level roofline with ideal inputs is not signoff proof.

    Check yourself How do hierarchy effects show up in roofline placement?

    Kernels move between bandwidth ceilings as locality changes across cache, SRAM and DRAM levels. One flat bandwidth number merges levels that behave differently.

    Diagram
    Amdahl speedup from stated parameters
    formula:  S = 1 / ((1 - f) + f / k)
    example:  fraction enhanced f = 0.6, enhancement k = 3
    result:   1 / (0.4 + 0.2) = 1 / 0.6 = 1.67 times whole-program speedup
    Diagram
    Roofline bound from stated parameters
    formula:  attainable = min(peak_compute, bandwidth x intensity)
    example:  peak = 2000 GFLOP/s, bandwidth = 800 GB/s, intensity = 2 FLOP per byte
    result:   min(2000, 800 x 2) = min(2000, 1600) = 1600 GFLOP/s, memory-bound

    The model below checks the roofline minimum against hand calculation. It is an arithmetic check, not a hardware model.

    roofline_model.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    module roofline_model (
      input  logic [31:0] peak,
      input  logic [31:0] bw,
      input  logic [31:0] intensity,
      output logic [31:0] attainable
    );
      always_comb attainable = (bw * intensity < peak) ? (bw * intensity) : peak;
    endmodule
    
    module tb_roofline;
      logic [31:0] peak;
      logic [31:0] bw;
      logic [31:0] intensity;
      logic [31:0] attainable;
      roofline_model dut (.*);
      int bad = 0;
      initial begin
        peak = 2000; bw = 800; intensity = 2; #1;
        if (attainable != 1600) bad++;
        peak = 2000; bw = 800; intensity = 5; #1;
        if (attainable != 2000) bad++;
        if (bad == 0) $display("PASS: roofline gives 1600 and 2000 GFLOPS for the two hand cases");
        else $display("FAIL: %0d checks wrong", bad);
        $finish;
      end
    endmodule

    Tuning that ships

    Common pitfall

    Shipping a lab-only tuning tweak without holdout workloads, duration coverage and rollback triggers converts one benchmark win into production risk. Every tuning change carries a regression surface.

    Interview

    Likely probes: falsification discipline and guardrailed rollout.

    • One limiter relieved at a time, judged by global throughput.

    • Holdout workloads plus long runs before rollout.

    • Expected gain, regression surface and rollback trigger written down first.

    Check yourself What keeps tuning decisions senior-level?

    A written record of expected gain, regression surface, rollout guardrails and rollback triggers before enabling the change. Lab scores alone are junior evidence.

    Check yourself Post-silicon performance misses the model. What do you check?

    Workload differences, thermal throttling, binning, PMU setup and trace alignment. Blaming RTL before the measurement chain is validated wastes the bring-up.

    Related topics

    • Performance method

    • Roofline and tuning

    • Memory bandwidth and latency

    Previous

    83 / 86

    Next: Accelerator Questions

    Up next

    Up nextAccelerator Questions

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Pipeline and Out-of-Order Questions
    • Caches and Virtual Memory Questions
    • Interconnect Fabric Questions