The D·A·M Taxonomy

Purpose

When an ML system fails, where should you look first: the data path, the algorithm, or the machine?

In production, “it is slow” and “it is wrong” are rarely informative symptoms. A serving stack can miss its latency objective because the accelerator is idle (data starvation), because the model is doing unnecessary work (algorithmic overhead), or because the accelerator is genuinely saturated (machine-bound). Without a taxonomy, teams often optimize the wrong thing, buying faster accelerators to fix a slow input pipeline or rewriting kernels when the model is simply too large for the latency budget. This appendix provides a compact diagnostic framework, Data, Algorithm, and Machine, and shows how to map symptoms and measurements to the term of the iron law that dominates. D·A·M is the first-response checklist before committing to deeper optimization.

How to Use This Appendix

This appendix is designed as a reference. Start with the scorecard-style metrics, form a hypothesis about which axis dominates, and then pick the tool that can confirm (or falsify) that hypothesis. Conventions used here follow the book-wide notation (for example, we reserve \(B\) for batch size and use \(\text{BW}\) for bandwidth).

When training is slow, check accelerator utilization, data wait time, and Model FLOPs Utilization (MFU), then map each to its Data, Algorithm, or Machine axis. When serving misses a Service Level Objective (SLO), identify whether the regime is latency-bound (overhead), memory-bound (weight/KV movement), or compute bound. When cost is exploding, use the D·A·M rubric to ensure that effort targets the dominant term, not a nonbottleneck.

The Data · Algorithm · Machine (D·A·M) taxonomy is a primary diagnostic framework for ML systems engineering. It formalizes the interdependence between information flow, mathematical logic, and physical execution. When performance stalls or behavior degrades, the diagnostic task is to identify where the flow is blocked. This taxonomy helps practitioners form and test hypotheses about the dominant bottleneck using three interacting axes¹, while recognizing that real systems often involve boundary cases where two or more axes interact.

¹ MECE (Mutually Exclusive, Collectively Exhaustive): A classification principle from management consulting (popularized by McKinsey) requiring that categories do not overlap and together cover every possibility. D·A·M is not strictly MECE because its diagnostic axes overlap. It uses the categories as first-pass lenses, so the most useful diagnosis may name a dominant axis together with a boundary effect such as queueing, runtime overhead, or memory-bound execution.

Diagnostic Summary

The taxonomy maps directly to the iron law of ML systems established in Iron Law of ML Systems. Table 1 summarizes the role, primary physical constraint, and core optimization pathway for each axis.

Table 1: D·A·M Axis Reference: Each axis maps to a constraint class and optimization strategy. Form a hypothesis, confirm it with measurements, then follow the chapter pointer.

Axis	Role	Physical Constraint	High-Leverage Optimization
Data (D)	Information (The Fuel)	Volume, quality, arrival rate	Data Selection (Data Selection)
Algorithm (A)	Logic (The Blueprint)	Operations and dependencies	Model Compression (Model Compression)
Machine (M)	Physics (The Engine)	Compute, memory, I/O	Hardware Acceleration (Hardware Acceleration)

This first-pass separation is useful, but production systems rarely suffer from a single axis-centered bottleneck. More often, the problem sits at the boundary between two axes—a data format choice that determines whether the GPU can be saturated, or a pruning strategy that changes the memory access pattern. To handle these cases, we need to map the intersections.

Intersection Landscape

Real systems engineering lives at the boundaries between axes. Figure 1 maps the intersection landscape: what concepts and techniques emerge when two or three axes overlap.

Table 2 provides a scannable reference for each zone.

Table 2: D·A·M Intersection Reference: Each zone maps specific techniques to the axes they span and the chapters that cover them. The pairwise intersections require reasoning about two domains simultaneously; the center requires all three.

Zone	Name	Key Techniques	Book Coverage
Data	Information	Storage formats, data quality, distributions	Data Engineering
Algorithm	Logic	Loss functions, architectures, gradients	Neural Computation, Network Architectures
Data \(\cap\) Algorithm	What to Learn From	Data selection, curriculum learning, compute-optimal scaling	Data Selection, Model Training
Data \(\cap\) Machine	How to Move Information	I/O bandwidth, prefetching, data formats	Data Engineering, Hardware Acceleration
Algorithm \(\cap\) Machine	How to Execute Efficiently	Quantization, pruning, kernel fusion, mixed precision	ML Frameworks, Model Compression
Machine	Physics	Silicon, memory hierarchy, peak FLOP/s	Hardware Acceleration
Data \(\cap\) Algorithm \(\cap\) Machine	ML Systems Engineering	Iron law, Roofline, training loops, serving	Model Training, Model Serving, Benchmarking

