---
title: 'Low FLOPs Pitfall: Beyond FLOPs Efficiency'
url: https://www.emergentmind.com/topics/low-flops-pitfall
type: topic
---

# Low FLOPs Pitfall: Beyond FLOPs Efficiency

The "Low FLOPs Pitfall" refers to a diverse set of phenomena across numerical linear algebra, deep learning, network architecture, and system-level engineering, where minimizing floating-point operation (FLOP) counts—a widely used proxy for efficiency—fails to yield optimal or even reliable outcomes. This pitfall arises because FLOP minimization is often not aligned with true performance goals, whether that is wall-clock speed, representational capacity, energy efficiency, latency, or practical deployability in production systems.

## 1. Foundations: The Limitations of FLOP Count as a Metric

FLOP count, defined as the number of floating-point additions and multiplications, is a standard complexity proxy for computational tasks. It serves as a canonical objective in both numerical and ML workloads for operator selection, algorithm ordering, network pruning, and hardware mapping. However, large-scale studies in both classical numerical linear algebra and neural network workloads demonstrate that FLOPs is often not a sufficient or even reliable metric for real-world performance.

### Key Observations

- **In sparse Cholesky factorization**, minimizing FLOPs is distinct from minimizing fill-in even though both are structural sparsity metrics; the respective optimal orderings are provably incompatible, showing that simultaneous minimization is generally impossible [1303.1754].
- **In dense linear algebra**, empirical and statistical studies reveal that among mathematically equivalent algorithms, the minimal-FLOP variant is frequently not the fastest on real hardware; anomalies can occupy substantial regions of parameter space [2207.02070, 2209.03258].
- **In neural networks and data center systems**, minimizing FLOPs does not guarantee reduced latency or higher throughput, due to factors such as memory-bound computation regimes, operator underutilization, or architectural side-effects [2303.03667, 1801.09212].

## 2. Algorithmic Manifestations: Sparse and Dense Linear Algebra

### Sparse Cholesky and Fill–FLOPs Divergence

For a symmetric positive definite matrix $A$, the Cholesky factorization is $PAP^T = LL^T$. Two associated optimization problems arise:

- **Fill-minimization:** Minimize the number of fill-in entries introduced in $L$ not present in $A$'s sparsity pattern.
- **FLOPs-minimization:** Minimize the total scalar operations required to compute $L$.

Explicit constructions (e.g., on graphs $G(l,t,c) = C_l \vee (S_t+K_c)$) separate the minima for fill and FLOPs, establishing that optimal orderings diverge: $\alpha_1$ minimizes fill but not FLOPs, while $\alpha_2$ minimizes FLOPs but not fill. This lack of alignment is rigorous: "MinimumFill, MinimumFLOPs and Treewidth are three distinct optimization problems. In particular no single elimination ordering can simultaneously minimize both fill and FLOPs in general" [1303.1754]. Moreover, minimizing FLOPs is itself NP-hard via a reduction sequence through MaxCut and bipartite chain-completion problems.

- **Practical impact:** Widely adopted heuristics such as Approximate Minimum Degree (AMD) or METIS can differ by over 20% in FLOP count while achieving similar fill, directly affecting sparse direct solver speed and memory use.

### Dense Linear Algebra: Anomalies in FLOP-based Algorithm Selection

For matrix chain products and related expressions, high-level tools frequently pick the parenthesization with the lowest FLOP count. Yet, empirical evaluation shows:

- **Existence of anomalies:** Regions where algorithms with higher FLOP counts outperform minimum-FLOP algorithms by up to 30–40% in execution time [2207.02070, 2209.03258].
- **Root causes:** Differences in per-kernel efficiency, suboptimal cache utilization, and blocking strategies, not just FLOP totals. For instance, GEMM kernels with favorable operand shapes can achieve higher peak device FLOPS, offsetting extra arithmetic.
- **Statistical assessment:** An iterative, quantile-based comparison methodology flags anomalies when minimum-FLOP algorithms are not in the best empirical performance class, necessitating measurement-driven validation [2209.03258].