In the D·A·M acronym, Data, Algorithm, and Machine are taxonomy axes. They are not mathematical variables; formal quantities still follow the notation chapter, where \(D\) denotes dataset size or training tokens.

The axis-centered zones contain concepts that belong primarily to one axis: storage formats and distributions emphasize Data, loss functions and gradients emphasize Algorithm, and silicon physics and peak FLOP/s emphasize Machine. Single-domain expertise can introduce them, but deployed behavior may still depend on the other axes.

The pairwise intersections are where systems thinking begins. \(\mathsf{Data} \cap \mathsf{Algorithm}\) (What to Learn From) encompasses data selection, curriculum learning, active learning, and scaling laws like Chinchilla (\(D \approx 20P\) for the dense autoregressive language-model regime studied)—all requiring joint reasoning about information content and algorithmic capacity. Adding data without considering whether the model can learn from it wastes compute; choosing architectures without considering data availability wastes engineering time. \(\mathsf{Data} \cap \mathsf{Machine}\) (How to Move Information) covers I/O bandwidth, prefetching strategies, data formats, and the energy-movement invariant. This intersection is where data gravity manifests: the physical cost of moving bytes through the memory hierarchy determines whether the machine can be fed fast enough. \(\mathsf{Algorithm} \cap \mathsf{Machine}\) (How to Execute Efficiently) spans quantization, pruning, kernel fusion, mixed precision, and computational graph optimization. A pruning strategy that reduces FLOPs but destroys memory access patterns can slow down execution on real hardware.

The center—\(\mathsf{Data} \cap \mathsf{Algorithm} \cap \mathsf{Machine}\)—is where all three axes converge. The iron law, the Roofline Model, end-to-end training loops, serving pipelines, and holistic benchmarking all require simultaneous reasoning about data flow, algorithmic complexity, and hardware utilization. This center is not a single technique; it is the discipline itself.

Understanding the landscape reveals where a technique lives. The next step is quantifying which axis dominates for a given workload—and for that, we need the iron law.

Iron Law Mapping

The performance of any ML task is governed by the distribution of work across the D·A·M axes. The iron law mapping reveals which component’s variables dominate the execution time: \[ T = \underbrace{ \frac{D_{\text{vol}}}{\text{BW}} }_{\text{Data/Machine}} + \underbrace{ \frac{O}{R_{\text{peak}} \cdot \eta_{\text{hw}}} }_{\text{Algorithm/Machine}} + \underbrace{ L_{\text{lat}} }_{\text{Cross-axis overhead}} \]

Algorithm and Machine share the compute term, separated by which variable the engineer controls. Reducing the total operations (\(O\)) is an Algorithm lever, while improving the hardware’s peak throughput (\(R_{\text{peak}}\)) or utilization (\(\eta_{\text{hw}}\)) is a Machine lever.

This equation transforms performance debugging from a qualitative guessing game into a quantitative engineering problem. The dominant measured cost appears in one of these terms. A slow system may move too much data (\(D_{\text{vol}}\)), lack bandwidth (\(\text{BW}\)), execute too many operations (\(O\)), fail to use the hardware’s peak capability (\(\eta_{\text{hw}}\)), or pay cross-axis overhead (\(L_{\text{lat}}\)). The levers below map specific optimizations to the variables they improve.

Component levers

Data Lever: Reducing moved bytes (\(D_{\text{vol}}\)) through deduplication, selection, or lower-precision representation, or increasing I/O bandwidth (\(\text{BW}\)).
Algorithm Lever: Reducing operations (\(O\)) through pruning or architectural refinement. Quantization narrows representation and may raise hardware throughput; it does not generally reduce operation count.
Machine Lever: Increasing the denominator of the compute term by improving peak throughput (\(R_{\text{peak}}\)) or increasing the utilization factor (\(\eta_{\text{hw}}\)) via kernel fusion.

D·A·M coordination: From sum to max

The additive iron law represents sequential execution. Overlap can move the sum toward a max, but dependencies, contention, and incomplete overlap keep measured time above this ideal lower bound: \[ T_{\text{sequential}} = \frac{D_{\text{vol}}}{\text{BW}} + \frac{O}{R_{\text{peak}} \cdot \eta_{\text{hw}}} + L_{\text{lat}} \quad \xrightarrow{\text{overlap}} \quad T_{\text{pipelined}} \geq \max\left(\frac{D_{\text{vol}}}{\text{BW}}, \frac{O}{R_{\text{peak}} \cdot \eta_{\text{hw}}}\right) + L_{\text{lat}} \]

The systems engineer’s job is to make these components run in parallel, not in series. Table 3 summarizes key D·A·M Coordination techniques:

Table 3: D·A·M Overlap Techniques: Each technique overlaps work across axes, moving part of \(T = a + b\) toward the ideal lower bound \(T = \max(a, b)\). Dependencies and contention limit realized overlap.

Technique	D·A·M Axes Overlapped	Implementation
Prefetching	D overlaps M	DataLoader with `prefetch_factor`, `pin_memory=True`
CUDA Streams	D overlaps M	Separate streams for H2D transfer and compute
Async Gradient Sync	M (communication) overlaps A	Overlap bucketed AllReduce with remaining backward computation
Double Buffering	D overlaps M	Fill buffer N+1 while computing on buffer N

Overlap only helps when the D·A·M axes are reasonably balanced. If one term dominates (for example, severely memory bound), overlapping the smaller term with the larger yields negligible gain—the max is still dominated by the same bottleneck. Overlap provides the greatest benefit when \(D_{\text{vol}}/\text{BW} \approx O/(R_{\text{peak}} \cdot \eta_{\text{hw}})\). The latency term is the important exception.

Systems Perspective 1.1: The overhead that cannot hide

The unhidden latency term \(L_{\text{lat}}\) (kernel launch, synchronization barriers, Python dispatch) contains serialization points that cannot be fully overlapped. Kernel fusion can reduce this term by combining operations, but it does not eliminate all launch, scheduling, or synchronization overhead.

The iron law tells the engineer how much time each axis consumes. One critical question remains: when the bottleneck sits at the boundary between Data and Machine, which side is binding? The answer lies in a single ratio.

Arithmetic Intensity Boundary

The boundary between Data (memory bound) and Machine (compute bound) is not arbitrary; it is defined mathematically by arithmetic intensity² (\(I\)) of the workload.

² Arithmetic Intensity: This book uses the term for floating-point operations per byte transferred. Williams et al. (2009) calls the measured DRAM quantity operational intensity in the Roofline Model. Comparing the workload ratio with the hardware ridge point (\(R_{\text{peak}}/\text{BW}\)) gives an upper-bound diagnosis of memory- versus compute-bound execution.

Williams, Samuel, Andrew Waterman, and David Patterson. 2009. “Roofline: An Insightful Visual Performance Model for Multicore Architectures.” Communications of the ACM 52 (4): 65–76. https://doi.org/10.1145/1498765.1498785.

The roofline model provides rigorous definitions of arithmetic intensity and the roofline model. Use that model to quantitatively distinguish between Data and Machine bottlenecks before applying the optimizations below.

The Roofline Model provides an upper performance bound when traffic and achieved rates are measured consistently. In the middle of a production incident, faster screening heuristics can point to the measurements to collect next.

Rules of Thumb

In the heat of a production outage, there is rarely time to solve the full iron law equation. Veteran systems engineers instead rely on quantitative heuristics to quickly narrow the search space; the thresholds below are screening signals that should be checked against profiler traces and hardware counters.

Low accelerator utilization (\(<\) 80 percent): Screen for data, CPU, or launch starvation. Confirm with input-pipeline wait, host CPU saturation, memory-bandwidth counters, and trace gaps.
High accelerator utilization (\(>\) 95 percent): Treat this as machine bound only if compute units are busy and memory bandwidth is not saturated. If memory bandwidth is saturated, the bottleneck is still on the Data/Machine boundary.
If batch size is one: Treat this as a warning that latency or launch overhead may matter; confirm with traces before labeling the algorithm itself the bottleneck.
Low arithmetic intensity (below the hardware ridge point): The workload is likely memory bound (Data/Machine boundary). A 100 FLOP/byte threshold is only a mnemonic for quick current-generation checks; the precise boundary is \(R_{\text{peak}}/\text{BW}\) and depends on hardware and precision.
If the system works in dev but fails in prod: Treat data drift as one hypothesis alongside configuration, load, dependency, and runtime differences.