## 3. Hardware and Systems Level: When Low FLOPs Fails to Mean Fast

### Depthwise Convolution and Realized FLOPS

Reducing theoretical FLOPs by deploying depthwise or group convolutions often results in suboptimal device utilization. Observed device FLOPS (actual op/s) for depthwise convs is frequently an order of magnitude below that of standard convolution on both CPUs and GPUs, so latency remains high even with a much smaller compute footprint [2303.03667].

- **PConv Operator:** Partial Convolution (PConv) selectively applies standard convolution to a subset of channels, reducing both computation and memory access compared to depthwise convolution. This achieves higher realized throughput and lower latency in practice, as validated by FasterNet's systematic speedup over baselines at equivalent or better top-1 accuracy [2303.03667].

### Low Arithmetic Intensity in Memory-bound Workloads

In sparse matrix-vector multiplication (SpMV), frequently encountered in scientific and CFD codes, the arithmetic intensity $I$ is so low (0.1 FLOPs/byte) that performance is bounded by the memory subsystem, not the compute pipeline. Thus, further FLOPs reduction is ineffectual until $I$ is raised by hardware-locality-driven strategies such as on-chip caching, index compression, and data blocking, as realized in FPGA-optimized SpMV [2107.12371].

- **Roofline model:** The achievable performance is $P = \min(I B_\text{max}, F_\text{peak})$. Kernels with $I$ far below the "ridge point" remain bandwidth bound regardless of FLOP count reductions [2107.12371, 1801.09212].

### BOPS: Alternative Metrics for System Evaluation

Analysis of 17 datacenter workloads shows that FLOPS efficiency is typically $<0.1\%$ (i.e., nearly all compute resources are underutilized when judged by FP pipeline peak) [1801.09212]. DC workloads are dominated by data movement and integer compute. A new metric, BOPS (Basic OPerations per Second), counting both integer and FP arithmetic, memory addressing, and comparison ops, provides a more accurate and consistent proxy for datacenter code and aligns much better (bias $<10\%$) with empirical speedups. The DC-Roofline model, based on BOPS, guides optimization choices and enables system-level improvement (e.g., 4.4$\times$ gain in Sort workload).

## 4. Network Architecture: Low-FLOPs Degradation in Model Design

### Sub-20M FLOPs CNNs: Width and Depth Collapse

Aggressively reducing FLOPs in CNNs to sub-20M boundaries (for edge and mobile deployment) exposes two structural pitfalls [2011.12289, 2108.05894]:

- **Width collapse:** Shrinking channels to fit tight FLOP budgets causes catastrophic loss of per-unit connectivity; naive thinning of layers reduces the number of independent pathways between inputs and outputs, suppressing representational power.
- **Depth collapse:** Reducing the number of layers to meet constraints erodes the network's non-linear modeling capacity, as shallow stacks cannot accumulate sufficient expressivity.

MicroNet mitigates these by (1) micro-factorized convolutions—splitting both pointwise and depthwise convolutions into low-rank, group-structured operators, preserving more channels without prohibitively increasing compute—and (2) Dynamic Shift-Max activations, which inject dynamic, input-relative non-linearity after each block. Empirically, MicroNet achieves dramatic improvements: 6M FLOPs models with 53.0% top-1 vs. MobileNetV3's 6M with 41.8%; 12M model 61.1% vs 49.8% [2011.12289].

### Architecture–Pretraining Mismatch: "ParameterNet" Principle

ParameterNet identifies a distinct instance of the low-FLOPs pitfall: low-FLOP models do not benefit from large-scale pretraining, as their limited parameter capacity throttles representational gains. High-parameter architectures, enabled via sparse Mixture-of-Experts (MoE) or dynamic convolutional experts, allow low-FLOP inference while leveraging large-scale pretraining to reach performance parity with high-FLOP models (e.g., ParameterNet-600M at 0.6G FLOPs outperforms Swin-T at 4.5G FLOPs on ImageNet-22K) [2306.14525].