Common industry labels cross the axes. Memory-bound execution sits on the Data/Machine boundary because both bytes moved and available bandwidth matter. Compute-bound execution couples Algorithm work with Machine throughput. Latency-bound execution may reflect algorithmic serial depth, runtime dispatch, synchronization, or queueing.

Bottleneck diagnostic

Once the bottleneck is identified, table 4 shows which optimizations help and which ones are wasted:

Table 4: What Works vs. What Is Wasted: Optimizing a nonbinding term yields little or no end-to-end improvement. A memory-bound large language model will not benefit from additional peak FLOP/s alone, though an accelerator with more memory bandwidth may help.

If the workload is…	Dominant Term	Optimization That Works	Optimization That is Wasted
Memory-Bound	\(D_{\text{vol}}/\text{BW}\)	Quantization, pruning, batching, kernel fusion	Faster accelerator (more FLOP/s will not help)
Compute-Bound	\(O/(R_{\text{peak}} \cdot \eta_{\text{hw}})\)	Better kernels, Tensor Cores, faster accelerator, lower precision	More memory bandwidth (not the binding term)
Latency-Bound	\(L_{\text{lat}}\)	Reduce serial depth; fuse or dispatch asynchronously; batch within budget	More compute or bandwidth unless the trace shows it binding

Knowing what works also means recognizing what does not. In practice, teams under deadline pressure repeatedly fall into the same traps—optimizing the wrong axis with confidence. These failure modes are common enough to deserve their own names.

Anti-Patterns

Diagnosing systems is often a process of elimination. Before committing to complex kernel optimizations, watch for these common traps that waste engineering cycles.

The hardware crutch: Buying faster accelerators (Machine) to fix a slow Python data loader (Data). The new hardware will just idle faster.
The model twiddle: Changing neural architectures (Algorithm) when the bottleneck is actually network bandwidth or disk I/O.
The premature optimizer: Writing custom CUDA kernels (Machine) before verifying if the Algorithm is simply doing too many unnecessary operations.

Each anti-pattern follows the same root cause: acting before diagnosing. The following case studies show what proper diagnosis looks like—starting from a confusing symptom and systematically narrowing to the dominant D·A·M axis.

D·A·M Case Studies

Theoretical constraints often manifest as confusing symptoms in production. These representative scenarios illustrate how to apply the taxonomy. Each case follows the same three diagnostic moves: symptom, diagnosis, and fix.

Case 1: The starving accelerator (Data)

A team provisions a large A100 GPU instance to speed up training, but training time hardly improves and nvidia-smi shows GPU utilization fluctuating between 10 percent and 40 percent. The pattern suggests accelerator starvation but does not identify its cause. If traces show input-wait gaps with storage or CPU decoding saturation, the data path is binding. The useful intervention is then upstream of the model. Optimize the extract, transform, load (ETL) path by moving from raw JPEGs with heavy CPU decoding to sequential formats such as TFRecords or WebDataset, increasing data-loader parallelism, and prefetching batches into accelerator memory.

Case 2: The latency cliff (Algorithm)

A real-time recommendation service fails to meet a 20 ms latency service-level agreement (SLA), while accelerator utilization is low and the batch size is one. That combination suggests launch overhead, memory traffic, or serial model depth rather than a saturated chip. If a trace confirms that the sequential layer path dominates, adding more hardware will not remove it, so pruning or knowledge distillation can reduce model work. If weight traffic dominates instead, quantization can reduce moved bytes by using INT8 where accuracy allows. The measurements select the remedy.

Case 3: The compute wall (Machine)

Accelerator utilization is pinned at 99 percent, memory bandwidth remains unsaturated, and training is stable but takes three weeks. If profiler counters also show high compute-pipeline occupancy and MFU, the workload is compute bound. The data path is keeping the accelerator fed, so the next step must change the compute term in the iron law. The team can scale up from an A100 to an H100-class accelerator, scale out through data parallelism, or lower precision from FP32/TF32 to BF16 where numerically safe. On NVIDIA Tensor Core paths, BF16 peak throughput is typically about 2\(\times\) TF32 peak, with realized speedup depending on kernels and bottlenecks.

Taken together, the three cases show why the same utilization number can imply different next steps depending on loss behavior, batch size, and memory pressure.

Checkpoint 1.1: D·A·M diagnosis check

A training job shows 95 percent accelerator utilization but loss has plateaued for two epochs. Which D·A·M axis should you investigate, and why?
Your colleague suggests adding more data loader workers to a job where nvidia-smi shows 98 percent GPU utilization. Using the iron law, explain why this will not help.
An inference server meets its latency SLO at batch size 1 but fails at batch size 16. Which term in the iron law changed, and what does this tell you about the bottleneck regime?

These three cases illustrate clean, single-axis bottlenecks. Production incidents are rarely so tidy—symptoms often overlap, and the dominant axis can shift during debugging. The next section provides a systematic troubleshooting matrix for the messier scenarios encountered in practice.

Production Troubleshooting

Identifying the root cause of performance bottlenecks requires systematic elimination. Table 5 provides a diagnostic matrix for common failure modes observed in production deployments.

Table 5: D·A·M Diagnostic Matrix: First hypotheses and measurements for common failures. Confirm the binding component before intervening.

Symptom	Hypothesis	Confirm With	Act After Confirmation
Low Accelerator Utilization	Data/host starvation	Trace gaps; loader, CPU, storage, launch counters	Prefetch, parallelize, or cut launches.
High Latency (P99)	Algorithm/runtime/queue	Phase p99 and queue depth	Optimize the dominant phase.
High Training Cost	Low useful-work efficiency	MFU, communication, idle time	Reduce the largest loss or resize.
Silent Accuracy Drift	Data distribution change	\(P_t\) versus \(P_0\) plus delayed labels	Retrain or update filters.
Out-of-Memory (OOM)	Algorithm/Machine fit	Peak weights, states, activations	Checkpoint, shard, quantize, or shrink batch.

The diagnostic matrix indicates what to suspect. The next question is how to confirm that suspicion with evidence—which requires the right profiling tools.

Tooling Map

Once a hypothesis exists (for example, “the workload appears Machine-bound”), evidence is needed to confirm it. Abstract concepts must be measured with concrete utilities. Table 6 connects the theoretical components to the specific Linux and Python profiling tools that confirm them.

Table 6: D·A·M Tooling Map: Profiling utilities for diagnosing bottlenecks along each D·A·M axis. Start with the primary tool for quick triage; use secondary tools for deep-dive analysis when the primary tool’s output is inconclusive.

Axis	Key Metric	Primary Tool	Secondary Tool
Data	Batch Load and Wait Time	Framework profiler trace	`iostat`, `pidstat` (I/O/CPU)
Algorithm	FLOPs, Model Depth	PyTorch Profiler	DeepSpeed Flops Profiler
Machine	Accelerator Utilization, SM Occupancy	Nsight Compute	`nvidia-smi`, Nsight Systems

Profiling tools generate raw numbers—utilization percentages, FLOP counts, and bandwidth measurements. They become actionable only in workload and hardware context. The D·A·M Scorecard provides screening signals rather than universal standards, narrowing which measurements and interventions deserve attention.

D·A·M Scorecard

To move beyond qualitative guessing, the efficiency indicators in table 7 help decide what to investigate next. This report-card view aids the first comparison, but no row provides a universal grade. MFU³ is especially useful for large-model training.

³ MFU (Model FLOPs Utilization): The ratio of achieved model FLOP/s to the hardware’s theoretical peak FLOP/s, introduced in the PaLM paper (Chowdhery et al. 2022). Unlike raw accelerator utilization (which counts any work the accelerator performs), MFU measures model computation rate relative to peak hardware throughput, so non-model work and system overhead are not counted as achieved model FLOPs. Benchmarking covers MFU in depth.

Chowdhery, Aakanksha, Sharan Narang, Jacob Devlin, Maarten Bosma, Gaurav Mishra, Adam Roberts, Paul Barham, et al. 2022. “PaLM: Scaling Language Modeling with Pathways.” arXiv Preprint arXiv:2204.02311.

Table 7: D·A·M Screening Indicators: Context-dependent signals for investigation, not universal grades.

Axis	Metric	Definition	Investigate	Strong Signal
Data	I/O Overhead	\(\dfrac{\text{Data Wait Time}}{\text{Total Step Time}}\)	\(>\) 10% (screen)	\(<\) 1% (strong)
Algorithm	Avoidable Work	Profiler or ablation finds redundant operations	Redundant work found	End-to-end work falls
Machine	MFU	\(\dfrac{\text{Achieved model FLOP/s}}{\text{Peak FLOP/s}}\)	\(<\) 30% (large models)	\(>\) 50% (same regime)