### Operator and Data Domain Mismatch

Efficient photo-oriented models perform poorly on sketches due to domain-specific representational demands. Depthwise and bottleneck operators intended for dense visual structure quickly collapse accuracy on sparse sketches; this is remedied by cross-modal knowledge distillation and reinforcement-learned resolution selectors, which preserve accuracy under aggressive FLOPs reduction if guided correctly [2505.23763].

## 5. Optimization Methods: Pruning, Regularization, and Equivariance

### Network Pruning: The Fidelity–FLOPs Trade-off

Pruning networks to extremely low FLOP budgets via unstructured sparsification accentuates the fidelity problem: concentrating pruning in FLOP-heavy layers reduces compute but causes catastrophic accuracy collapse [2403.07094]. The FALCON framework addresses this by formulating a joint optimization (an ILP) balancing squared-parameter retention (as local fidelity proxy) under both parameter count and FLOP constraints. Exploiting low-rank Hessians, this enables high-accuracy pruning (e.g., 67.1% top-1 on ResNet50 at 20% FLOPs, vs. 12.9% for best prior method). Best practices include multi-stage pruning (FALCON++), joint constraints, and local quadratic modeling.

### Sparse Retrieval Models: Term-Frequency–Induced Latency

Learned sparse retrieval (SPLADE) models use FLOPS regularization to control per-document sparsity, but this fails to prevent dominance of high-frequency terms, resulting in extremely long posting lists and high retrieval latencies. The DF-FLOPS variant regularizes based on document frequency, penalizing frequent token activation and achieving 10$\times$ latency reduction with negligible accuracy drop (only 2.2 points MRR@10) [2505.15070].

### Equivariant Networks: FLOPs-per-Parameter and Block-diagonalization

Weight-tying for geometric invariance (e.g., mirror symmetry) increases the effective FLOPs per parameter. "Flopping for FLOPs" resolves this by working in the irreducible representation basis of the symmetry group, block-diagonalizing all linear layers and reducing theoretical and realized FLOP count to parity with standard networks, while retaining full equivariance [2502.05169].

## 6. Practical Guidelines and Synthesis

The Low FLOPs Pitfall recurs in many forms—failure modes, design mismatches, and bottlenecks—whenever FLOP count is used uncritically as a sole optimization or selection criterion. Empirical and theoretical evidence from recent research converges on several robust lessons:

- **Do not rely on FLOPs alone:** Whenever possible, combine FLOP-based heuristics with kernel-specific performance modeling, empirical timing measurement, or data-driven discriminants [2207.02070, 2209.03258].
- **Account for hardware and memory effects:** Consider arithmetic intensity, memory bandwidth, and realized device throughput. For memory-bound kernels, prioritize methods to raise $I$; for operator selection, prefer those that achieve high effective FLOPS [2303.03667, 2107.12371].
- **Preserve model capacity and representation:** In low-FLOP network design, maintain parameter count via efficient parameterizations (e.g., dynamic conv, MoE), factorized connectivity, and strong per-layer non-linearity [2011.12289, 2108.05894, 2306.14525].
- **In pruning and regularization, jointly constrain both accuracy and resource:** Use fidelity-aware objectives (e.g., local quadratic pruning), enforce both FLOP and sparsity constraints, and explicitly penalize term/document frequency in sparse retrieval [2403.07094, 2505.15070].
- **Deploy domain-specific variants as needed:** For domain-mismatched data (e.g., sketches), supplement core models with task- or data-tailored architectural or training interventions to avoid collapse under low-FLOP constraints [2505.23763].

The continued prevalence of the low-FLOPs pitfall underscores the necessity for holistic, problem-aware metrics and optimization schemes throughout the algorithm–architecture–system stack. FLOPs remains a useful but inadequate proxy; escaping its limitations requires integrating workload characteristics, structural fidelity, and device-level constraints.

Source: https://www.emergentmind.com/topics/low-flops-pitfall