The Scorecard and the Roofline Model both answer efficiency questions, but at different scales. The Scorecard screens the current system using context-dependent indicators. Scaling laws and the information-roofline metaphor ask what may happen as the system scales beyond its current size.

Scaling Laws vs. Roofline

Systems engineering requires distinguishing between growth trajectories and fundamental limits.

Scaling laws (the journey)

Scaling laws⁴ are empirical power laws that predict how held-out loss changes as resources increase within the fitted regime. Two landmark results are Kaplan Scaling (Kaplan et al. 2020), which studied loss against parameter count (\(P\)), data (\(D\)), and total operations (\(O\)), and Chinchilla Scaling (Hoffmann et al. 2022), which estimated a compute-optimal balance for the dense autoregressive language-model regime studied, often summarized as roughly 20 training tokens per parameter (\(D \approx 20P\)).

⁴ Scaling Laws: Empirical relationships, typically power laws with a fitted negative exponent, that predict model loss as a function of dataset size, parameter count, or compute budget. Kaplan et al. (2020) studied these relationships for neural language models at OpenAI; Hoffmann et al. (2022) later estimated the compute-optimal training trade-off for its studied dense language-model regime. Model Training discusses scaling laws in detail.

Kaplan, J., S. McCandlish, T. Henighan, T. B. Brown, B. Chess, R. Child, S. Gray, A. Radford, J. Wu, and D. Amodei. 2020. “Scaling Laws for Neural Language Models.” ArXiv Preprint abs/2001.08361.

Hoffmann, Jordan, Sebastian Borgeaud, Arthur Mensch, Elena Buchatskaya, Trevor Cai, Eliza Rutherford, Diego de Las Casas, et al. 2022. “Training Compute-Optimal Large Language Models.” Advances in Neural Information Processing Systems 35 35: 30016–30. https://doi.org/10.52202/068431-2176.

As economic guides, these fits estimate how held-out loss changes with compute inside the observed regime. They do not guarantee a task error-rate reduction or extrapolate unchanged across architectures and data distributions.

Information roofline (the destination)

The information roofline is used here as a diagnostic metaphor rather than a standard quantitative law. Its destination image points to limits on what can be learned from the available data. For classification under a fixed data distribution and loss, the Bayes Error Rate⁵ is an irreducible error floor, not a ceiling. Noise, label ambiguity, coverage gaps, and distribution shift can create data-quality limits, but they do not define one universal slope or breakpoint.

⁵ Bayes Error Rate: The lowest achievable error rate for any classifier on a given data distribution, determined by the overlap between class-conditional distributions (Goodfellow et al. 2016). Named after Thomas Bayes (1701–1761). No amount of data, parameters, or compute can reduce error below this theoretical floor.

Goodfellow, Ian, Yoshua Bengio, and Aaron Courville. 2016. Deep Learning. MIT Press.

The diagnostic lesson is narrower. Scaling laws describe a fitted improvement trajectory, while the information-roofline metaphor prompts a search for data-quality limits. If a loss curve flattens relative to the fitted trend, investigate optimization, capacity, evaluation noise, and data quality; flattening alone does not identify which cause dominates. The Bayes floor describes the best achievable classifier for the specified distribution. Adding accelerators or parameters is futile only after measurements establish that data quality is binding. Whether debugging a training step, evaluating hardware utilization, or planning a scaling campaign, measure which axis is binding before choosing a lever.

Summary

The D·A·M taxonomy provides a systematic framework for diagnosing ML systems bottlenecks. Each axis highlights a primary class of constraints rather than a distinct physical bucket. Data volume meets machine bandwidth, algorithmic work meets realized throughput, and runtime overhead can cross all three. The iron law quantifies these interacting terms. Use arithmetic intensity to investigate the Data/Machine boundary and the scorecard as a context-dependent screen. In practice, this sequence turns diagnosis into a short set of first questions.

Key Takeaways: Where to look first

Start with three interacting lenses: Data, Algorithm, and Machine narrow the search, while boundary effects and runtime overhead may span them.
Profile arithmetic intensity before optimizing: Comparing intensity with the hardware ridge point helps distinguish memory- from compute-bound regimes.
Diagnose the binding term first: Optimizing a nonbinding term yields little or no end-to-end improvement.
Use the scorecard as a screen: Interpret I/O overhead, avoidable work, and MFU against the workload and hardware rather than universal pass/fail thresholds.