Low Level Optimization FAQ & Answers

Follow this 8-step memory alignment optimization process: 1) Identify alignment requirements - SSE needs 16-byte, AVX needs 32-byte, AVX-512 needs 64-byte alignment; cache lines are 64 bytes. 2) Check current alignment - use (uintptr_t)ptr % alignment or assert((uintptr_t)ptr & (alignment-1) == 0). 3) For stack variables: use alignas(N) specifier in C++11+ or attribute((aligned(N))). 4) For heap allocations: use aligned_alloc(alignment, size), _mm_malloc(size, alignment), or posix_memalign(). 5) For structure members: use alignas() or pack/align pragmas; be aware of padding impact on size. 6) Verify SIMD load/store instructions: use aligned loads (_mm256_load_ps) when alignment guaranteed, unaligned (_mm256_loadu_ps) otherwise. 7) Measure performance difference - on modern CPUs (Haswell+), unaligned access penalty is small UNLESS crossing cache line boundary; crossing penalty is significant. 8) Consider cache line alignment for hot data - align frequently accessed data to 64-byte boundaries to avoid split loads and false sharing. Trade-off: over-alignment wastes memory; align only what's performance-critical.

Follow this 10-step allocation optimization process: 1) Profile allocations - use heap profiler (Massif, Heaptrack) to count allocations and measure overhead. 2) Identify hot allocators - find code paths with most frequent allocations. 3) Calculate allocation cost - typical malloc: 50-200 cycles; for small allocations, overhead dominates. 4) Consider object pooling - pre-allocate pool of objects, reuse instead of alloc/free. 5) Use arena allocators - allocate from contiguous region, free all at once; excellent for phase-based work. 6) Enable small block optimizers - jemalloc, tcmalloc have optimized small allocation paths. 7) Use stack allocation - alloca or VLAs for temporary, known-bounded data (be careful of stack overflow). 8) Batch allocations - allocate array of N objects instead of N separate allocations. 9) Consider custom allocators - for specific size classes, slab allocators eliminate fragmentation and overhead. 10) Reduce allocation count - reuse buffers, use string_view instead of string copies, pass by reference. Measure: profile allocation rate (per second) and total overhead; target <5% of CPU time on allocations.

Follow this 12-point production monitoring checklist: 1) Define SLOs - establish latency percentiles (p50, p95, p99), throughput targets, error budgets. 2) Instrument code - add timing for critical paths, use low-overhead methods (RDTSC-based). 3) Sample, don't trace everything - 1-10% sampling rate sufficient for trends, avoids overhead. 4) Monitor system metrics - CPU utilization, memory usage, cache hit rates, context switches. 5) Set up alerting - alert when metrics approach SLO boundaries, not when violated. 6) Create dashboards - visualize key metrics over time, correlate with deployments. 7) Establish baselines - record normal performance ranges for comparison. 8) Enable on-demand profiling - mechanism to capture detailed profiles when issues detected. 9) Log slow requests - capture details of requests exceeding latency thresholds. 10) Track performance per version - correlate performance changes with code changes. 11) Monitor resource costs - track CPU-time, memory-hours, cost per request. 12) Regular performance reviews - periodic analysis of trends, capacity planning. Tools: Prometheus+Grafana for metrics, Jaeger/Zipkin for tracing, continuous profiling services (Parca, Pyroscope).

Follow this 12-point cloud optimization checklist: 1) Minimize cold start - for serverless: reduce package size, lazy load dependencies, use provisioned concurrency. 2) Optimize for spot/preemptible instances - checkpoint state, handle termination gracefully. 3) Right-size instances - profile to choose appropriate CPU/memory; oversized wastes money, undersized hurts performance. 4) Use appropriate storage tier - SSD for IOPS, HDD for throughput, object storage for large files. 5) Optimize network architecture - minimize cross-AZ traffic, use private endpoints, consider edge locations. 6) Implement connection pooling - database connections are expensive; reuse across invocations. 7) Cache aggressively - use Redis/Memcached for hot data; CDN for static content. 8) Batch operations - reduce round-trips to managed services which often have high per-request latency. 9) Monitor costs alongside performance - cloud bills can surprise; optimize for cost-performance ratio. 10) Use autoscaling effectively - set appropriate thresholds; don't scale on minor fluctuations. 11) Consider reserved capacity - committed use discounts for predictable workloads. 12) Profile regularly - cloud environment changes; re-profile after updates.

Follow this 10-step linked structure optimization process: 1) Profile access patterns - identify traversal patterns, random vs sequential access frequency. 2) Measure cache misses - linked structures typically have poor locality; quantify the cost. 3) Consider unrolled variants - unrolled linked lists store multiple elements per node, improving locality. 4) Pool allocations - allocate nodes from contiguous memory pool to improve spatial locality. 5) Prefetch next nodes - during traversal, prefetch next pointer's target: prefetch(node->next). 6) Consider cache-oblivious layouts - Van Emde Boas layout for trees improves cache efficiency. 7) Evaluate array-based alternatives - many linked structures can be replaced with arrays + indices. 8) Use flat storage for small structures - for trees with <1000 nodes, array-based often faster than pointer-based. 9) Pack related data - ensure frequently accessed fields are in same cache line as link pointers. 10) Consider converting to array on access - if structure is built once and traversed many times, copy to array for traversal. Key insight: modern CPUs heavily favor arrays due to prefetching; linked structures should be a last resort for performance-critical code.

Follow this 10-step emergency performance triage process: 1) Acknowledge and communicate - alert relevant teams, set expectations for resolution time. 2) Assess impact scope - how many users affected, which services, severity? 3) Check for recent changes - deployments, config changes, traffic patterns in last 24 hours. 4) Gather quick metrics - CPU, memory, disk I/O, network, error rates across affected services. 5) Identify proximate cause - is it application code, database, network, external dependency? 6) Apply temporary mitigation - scale up, enable rate limiting, disable expensive features, rollback if recent change. 7) Capture diagnostic data - while issue is occurring: thread dumps, heap dumps, traces, logs. 8) Root cause analysis - after mitigation, investigate captured data to find actual cause. 9) Implement proper fix - address root cause, not just symptoms. 10) Post-mortem - document incident, timeline, root cause, fix, prevention measures. Key principle: mitigate first, debug second. A working system at reduced capacity is better than extended downtime while investigating.

Follow this 11-step distributed systems performance debugging process: 1) Define the symptom - quantify: which requests are slow, how slow, what percentile affected? 2) Collect distributed traces - use Jaeger, Zipkin, or vendor tracing to see request flow. 3) Identify slow spans - find which service/component contributes most latency. 4) Check for queuing - high queue time indicates insufficient capacity or slow downstream. 5) Profile the slow component - use local profiling techniques on identified service. 6) Check network latency - measure RTT between services; unexpected high latency indicates network issues. 7) Look for retry amplification - retries causing load increase, causing more retries. 8) Check for resource contention - CPU, memory, connections, thread pools hitting limits. 9) Analyze dependencies - slow downstream service can cause upstream queuing. 10) Check for data skew - uneven load distribution causing some instances to be hot. 11) Verify with fix - implement fix, monitor distributed traces to confirm improvement. Key insight: in distributed systems, latency is often dominated by network, queuing, and serialization - not CPU computation.

Follow this 9-step recursive algorithm optimization process: 1) Profile recursion depth and call frequency - identify how deep and how many total calls. 2) Check for tail recursion - if tail-recursive, compiler may optimize to iteration; enable with -O2. 3) Consider explicit iteration - convert to loop with manual stack if recursion overhead significant. 4) Implement memoization - cache results of expensive recursive calls; check if subproblems overlap. 5) Use trampolining - for languages without tail call optimization, avoid stack overflow with continuation-passing. 6) Optimize base cases - ensure base cases are fast; consider handling more cases in base to reduce depth. 7) Increase problem size per call - process more work per recursive call to reduce call overhead ratio. 8) Consider iterative deepening - for search problems, avoid deep recursion with bounded iterations. 9) Profile stack usage - deep recursion can cause cache misses on stack; consider explicit data structures. Trade-off: recursive code is often clearer; only optimize if profiling shows recursion overhead is significant. Memoization often gives biggest wins for overlapping subproblems (dynamic programming).

Follow this diagnostic process when IPC is below 1.0: 1) Measure IPC precisely - use perf stat -e cycles,instructions to get accurate IPC value. 2) Check memory boundedness first - measure cache misses: perf stat -e L1-dcache-load-misses,LLC-load-misses. If LLC miss rate > 1%, memory latency is likely culprit. 3) If memory-bound: follow cache optimization checklist - improve locality, add prefetching, reduce working set. 4) Check branch mispredictions - perf stat -e branch-misses. If misprediction rate > 2%, branch prediction is culprit. 5) If branch-bound: follow branch optimization checklist - improve predictability, use branchless code. 6) Check for long dependency chains - look for serial arithmetic operations where each depends on previous result. 7) If dependency-bound: break chains with temporary variables, use associative transformations, increase ILP. 8) Check for execution port saturation - use VTune Port Utilization or pmu-tools. 9) If port-bound: use different instruction mix, reduce pressure on saturated ports. 10) Check for front-end issues - I-cache misses, complex instructions causing decode stalls. Low IPC is usually memory (most common), branches, or dependencies (in that order).

Use this 12-point checklist to validate benchmark methodology: 1) Representative workload - does benchmark reflect real-world usage patterns and data sizes? 2) Warm-up period - are caches and JIT compilers in steady state before measurement? 3) Sufficient iterations - do you have 30+ measurements for statistical validity? 4) Controlled environment - is CPU frequency fixed, Turbo Boost disabled, other processes minimized? 5) Thread affinity - are benchmark threads pinned to specific cores? 6) Memory state - is ASLR disabled or results averaged across multiple runs? 7) Statistical reporting - do you report mean, median, standard deviation, AND confidence intervals? 8) Baseline comparison - are you comparing against a known baseline, not just measuring absolute numbers? 9) Single variable - are you changing only one thing between compared benchmarks? 10) Result validation - does the benchmark compute correct results? Dead code elimination? 11) Hardware documentation - did you record exact CPU model, RAM speed, compiler version? 12) Reproducibility - can someone else run your benchmark and get similar results? If any point fails, benchmark results may be misleading or meaningless.

Follow this 10-step code size optimization checklist: 1) Measure code size - check binary size, use size command to see text segment. 2) Profile I-cache misses - use perf stat -e L1-icache-load-misses to measure instruction cache behavior. 3) Reduce function size - split large functions, move cold code to separate functions. 4) Use -Os flag - optimize for size; may be faster than -O3 if I-cache bound. 5) Avoid excessive inlining - inline only truly hot, small functions; large inlined functions bloat code. 6) Reduce template instantiations - templates generate separate code for each type; use type erasure where possible. 7) Use link-time optimization (LTO) - -flto enables cross-file optimization and dead code elimination. 8) Arrange functions by hotness - place hot functions together in memory; use profile-guided layout. 9) Consider compression - code compression techniques for embedded or cold code regions. 10) Review loop unrolling - excessive unrolling bloats code; tune unroll factor considering I-cache. Trade-off: smaller code has better I-cache hit rate but may have more instructions executed; profile both.

Follow this 10-step loop tiling process: 1) Identify candidate loops - nested loops accessing multi-dimensional arrays with poor cache reuse. Classic example: matrix operations. 2) Analyze access pattern - understand which indices access which dimensions, identify stride patterns. 3) Calculate cache parameters - L1 data cache size (typically 32KB), line size (64 bytes), associativity. 4) Choose tile sizes - tile should fit in target cache level. For L1: total data per tile < 32KB. For L2: < 256KB. 5) Tile innermost data reuse dimension - place tile loops to maximize reuse within tile. 6) Handle boundary conditions - when array dimensions aren't divisible by tile size, handle remainder tiles. 7) Implement tiled loop nest - original: for(i) for(j) for(k) becomes: for(ii+=TI) for(jj+=TJ) for(i=ii) for(j=jj) for(k). 8) Verify correctness - tiled loop must compute same result as original. 9) Tune tile sizes - optimal sizes depend on problem size and cache hierarchy; try powers of 2: 16, 32, 64. 10) Measure improvement - profile cache miss rates before/after; L1 misses should decrease significantly for properly tiled loops.

Follow this 10-step sort optimization process: 1) Profile current sort - measure comparison count, swap count, cache misses. 2) Check data characteristics - size, distribution (nearly sorted, random, many duplicates), key type. 3) For small arrays (<50 elements) - use insertion sort; best for small N due to low overhead. 4) For medium arrays (50-1000) - quicksort variants with good pivot selection (median-of-three). 5) For large arrays - consider cache-aware algorithms like cache-oblivious mergesort or radix sort for integers. 6) For nearly sorted data - insertion sort or timsort which detects and exploits runs. 7) For many duplicates - use 3-way partitioning quicksort (Dutch National Flag). 8) Optimize comparison function - inline, minimize branches, compare discriminating fields first. 9) Use SIMD for sorting networks - for fixed small sizes, SIMD sorting networks are very fast. 10) Consider radix sort for integers/strings - O(nk) can beat O(n log n) for appropriate data. Benchmark standard library sort (usually introsort) as baseline; often highly optimized already.

Follow this 8-step register optimization process: 1) Identify register pressure issues - look for spill/fill instructions in generated assembly, or use compiler reports. 2) Count live variables - at any point, live variables > available registers causes spills. x86-64 has 16 general-purpose, 16 vector registers. 3) Reduce variable lifetimes - compute values as late as possible, use values as soon as computed. 4) Split hot and cold paths - keep register-intensive code on hot path; cold paths can spill. 5) Use function parameters wisely - first 6 integer args and first 8 FP args passed in registers (x86-64 SysV ABI). 6) Consider manual register hints - use register keyword (hint only), or inline assembly for critical sections. 7) Restructure code - split large functions, move invariants outside loops, reduce nested scopes. 8) Check compiler options - -freg-struct-return, -mprefer-vector-width affect register usage. Key insight: modern compilers have excellent register allocators; manual intervention rarely helps except in extreme cases. Focus on reducing variable count and scope instead.

Follow this 11-step profile-guided optimization process: 1) Build baseline without PGO - measure current performance for comparison. 2) Instrument code for profiling - GCC: -fprofile-generate, Clang: -fprofile-instr-generate. 3) Design representative workload - must cover typical production patterns, not just unit tests. 4) Run instrumented binary - execute with representative workload to collect profile data. 5) Verify coverage - ensure hot code paths were executed; check coverage reports. 6) Build with profile data - GCC: -fprofile-use, Clang: -fprofile-instr-use=profile.profdata. 7) Measure improvement - compare PGO build against baseline on same workload. 8) Verify correctness - run full test suite on PGO build. 9) Establish profile update cadence - re-profile when code or usage patterns change significantly. 10) Automate in CI/CD - integrate profile collection and PGO builds into build pipeline. 11) Consider BOLT - post-link optimization using perf data for additional gains (5-15% typical). Expected gains: 10-30% for branch-heavy code like compilers, interpreters; less for compute-bound numeric code.

Follow this 9-step cache thrashing diagnosis and fix process: 1) Detect thrashing symptoms - high cache miss rate despite working set appearing to fit in cache. 2) Profile cache behavior - use Cachegrind or perf to measure actual miss rates vs expected. 3) Identify conflict misses - thrashing occurs when multiple data items map to same cache set, evicting each other. 4) Analyze access patterns - find which arrays/structures are accessed together and their addresses. 5) Check alignment/stride - power-of-2 strides with power-of-2 array sizes cause conflict misses. 6) Calculate conflict addresses - items conflict if: (address1 / cache_line_size) mod num_sets == (address2 / cache_line_size) mod num_sets. 7) Apply padding - add padding to shift one array's addresses to different sets. Typical: add cache_line_size bytes. 8) Use different allocation strategy - malloc may align large allocations; use memalign with offset. 9) Verify fix - re-profile to confirm miss rate decreased and performance improved. Example: two 4KB arrays both at 4KB-aligned addresses conflict in every L1 set; padding one by 64 bytes eliminates conflicts.

Follow this 12-point GPU kernel optimization checklist: 1) Profile with vendor tools - NVIDIA Nsight Compute, AMD ROCm Profiler, or Intel VTune GPU. 2) Check occupancy - percentage of GPU resources utilized; low occupancy wastes parallelism. 3) Identify bottleneck type - compute-bound, memory-bound, or latency-bound (use roofline analysis). 4) Optimize memory access patterns - ensure coalesced memory access; avoid strided or random patterns. 5) Use shared memory - for data reused across threads in a block; reduces global memory traffic. 6) Minimize divergence - avoid branches where threads in warp take different paths. 7) Optimize block/grid dimensions - tune for occupancy and memory access patterns. 8) Use appropriate precision - FP16/BF16 faster than FP32 on many GPUs; use if accuracy allows. 9) Overlap compute and transfer - async memory copies while kernels execute. 10) Reduce CPU-GPU synchronization - batch operations to minimize sync points. 11) Use tensor cores where applicable - for matrix operations, specialized hardware gives huge speedup. 12) Profile power and thermal - throttling due to heat reduces performance; check sustained performance vs peak. Compare against theoretical limits: memory bandwidth, compute throughput for target GPU.

Follow this 12-step A/B performance comparison process: 1) Define hypothesis - state expected improvement and metrics to measure. 2) Control environment - identical hardware, OS config, background load for both runs. 3) Pin CPU frequency - disable Turbo Boost and frequency scaling. 4) Warm up - run code before measurement to stabilize caches and JIT. 5) Measure baseline (A) - run configuration A, record multiple trials (minimum 30). 6) Calculate baseline statistics - mean, median, standard deviation, 95% confidence interval. 7) Measure treatment (B) - identical conditions, same number of trials. 8) Calculate treatment statistics - same metrics as baseline. 9) Perform statistical test - use t-test if normally distributed, Mann-Whitney otherwise. Check p-value < 0.05 for significance. 10) Calculate effect size - percent improvement and confidence interval on the difference. 11) Verify non-overlapping confidence intervals - if intervals overlap, difference may not be significant. 12) Document results - record all details: hardware, software versions, metrics, statistical analysis, raw data. Report inconclusive results honestly; negative results are still results.

Follow this 10-step loop unrolling checklist: 1) Verify loop is hot - don't unroll cold loops; consumes code cache for no benefit. 2) Check compiler auto-unrolling - compile with -funroll-loops and check if already unrolled. 3) Measure baseline - record cycles per iteration, IPC, code size. 4) Assess unroll benefit potential - highest benefit when: loop overhead significant vs body, iterations are independent, body has instruction-level parallelism. 5) Choose unroll factor - start with 2x or 4x; optimal is often power of 2. 6) Handle remainder - for N iterations with unroll factor U: handle N%U iterations separately (epilog loop or Duff's device). 7) Check register pressure - unrolling increases live variables; if registers spill to stack, benefit is lost. 8) Verify vectorization interaction - unrolling may enable or prevent auto-vectorization depending on structure. 9) Measure result - compare cycles/iteration, watch for: code bloat causing I-cache misses, register spills. 10) Document decision - record unroll factor and why, as optimal may change with compiler versions or hardware. Rule of thumb: if unrolled code > 64 instructions, risk of I-cache pressure increases.

Follow this 7-step TMAM analysis process: 1) Run top-level analysis - use VTune or pmu-tools toplev.py to get percentages for: Retiring (useful work), Bad Speculation (wasted work), Frontend Bound (instruction fetch issues), Backend Bound (execution issues). 2) Identify dominant category - focus on the category with highest percentage (often Backend Bound for unoptimized code). 3) If Frontend Bound dominant: drill into Frontend Latency (I-cache misses, ITLB misses) vs Frontend Bandwidth (decoder throughput). Fix: simplify code, improve instruction locality. 4) If Bad Speculation dominant: drill into Branch Mispredict vs Machine Clears. Fix: improve branch predictability, avoid self-modifying code. 5) If Backend Bound dominant: drill into Memory Bound vs Core Bound. 6) If Memory Bound: check L1/L2/L3 Bound and DRAM Bound to identify which level. Fix: improve cache usage, prefetch, reduce memory traffic. 7) If Core Bound: check Port Utilization to find saturated execution units. Fix: reduce dependency chains, increase ILP, use different instruction mix. Key insight: only optimize the bottleneck category - improving non-bottleneck areas provides no benefit.

Follow this 8-step false sharing prevention checklist: 1) Identify potential false sharing - look for arrays or structures where different threads write to adjacent elements. 2) Understand cache line size - typically 64 bytes on modern x86; false sharing occurs when threads write to same 64-byte region. 3) Profile for false sharing - look for high cache coherency traffic, poor scaling with thread count, or use tools like Intel Inspector. 4) Pad per-thread data - add padding to ensure each thread's data is in its own cache line: struct alignas(64) ThreadData { int data; char padding[60]; }; 5) Use thread-local storage - thread_local in C++, __thread in GCC, or explicit thread-local arrays. 6) Restructure arrays - instead of data[thread_id].field, use field[thread_id] with proper spacing. 7) Avoid sharing where possible - duplicate read-only data per thread rather than sharing single copy if write contention occurs. 8) Verify fix - re-profile to confirm cache coherency traffic reduced and scaling improved. Common pitfall: padding increases memory usage; only pad frequently-written data in hot paths.

Follow this 11-step scalar-to-vector transformation process: 1) Identify vectorization target - loop or repeated computation with data parallelism. 2) Verify independence - iterations must be independent; no loop-carried dependencies (or handle with reductions). 3) Choose vector width - match hardware: SSE=4 floats, AVX2=8 floats, AVX-512=16 floats. 4) Handle alignment - align arrays to vector width boundaries. 5) Transform data access - convert scalar loads to vector loads: float a = arr[i] becomes __m256 a = _mm256_load_ps(&arr[i]). 6) Transform operations - scalar ops to vector: a+b becomes _mm256_add_ps(a,b). 7) Handle horizontal operations - reductions (sum, max) need special handling with horizontal adds. 8) Handle conditionals - replace if/else with blending: _mm256_blendv_ps. 9) Handle loop remainder - iterations not divisible by vector width need scalar epilog or masked operations. 10) Verify correctness - compare vector results against scalar reference. 11) Benchmark - measure actual speedup; theoretical 8x rarely achieved due to memory bandwidth limits. Tools: Intel SDE for emulating unavailable instructions, compiler auto-vectorization reports for reference.

Follow this 13-point multi-threaded profiling checklist: 1) Profile single-threaded first - establish baseline, understand serial hot spots. 2) Use thread-aware profiler - VTune Threading analysis, perf with -t flag, or dedicated tools like Helgrind. 3) Measure scalability - run with 1, 2, 4, 8, N threads; calculate speedup = T1/TN. 4) Identify scalability limiters - is speedup sub-linear? Look for serial sections, contention, imbalanced work. 5) Profile lock contention - use perf lock, VTune Locks and Waits, or mutex debugging libraries. 6) Check for false sharing - if performance degrades with more threads, look for shared cache lines. 7) Verify work balance - check per-thread execution times; imbalance causes idle waiting. 8) Profile context switches - high context switch rate indicates excessive locking or thread thrashing. 9) Check NUMA effects - threads accessing remote memory have higher latency; use numactl to diagnose. 10) Measure synchronization overhead - time spent in barriers, locks, atomic operations. 11) Check memory bandwidth saturation - may limit scaling even if CPUs available. 12) Profile with production thread count - behavior may differ from small-scale testing. 13) Use timeline views - visualize thread activity over time to spot idle periods and synchronization patterns.

Follow this 10-step critical path latency reduction process: 1) Identify critical path - sequence of dependent operations determining minimum execution time. Use dependency analysis or VTune critical path view. 2) Measure path latency - sum instruction latencies along critical path. 3) Look for high-latency instructions - division (15-50 cycles), some shuffles, memory accesses on cache miss. 4) Replace high-latency ops - use approximations (rsqrt instead of 1/sqrt), lookup tables, or different algorithms. 5) Break dependency chains - use associativity to parallelize: (a+b)+(c+d) instead of a+b+c+d. 6) Use instruction-level parallelism - interleave independent operations to fill pipeline while waiting for dependencies. 7) Reduce memory latency impact - prefetch, improve locality, keep critical data in registers. 8) Avoid false dependencies - use different registers for independent computations to prevent false RAW hazards. 9) Consider out-of-order execution - modern CPUs reorder, but ROB size limits how far ahead they can look (~200 instructions). 10) Measure improvement - verify critical path shortened and latency reduced. Critical insight: reducing latency matters most for throughput when many instances are in-flight; for single execution, may not matter.

Follow this 10-step lock-free optimization process: 1) Profile contention - measure CAS failure rates, retry counts, throughput under contention. 2) Understand memory ordering - verify correct use of acquire/release/seq_cst; incorrect ordering causes bugs. 3) Minimize atomic operations - reduce number of atomics in hot path; batch updates where possible. 4) Use appropriate memory orders - relaxed is cheapest, acquire/release sufficient for most cases, avoid seq_cst unless necessary. 5) Avoid false sharing - pad atomic variables to separate cache lines. 6) Consider DCAS vs CAS - some algorithms need double-word CAS; x86 has CMPXCHG16B. 7) Profile cache line bouncing - high cache coherency traffic indicates contention; consider partitioning. 8) Use backoff strategies - exponential backoff on CAS failure reduces contention. 9) Consider hybrid approaches - lock-free for common case, fallback to locks for rare cases. 10) Benchmark against locked alternatives - lock-free isn't always faster; mutex with short critical section may be better under low contention. Correctness first: lock-free bugs are subtle and hard to reproduce; use formal verification or extensive testing.

Follow this 9-step function call overhead reduction process: 1) Profile call frequency - identify functions called millions of times in hot paths. 2) Measure call overhead - typical overhead: 5-20 cycles for direct call, 10-30 for indirect/virtual, 50-100+ if cache miss on code. 3) Consider inlining - for small functions (<10 instructions), inlining eliminates call overhead entirely. Use inline keyword, -finline-functions, or attribute((always_inline)). 4) Check compiler inlining decisions - use -Winline (GCC) to see what wasn't inlined and why. 5) Reduce argument passing overhead - pass large structures by pointer/reference, not value. On x86-64: first 6 integer args in registers, rest on stack. 6) Avoid unnecessary virtual calls - use final keyword for classes not inherited, devirtualization with -fdevirtualize. 7) Consider function pointers vs switch - switch may be faster for small fixed set of functions due to better branch prediction. 8) Batch calls - instead of calling function N times with single items, pass array of N items. 9) Verify benefit - measure actual improvement; modern CPUs predict calls well, so overhead may be less than expected. Focus on calls in innermost loops where overhead multiplies.

Use this 12-point checklist to validate benchmark methodology: 1) Representative workload - does benchmark reflect real-world usage patterns and data sizes? 2) Warm-up period - are caches and JIT compilers in steady state before measurement? 3) Sufficient iterations - do you have 30+ measurements for statistical validity? 4) Controlled environment - is CPU frequency fixed, Turbo Boost disabled, other processes minimized? 5) Thread affinity - are benchmark threads pinned to specific cores? 6) Memory state - is ASLR disabled or results averaged across multiple runs? 7) Statistical reporting - do you report mean, median, standard deviation, AND confidence intervals? 8) Baseline comparison - are you comparing against a known baseline, not just measuring absolute numbers? 9) Single variable - are you changing only one thing between compared benchmarks? 10) Result validation - does the benchmark compute correct results? Dead code elimination? 11) Hardware documentation - did you record exact CPU model, RAM speed, compiler version? 12) Reproducibility - can someone else run your benchmark and get similar results? If any point fails, benchmark results may be misleading or meaningless.

Apply loop optimizations in this recommended order: 1) Algorithm optimization - ensure you're using best algorithm; O(n) beats optimized O(n^2). 2) Loop-invariant code motion - move calculations that don't change per iteration outside loop. 3) Strength reduction - replace expensive ops (mul, div, mod) with cheaper ones (add, shift, mask). 4) Dead code elimination - remove calculations whose results are never used. 5) Loop interchange - for nested loops, reorder to improve memory access pattern. 6) Loop tiling/blocking - for cache locality when processing large arrays. 7) Loop fusion - combine adjacent loops with same bounds to improve locality. 8) Loop fission - split loop if it enables vectorization or reduces register pressure. 9) Loop unrolling - reduce loop overhead, expose ILP; try 2x, 4x factors. 10) Vectorization - SIMD for data-parallel operations. 11) Parallelization - multi-thread outer loops if sufficient work per thread. 12) Software pipelining - for VLIW or when other opts insufficient. Rationale: early opts may enable later ones (hoisting enables vectorization), algorithmic changes give biggest wins, parallelization adds complexity so comes last.

Follow this 12-step A/B performance comparison process: 1) Define hypothesis - state expected improvement and metrics to measure. 2) Control environment - identical hardware, OS config, background load for both runs. 3) Pin CPU frequency - disable Turbo Boost and frequency scaling. 4) Warm up - run code before measurement to stabilize caches and JIT. 5) Measure baseline (A) - run configuration A, record multiple trials (minimum 30). 6) Calculate baseline statistics - mean, median, standard deviation, 95% confidence interval. 7) Measure treatment (B) - identical conditions, same number of trials. 8) Calculate treatment statistics - same metrics as baseline. 9) Perform statistical test - use t-test if normally distributed, Mann-Whitney otherwise. Check p-value < 0.05 for significance. 10) Calculate effect size - percent improvement and confidence interval on the difference. 11) Verify non-overlapping confidence intervals - if intervals overlap, difference may not be significant. 12) Document results - record all details: hardware, software versions, metrics, statistical analysis, raw data. Report inconclusive results honestly; negative results are still results.

Follow this 11-step container optimization process: 1) Minimize image size - use multi-stage builds, alpine bases, remove unnecessary files. Smaller = faster pull. 2) Layer effectively - put rarely-changing layers first (dependencies) to maximize cache reuse. 3) Optimize application startup - same startup optimizations as native, plus container-specific considerations. 4) Set appropriate resource limits - too low causes throttling, too high wastes cluster resources. 5) Use init containers wisely - parallelize where possible, minimize init work. 6) Configure health checks properly - fast to execute, appropriate intervals to avoid unnecessary restarts. 7) Use local image caching - pre-pull images to nodes, use image caching solutions. 8) Optimize overlay filesystem - many small files perform poorly; consider init container to unpack. 9) Profile container overhead - compare performance in container vs bare metal; identify container-specific costs. 10) Use appropriate base images - distroless or scratch for minimal overhead. 11) Consider sidecar overhead - service meshes, log collectors add CPU/memory; profile their impact. Kubernetes-specific: tune kubelet, use node-local DNS caching, appropriate pod disruption budgets.

Follow this 12-step performance regression debugging process: 1) Confirm the regression - verify with multiple runs that performance actually degraded (not measurement noise). 2) Quantify the regression - measure exact percentage slowdown and which metrics changed (latency, throughput, CPU time). 3) Identify the regression window - use git bisect to find the exact commit that introduced the regression. 4) Compare profiles before/after - run same profiler on good and bad versions with identical workload. 5) Generate differential flame graph - visualize what got slower (red) vs faster (blue). 6) Analyze the diff - identify which functions show increased time. 7) Check for obvious causes - new allocations, additional logging, changed algorithms, new dependencies. 8) Profile specific metrics - if not obvious, profile cache misses, branch mispredictions, IPC separately. 9) Inspect code changes - review the diff of the regression commit for performance-impacting changes. 10) Form hypothesis - propose specific cause based on profile differences. 11) Verify hypothesis - create minimal reproducer or targeted benchmark. 12) Fix and verify - implement fix, confirm regression is resolved, ensure no new regressions introduced. Add regression test to CI to prevent recurrence.

Follow this 11-step data structure optimization process: 1) Profile access patterns - identify which fields are accessed together, frequency of operations (read/write/iterate). 2) Measure current performance - baseline cache miss rates, memory bandwidth usage. 3) Calculate structure size and alignment - use sizeof(), check for padding with offsetof(). 4) Identify hot fields - fields accessed in tight loops or critical paths. 5) Group hot fields together - reorder struct members so hot fields are in same cache line (64 bytes). 6) Consider AoS vs SoA - if iterating over one field of many objects, SoA (separate arrays per field) improves spatial locality. 7) Reduce structure size - use smaller types where possible (int16_t vs int32_t), use bitfields for flags, remove unused fields. 8) Align to cache lines - use alignas(64) for frequently accessed structures to avoid split accesses. 9) Consider padding to avoid false sharing - in multi-threaded code, pad to 64 bytes between thread-local data. 10) Evaluate pointer vs index - indices into arrays have better cache behavior than pointers to dispersed memory. 11) Benchmark alternatives - test different layouts with production-like workload, as optimal depends on access pattern.

Follow this 9-step recursive algorithm optimization process: 1) Profile recursion depth and call frequency - identify how deep and how many total calls. 2) Check for tail recursion - if tail-recursive, compiler may optimize to iteration; enable with -O2. 3) Consider explicit iteration - convert to loop with manual stack if recursion overhead significant. 4) Implement memoization - cache results of expensive recursive calls; check if subproblems overlap. 5) Use trampolining - for languages without tail call optimization, avoid stack overflow with continuation-passing. 6) Optimize base cases - ensure base cases are fast; consider handling more cases in base to reduce depth. 7) Increase problem size per call - process more work per recursive call to reduce call overhead ratio. 8) Consider iterative deepening - for search problems, avoid deep recursion with bounded iterations. 9) Profile stack usage - deep recursion can cause cache misses on stack; consider explicit data structures. Trade-off: recursive code is often clearer; only optimize if profiling shows recursion overhead is significant. Memoization often gives biggest wins for overlapping subproblems (dynamic programming).

Follow this 8-step loop fission process: 1) Identify fission candidates - single loop with multiple independent statement groups accessing different data. 2) Check dependency safety - statements in resulting separate loops must not have cross-loop dependencies. 3) Analyze benefit potential - fission beneficial when: different statements access different data (improved spatial locality), one statement group can be vectorized but others prevent it, register pressure in combined loop causes spills. 4) Identify split points - group statements that access same data or have dependencies together. 5) Implement fission - split single loop into multiple loops. Before: for(i) { A[i]=..; B[i]=..; } After: for(i) A[i]=..; for(i) B[i]=..; 6) Handle carried dependencies - if dependency exists, fission may require reordering or may not be legal. 7) Verify correctness - split loops must produce identical results to original. 8) Measure improvement - check vectorization status (compiler reports), cache behavior, overall performance. Fission is inverse of fusion; useful when combined loop body is too large for registers or prevents vectorization.

Follow this 10-step linked structure optimization process: 1) Profile access patterns - identify traversal patterns, random vs sequential access frequency. 2) Measure cache misses - linked structures typically have poor locality; quantify the cost. 3) Consider unrolled variants - unrolled linked lists store multiple elements per node, improving locality. 4) Pool allocations - allocate nodes from contiguous memory pool to improve spatial locality. 5) Prefetch next nodes - during traversal, prefetch next pointer's target: prefetch(node->next). 6) Consider cache-oblivious layouts - Van Emde Boas layout for trees improves cache efficiency. 7) Evaluate array-based alternatives - many linked structures can be replaced with arrays + indices. 8) Use flat storage for small structures - for trees with <1000 nodes, array-based often faster than pointer-based. 9) Pack related data - ensure frequently accessed fields are in same cache line as link pointers. 10) Consider converting to array on access - if structure is built once and traversed many times, copy to array for traversal. Key insight: modern CPUs heavily favor arrays due to prefetching; linked structures should be a last resort for performance-critical code.

Follow this 12-point production monitoring checklist: 1) Define SLOs - establish latency percentiles (p50, p95, p99), throughput targets, error budgets. 2) Instrument code - add timing for critical paths, use low-overhead methods (RDTSC-based). 3) Sample, don't trace everything - 1-10% sampling rate sufficient for trends, avoids overhead. 4) Monitor system metrics - CPU utilization, memory usage, cache hit rates, context switches. 5) Set up alerting - alert when metrics approach SLO boundaries, not when violated. 6) Create dashboards - visualize key metrics over time, correlate with deployments. 7) Establish baselines - record normal performance ranges for comparison. 8) Enable on-demand profiling - mechanism to capture detailed profiles when issues detected. 9) Log slow requests - capture details of requests exceeding latency thresholds. 10) Track performance per version - correlate performance changes with code changes. 11) Monitor resource costs - track CPU-time, memory-hours, cost per request. 12) Regular performance reviews - periodic analysis of trends, capacity planning. Tools: Prometheus+Grafana for metrics, Jaeger/Zipkin for tracing, continuous profiling services (Parca, Pyroscope).

Follow this 9-step dependency chain optimization process: 1) Identify long dependency chains - look for serial sequences where each instruction depends on previous result. 2) Measure chain length - count instructions from first to last in chain; compare to loop iteration count. 3) Calculate chain latency - sum latencies of instructions in chain; this is minimum time per iteration. 4) Check IPC - low IPC with low cache misses often indicates dependency-bound code. 5) Break arithmetic chains - use associativity: sum = (a+b) + (c+d) instead of a+b+c+d allows parallel execution. 6) Use multiple accumulators - for reductions, use 4-8 independent accumulators, combine at end. 7) Unroll with independent computations - unroll loop and interleave independent iterations. 8) Reorder instructions - place independent instructions between dependent ones to fill latency. 9) Verify improvement - check IPC increased and execution time decreased. Example: summing array with single accumulator has N-instruction chain; with 4 accumulators, chain is N/4, allowing 4x parallelism until final combination.

Follow this 14-step cache optimization checklist: 1) Measure baseline - profile L1/L2/L3 hit rates and miss penalties using perf or Cachegrind. 2) Understand cache parameters - L1: 32-64KB, 4-8 way, 64B lines; L2: 256KB-1MB; L3: shared, multi-MB. 3) Calculate working set size - total unique data accessed in hot regions. 4) If working set > cache: apply blocking/tiling to process data in cache-sized chunks. 5) If spatial locality poor: reorganize data layout for sequential access, convert AoS to SoA. 6) If temporal locality poor: reorder computations to reuse data while still in cache. 7) Align data structures - align to 64-byte cache line boundaries to avoid split accesses. 8) Avoid false sharing in parallel code - pad structures so different threads don't share cache lines. 9) Use prefetching for predictable access - software prefetch 200-400 cycles ahead of use. 10) Minimize pointer chasing - linearize linked structures or use indices into arrays. 11) Consider cache-oblivious algorithms - algorithms that work well regardless of cache size. 12) Profile TLB misses - if high, consider huge pages (2MB instead of 4KB). 13) Check NUMA locality - ensure data allocated on same node as accessing CPU. 14) Verify improvements - confirm cache miss reduction yields proportional speedup.

Use this 12-point performance documentation checklist: 1) Describe the problem - what was slow, how slow, under what conditions? 2) Include baseline measurements - exact numbers with methodology, environment details. 3) Explain root cause analysis - how did you identify the bottleneck? What tools used? 4) Document what you tried - including approaches that didn't work and why. 5) Describe the solution - what change was made, why does it work? 6) Include after measurements - same methodology as baseline for valid comparison. 7) Quantify improvement - percentage, absolute numbers, statistical significance. 8) Note tradeoffs - does optimization increase memory usage, code complexity, or reduce maintainability? 9) Specify applicability - when does this optimization apply? What conditions might make it not apply? 10) Add code comments - explain non-obvious optimization in code near the optimization. 11) Update performance tests - add regression tests to prevent future slowdowns. 12) Record environment details - compiler version, flags, hardware, OS - for reproducibility. Good documentation prevents: re-investigating same issues, accidentally reverting optimizations, applying optimizations where they don't help.

Follow this 9-step Roofline analysis checklist: 1) Generate roofline plot - use Intel Advisor or manual calculation with collected FLOPS and bandwidth data. 2) Identify kernel locations - each dot represents a kernel; position shows performance vs potential. 3) Check which roof limits each kernel - sloped (memory) or flat (compute) portion. 4) For kernels on memory roof (left/sloped): improve arithmetic intensity by: increasing cache reuse (tiling), reducing memory traffic, using smaller data types. 5) For kernels on compute roof (right/flat): improve by: vectorizing (wider SIMD), reducing instruction count, better ILP. 6) For kernels below all roofs: investigate microarchitectural bottlenecks - latency, port contention, cache conflicts. 7) Check distance from roof - large gap indicates significant optimization opportunity. 8) Prioritize by time - optimize kernels that take most time, not those furthest from roof. 9) Re-analyze after optimization - verify kernel moved closer to roof or shifted to different roof. Goal: kernels should approach respective roofs; reaching roof means near-optimal for that resource.

Follow this 10-step Valgrind usage checklist: 1) Build with debug info - compile with -g for source-level annotations. Keep -O2 for representative performance but consider -O0 for clearer traces. 2) Choose appropriate tool - Memcheck (default): memory errors; Cachegrind: cache simulation; Callgrind: call graph profiling; Massif: heap profiling; Helgrind/DRD: threading errors. 3) Expect slowdown - Memcheck: 10-50x slower, Cachegrind: 20-100x, Callgrind: 10-100x. Reduce input size accordingly. 4) Suppress known false positives - use suppression files to ignore expected errors from system libraries. 5) Run representative workload - even small inputs reveal cache behavior patterns. 6) Use annotation tools - cg_annotate for Cachegrind, callgrind_annotate for Callgrind, ms_print for Massif. 7) Focus on significant results - sort by impact (cache misses, time, allocations); ignore noise. 8) Check Cachegrind cache configuration - verify simulated cache matches target hardware: --I1, --D1, --LL options. 9) Use Callgrind with instrumentation control - CALLGRIND_START_INSTRUMENTATION/STOP to focus on hot code. 10) Interpret results carefully - Valgrind simulates, doesn't measure; use as relative comparison, not absolute numbers.

Follow this 11-step scalar-to-vector transformation process: 1) Identify vectorization target - loop or repeated computation with data parallelism. 2) Verify independence - iterations must be independent; no loop-carried dependencies (or handle with reductions). 3) Choose vector width - match hardware: SSE=4 floats, AVX2=8 floats, AVX-512=16 floats. 4) Handle alignment - align arrays to vector width boundaries. 5) Transform data access - convert scalar loads to vector loads: float a = arr[i] becomes __m256 a = _mm256_load_ps(&arr[i]). 6) Transform operations - scalar ops to vector: a+b becomes _mm256_add_ps(a,b). 7) Handle horizontal operations - reductions (sum, max) need special handling with horizontal adds. 8) Handle conditionals - replace if/else with blending: _mm256_blendv_ps. 9) Handle loop remainder - iterations not divisible by vector width need scalar epilog or masked operations. 10) Verify correctness - compare vector results against scalar reference. 11) Benchmark - measure actual speedup; theoretical 8x rarely achieved due to memory bandwidth limits. Tools: Intel SDE for emulating unavailable instructions, compiler auto-vectorization reports for reference.

Follow this 9-step Roofline analysis checklist: 1) Generate roofline plot - use Intel Advisor or manual calculation with collected FLOPS and bandwidth data. 2) Identify kernel locations - each dot represents a kernel; position shows performance vs potential. 3) Check which roof limits each kernel - sloped (memory) or flat (compute) portion. 4) For kernels on memory roof (left/sloped): improve arithmetic intensity by: increasing cache reuse (tiling), reducing memory traffic, using smaller data types. 5) For kernels on compute roof (right/flat): improve by: vectorizing (wider SIMD), reducing instruction count, better ILP. 6) For kernels below all roofs: investigate microarchitectural bottlenecks - latency, port contention, cache conflicts. 7) Check distance from roof - large gap indicates significant optimization opportunity. 8) Prioritize by time - optimize kernels that take most time, not those furthest from roof. 9) Re-analyze after optimization - verify kernel moved closer to roof or shifted to different roof. Goal: kernels should approach respective roofs; reaching roof means near-optimal for that resource.

Follow this 10-point optimization correctness checklist: 1) Preserve semantics - optimized code must produce identical output for all valid inputs. 2) Test with original test suite - all existing tests must pass unchanged. 3) Add edge case tests - empty inputs, single elements, maximum sizes, boundary values. 4) Compare against reference - run both versions on diverse inputs, compare outputs exactly. 5) Test numerical stability - for floating-point, verify acceptable precision (may differ due to reassociation). 6) Check corner cases - negative numbers, zeros, NaN, infinity for floating-point. 7) Test with sanitizers - run with AddressSanitizer, UndefinedBehaviorSanitizer to catch subtle bugs. 8) Verify thread safety - if parallelized, test with ThreadSanitizer, various thread counts. 9) Stress test - large inputs, sustained load, verify no degradation or crashes. 10) Document semantic changes - if optimization intentionally changes behavior (fast-math), document clearly. Golden rule: never trust an optimization until independently verified; subtle bugs in optimized code can be worse than slow correct code.

Use this 15-point code review performance checklist: 1) N+1 queries - loops making database calls; should be batched. 2) Unbounded allocations - lists/buffers that can grow without limit. 3) String concatenation in loops - use StringBuilder or pre-sized buffer. 4) Synchronous I/O in hot path - should be async or moved off critical path. 5) Logging in tight loops - logging overhead adds up; use sampling or move outside loop. 6) Exception-based control flow - exceptions are expensive; don't use for normal cases. 7) Unnecessary boxing/unboxing - primitive to object conversion overhead. 8) Missing short-circuit evaluation - expensive checks should come last in conditions. 9) Unnecessary defensive copies - copying large objects 'just in case'. 10) Lock contention - locks held too long or too broadly. 11) Cache-unfriendly data structures - linked lists, hash tables with poor locality. 12) Repeated computation - same calculation done multiple times without caching. 13) Blocking on I/O - synchronously waiting for network/disk. 14) Inefficient algorithms - O(n^2) where O(n log n) exists. 15) Missing resource limits - unbounded queues, connection pools, thread creation. Not all patterns are problems everywhere; focus on hot paths identified by profiling.

Follow this 8-step hot spot identification process: 1) Choose appropriate profiler - use sampling profiler (perf, VTune, Instruments) for low overhead and statistical accuracy. 2) Run representative workload - use production-like data and usage patterns, not toy inputs. 3) Ensure sufficient samples - minimum 1000 samples in hot regions for statistical reliability (run longer if needed). 4) Generate initial report - sort functions by CPU time (self time first, then including callees). 5) Identify hot spots - functions consuming >5% of total time are candidates for optimization. 6) Analyze call context - use call graph to understand HOW hot functions are reached (same function called from multiple paths may have different optimization strategies). 7) Generate flame graph - visual overview shows widest boxes as hottest paths, helps spot unexpected hot code. 8) Drill down with annotation - use perf annotate or VTune source view to find hot instructions within hot functions. Remember: some hot spots are fundamental (main computation) and cannot be eliminated; focus on reducible overhead and inefficiencies.

Follow this systematic 8-step process: 1) Establish baseline metrics - measure current performance with representative workloads, record wall time, CPU time, memory usage, and throughput. 2) Profile to identify hotspots - use sampling profiler (perf, VTune) to find where >10% of time is spent. 3) Categorize the bottleneck - determine if CPU-bound (high CPU utilization), memory-bound (high cache misses), I/O-bound (high wait time), or branch-bound (high misprediction rate). 4) Analyze the specific bottleneck - if memory-bound, profile cache behavior; if CPU-bound, check IPC and instruction mix. 5) Form optimization hypothesis - propose specific change based on bottleneck type. 6) Implement targeted fix - make ONE change at a time for measurable impact. 7) Measure improvement - re-profile with same workload, compare metrics quantitatively. 8) Iterate - if target not met, return to step 2; new hotspots may emerge after optimization. Critical rule: never optimize without profiling data first.

Follow this 11-point ARM optimization checklist: 1) Identify target ARM variant - ARMv7, ARMv8 (AArch64), or specific cores (Cortex-A72, Apple M1). 2) Check NEON availability - ARM's SIMD extension; 128-bit vectors on ARMv7/v8, wider on some v9. 3) Use ARM-appropriate compiler flags - -march=armv8-a+simd, -mcpu=native for target-specific. 4) Consider in-order vs out-of-order - many ARM cores are in-order; instruction scheduling matters more. 5) Optimize for different cache sizes - ARM cores vary widely in cache configuration. 6) Use intrinsics for NEON - <arm_neon.h> for portable SIMD; different from x86 intrinsics. 7) Check alignment requirements - some ARM implementations require aligned SIMD access. 8) Consider big.LITTLE - heterogeneous cores; schedule appropriately for efficiency vs performance cores. 9) Profile on target hardware - ARM simulators don't capture real performance; test on actual devices. 10) Watch for endianness - some ARM can be big or little endian; verify code handles correctly. 11) Use SVE/SVE2 where available - Scalable Vector Extension on ARMv9; variable vector lengths. Apple Silicon: specific optimizations for M1/M2/M3 differ from Android ARM SoCs.

Follow this 11-step real-time media optimization process: 1) Define latency budget - audio typically <10ms, video <33ms for 30fps; allocate per stage. 2) Use lock-free communication - between capture/process/playback threads to avoid priority inversion. 3) Pre-allocate all buffers - no runtime allocation; use circular buffers for streaming. 4) Avoid syscalls in processing - no file I/O, logging, or allocation in real-time thread. 5) Use SIMD extensively - media processing (filters, transforms) benefits greatly from vectorization. 6) Pin to dedicated cores - isolate real-time threads from system interrupts and other processes. 7) Use appropriate thread priority - SCHED_FIFO on Linux, THREAD_PRIORITY_TIME_CRITICAL on Windows. 8) Profile worst-case latency - measure 99.9th percentile, not average; spikes cause glitches. 9) Handle overload gracefully - drop frames rather than accumulating latency. 10) Use specialized DSP libraries - IPP, FFTW, vendor-specific audio libraries are highly optimized. 11) Test under stress - full CPU load, memory pressure, disk activity to find edge cases. Real-time constraint: every processing deadline must be met; missing one causes audible/visible glitch.

Follow this 10-step loop unrolling checklist: 1) Verify loop is hot - don't unroll cold loops; consumes code cache for no benefit. 2) Check compiler auto-unrolling - compile with -funroll-loops and check if already unrolled. 3) Measure baseline - record cycles per iteration, IPC, code size. 4) Assess unroll benefit potential - highest benefit when: loop overhead significant vs body, iterations are independent, body has instruction-level parallelism. 5) Choose unroll factor - start with 2x or 4x; optimal is often power of 2. 6) Handle remainder - for N iterations with unroll factor U: handle N%U iterations separately (epilog loop or Duff's device). 7) Check register pressure - unrolling increases live variables; if registers spill to stack, benefit is lost. 8) Verify vectorization interaction - unrolling may enable or prevent auto-vectorization depending on structure. 9) Measure result - compare cycles/iteration, watch for: code bloat causing I-cache misses, register spills. 10) Document decision - record unroll factor and why, as optimal may change with compiler versions or hardware. Rule of thumb: if unrolled code > 64 instructions, risk of I-cache pressure increases.

Follow this 11-step SIMD vectorization process: 1) Identify vectorization candidate - find loops with independent iterations and arithmetic operations. 2) Check auto-vectorization first - compile with -O3 -march=native and check compiler reports (gcc: -fopt-info-vec-all, icc: -qopt-report=5). 3) If not auto-vectorized, identify blockers - look for: non-unit stride, data dependencies, function calls, complex control flow. 4) Simplify loop structure - remove conditionals, ensure trip count is known or add #pragma loop count. 5) Ensure proper alignment - align arrays to 16/32/64 bytes matching SIMD width (SSE=16, AVX=32, AVX-512=64). 6) Eliminate pointer aliasing - use restrict keyword or #pragma ivdep to tell compiler pointers don't alias. 7) Handle remainder iterations - decide between scalar epilog, masked operations, or padding. 8) Choose SIMD width - SSE (128-bit), AVX2 (256-bit), or AVX-512 (512-bit) based on target CPUs. 9) If manual vectorization needed - use intrinsics (mm256*), start with loads/stores, then operations. 10) Verify correctness - compare results against scalar version. 11) Benchmark - measure actual speedup, as theoretical gains may not materialize due to memory bandwidth limits.

Follow this 8-step parallelization decision process: 1) Profile first - identify if code is CPU-bound; parallelizing I/O-bound code rarely helps. 2) Measure serial fraction - use Amdahl's Law: if 50% is serial, max speedup is 2x regardless of core count. 3) Estimate parallelism - count independent operations; need more parallel work than available cores. 4) Calculate overhead - thread creation/joining costs ~1-10 microseconds, synchronization adds latency. 5) Decision point: if work per thread < 10,000 cycles, overhead likely exceeds benefit - do not parallelize. 6) Check memory bandwidth - if already memory-bound, more threads may contend for bandwidth without speedup. 7) Assess data sharing - heavy sharing requires synchronization; consider data partitioning or thread-local copies. 8) Choose parallelization strategy - task parallel (independent work items) or data parallel (same operation on partitioned data). For loops: parallelize outermost loop if possible to minimize fork/join overhead. Rule of thumb: parallelize when expected speedup > 2x and work per thread > 1 million cycles.

Follow this 12-point GPU kernel optimization checklist: 1) Profile with vendor tools - NVIDIA Nsight Compute, AMD ROCm Profiler, or Intel VTune GPU. 2) Check occupancy - percentage of GPU resources utilized; low occupancy wastes parallelism. 3) Identify bottleneck type - compute-bound, memory-bound, or latency-bound (use roofline analysis). 4) Optimize memory access patterns - ensure coalesced memory access; avoid strided or random patterns. 5) Use shared memory - for data reused across threads in a block; reduces global memory traffic. 6) Minimize divergence - avoid branches where threads in warp take different paths. 7) Optimize block/grid dimensions - tune for occupancy and memory access patterns. 8) Use appropriate precision - FP16/BF16 faster than FP32 on many GPUs; use if accuracy allows. 9) Overlap compute and transfer - async memory copies while kernels execute. 10) Reduce CPU-GPU synchronization - batch operations to minimize sync points. 11) Use tensor cores where applicable - for matrix operations, specialized hardware gives huge speedup. 12) Profile power and thermal - throttling due to heat reduces performance; check sustained performance vs peak. Compare against theoretical limits: memory bandwidth, compute throughput for target GPU.

Follow this 9-step string optimization process: 1) Profile string operations - identify hot string functions (strcmp, strlen, memcpy, parsing). 2) Use SIMD string functions - modern libraries (glibc, MSVC) have AVX2-optimized implementations. 3) Avoid unnecessary allocations - reuse buffers, use string views/spans instead of copying. 4) Use small string optimization (SSO) - std::string typically stores strings <15-23 chars inline without heap allocation. 5) Process in bulk - don't call strlen in every loop iteration; compute once and store. 6) Use memcmp/memcpy for known lengths - faster than strcmp/strcpy when length is known. 7) Consider specialized algorithms - for pattern matching, use SIMD-optimized search (SWAR, SSE4.2 PCMPESTRI). 8) Minimize format string parsing - printf-style formatting is slow; consider faster alternatives or pre-formatting. 9) Use interned strings for comparisons - compare pointers instead of content for frequently compared strings. Benchmark: simple optimizations (avoiding redundant strlen) often give bigger wins than complex SIMD; measure before implementing complex solutions.

Follow this 11-point ARM optimization checklist: 1) Identify target ARM variant - ARMv7, ARMv8 (AArch64), or specific cores (Cortex-A72, Apple M1). 2) Check NEON availability - ARM's SIMD extension; 128-bit vectors on ARMv7/v8, wider on some v9. 3) Use ARM-appropriate compiler flags - -march=armv8-a+simd, -mcpu=native for target-specific. 4) Consider in-order vs out-of-order - many ARM cores are in-order; instruction scheduling matters more. 5) Optimize for different cache sizes - ARM cores vary widely in cache configuration. 6) Use intrinsics for NEON - <arm_neon.h> for portable SIMD; different from x86 intrinsics. 7) Check alignment requirements - some ARM implementations require aligned SIMD access. 8) Consider big.LITTLE - heterogeneous cores; schedule appropriately for efficiency vs performance cores. 9) Profile on target hardware - ARM simulators don't capture real performance; test on actual devices. 10) Watch for endianness - some ARM can be big or little endian; verify code handles correctly. 11) Use SVE/SVE2 where available - Scalable Vector Extension on ARMv9; variable vector lengths. Apple Silicon: specific optimizations for M1/M2/M3 differ from Android ARM SoCs.

Follow these optimization steps for matrix multiplication in order: 1) Baseline - implement naive O(n^3) triple loop, measure GFLOPS. 2) Loop reordering - change loop order to i-k-j for row-major arrays (improves B access pattern). 3) Register blocking - unroll inner loops to keep small blocks in registers, reducing load/store. 4) Cache tiling - tile for L1 cache (typically 32x32 to 64x64 blocks for double precision). 5) Multi-level tiling - add L2 tile level for larger matrices. 6) SIMD vectorization - vectorize innermost loop using AVX2 (4 doubles) or AVX-512 (8 doubles). 7) Software pipelining - prefetch next tiles while computing current. 8) Parallelization - parallelize outer tile loops with OpenMP. 9) NUMA awareness - ensure data locality for thread-tile mapping. 10) Specialized handling - separate paths for small matrices (direct computation) vs large (blocked). Compare against BLAS library (OpenBLAS, MKL) as ultimate baseline; well-tuned BLAS typically achieves 80%+ of theoretical peak FLOPS.

Follow this 9-step software prefetching process: 1) Identify prefetch candidates - loops with: predictable access pattern, large data that doesn't fit cache, high cache miss rate on profiling. 2) Verify hardware prefetcher isn't sufficient - sequential and simple strided patterns are often handled automatically. 3) Calculate prefetch distance - prefetch D iterations ahead where D = memory_latency / loop_iteration_time. Typical: 100-300 cycles latency / 10-50 cycles per iteration = 3-30 iterations ahead. 4) Choose prefetch type - _mm_prefetch with _MM_HINT_T0 (all cache levels) for data used soon, _MM_HINT_NTA (non-temporal) for data used once. 5) Insert prefetch instructions - at loop start, prefetch data for iteration i+D while processing iteration i. 6) Avoid over-prefetching - too many prefetches can evict useful data and saturate memory bandwidth. 7) Handle loop boundaries - don't prefetch beyond array bounds (use conditional or limit prefetch iterations). 8) Measure impact - compare cache miss rate and runtime; prefetching should reduce misses without increasing total memory traffic significantly. 9) Test on target hardware - optimal distance varies by CPU; tune for deployment platform.

Follow this 10-step branch optimization process for code with high branch density: 1) Profile branch behavior - identify which branches mispredicted most: perf record -e branch-misses. 2) Categorize branches - predictable (taken/not-taken >90% of time), moderately predictable (70-90%), unpredictable (<70%). 3) For predictable branches: use likely/unlikely hints (__builtin_expect), ensure hot path is fall-through. 4) For unpredictable data-dependent branches: consider branchless alternatives using bitwise ops, conditional moves, or arithmetic. 5) For loop-exit branches: use loop unswitching to move branch outside loop if condition is loop-invariant. 6) For multiple chained conditions: reorder to evaluate most likely first, or use short-circuit evaluation. 7) For switch statements: ensure compiler generates jump table for dense cases; consider profile-guided ordering. 8) For function dispatch: replace virtual calls with switch if small fixed set of types. 9) Use SIMD masking - process all paths simultaneously, select results with blend instructions. 10) Apply PGO - profile-guided optimization provides measured branch probabilities to compiler. Verify: branchless code may have higher latency per operation but removes unpredictability; measure to confirm improvement.

Follow this 9-step compiler optimization flag selection process: 1) Start with -O2 - balanced optimization, safe for production, good baseline. 2) Profile with -O2 - identify remaining hotspots and bottleneck types. 3) Try -O3 - adds aggressive optimizations (vectorization, unrolling); measure if it helps or hurts (code bloat can cause instruction cache misses). 4) Add -march=native - enables CPU-specific instructions (AVX2, etc.) for target machine; omit for portable binaries. 5) Consider -flto - Link-Time Optimization enables cross-file inlining and optimization; significant build time increase. 6) For floating-point heavy code: evaluate -ffast-math (may change results) or individual flags like -fno-math-errno. 7) Profile-Guided Optimization: compile with -fprofile-generate, run representative workload, recompile with -fprofile-use for best results. 8) Check for regressions - some optimizations can cause slowdowns; always measure. 9) Document final flags - record which flags used and why, include in build system. Avoid: -O0 in production (no optimization), -Os unless binary size critical (sacrifices speed), untested flag combinations.

Follow this 10-step startup optimization process: 1) Profile startup - use strace -tt -T to see syscalls, perf record from process start. 2) Identify phases - categorize: loading, parsing, initialization, warm-up. 3) Measure dynamic linking time - large number of shared libraries adds loading overhead; consider static linking. 4) Lazy initialize - defer initialization until first use; avoid loading unused features. 5) Reduce I/O - combine config files, use memory-mapped files, parallelize independent reads. 6) Optimize parsing - use faster parsers, binary formats instead of JSON/XML for large configs. 7) Use dlopen for optional features - load plugins on-demand rather than at startup. 8) Cache computed state - serialize initialized state to disk, reload on subsequent starts. 9) Parallelize initialization - independent subsystems can initialize concurrently. 10) Profile and eliminate - use flame graph of startup to identify and remove unnecessary work. Tools: systemd-analyze for service startup, bootchart for system-level, custom timestamps for application-level. Goal: minimize time-to-first-useful-output.

Follow this 15-step micro-benchmark creation checklist: 1) Define what you're measuring - single specific operation, not compound behavior. 2) Isolate the code under test - remove unrelated setup/teardown from timed region. 3) Prevent dead code elimination - use result (Blackhole.consume in JMH, DoNotOptimize in Google Benchmark). 4) Prevent constant folding - use runtime inputs, not compile-time constants. 5) Control iteration count - let framework determine iterations, don't add manual loops. 6) Warm up properly - run enough iterations for JIT compilation (JVM) or cache warming. 7) Pin CPU frequency - disable Turbo Boost and frequency scaling for consistency. 8) Pin threads to cores - use taskset/numactl to avoid migration. 9) Run sufficient trials - minimum 10 iterations, ideally 30+ for statistical validity. 10) Measure variance - report standard deviation and confidence intervals, not just mean. 11) Use appropriate time resolution - std::chrono::high_resolution_clock, QueryPerformanceCounter, or RDTSC. 12) Account for timer overhead - measure and subtract if measuring sub-microsecond operations. 13) Test multiple input sizes - performance may vary non-linearly with size. 14) Compare against baseline - always measure relative improvement, not just absolute numbers. 15) Document environment - record CPU model, compiler version, flags, OS version.

Follow this 9-step function call overhead reduction process: 1) Profile call frequency - identify functions called millions of times in hot paths. 2) Measure call overhead - typical overhead: 5-20 cycles for direct call, 10-30 for indirect/virtual, 50-100+ if cache miss on code. 3) Consider inlining - for small functions (<10 instructions), inlining eliminates call overhead entirely. Use inline keyword, -finline-functions, or attribute((always_inline)). 4) Check compiler inlining decisions - use -Winline (GCC) to see what wasn't inlined and why. 5) Reduce argument passing overhead - pass large structures by pointer/reference, not value. On x86-64: first 6 integer args in registers, rest on stack. 6) Avoid unnecessary virtual calls - use final keyword for classes not inherited, devirtualization with -fdevirtualize. 7) Consider function pointers vs switch - switch may be faster for small fixed set of functions due to better branch prediction. 8) Batch calls - instead of calling function N times with single items, pass array of N items. 9) Verify benefit - measure actual improvement; modern CPUs predict calls well, so overhead may be less than expected. Focus on calls in innermost loops where overhead multiplies.

Follow this 7-step TMAM analysis process: 1) Run top-level analysis - use VTune or pmu-tools toplev.py to get percentages for: Retiring (useful work), Bad Speculation (wasted work), Frontend Bound (instruction fetch issues), Backend Bound (execution issues). 2) Identify dominant category - focus on the category with highest percentage (often Backend Bound for unoptimized code). 3) If Frontend Bound dominant: drill into Frontend Latency (I-cache misses, ITLB misses) vs Frontend Bandwidth (decoder throughput). Fix: simplify code, improve instruction locality. 4) If Bad Speculation dominant: drill into Branch Mispredict vs Machine Clears. Fix: improve branch predictability, avoid self-modifying code. 5) If Backend Bound dominant: drill into Memory Bound vs Core Bound. 6) If Memory Bound: check L1/L2/L3 Bound and DRAM Bound to identify which level. Fix: improve cache usage, prefetch, reduce memory traffic. 7) If Core Bound: check Port Utilization to find saturated execution units. Fix: reduce dependency chains, increase ILP, use different instruction mix. Key insight: only optimize the bottleneck category - improving non-bottleneck areas provides no benefit.

Follow this 10-step sort optimization process: 1) Profile current sort - measure comparison count, swap count, cache misses. 2) Check data characteristics - size, distribution (nearly sorted, random, many duplicates), key type. 3) For small arrays (<50 elements) - use insertion sort; best for small N due to low overhead. 4) For medium arrays (50-1000) - quicksort variants with good pivot selection (median-of-three). 5) For large arrays - consider cache-aware algorithms like cache-oblivious mergesort or radix sort for integers. 6) For nearly sorted data - insertion sort or timsort which detects and exploits runs. 7) For many duplicates - use 3-way partitioning quicksort (Dutch National Flag). 8) Optimize comparison function - inline, minimize branches, compare discriminating fields first. 9) Use SIMD for sorting networks - for fixed small sizes, SIMD sorting networks are very fast. 10) Consider radix sort for integers/strings - O(nk) can beat O(n log n) for appropriate data. Benchmark standard library sort (usually introsort) as baseline; often highly optimized already.

Follow this 10-step network I/O benchmarking process: 1) Define metrics - throughput (bytes/second), latency (time per operation), connections per second. 2) Establish baseline - use standard tools: iperf3 for throughput, ping/hping for latency. 3) Control network conditions - test on isolated network or emulate conditions with tc (traffic control). 4) Warm up connections - TCP slow start affects initial measurements; run warm-up period. 5) Measure at multiple layers - raw socket, TCP, HTTP, application protocol - to isolate overhead sources. 6) Test various payload sizes - performance characteristics differ for small vs large transfers. 7) Test concurrent connections - single connection vs many; contention and scaling behavior. 8) Measure both client and server - bottleneck may be on either end. 9) Profile CPU usage - network I/O can be CPU-bound with high connection counts or encryption. 10) Compare against theoretical limits - calculate maximum based on link speed, latency; measure achieved percentage. Tools: wrk/wrk2 for HTTP, netperf for low-level, custom benchmarks for application protocols. Account for: TCP overhead, encryption (TLS), serialization.

Follow this 11-point microarchitecture optimization checklist: 1) Identify target microarchitecture - determine specific CPU family (Skylake, Zen 3, etc.) in deployment. 2) Study microarchitecture resources - Agner Fog's instruction tables, Intel/AMD optimization manuals. 3) Understand execution resources - number of ports, which instructions use which ports, throughput/latency. 4) Check instruction latencies - critical for dependency chains; prefer lower-latency alternatives. 5) Balance port utilization - avoid saturating single port; spread work across available units. 6) Respect retirement width - 4-6 micro-ops/cycle on modern CPUs; don't exceed sustainable rate. 7) Use appropriate vector width - wider SIMD (AVX-512) may cause frequency reduction on some CPUs. 8) Consider cache hierarchy - L1/L2/L3 sizes and latencies vary by microarchitecture. 9) Check feature availability - not all instructions available on all CPUs; use CPUID for runtime detection. 10) Use -march appropriately - -march=native for single target, specific -march=skylake etc for known deployment. 11) Test on target hardware - simulator/emulator performance doesn't reflect real microarchitecture behavior. Trade-off: highly tuned code may pessimize on other microarchitectures; consider multi-versioning.

Follow this 10-step memory bandwidth optimization process: 1) Measure current bandwidth usage - use Intel PCM, likwid, or perf with memory controller events. 2) Calculate theoretical peak - check CPU specs for max memory bandwidth (e.g., DDR4-3200 dual channel = 51.2 GB/s). 3) Calculate achieved vs peak ratio - if <50% of peak, there's room for improvement; if near peak, must reduce memory traffic. 4) Reduce unnecessary memory traffic - eliminate redundant loads/stores, use registers for temporaries. 5) Improve cache utilization - tiling and blocking to keep data in cache, reducing main memory accesses. 6) Use non-temporal stores - for write-only data that won't be read again, skip cache pollution with mm_stream*. 7) Optimize prefetching - ensure prefetches don't exceed available bandwidth, causing contention. 8) Consider compression - if compute-cheap, compress data to reduce memory traffic. 9) Use appropriate data types - float vs double halves bandwidth requirement; int16_t vs int32_t similarly. 10) For multi-threaded code - ensure threads access local NUMA memory, consider bandwidth-aware thread scheduling. Key insight: memory-bound code scales poorly - adding threads doesn't help if bandwidth is saturated.

Follow this 10-step emergency performance triage process: 1) Acknowledge and communicate - alert relevant teams, set expectations for resolution time. 2) Assess impact scope - how many users affected, which services, severity? 3) Check for recent changes - deployments, config changes, traffic patterns in last 24 hours. 4) Gather quick metrics - CPU, memory, disk I/O, network, error rates across affected services. 5) Identify proximate cause - is it application code, database, network, external dependency? 6) Apply temporary mitigation - scale up, enable rate limiting, disable expensive features, rollback if recent change. 7) Capture diagnostic data - while issue is occurring: thread dumps, heap dumps, traces, logs. 8) Root cause analysis - after mitigation, investigate captured data to find actual cause. 9) Implement proper fix - address root cause, not just symptoms. 10) Post-mortem - document incident, timeline, root cause, fix, prevention measures. Key principle: mitigate first, debug second. A working system at reduced capacity is better than extended downtime while investigating.

Follow this 11-step data structure optimization process: 1) Profile access patterns - identify which fields are accessed together, frequency of operations (read/write/iterate). 2) Measure current performance - baseline cache miss rates, memory bandwidth usage. 3) Calculate structure size and alignment - use sizeof(), check for padding with offsetof(). 4) Identify hot fields - fields accessed in tight loops or critical paths. 5) Group hot fields together - reorder struct members so hot fields are in same cache line (64 bytes). 6) Consider AoS vs SoA - if iterating over one field of many objects, SoA (separate arrays per field) improves spatial locality. 7) Reduce structure size - use smaller types where possible (int16_t vs int32_t), use bitfields for flags, remove unused fields. 8) Align to cache lines - use alignas(64) for frequently accessed structures to avoid split accesses. 9) Consider padding to avoid false sharing - in multi-threaded code, pad to 64 bytes between thread-local data. 10) Evaluate pointer vs index - indices into arrays have better cache behavior than pointers to dispersed memory. 11) Benchmark alternatives - test different layouts with production-like workload, as optimal depends on access pattern.

Follow this 11-step database query optimization process: 1) Profile query frequency and latency - identify hot queries (frequent) and slow queries (high latency). 2) Examine query plans - use EXPLAIN ANALYZE to see execution plan and actual times. 3) Check index usage - verify indexes exist and are used; add missing indexes for WHERE/JOIN columns. 4) Reduce round trips - batch queries, use JOINs instead of N+1 queries, fetch multiple results at once. 5) Limit result sets - use LIMIT, pagination; don't fetch more than needed. 6) Optimize data transfer - select only needed columns, not SELECT *; reduce transferred bytes. 7) Use connection pooling - connection creation is expensive; reuse connections. 8) Add application-level caching - cache read-heavy, rarely-changing data; use appropriate TTLs. 9) Use prepared statements - reduce parsing overhead for repeated queries. 10) Optimize transactions - minimize transaction scope and duration; avoid holding locks during app logic. 11) Consider denormalization - for read-heavy workloads, duplicate data to avoid expensive joins. Measure at application level: database latency is only part; include serialization, network, and app processing time.

Follow this diagnostic process when IPC is below 1.0: 1) Measure IPC precisely - use perf stat -e cycles,instructions to get accurate IPC value. 2) Check memory boundedness first - measure cache misses: perf stat -e L1-dcache-load-misses,LLC-load-misses. If LLC miss rate > 1%, memory latency is likely culprit. 3) If memory-bound: follow cache optimization checklist - improve locality, add prefetching, reduce working set. 4) Check branch mispredictions - perf stat -e branch-misses. If misprediction rate > 2%, branch prediction is culprit. 5) If branch-bound: follow branch optimization checklist - improve predictability, use branchless code. 6) Check for long dependency chains - look for serial arithmetic operations where each depends on previous result. 7) If dependency-bound: break chains with temporary variables, use associative transformations, increase ILP. 8) Check for execution port saturation - use VTune Port Utilization or pmu-tools. 9) If port-bound: use different instruction mix, reduce pressure on saturated ports. 10) Check for front-end issues - I-cache misses, complex instructions causing decode stalls. Low IPC is usually memory (most common), branches, or dependencies (in that order).

Follow this 10-step memory bandwidth optimization process: 1) Measure current bandwidth usage - use Intel PCM, likwid, or perf with memory controller events. 2) Calculate theoretical peak - check CPU specs for max memory bandwidth (e.g., DDR4-3200 dual channel = 51.2 GB/s). 3) Calculate achieved vs peak ratio - if <50% of peak, there's room for improvement; if near peak, must reduce memory traffic. 4) Reduce unnecessary memory traffic - eliminate redundant loads/stores, use registers for temporaries. 5) Improve cache utilization - tiling and blocking to keep data in cache, reducing main memory accesses. 6) Use non-temporal stores - for write-only data that won't be read again, skip cache pollution with mm_stream*. 7) Optimize prefetching - ensure prefetches don't exceed available bandwidth, causing contention. 8) Consider compression - if compute-cheap, compress data to reduce memory traffic. 9) Use appropriate data types - float vs double halves bandwidth requirement; int16_t vs int32_t similarly. 10) For multi-threaded code - ensure threads access local NUMA memory, consider bandwidth-aware thread scheduling. Key insight: memory-bound code scales poorly - adding threads doesn't help if bandwidth is saturated.

Follow this 10-step code size optimization checklist: 1) Measure code size - check binary size, use size command to see text segment. 2) Profile I-cache misses - use perf stat -e L1-icache-load-misses to measure instruction cache behavior. 3) Reduce function size - split large functions, move cold code to separate functions. 4) Use -Os flag - optimize for size; may be faster than -O3 if I-cache bound. 5) Avoid excessive inlining - inline only truly hot, small functions; large inlined functions bloat code. 6) Reduce template instantiations - templates generate separate code for each type; use type erasure where possible. 7) Use link-time optimization (LTO) - -flto enables cross-file optimization and dead code elimination. 8) Arrange functions by hotness - place hot functions together in memory; use profile-guided layout. 9) Consider compression - code compression techniques for embedded or cold code regions. 10) Review loop unrolling - excessive unrolling bloats code; tune unroll factor considering I-cache. Trade-off: smaller code has better I-cache hit rate but may have more instructions executed; profile both.

Follow this 10-step branch optimization process: 1) Profile branch mispredictions - use perf stat -e branches,branch-misses to get overall rate, target <1% for hot paths. 2) Identify mispredicted branches - use perf record -e branch-misses and perf report to find specific locations. 3) Analyze branch pattern - determine if branch is: always taken, always not-taken, alternating, random, or data-dependent. 4) For predictable branches: ensure hot path is fall-through, use likely/unlikely hints if available. 5) For unpredictable branches in loops: try loop unswitching to move branch outside loop. 6) For data-dependent branches: consider branchless alternatives using conditional moves (CMOV), arithmetic, or SIMD masking. 7) For multiple related branches: convert to lookup table or switch statement that compilers optimize better. 8) Reduce branch count: combine conditions, use short-circuit evaluation strategically. 9) Consider profile-guided optimization (PGO): compile with instrumentation, run representative workload, recompile with profile data. 10) Verify improvement: confirm misprediction rate dropped AND overall performance improved (branchless code may have higher latency).

Follow this 8-step parallelization decision process: 1) Profile first - identify if code is CPU-bound; parallelizing I/O-bound code rarely helps. 2) Measure serial fraction - use Amdahl's Law: if 50% is serial, max speedup is 2x regardless of core count. 3) Estimate parallelism - count independent operations; need more parallel work than available cores. 4) Calculate overhead - thread creation/joining costs ~1-10 microseconds, synchronization adds latency. 5) Decision point: if work per thread < 10,000 cycles, overhead likely exceeds benefit - do not parallelize. 6) Check memory bandwidth - if already memory-bound, more threads may contend for bandwidth without speedup. 7) Assess data sharing - heavy sharing requires synchronization; consider data partitioning or thread-local copies. 8) Choose parallelization strategy - task parallel (independent work items) or data parallel (same operation on partitioned data). For loops: parallelize outermost loop if possible to minimize fork/join overhead. Rule of thumb: parallelize when expected speedup > 2x and work per thread > 1 million cycles.

Follow this 8-step hot spot identification process: 1) Choose appropriate profiler - use sampling profiler (perf, VTune, Instruments) for low overhead and statistical accuracy. 2) Run representative workload - use production-like data and usage patterns, not toy inputs. 3) Ensure sufficient samples - minimum 1000 samples in hot regions for statistical reliability (run longer if needed). 4) Generate initial report - sort functions by CPU time (self time first, then including callees). 5) Identify hot spots - functions consuming >5% of total time are candidates for optimization. 6) Analyze call context - use call graph to understand HOW hot functions are reached (same function called from multiple paths may have different optimization strategies). 7) Generate flame graph - visual overview shows widest boxes as hottest paths, helps spot unexpected hot code. 8) Drill down with annotation - use perf annotate or VTune source view to find hot instructions within hot functions. Remember: some hot spots are fundamental (main computation) and cannot be eliminated; focus on reducible overhead and inefficiencies.

Follow this 9-step compiler optimization flag selection process: 1) Start with -O2 - balanced optimization, safe for production, good baseline. 2) Profile with -O2 - identify remaining hotspots and bottleneck types. 3) Try -O3 - adds aggressive optimizations (vectorization, unrolling); measure if it helps or hurts (code bloat can cause instruction cache misses). 4) Add -march=native - enables CPU-specific instructions (AVX2, etc.) for target machine; omit for portable binaries. 5) Consider -flto - Link-Time Optimization enables cross-file inlining and optimization; significant build time increase. 6) For floating-point heavy code: evaluate -ffast-math (may change results) or individual flags like -fno-math-errno. 7) Profile-Guided Optimization: compile with -fprofile-generate, run representative workload, recompile with -fprofile-use for best results. 8) Check for regressions - some optimizations can cause slowdowns; always measure. 9) Document final flags - record which flags used and why, include in build system. Avoid: -O0 in production (no optimization), -Os unless binary size critical (sacrifices speed), untested flag combinations.

Follow this 11-point microarchitecture optimization checklist: 1) Identify target microarchitecture - determine specific CPU family (Skylake, Zen 3, etc.) in deployment. 2) Study microarchitecture resources - Agner Fog's instruction tables, Intel/AMD optimization manuals. 3) Understand execution resources - number of ports, which instructions use which ports, throughput/latency. 4) Check instruction latencies - critical for dependency chains; prefer lower-latency alternatives. 5) Balance port utilization - avoid saturating single port; spread work across available units. 6) Respect retirement width - 4-6 micro-ops/cycle on modern CPUs; don't exceed sustainable rate. 7) Use appropriate vector width - wider SIMD (AVX-512) may cause frequency reduction on some CPUs. 8) Consider cache hierarchy - L1/L2/L3 sizes and latencies vary by microarchitecture. 9) Check feature availability - not all instructions available on all CPUs; use CPUID for runtime detection. 10) Use -march appropriately - -march=native for single target, specific -march=skylake etc for known deployment. 11) Test on target hardware - simulator/emulator performance doesn't reflect real microarchitecture behavior. Trade-off: highly tuned code may pessimize on other microarchitectures; consider multi-versioning.

Try optimizations in this order for CPU-bound loops: 1) Algorithm improvement - can you reduce complexity? O(n) vs O(n log n) matters more than micro-optimization. 2) Compiler optimization check - ensure -O2/-O3 enabled, check vectorization reports. 3) Loop-invariant code motion - move calculations that don't change per iteration outside the loop. 4) Strength reduction - replace expensive operations (multiply/divide) with cheaper ones (shift/add). 5) Common subexpression elimination - compute shared expressions once, store in variable. 6) Loop unrolling - try 2x, 4x, 8x unroll factors; let compiler try first with -funroll-loops. 7) Vectorization - if not auto-vectorized, address blockers (aliasing, alignment, dependencies). 8) Reduce function call overhead - inline small functions, avoid virtual calls in hot path. 9) Reduce branch count - combine conditions, use branchless techniques for unpredictable branches. 10) Instruction-level parallelism - reorder independent operations to fill pipeline. Stop when: target performance achieved, profiler shows different bottleneck, or optimization yields <5% improvement (diminishing returns).

Follow this 11-step SIMD vectorization process: 1) Identify vectorization candidate - find loops with independent iterations and arithmetic operations. 2) Check auto-vectorization first - compile with -O3 -march=native and check compiler reports (gcc: -fopt-info-vec-all, icc: -qopt-report=5). 3) If not auto-vectorized, identify blockers - look for: non-unit stride, data dependencies, function calls, complex control flow. 4) Simplify loop structure - remove conditionals, ensure trip count is known or add #pragma loop count. 5) Ensure proper alignment - align arrays to 16/32/64 bytes matching SIMD width (SSE=16, AVX=32, AVX-512=64). 6) Eliminate pointer aliasing - use restrict keyword or #pragma ivdep to tell compiler pointers don't alias. 7) Handle remainder iterations - decide between scalar epilog, masked operations, or padding. 8) Choose SIMD width - SSE (128-bit), AVX2 (256-bit), or AVX-512 (512-bit) based on target CPUs. 9) If manual vectorization needed - use intrinsics (mm256*), start with loads/stores, then operations. 10) Verify correctness - compare results against scalar version. 11) Benchmark - measure actual speedup, as theoretical gains may not materialize due to memory bandwidth limits.

Follow this 10-step branch optimization process: 1) Profile branch mispredictions - use perf stat -e branches,branch-misses to get overall rate, target <1% for hot paths. 2) Identify mispredicted branches - use perf record -e branch-misses and perf report to find specific locations. 3) Analyze branch pattern - determine if branch is: always taken, always not-taken, alternating, random, or data-dependent. 4) For predictable branches: ensure hot path is fall-through, use likely/unlikely hints if available. 5) For unpredictable branches in loops: try loop unswitching to move branch outside loop. 6) For data-dependent branches: consider branchless alternatives using conditional moves (CMOV), arithmetic, or SIMD masking. 7) For multiple related branches: convert to lookup table or switch statement that compilers optimize better. 8) Reduce branch count: combine conditions, use short-circuit evaluation strategically. 9) Consider profile-guided optimization (PGO): compile with instrumentation, run representative workload, recompile with profile data. 10) Verify improvement: confirm misprediction rate dropped AND overall performance improved (branchless code may have higher latency).

Follow this 11-step floating-point optimization process: 1) Profile FP operations - use perf with FP-specific events or VTune to count FLOPS and FP stalls. 2) Check for denormal penalties - denormalized numbers (very small values near zero) can be 100x slower; consider flushing to zero with _MM_SET_FLUSH_ZERO_MODE. 3) Identify precision requirements - float (32-bit) is 2x throughput of double (64-bit) for SIMD; use float if precision allows. 4) Use FMA instructions - fused multiply-add has lower latency than separate mul+add and may be more accurate. Enable with -mfma. 5) Consider -ffast-math - enables aggressive optimizations (reassociation, reciprocal approximations) that may change results. Use -fno-math-errno, -ffinite-math-only, -fno-trapping-math individually for finer control. 6) Reduce division - multiply by reciprocal when denominator is loop-invariant; division is 15-20x slower than multiplication. 7) Use intrinsics for special functions - approximate rsqrt, rcp are much faster than precise versions when acceptable. 8) Vectorize FP loops - SIMD provides 4x (SSE/float) to 16x (AVX-512/float) throughput. 9) Check for unnecessary type conversions - int-to-float conversions have latency. 10) Order operations for accuracy - sum small numbers first to reduce rounding error. 11) Verify numerical results - aggressive optimizations can change results; compare against reference implementation.

Follow this 10-step memory leak debugging process: 1) Confirm leak exists - monitor memory usage over time; growing usage without corresponding workload increase indicates leak. 2) Reproduce reliably - identify workload pattern that triggers leak; create minimal reproducer. 3) Quantify leak rate - measure bytes leaked per operation or per time period. 4) Run with leak detector - Valgrind Memcheck, AddressSanitizer (-fsanitize=address), or Dr. Memory. 5) Identify allocation site - detector reports where leaked memory was allocated. 6) Trace ownership - follow code path from allocation to understand intended deallocation point. 7) Identify missing free - find where deallocation should occur but doesn't. 8) Categorize leak type - true leak (lost pointer), logical leak (growing cache/queue), or reference cycle (garbage-collected languages). 9) Implement fix - add missing deallocation, limit cache size, break reference cycles. 10) Verify fix - rerun leak detector, monitor memory usage over extended period. For production: use sampling-based leak detectors (TCMalloc heap profiler) that have lower overhead than Valgrind.

Follow this 15-point benchmarking environment checklist: 1) Dedicated hardware - use machine not running other workloads. 2) Disable Turbo Boost - 'echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo'. 3) Set fixed CPU frequency - 'cpupower frequency-set -g performance -d FREQ -u FREQ'. 4) Disable hyper-threading if testing single-thread - isolate physical cores. 5) Set CPU governor to performance - 'cpupower frequency-set -g performance'. 6) Disable ASLR - 'echo 0 > /proc/sys/kernel/randomize_va_space'. 7) Set CPU affinity - pin benchmark to specific cores with taskset. 8) Disable swap - 'swapoff -a' to ensure consistent memory behavior. 9) Drop caches before test - 'echo 3 > /proc/sys/vm/drop_caches'. 10) Minimize background processes - stop unnecessary services. 11) Use isolcpus - boot parameter to reserve cores from scheduler. 12) Disable network interrupts - on benchmark cores. 13) Wait for thermal equilibrium - let system temperature stabilize. 14) Record environment - CPU model, frequencies, kernel version, compiler version. 15) Validate repeatability - run multiple times, verify low variance (<5% coefficient of variation).

Follow this 9-step VLIW instruction scheduling process: 1) Understand the target architecture - identify number of functional units, instruction latencies, and bundle width (how many ops per VLIW word). 2) Build dependency graph - create DAG of instructions showing true dependencies (RAW), anti-dependencies (WAR), and output dependencies (WAW). 3) Calculate critical path - find longest dependency chain; this is minimum execution time. 4) Identify parallelism - find independent instruction groups that can execute simultaneously. 5) Apply list scheduling - prioritize instructions by: critical path length, number of successors, resource constraints. 6) Pack into bundles - place compatible instructions in same VLIW word respecting functional unit constraints. 7) Handle hazards - insert NOPs where dependencies cannot be satisfied by scheduling. 8) Consider software pipelining - for loops, overlap iterations by starting iteration N+1 before N completes, using modulo scheduling. 9) Minimize code size - balance between NOP insertion (code bloat) and register pressure. Software pipelining particularly effective for VLIW as it exposes more parallelism than single-iteration scheduling.

Follow this 12-step hot loop optimization checklist: 1) Confirm hotness - verify loop consumes >10% of total cycles using profiler. 2) Measure baseline IPC - if IPC<1.0, suspect memory or dependency issues; if IPC>1.0, focus on reducing instruction count. 3) Count operations per iteration - tally loads, stores, FLOPs, branches, function calls. 4) Check loop-carried dependencies - identify if iteration N depends on iteration N-1 results. 5) Verify compiler optimizations applied - check compiler reports for vectorization, unrolling status. 6) Profile cache behavior - measure L1/L2/L3 miss rates for loop accesses. 7) Check memory access pattern - verify sequential/strided access, look for indirect addressing. 8) Assess branch predictability - profile branch misprediction rate within loop. 9) Evaluate vectorization potential - check for data dependencies preventing SIMD. 10) Consider loop transformations - interchange, tiling, fusion, fission as applicable. 11) Implement changes one at a time - measure after each. 12) Verify correctness - ensure loop produces identical results post-optimization.

Follow this 9-step instruction count reduction process: 1) Profile instruction mix - use perf stat to get total instructions, breakdown by type if available. 2) Identify high-instruction-count regions - use perf annotate to see instruction counts per source line. 3) Look for redundant computations - common subexpressions, loop-invariant calculations, repeated checks. 4) Apply strength reduction - replace expensive ops: multiply by power of 2 -> shift, divide -> multiply by reciprocal, modulo -> bitwise AND for power-of-2 divisors. 5) Use lookup tables - for complex calculations with small input domain, precompute results. 6) Leverage SIMD - one vector instruction replaces 4-16 scalar instructions. 7) Use specialized instructions - POPCNT for bit counting, LZCNT for leading zeros, FMA for multiply-add. 8) Simplify control flow - merge similar branches, eliminate dead code, simplify predicates. 9) Measure actual impact - fewer instructions doesn't always mean faster if new instructions are higher latency or cause other bottlenecks. Focus on hot code paths; reducing cold code instructions has minimal impact.

Follow this 10-step power optimization process: 1) Profile power usage - use Intel RAPL (Running Average Power Limit), powertop, or hardware power meters. 2) Understand power-performance trade-off - reducing frequency saves power but increases latency. 3) Optimize for completion time - faster completion allows longer idle periods; Race to Sleep strategy. 4) Use appropriate SIMD width - AVX-512 can cause frequency reduction on some CPUs; AVX2 may be more power-efficient. 5) Reduce memory traffic - DRAM access consumes significant power; cache optimization helps power too. 6) Use sleep states - yield CPU during waits rather than spinning; use condition variables. 7) Batch operations - process data in bursts allowing CPU to enter deeper sleep states between. 8) Consider compute intensity - power ~= constant + activity; more compute per memory access is more efficient. 9) Tune frequency governors - for sustained workloads, consider 'powersave' governor with occasional bursts. 10) Profile energy-delay product - minimize Energy x Time rather than just one metric. For servers: power efficiency (perf/watt) often more important than raw performance; for mobile: battery life critical.

Follow these optimization steps for matrix multiplication in order: 1) Baseline - implement naive O(n^3) triple loop, measure GFLOPS. 2) Loop reordering - change loop order to i-k-j for row-major arrays (improves B access pattern). 3) Register blocking - unroll inner loops to keep small blocks in registers, reducing load/store. 4) Cache tiling - tile for L1 cache (typically 32x32 to 64x64 blocks for double precision). 5) Multi-level tiling - add L2 tile level for larger matrices. 6) SIMD vectorization - vectorize innermost loop using AVX2 (4 doubles) or AVX-512 (8 doubles). 7) Software pipelining - prefetch next tiles while computing current. 8) Parallelization - parallelize outer tile loops with OpenMP. 9) NUMA awareness - ensure data locality for thread-tile mapping. 10) Specialized handling - separate paths for small matrices (direct computation) vs large (blocked). Compare against BLAS library (OpenBLAS, MKL) as ultimate baseline; well-tuned BLAS typically achieves 80%+ of theoretical peak FLOPS.

Try optimizations in this order for memory-bound code: 1) Algorithmic improvement - reduce memory access complexity (O(n) accesses vs O(n^2)). 2) Data layout optimization - convert AoS to SoA if processing single field at a time. 3) Loop tiling/blocking - process cache-sized chunks to maximize reuse. 4) Loop fusion - combine loops accessing same data to improve temporal locality. 5) Data alignment - align to cache lines to avoid split accesses. 6) Prefetching - software prefetch for irregular access patterns not handled by hardware. 7) Reduce data size - use smaller types (float vs double, int16 vs int32) if precision allows. 8) Compress data - if compute-cheap, compress to reduce memory traffic. 9) Non-temporal stores - for write-only streaming, bypass cache to avoid pollution. 10) NUMA optimization - bind threads and data to same NUMA node. 11) Huge pages - reduce TLB misses for large working sets. Stop when: profile shows code is no longer memory-bound (check TMAM), or target performance achieved. Common mistake: trying to improve IPC when memory-bound - IPC will remain low until memory pressure reduced.

Follow this 10-step allocation optimization process: 1) Profile allocations - use heap profiler (Massif, Heaptrack) to count allocations and measure overhead. 2) Identify hot allocators - find code paths with most frequent allocations. 3) Calculate allocation cost - typical malloc: 50-200 cycles; for small allocations, overhead dominates. 4) Consider object pooling - pre-allocate pool of objects, reuse instead of alloc/free. 5) Use arena allocators - allocate from contiguous region, free all at once; excellent for phase-based work. 6) Enable small block optimizers - jemalloc, tcmalloc have optimized small allocation paths. 7) Use stack allocation - alloca or VLAs for temporary, known-bounded data (be careful of stack overflow). 8) Batch allocations - allocate array of N objects instead of N separate allocations. 9) Consider custom allocators - for specific size classes, slab allocators eliminate fragmentation and overhead. 10) Reduce allocation count - reuse buffers, use string_view instead of string copies, pass by reference. Measure: profile allocation rate (per second) and total overhead; target <5% of CPU time on allocations.

Follow this 10-step PGO checklist: 1) Understand PGO mechanism - compiler instruments code to collect runtime data, then uses data to optimize. 2) Build instrumented binary - GCC: -fprofile-generate, Clang: -fprofile-instr-generate, MSVC: /GENPROFILE. 3) Run with representative workload - critical step; profile data must reflect production usage patterns. Include common paths, edge cases, various input sizes. 4) Cover code paths adequately - aim for >80% code coverage; uncovered code won't benefit. 5) Run sufficient iterations - ensure statistical significance in collected data. 6) Collect profile data - GCC: .gcda files generated on program exit; Clang: merge with llvm-profdata. 7) Build optimized binary - GCC: -fprofile-use, Clang: -fprofile-use=default.profdata, MSVC: /USEPROFILE. 8) Measure improvement - typical gains: 10-30% for branch-heavy code; less for compute-heavy. 9) Validate correctness - PGO-optimized code must produce same results. 10) Maintain profile data - re-profile when code changes significantly; stale profiles can cause pessimization. PGO benefits: better branch prediction hints, optimal function inlining, improved basic block placement.

Follow this 8-step loop fusion process: 1) Identify fusion candidates - separate loops with same iteration bounds and no conflicting dependencies. 2) Check dependency safety - loop 2 must not read values that loop 1 writes in later iterations. Fusion is safe if: loops are independent, or loop 2 only reads what loop 1 wrote in same iteration. 3) Analyze cache benefit - fusion beneficial when: loops access same data (improved temporal locality), combined body still fits in registers. 4) Check code size impact - fused loop body must not exceed I-cache capacity; may hurt if bodies are large. 5) Implement fusion - combine loop bodies, merge induction variables. Before: for(i) A[i]=..; for(i) B[i]=A[i]+..; After: for(i) { A[i]=..; B[i]=A[i]+..; } 6) Handle different iteration counts - if counts differ, fuse common portion, separate epilog for remainder. 7) Verify correctness - fused loop must produce identical results to original sequence. 8) Measure improvement - check reduced cache misses and overall speedup. Fusion reduces loop overhead and improves locality but increases register pressure and code size.

Follow this 10-point cross-vendor optimization checklist: 1) Identify target CPUs - determine if code will run on Intel-only, AMD-only, or both. 2) Check instruction availability - AVX-512 availability varies; AMD added support in Zen 4. 3) Consider cache differences - AMD typically has larger L3, different associativity; Intel has larger L2 per core. 4) Check SIMD performance - some SIMD instructions have different throughput/latency between vendors. 5) Profile on both architectures - performance characteristics can differ significantly. 6) Use vendor-agnostic intrinsics - prefer generic _mm* over vendor-specific extensions. 7) Check branch predictor differences - some patterns predicted differently; profile branch misses on both. 8) Consider NUMA topology - AMD chiplet design has different NUMA characteristics than Intel monolithic. 9) Test AVX2 vs AVX-512 - on AMD, AVX-512 may not be faster due to frequency scaling; benchmark. 10) Use runtime dispatch - detect CPU features and dispatch to optimized code paths: __builtin_cpu_supports(). For portable code: optimize for common subset (AVX2), add special paths for vendor-specific features with runtime detection.

Follow this 14-step cache optimization checklist: 1) Measure baseline - profile L1/L2/L3 hit rates and miss penalties using perf or Cachegrind. 2) Understand cache parameters - L1: 32-64KB, 4-8 way, 64B lines; L2: 256KB-1MB; L3: shared, multi-MB. 3) Calculate working set size - total unique data accessed in hot regions. 4) If working set > cache: apply blocking/tiling to process data in cache-sized chunks. 5) If spatial locality poor: reorganize data layout for sequential access, convert AoS to SoA. 6) If temporal locality poor: reorder computations to reuse data while still in cache. 7) Align data structures - align to 64-byte cache line boundaries to avoid split accesses. 8) Avoid false sharing in parallel code - pad structures so different threads don't share cache lines. 9) Use prefetching for predictable access - software prefetch 200-400 cycles ahead of use. 10) Minimize pointer chasing - linearize linked structures or use indices into arrays. 11) Consider cache-oblivious algorithms - algorithms that work well regardless of cache size. 12) Profile TLB misses - if high, consider huge pages (2MB instead of 4KB). 13) Check NUMA locality - ensure data allocated on same node as accessing CPU. 14) Verify improvements - confirm cache miss reduction yields proportional speedup.

Follow this 10-step PGO checklist: 1) Understand PGO mechanism - compiler instruments code to collect runtime data, then uses data to optimize. 2) Build instrumented binary - GCC: -fprofile-generate, Clang: -fprofile-instr-generate, MSVC: /GENPROFILE. 3) Run with representative workload - critical step; profile data must reflect production usage patterns. Include common paths, edge cases, various input sizes. 4) Cover code paths adequately - aim for >80% code coverage; uncovered code won't benefit. 5) Run sufficient iterations - ensure statistical significance in collected data. 6) Collect profile data - GCC: .gcda files generated on program exit; Clang: merge with llvm-profdata. 7) Build optimized binary - GCC: -fprofile-use, Clang: -fprofile-use=default.profdata, MSVC: /USEPROFILE. 8) Measure improvement - typical gains: 10-30% for branch-heavy code; less for compute-heavy. 9) Validate correctness - PGO-optimized code must produce same results. 10) Maintain profile data - re-profile when code changes significantly; stale profiles can cause pessimization. PGO benefits: better branch prediction hints, optimal function inlining, improved basic block placement.

Try optimizations in this order for memory-bound code: 1) Algorithmic improvement - reduce memory access complexity (O(n) accesses vs O(n^2)). 2) Data layout optimization - convert AoS to SoA if processing single field at a time. 3) Loop tiling/blocking - process cache-sized chunks to maximize reuse. 4) Loop fusion - combine loops accessing same data to improve temporal locality. 5) Data alignment - align to cache lines to avoid split accesses. 6) Prefetching - software prefetch for irregular access patterns not handled by hardware. 7) Reduce data size - use smaller types (float vs double, int16 vs int32) if precision allows. 8) Compress data - if compute-cheap, compress to reduce memory traffic. 9) Non-temporal stores - for write-only streaming, bypass cache to avoid pollution. 10) NUMA optimization - bind threads and data to same NUMA node. 11) Huge pages - reduce TLB misses for large working sets. Stop when: profile shows code is no longer memory-bound (check TMAM), or target performance achieved. Common mistake: trying to improve IPC when memory-bound - IPC will remain low until memory pressure reduced.

Follow this 11-step distributed systems performance debugging process: 1) Define the symptom - quantify: which requests are slow, how slow, what percentile affected? 2) Collect distributed traces - use Jaeger, Zipkin, or vendor tracing to see request flow. 3) Identify slow spans - find which service/component contributes most latency. 4) Check for queuing - high queue time indicates insufficient capacity or slow downstream. 5) Profile the slow component - use local profiling techniques on identified service. 6) Check network latency - measure RTT between services; unexpected high latency indicates network issues. 7) Look for retry amplification - retries causing load increase, causing more retries. 8) Check for resource contention - CPU, memory, connections, thread pools hitting limits. 9) Analyze dependencies - slow downstream service can cause upstream queuing. 10) Check for data skew - uneven load distribution causing some instances to be hot. 11) Verify with fix - implement fix, monitor distributed traces to confirm improvement. Key insight: in distributed systems, latency is often dominated by network, queuing, and serialization - not CPU computation.

Follow this 8-step memory alignment optimization process: 1) Identify alignment requirements - SSE needs 16-byte, AVX needs 32-byte, AVX-512 needs 64-byte alignment; cache lines are 64 bytes. 2) Check current alignment - use (uintptr_t)ptr % alignment or assert((uintptr_t)ptr & (alignment-1) == 0). 3) For stack variables: use alignas(N) specifier in C++11+ or attribute((aligned(N))). 4) For heap allocations: use aligned_alloc(alignment, size), _mm_malloc(size, alignment), or posix_memalign(). 5) For structure members: use alignas() or pack/align pragmas; be aware of padding impact on size. 6) Verify SIMD load/store instructions: use aligned loads (_mm256_load_ps) when alignment guaranteed, unaligned (_mm256_loadu_ps) otherwise. 7) Measure performance difference - on modern CPUs (Haswell+), unaligned access penalty is small UNLESS crossing cache line boundary; crossing penalty is significant. 8) Consider cache line alignment for hot data - align frequently accessed data to 64-byte boundaries to avoid split loads and false sharing. Trade-off: over-alignment wastes memory; align only what's performance-critical.

Follow this 10-step JSON parsing optimization process: 1) Profile current parser - measure parse time, memory allocations, CPU cycles per byte. 2) Choose fast parser library - simdjson (fastest), rapidjson, yyjson outperform standard library parsers. 3) Use lazy parsing - parse on-demand rather than building full DOM if only accessing few fields. 4) Avoid string copies - use string views into original buffer rather than copying strings. 5) Pre-allocate buffers - reuse parser state and output buffers across parses. 6) Use binary formats for internal communication - MessagePack, Protocol Buffers, FlatBuffers avoid parse overhead. 7) Schema-aware parsing - if structure is known, generate specialized parser (code generation). 8) SIMD acceleration - simdjson uses SIMD for structural character scanning; huge speedup. 9) Streaming parse for large documents - avoid loading entire document into memory. 10) Profile memory allocation - JSON parsing often allocation-heavy; arena allocators help. Benchmark: simdjson achieves 2-3 GB/s parsing speed; compare against your current solution. For serialization, similar process: use fast library, avoid intermediate strings, stream output.

Follow this 15-step micro-benchmark creation checklist: 1) Define what you're measuring - single specific operation, not compound behavior. 2) Isolate the code under test - remove unrelated setup/teardown from timed region. 3) Prevent dead code elimination - use result (Blackhole.consume in JMH, DoNotOptimize in Google Benchmark). 4) Prevent constant folding - use runtime inputs, not compile-time constants. 5) Control iteration count - let framework determine iterations, don't add manual loops. 6) Warm up properly - run enough iterations for JIT compilation (JVM) or cache warming. 7) Pin CPU frequency - disable Turbo Boost and frequency scaling for consistency. 8) Pin threads to cores - use taskset/numactl to avoid migration. 9) Run sufficient trials - minimum 10 iterations, ideally 30+ for statistical validity. 10) Measure variance - report standard deviation and confidence intervals, not just mean. 11) Use appropriate time resolution - std::chrono::high_resolution_clock, QueryPerformanceCounter, or RDTSC. 12) Account for timer overhead - measure and subtract if measuring sub-microsecond operations. 13) Test multiple input sizes - performance may vary non-linearly with size. 14) Compare against baseline - always measure relative improvement, not just absolute numbers. 15) Document environment - record CPU model, compiler version, flags, OS version.

Follow this 11-step hash table optimization checklist: 1) Profile access patterns - measure lookup/insert/delete frequency, hit rate, probe length. 2) Choose appropriate load factor - 0.5-0.7 balances memory and performance; lower for latency-critical. 3) Select hash function - use fast, high-quality hash (xxHash, wyhash, or built-in); avoid cryptographic hashes. 4) Minimize key comparison cost - store hash values to avoid recomputing; use prefix comparison for strings. 5) Optimize probing strategy - linear probing has better cache behavior than separate chaining. 6) Use power-of-2 sizes - enables fast modulo via bitwise AND. 7) Implement SIMD parallel lookup - compare multiple keys simultaneously using vector instructions. 8) Prefetch during probing - prefetch next probe location while checking current. 9) Consider flat hash maps - store entries inline rather than following pointers (better cache). 10) Handle hot keys - very frequently accessed keys can use separate fast path or front-of-bucket. 11) Profile memory usage - hash tables can waste significant memory; Swiss table and similar designs improve density. Benchmark against robin hood, cuckoo, and Swiss table variants for your access pattern.

Follow this 8-step loop fusion process: 1) Identify fusion candidates - separate loops with same iteration bounds and no conflicting dependencies. 2) Check dependency safety - loop 2 must not read values that loop 1 writes in later iterations. Fusion is safe if: loops are independent, or loop 2 only reads what loop 1 wrote in same iteration. 3) Analyze cache benefit - fusion beneficial when: loops access same data (improved temporal locality), combined body still fits in registers. 4) Check code size impact - fused loop body must not exceed I-cache capacity; may hurt if bodies are large. 5) Implement fusion - combine loop bodies, merge induction variables. Before: for(i) A[i]=..; for(i) B[i]=A[i]+..; After: for(i) { A[i]=..; B[i]=A[i]+..; } 6) Handle different iteration counts - if counts differ, fuse common portion, separate epilog for remainder. 7) Verify correctness - fused loop must produce identical results to original sequence. 8) Measure improvement - check reduced cache misses and overall speedup. Fusion reduces loop overhead and improves locality but increases register pressure and code size.

Follow this 12-step performance regression debugging process: 1) Confirm the regression - verify with multiple runs that performance actually degraded (not measurement noise). 2) Quantify the regression - measure exact percentage slowdown and which metrics changed (latency, throughput, CPU time). 3) Identify the regression window - use git bisect to find the exact commit that introduced the regression. 4) Compare profiles before/after - run same profiler on good and bad versions with identical workload. 5) Generate differential flame graph - visualize what got slower (red) vs faster (blue). 6) Analyze the diff - identify which functions show increased time. 7) Check for obvious causes - new allocations, additional logging, changed algorithms, new dependencies. 8) Profile specific metrics - if not obvious, profile cache misses, branch mispredictions, IPC separately. 9) Inspect code changes - review the diff of the regression commit for performance-impacting changes. 10) Form hypothesis - propose specific cause based on profile differences. 11) Verify hypothesis - create minimal reproducer or targeted benchmark. 12) Fix and verify - implement fix, confirm regression is resolved, ensure no new regressions introduced. Add regression test to CI to prevent recurrence.

Follow this 9-step software prefetching process: 1) Identify prefetch candidates - loops with: predictable access pattern, large data that doesn't fit cache, high cache miss rate on profiling. 2) Verify hardware prefetcher isn't sufficient - sequential and simple strided patterns are often handled automatically. 3) Calculate prefetch distance - prefetch D iterations ahead where D = memory_latency / loop_iteration_time. Typical: 100-300 cycles latency / 10-50 cycles per iteration = 3-30 iterations ahead. 4) Choose prefetch type - _mm_prefetch with _MM_HINT_T0 (all cache levels) for data used soon, _MM_HINT_NTA (non-temporal) for data used once. 5) Insert prefetch instructions - at loop start, prefetch data for iteration i+D while processing iteration i. 6) Avoid over-prefetching - too many prefetches can evict useful data and saturate memory bandwidth. 7) Handle loop boundaries - don't prefetch beyond array bounds (use conditional or limit prefetch iterations). 8) Measure impact - compare cache miss rate and runtime; prefetching should reduce misses without increasing total memory traffic significantly. 9) Test on target hardware - optimal distance varies by CPU; tune for deployment platform.

Follow this 10-step startup optimization process: 1) Profile startup - use strace -tt -T to see syscalls, perf record from process start. 2) Identify phases - categorize: loading, parsing, initialization, warm-up. 3) Measure dynamic linking time - large number of shared libraries adds loading overhead; consider static linking. 4) Lazy initialize - defer initialization until first use; avoid loading unused features. 5) Reduce I/O - combine config files, use memory-mapped files, parallelize independent reads. 6) Optimize parsing - use faster parsers, binary formats instead of JSON/XML for large configs. 7) Use dlopen for optional features - load plugins on-demand rather than at startup. 8) Cache computed state - serialize initialized state to disk, reload on subsequent starts. 9) Parallelize initialization - independent subsystems can initialize concurrently. 10) Profile and eliminate - use flame graph of startup to identify and remove unnecessary work. Tools: systemd-analyze for service startup, bootchart for system-level, custom timestamps for application-level. Goal: minimize time-to-first-useful-output.

Follow this 10-step memory access optimization process: 1) Profile cache miss rates - use perf stat -e L1-dcache-load-misses,LLC-load-misses to identify miss levels. 2) Identify miss source - if L1 misses high but L2 hits, data not fitting L1; if LLC misses high, data not in cache at all. 3) Analyze access pattern - check if sequential (spatial locality good), strided (may miss cache lines), or random (poor locality). 4) Check data structure layout - Array of Structures (AoS) vs Structure of Arrays (SoA), identify if accessing cold fields. 5) Evaluate working set size - compare data size to cache sizes (L1: 32KB, L2: 256KB, L3: varies). 6) If random access pattern: consider prefetching, restructure algorithm, or use cache-oblivious data structures. 7) If strided access: apply loop interchange to improve stride, consider data layout transformation. 8) If working set too large: apply loop tiling/blocking to fit in cache. 9) Check alignment - ensure data aligned to cache line boundaries (64 bytes). 10) Re-profile after each change - verify cache miss reduction translates to speedup.

Follow this 8-step register optimization process: 1) Identify register pressure issues - look for spill/fill instructions in generated assembly, or use compiler reports. 2) Count live variables - at any point, live variables > available registers causes spills. x86-64 has 16 general-purpose, 16 vector registers. 3) Reduce variable lifetimes - compute values as late as possible, use values as soon as computed. 4) Split hot and cold paths - keep register-intensive code on hot path; cold paths can spill. 5) Use function parameters wisely - first 6 integer args and first 8 FP args passed in registers (x86-64 SysV ABI). 6) Consider manual register hints - use register keyword (hint only), or inline assembly for critical sections. 7) Restructure code - split large functions, move invariants outside loops, reduce nested scopes. 8) Check compiler options - -freg-struct-return, -mprefer-vector-width affect register usage. Key insight: modern compilers have excellent register allocators; manual intervention rarely helps except in extreme cases. Focus on reducing variable count and scope instead.

Follow this 9-step cache thrashing diagnosis and fix process: 1) Detect thrashing symptoms - high cache miss rate despite working set appearing to fit in cache. 2) Profile cache behavior - use Cachegrind or perf to measure actual miss rates vs expected. 3) Identify conflict misses - thrashing occurs when multiple data items map to same cache set, evicting each other. 4) Analyze access patterns - find which arrays/structures are accessed together and their addresses. 5) Check alignment/stride - power-of-2 strides with power-of-2 array sizes cause conflict misses. 6) Calculate conflict addresses - items conflict if: (address1 / cache_line_size) mod num_sets == (address2 / cache_line_size) mod num_sets. 7) Apply padding - add padding to shift one array's addresses to different sets. Typical: add cache_line_size bytes. 8) Use different allocation strategy - malloc may align large allocations; use memalign with offset. 9) Verify fix - re-profile to confirm miss rate decreased and performance improved. Example: two 4KB arrays both at 4KB-aligned addresses conflict in every L1 set; padding one by 64 bytes eliminates conflicts.

Follow these optimization steps for memory-intensive batch processing: 1) Profile memory usage - identify peak memory, allocation patterns, and hot allocation sites. 2) Stream instead of load all - process data incrementally rather than loading entire dataset into memory. 3) Use memory-mapped files - let OS manage paging for large files instead of explicit reads. 4) Implement chunked processing - process data in cache-friendly chunk sizes (e.g., 1-4MB chunks). 5) Optimize data representation - use smaller types, compression, or packed formats to reduce footprint. 6) Reuse buffers - allocate buffers once and reuse across iterations rather than reallocating. 7) Use arena allocators - for temporary allocations within batch items, reset arena between items. 8) Process in cache-optimal order - access data in patterns that maximize cache hits. 9) Prefetch upcoming chunks - while processing chunk N, prefetch chunk N+1 data. 10) Parallelize with memory awareness - partition data to minimize cross-thread memory contention. 11) Consider out-of-core algorithms - for datasets exceeding RAM, use external memory algorithms. Goal: maintain constant memory usage regardless of input size while maximizing throughput.

Follow this 9-step string optimization process: 1) Profile string operations - identify hot string functions (strcmp, strlen, memcpy, parsing). 2) Use SIMD string functions - modern libraries (glibc, MSVC) have AVX2-optimized implementations. 3) Avoid unnecessary allocations - reuse buffers, use string views/spans instead of copying. 4) Use small string optimization (SSO) - std::string typically stores strings <15-23 chars inline without heap allocation. 5) Process in bulk - don't call strlen in every loop iteration; compute once and store. 6) Use memcmp/memcpy for known lengths - faster than strcmp/strcpy when length is known. 7) Consider specialized algorithms - for pattern matching, use SIMD-optimized search (SWAR, SSE4.2 PCMPESTRI). 8) Minimize format string parsing - printf-style formatting is slow; consider faster alternatives or pre-formatting. 9) Use interned strings for comparisons - compare pointers instead of content for frequently compared strings. Benchmark: simple optimizations (avoiding redundant strlen) often give bigger wins than complex SIMD; measure before implementing complex solutions.

Follow this 10-step network I/O benchmarking process: 1) Define metrics - throughput (bytes/second), latency (time per operation), connections per second. 2) Establish baseline - use standard tools: iperf3 for throughput, ping/hping for latency. 3) Control network conditions - test on isolated network or emulate conditions with tc (traffic control). 4) Warm up connections - TCP slow start affects initial measurements; run warm-up period. 5) Measure at multiple layers - raw socket, TCP, HTTP, application protocol - to isolate overhead sources. 6) Test various payload sizes - performance characteristics differ for small vs large transfers. 7) Test concurrent connections - single connection vs many; contention and scaling behavior. 8) Measure both client and server - bottleneck may be on either end. 9) Profile CPU usage - network I/O can be CPU-bound with high connection counts or encryption. 10) Compare against theoretical limits - calculate maximum based on link speed, latency; measure achieved percentage. Tools: wrk/wrk2 for HTTP, netperf for low-level, custom benchmarks for application protocols. Account for: TCP overhead, encryption (TLS), serialization.

Follow this 11-step real-time media optimization process: 1) Define latency budget - audio typically <10ms, video <33ms for 30fps; allocate per stage. 2) Use lock-free communication - between capture/process/playback threads to avoid priority inversion. 3) Pre-allocate all buffers - no runtime allocation; use circular buffers for streaming. 4) Avoid syscalls in processing - no file I/O, logging, or allocation in real-time thread. 5) Use SIMD extensively - media processing (filters, transforms) benefits greatly from vectorization. 6) Pin to dedicated cores - isolate real-time threads from system interrupts and other processes. 7) Use appropriate thread priority - SCHED_FIFO on Linux, THREAD_PRIORITY_TIME_CRITICAL on Windows. 8) Profile worst-case latency - measure 99.9th percentile, not average; spikes cause glitches. 9) Handle overload gracefully - drop frames rather than accumulating latency. 10) Use specialized DSP libraries - IPP, FFTW, vendor-specific audio libraries are highly optimized. 11) Test under stress - full CPU load, memory pressure, disk activity to find edge cases. Real-time constraint: every processing deadline must be met; missing one causes audible/visible glitch.

Follow this 10-step Valgrind usage checklist: 1) Build with debug info - compile with -g for source-level annotations. Keep -O2 for representative performance but consider -O0 for clearer traces. 2) Choose appropriate tool - Memcheck (default): memory errors; Cachegrind: cache simulation; Callgrind: call graph profiling; Massif: heap profiling; Helgrind/DRD: threading errors. 3) Expect slowdown - Memcheck: 10-50x slower, Cachegrind: 20-100x, Callgrind: 10-100x. Reduce input size accordingly. 4) Suppress known false positives - use suppression files to ignore expected errors from system libraries. 5) Run representative workload - even small inputs reveal cache behavior patterns. 6) Use annotation tools - cg_annotate for Cachegrind, callgrind_annotate for Callgrind, ms_print for Massif. 7) Focus on significant results - sort by impact (cache misses, time, allocations); ignore noise. 8) Check Cachegrind cache configuration - verify simulated cache matches target hardware: --I1, --D1, --LL options. 9) Use Callgrind with instrumentation control - CALLGRIND_START_INSTRUMENTATION/STOP to focus on hot code. 10) Interpret results carefully - Valgrind simulates, doesn't measure; use as relative comparison, not absolute numbers.

Follow this 12-step hot loop optimization checklist: 1) Confirm hotness - verify loop consumes >10% of total cycles using profiler. 2) Measure baseline IPC - if IPC<1.0, suspect memory or dependency issues; if IPC>1.0, focus on reducing instruction count. 3) Count operations per iteration - tally loads, stores, FLOPs, branches, function calls. 4) Check loop-carried dependencies - identify if iteration N depends on iteration N-1 results. 5) Verify compiler optimizations applied - check compiler reports for vectorization, unrolling status. 6) Profile cache behavior - measure L1/L2/L3 miss rates for loop accesses. 7) Check memory access pattern - verify sequential/strided access, look for indirect addressing. 8) Assess branch predictability - profile branch misprediction rate within loop. 9) Evaluate vectorization potential - check for data dependencies preventing SIMD. 10) Consider loop transformations - interchange, tiling, fusion, fission as applicable. 11) Implement changes one at a time - measure after each. 12) Verify correctness - ensure loop produces identical results post-optimization.

Follow this 15-point benchmarking environment checklist: 1) Dedicated hardware - use machine not running other workloads. 2) Disable Turbo Boost - 'echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo'. 3) Set fixed CPU frequency - 'cpupower frequency-set -g performance -d FREQ -u FREQ'. 4) Disable hyper-threading if testing single-thread - isolate physical cores. 5) Set CPU governor to performance - 'cpupower frequency-set -g performance'. 6) Disable ASLR - 'echo 0 > /proc/sys/kernel/randomize_va_space'. 7) Set CPU affinity - pin benchmark to specific cores with taskset. 8) Disable swap - 'swapoff -a' to ensure consistent memory behavior. 9) Drop caches before test - 'echo 3 > /proc/sys/vm/drop_caches'. 10) Minimize background processes - stop unnecessary services. 11) Use isolcpus - boot parameter to reserve cores from scheduler. 12) Disable network interrupts - on benchmark cores. 13) Wait for thermal equilibrium - let system temperature stabilize. 14) Record environment - CPU model, frequencies, kernel version, compiler version. 15) Validate repeatability - run multiple times, verify low variance (<5% coefficient of variation).

Follow this 13-point multi-threaded profiling checklist: 1) Profile single-threaded first - establish baseline, understand serial hot spots. 2) Use thread-aware profiler - VTune Threading analysis, perf with -t flag, or dedicated tools like Helgrind. 3) Measure scalability - run with 1, 2, 4, 8, N threads; calculate speedup = T1/TN. 4) Identify scalability limiters - is speedup sub-linear? Look for serial sections, contention, imbalanced work. 5) Profile lock contention - use perf lock, VTune Locks and Waits, or mutex debugging libraries. 6) Check for false sharing - if performance degrades with more threads, look for shared cache lines. 7) Verify work balance - check per-thread execution times; imbalance causes idle waiting. 8) Profile context switches - high context switch rate indicates excessive locking or thread thrashing. 9) Check NUMA effects - threads accessing remote memory have higher latency; use numactl to diagnose. 10) Measure synchronization overhead - time spent in barriers, locks, atomic operations. 11) Check memory bandwidth saturation - may limit scaling even if CPUs available. 12) Profile with production thread count - behavior may differ from small-scale testing. 13) Use timeline views - visualize thread activity over time to spot idle periods and synchronization patterns.

Try optimizations in this order for CPU-bound loops: 1) Algorithm improvement - can you reduce complexity? O(n) vs O(n log n) matters more than micro-optimization. 2) Compiler optimization check - ensure -O2/-O3 enabled, check vectorization reports. 3) Loop-invariant code motion - move calculations that don't change per iteration outside the loop. 4) Strength reduction - replace expensive operations (multiply/divide) with cheaper ones (shift/add). 5) Common subexpression elimination - compute shared expressions once, store in variable. 6) Loop unrolling - try 2x, 4x, 8x unroll factors; let compiler try first with -funroll-loops. 7) Vectorization - if not auto-vectorized, address blockers (aliasing, alignment, dependencies). 8) Reduce function call overhead - inline small functions, avoid virtual calls in hot path. 9) Reduce branch count - combine conditions, use branchless techniques for unpredictable branches. 10) Instruction-level parallelism - reorder independent operations to fill pipeline. Stop when: target performance achieved, profiler shows different bottleneck, or optimization yields <5% improvement (diminishing returns).

Apply loop optimizations in this recommended order: 1) Algorithm optimization - ensure you're using best algorithm; O(n) beats optimized O(n^2). 2) Loop-invariant code motion - move calculations that don't change per iteration outside loop. 3) Strength reduction - replace expensive ops (mul, div, mod) with cheaper ones (add, shift, mask). 4) Dead code elimination - remove calculations whose results are never used. 5) Loop interchange - for nested loops, reorder to improve memory access pattern. 6) Loop tiling/blocking - for cache locality when processing large arrays. 7) Loop fusion - combine adjacent loops with same bounds to improve locality. 8) Loop fission - split loop if it enables vectorization or reduces register pressure. 9) Loop unrolling - reduce loop overhead, expose ILP; try 2x, 4x factors. 10) Vectorization - SIMD for data-parallel operations. 11) Parallelization - multi-thread outer loops if sufficient work per thread. 12) Software pipelining - for VLIW or when other opts insufficient. Rationale: early opts may enable later ones (hoisting enables vectorization), algorithmic changes give biggest wins, parallelization adds complexity so comes last.

Follow this systematic 8-step process: 1) Establish baseline metrics - measure current performance with representative workloads, record wall time, CPU time, memory usage, and throughput. 2) Profile to identify hotspots - use sampling profiler (perf, VTune) to find where >10% of time is spent. 3) Categorize the bottleneck - determine if CPU-bound (high CPU utilization), memory-bound (high cache misses), I/O-bound (high wait time), or branch-bound (high misprediction rate). 4) Analyze the specific bottleneck - if memory-bound, profile cache behavior; if CPU-bound, check IPC and instruction mix. 5) Form optimization hypothesis - propose specific change based on bottleneck type. 6) Implement targeted fix - make ONE change at a time for measurable impact. 7) Measure improvement - re-profile with same workload, compare metrics quantitatively. 8) Iterate - if target not met, return to step 2; new hotspots may emerge after optimization. Critical rule: never optimize without profiling data first.

Follow this 10-step critical path latency reduction process: 1) Identify critical path - sequence of dependent operations determining minimum execution time. Use dependency analysis or VTune critical path view. 2) Measure path latency - sum instruction latencies along critical path. 3) Look for high-latency instructions - division (15-50 cycles), some shuffles, memory accesses on cache miss. 4) Replace high-latency ops - use approximations (rsqrt instead of 1/sqrt), lookup tables, or different algorithms. 5) Break dependency chains - use associativity to parallelize: (a+b)+(c+d) instead of a+b+c+d. 6) Use instruction-level parallelism - interleave independent operations to fill pipeline while waiting for dependencies. 7) Reduce memory latency impact - prefetch, improve locality, keep critical data in registers. 8) Avoid false dependencies - use different registers for independent computations to prevent false RAW hazards. 9) Consider out-of-order execution - modern CPUs reorder, but ROB size limits how far ahead they can look (~200 instructions). 10) Measure improvement - verify critical path shortened and latency reduced. Critical insight: reducing latency matters most for throughput when many instances are in-flight; for single execution, may not matter.

Follow this 10-point optimization correctness checklist: 1) Preserve semantics - optimized code must produce identical output for all valid inputs. 2) Test with original test suite - all existing tests must pass unchanged. 3) Add edge case tests - empty inputs, single elements, maximum sizes, boundary values. 4) Compare against reference - run both versions on diverse inputs, compare outputs exactly. 5) Test numerical stability - for floating-point, verify acceptable precision (may differ due to reassociation). 6) Check corner cases - negative numbers, zeros, NaN, infinity for floating-point. 7) Test with sanitizers - run with AddressSanitizer, UndefinedBehaviorSanitizer to catch subtle bugs. 8) Verify thread safety - if parallelized, test with ThreadSanitizer, various thread counts. 9) Stress test - large inputs, sustained load, verify no degradation or crashes. 10) Document semantic changes - if optimization intentionally changes behavior (fast-math), document clearly. Golden rule: never trust an optimization until independently verified; subtle bugs in optimized code can be worse than slow correct code.

Follow this 8-step loop fission process: 1) Identify fission candidates - single loop with multiple independent statement groups accessing different data. 2) Check dependency safety - statements in resulting separate loops must not have cross-loop dependencies. 3) Analyze benefit potential - fission beneficial when: different statements access different data (improved spatial locality), one statement group can be vectorized but others prevent it, register pressure in combined loop causes spills. 4) Identify split points - group statements that access same data or have dependencies together. 5) Implement fission - split single loop into multiple loops. Before: for(i) { A[i]=..; B[i]=..; } After: for(i) A[i]=..; for(i) B[i]=..; 6) Handle carried dependencies - if dependency exists, fission may require reordering or may not be legal. 7) Verify correctness - split loops must produce identical results to original. 8) Measure improvement - check vectorization status (compiler reports), cache behavior, overall performance. Fission is inverse of fusion; useful when combined loop body is too large for registers or prevents vectorization.

Follow this 10-step power optimization process: 1) Profile power usage - use Intel RAPL (Running Average Power Limit), powertop, or hardware power meters. 2) Understand power-performance trade-off - reducing frequency saves power but increases latency. 3) Optimize for completion time - faster completion allows longer idle periods; Race to Sleep strategy. 4) Use appropriate SIMD width - AVX-512 can cause frequency reduction on some CPUs; AVX2 may be more power-efficient. 5) Reduce memory traffic - DRAM access consumes significant power; cache optimization helps power too. 6) Use sleep states - yield CPU during waits rather than spinning; use condition variables. 7) Batch operations - process data in bursts allowing CPU to enter deeper sleep states between. 8) Consider compute intensity - power ~= constant + activity; more compute per memory access is more efficient. 9) Tune frequency governors - for sustained workloads, consider 'powersave' governor with occasional bursts. 10) Profile energy-delay product - minimize Energy x Time rather than just one metric. For servers: power efficiency (perf/watt) often more important than raw performance; for mobile: battery life critical.

Follow this 8-step false sharing prevention checklist: 1) Identify potential false sharing - look for arrays or structures where different threads write to adjacent elements. 2) Understand cache line size - typically 64 bytes on modern x86; false sharing occurs when threads write to same 64-byte region. 3) Profile for false sharing - look for high cache coherency traffic, poor scaling with thread count, or use tools like Intel Inspector. 4) Pad per-thread data - add padding to ensure each thread's data is in its own cache line: struct alignas(64) ThreadData { int data; char padding[60]; }; 5) Use thread-local storage - thread_local in C++, __thread in GCC, or explicit thread-local arrays. 6) Restructure arrays - instead of data[thread_id].field, use field[thread_id] with proper spacing. 7) Avoid sharing where possible - duplicate read-only data per thread rather than sharing single copy if write contention occurs. 8) Verify fix - re-profile to confirm cache coherency traffic reduced and scaling improved. Common pitfall: padding increases memory usage; only pad frequently-written data in hot paths.

Use this 15-point code review performance checklist: 1) N+1 queries - loops making database calls; should be batched. 2) Unbounded allocations - lists/buffers that can grow without limit. 3) String concatenation in loops - use StringBuilder or pre-sized buffer. 4) Synchronous I/O in hot path - should be async or moved off critical path. 5) Logging in tight loops - logging overhead adds up; use sampling or move outside loop. 6) Exception-based control flow - exceptions are expensive; don't use for normal cases. 7) Unnecessary boxing/unboxing - primitive to object conversion overhead. 8) Missing short-circuit evaluation - expensive checks should come last in conditions. 9) Unnecessary defensive copies - copying large objects 'just in case'. 10) Lock contention - locks held too long or too broadly. 11) Cache-unfriendly data structures - linked lists, hash tables with poor locality. 12) Repeated computation - same calculation done multiple times without caching. 13) Blocking on I/O - synchronously waiting for network/disk. 14) Inefficient algorithms - O(n^2) where O(n log n) exists. 15) Missing resource limits - unbounded queues, connection pools, thread creation. Not all patterns are problems everywhere; focus on hot paths identified by profiling.

Follow this 11-step container optimization process: 1) Minimize image size - use multi-stage builds, alpine bases, remove unnecessary files. Smaller = faster pull. 2) Layer effectively - put rarely-changing layers first (dependencies) to maximize cache reuse. 3) Optimize application startup - same startup optimizations as native, plus container-specific considerations. 4) Set appropriate resource limits - too low causes throttling, too high wastes cluster resources. 5) Use init containers wisely - parallelize where possible, minimize init work. 6) Configure health checks properly - fast to execute, appropriate intervals to avoid unnecessary restarts. 7) Use local image caching - pre-pull images to nodes, use image caching solutions. 8) Optimize overlay filesystem - many small files perform poorly; consider init container to unpack. 9) Profile container overhead - compare performance in container vs bare metal; identify container-specific costs. 10) Use appropriate base images - distroless or scratch for minimal overhead. 11) Consider sidecar overhead - service meshes, log collectors add CPU/memory; profile their impact. Kubernetes-specific: tune kubelet, use node-local DNS caching, appropriate pod disruption budgets.

Follow this 9-step dependency chain optimization process: 1) Identify long dependency chains - look for serial sequences where each instruction depends on previous result. 2) Measure chain length - count instructions from first to last in chain; compare to loop iteration count. 3) Calculate chain latency - sum latencies of instructions in chain; this is minimum time per iteration. 4) Check IPC - low IPC with low cache misses often indicates dependency-bound code. 5) Break arithmetic chains - use associativity: sum = (a+b) + (c+d) instead of a+b+c+d allows parallel execution. 6) Use multiple accumulators - for reductions, use 4-8 independent accumulators, combine at end. 7) Unroll with independent computations - unroll loop and interleave independent iterations. 8) Reorder instructions - place independent instructions between dependent ones to fill latency. 9) Verify improvement - check IPC increased and execution time decreased. Example: summing array with single accumulator has N-instruction chain; with 4 accumulators, chain is N/4, allowing 4x parallelism until final combination.

Follow this 10-step memory access optimization process: 1) Profile cache miss rates - use perf stat -e L1-dcache-load-misses,LLC-load-misses to identify miss levels. 2) Identify miss source - if L1 misses high but L2 hits, data not fitting L1; if LLC misses high, data not in cache at all. 3) Analyze access pattern - check if sequential (spatial locality good), strided (may miss cache lines), or random (poor locality). 4) Check data structure layout - Array of Structures (AoS) vs Structure of Arrays (SoA), identify if accessing cold fields. 5) Evaluate working set size - compare data size to cache sizes (L1: 32KB, L2: 256KB, L3: varies). 6) If random access pattern: consider prefetching, restructure algorithm, or use cache-oblivious data structures. 7) If strided access: apply loop interchange to improve stride, consider data layout transformation. 8) If working set too large: apply loop tiling/blocking to fit in cache. 9) Check alignment - ensure data aligned to cache line boundaries (64 bytes). 10) Re-profile after each change - verify cache miss reduction translates to speedup.

Follow this 10-step lock-free optimization process: 1) Profile contention - measure CAS failure rates, retry counts, throughput under contention. 2) Understand memory ordering - verify correct use of acquire/release/seq_cst; incorrect ordering causes bugs. 3) Minimize atomic operations - reduce number of atomics in hot path; batch updates where possible. 4) Use appropriate memory orders - relaxed is cheapest, acquire/release sufficient for most cases, avoid seq_cst unless necessary. 5) Avoid false sharing - pad atomic variables to separate cache lines. 6) Consider DCAS vs CAS - some algorithms need double-word CAS; x86 has CMPXCHG16B. 7) Profile cache line bouncing - high cache coherency traffic indicates contention; consider partitioning. 8) Use backoff strategies - exponential backoff on CAS failure reduces contention. 9) Consider hybrid approaches - lock-free for common case, fallback to locks for rare cases. 10) Benchmark against locked alternatives - lock-free isn't always faster; mutex with short critical section may be better under low contention. Correctness first: lock-free bugs are subtle and hard to reproduce; use formal verification or extensive testing.

Follow this 10-step branch optimization process for code with high branch density: 1) Profile branch behavior - identify which branches mispredicted most: perf record -e branch-misses. 2) Categorize branches - predictable (taken/not-taken >90% of time), moderately predictable (70-90%), unpredictable (<70%). 3) For predictable branches: use likely/unlikely hints (__builtin_expect), ensure hot path is fall-through. 4) For unpredictable data-dependent branches: consider branchless alternatives using bitwise ops, conditional moves, or arithmetic. 5) For loop-exit branches: use loop unswitching to move branch outside loop if condition is loop-invariant. 6) For multiple chained conditions: reorder to evaluate most likely first, or use short-circuit evaluation. 7) For switch statements: ensure compiler generates jump table for dense cases; consider profile-guided ordering. 8) For function dispatch: replace virtual calls with switch if small fixed set of types. 9) Use SIMD masking - process all paths simultaneously, select results with blend instructions. 10) Apply PGO - profile-guided optimization provides measured branch probabilities to compiler. Verify: branchless code may have higher latency per operation but removes unpredictability; measure to confirm improvement.

Follow this 10-step loop tiling process: 1) Identify candidate loops - nested loops accessing multi-dimensional arrays with poor cache reuse. Classic example: matrix operations. 2) Analyze access pattern - understand which indices access which dimensions, identify stride patterns. 3) Calculate cache parameters - L1 data cache size (typically 32KB), line size (64 bytes), associativity. 4) Choose tile sizes - tile should fit in target cache level. For L1: total data per tile < 32KB. For L2: < 256KB. 5) Tile innermost data reuse dimension - place tile loops to maximize reuse within tile. 6) Handle boundary conditions - when array dimensions aren't divisible by tile size, handle remainder tiles. 7) Implement tiled loop nest - original: for(i) for(j) for(k) becomes: for(ii+=TI) for(jj+=TJ) for(i=ii) for(j=jj) for(k). 8) Verify correctness - tiled loop must compute same result as original. 9) Tune tile sizes - optimal sizes depend on problem size and cache hierarchy; try powers of 2: 16, 32, 64. 10) Measure improvement - profile cache miss rates before/after; L1 misses should decrease significantly for properly tiled loops.

Follow this 11-step profile-guided optimization process: 1) Build baseline without PGO - measure current performance for comparison. 2) Instrument code for profiling - GCC: -fprofile-generate, Clang: -fprofile-instr-generate. 3) Design representative workload - must cover typical production patterns, not just unit tests. 4) Run instrumented binary - execute with representative workload to collect profile data. 5) Verify coverage - ensure hot code paths were executed; check coverage reports. 6) Build with profile data - GCC: -fprofile-use, Clang: -fprofile-instr-use=profile.profdata. 7) Measure improvement - compare PGO build against baseline on same workload. 8) Verify correctness - run full test suite on PGO build. 9) Establish profile update cadence - re-profile when code or usage patterns change significantly. 10) Automate in CI/CD - integrate profile collection and PGO builds into build pipeline. 11) Consider BOLT - post-link optimization using perf data for additional gains (5-15% typical). Expected gains: 10-30% for branch-heavy code like compilers, interpreters; less for compute-bound numeric code.

Follow this 11-step database query optimization process: 1) Profile query frequency and latency - identify hot queries (frequent) and slow queries (high latency). 2) Examine query plans - use EXPLAIN ANALYZE to see execution plan and actual times. 3) Check index usage - verify indexes exist and are used; add missing indexes for WHERE/JOIN columns. 4) Reduce round trips - batch queries, use JOINs instead of N+1 queries, fetch multiple results at once. 5) Limit result sets - use LIMIT, pagination; don't fetch more than needed. 6) Optimize data transfer - select only needed columns, not SELECT *; reduce transferred bytes. 7) Use connection pooling - connection creation is expensive; reuse connections. 8) Add application-level caching - cache read-heavy, rarely-changing data; use appropriate TTLs. 9) Use prepared statements - reduce parsing overhead for repeated queries. 10) Optimize transactions - minimize transaction scope and duration; avoid holding locks during app logic. 11) Consider denormalization - for read-heavy workloads, duplicate data to avoid expensive joins. Measure at application level: database latency is only part; include serialization, network, and app processing time.

Follow these optimization steps for memory-intensive batch processing: 1) Profile memory usage - identify peak memory, allocation patterns, and hot allocation sites. 2) Stream instead of load all - process data incrementally rather than loading entire dataset into memory. 3) Use memory-mapped files - let OS manage paging for large files instead of explicit reads. 4) Implement chunked processing - process data in cache-friendly chunk sizes (e.g., 1-4MB chunks). 5) Optimize data representation - use smaller types, compression, or packed formats to reduce footprint. 6) Reuse buffers - allocate buffers once and reuse across iterations rather than reallocating. 7) Use arena allocators - for temporary allocations within batch items, reset arena between items. 8) Process in cache-optimal order - access data in patterns that maximize cache hits. 9) Prefetch upcoming chunks - while processing chunk N, prefetch chunk N+1 data. 10) Parallelize with memory awareness - partition data to minimize cross-thread memory contention. 11) Consider out-of-core algorithms - for datasets exceeding RAM, use external memory algorithms. Goal: maintain constant memory usage regardless of input size while maximizing throughput.

Follow this 9-step VLIW instruction scheduling process: 1) Understand the target architecture - identify number of functional units, instruction latencies, and bundle width (how many ops per VLIW word). 2) Build dependency graph - create DAG of instructions showing true dependencies (RAW), anti-dependencies (WAR), and output dependencies (WAW). 3) Calculate critical path - find longest dependency chain; this is minimum execution time. 4) Identify parallelism - find independent instruction groups that can execute simultaneously. 5) Apply list scheduling - prioritize instructions by: critical path length, number of successors, resource constraints. 6) Pack into bundles - place compatible instructions in same VLIW word respecting functional unit constraints. 7) Handle hazards - insert NOPs where dependencies cannot be satisfied by scheduling. 8) Consider software pipelining - for loops, overlap iterations by starting iteration N+1 before N completes, using modulo scheduling. 9) Minimize code size - balance between NOP insertion (code bloat) and register pressure. Software pipelining particularly effective for VLIW as it exposes more parallelism than single-iteration scheduling.

Follow this 11-step hash table optimization checklist: 1) Profile access patterns - measure lookup/insert/delete frequency, hit rate, probe length. 2) Choose appropriate load factor - 0.5-0.7 balances memory and performance; lower for latency-critical. 3) Select hash function - use fast, high-quality hash (xxHash, wyhash, or built-in); avoid cryptographic hashes. 4) Minimize key comparison cost - store hash values to avoid recomputing; use prefix comparison for strings. 5) Optimize probing strategy - linear probing has better cache behavior than separate chaining. 6) Use power-of-2 sizes - enables fast modulo via bitwise AND. 7) Implement SIMD parallel lookup - compare multiple keys simultaneously using vector instructions. 8) Prefetch during probing - prefetch next probe location while checking current. 9) Consider flat hash maps - store entries inline rather than following pointers (better cache). 10) Handle hot keys - very frequently accessed keys can use separate fast path or front-of-bucket. 11) Profile memory usage - hash tables can waste significant memory; Swiss table and similar designs improve density. Benchmark against robin hood, cuckoo, and Swiss table variants for your access pattern.

Use this 12-point performance documentation checklist: 1) Describe the problem - what was slow, how slow, under what conditions? 2) Include baseline measurements - exact numbers with methodology, environment details. 3) Explain root cause analysis - how did you identify the bottleneck? What tools used? 4) Document what you tried - including approaches that didn't work and why. 5) Describe the solution - what change was made, why does it work? 6) Include after measurements - same methodology as baseline for valid comparison. 7) Quantify improvement - percentage, absolute numbers, statistical significance. 8) Note tradeoffs - does optimization increase memory usage, code complexity, or reduce maintainability? 9) Specify applicability - when does this optimization apply? What conditions might make it not apply? 10) Add code comments - explain non-obvious optimization in code near the optimization. 11) Update performance tests - add regression tests to prevent future slowdowns. 12) Record environment details - compiler version, flags, hardware, OS - for reproducibility. Good documentation prevents: re-investigating same issues, accidentally reverting optimizations, applying optimizations where they don't help.

Follow this 10-step JSON parsing optimization process: 1) Profile current parser - measure parse time, memory allocations, CPU cycles per byte. 2) Choose fast parser library - simdjson (fastest), rapidjson, yyjson outperform standard library parsers. 3) Use lazy parsing - parse on-demand rather than building full DOM if only accessing few fields. 4) Avoid string copies - use string views into original buffer rather than copying strings. 5) Pre-allocate buffers - reuse parser state and output buffers across parses. 6) Use binary formats for internal communication - MessagePack, Protocol Buffers, FlatBuffers avoid parse overhead. 7) Schema-aware parsing - if structure is known, generate specialized parser (code generation). 8) SIMD acceleration - simdjson uses SIMD for structural character scanning; huge speedup. 9) Streaming parse for large documents - avoid loading entire document into memory. 10) Profile memory allocation - JSON parsing often allocation-heavy; arena allocators help. Benchmark: simdjson achieves 2-3 GB/s parsing speed; compare against your current solution. For serialization, similar process: use fast library, avoid intermediate strings, stream output.

Follow this 12-point cloud optimization checklist: 1) Minimize cold start - for serverless: reduce package size, lazy load dependencies, use provisioned concurrency. 2) Optimize for spot/preemptible instances - checkpoint state, handle termination gracefully. 3) Right-size instances - profile to choose appropriate CPU/memory; oversized wastes money, undersized hurts performance. 4) Use appropriate storage tier - SSD for IOPS, HDD for throughput, object storage for large files. 5) Optimize network architecture - minimize cross-AZ traffic, use private endpoints, consider edge locations. 6) Implement connection pooling - database connections are expensive; reuse across invocations. 7) Cache aggressively - use Redis/Memcached for hot data; CDN for static content. 8) Batch operations - reduce round-trips to managed services which often have high per-request latency. 9) Monitor costs alongside performance - cloud bills can surprise; optimize for cost-performance ratio. 10) Use autoscaling effectively - set appropriate thresholds; don't scale on minor fluctuations. 11) Consider reserved capacity - committed use discounts for predictable workloads. 12) Profile regularly - cloud environment changes; re-profile after updates.

Follow this 11-step floating-point optimization process: 1) Profile FP operations - use perf with FP-specific events or VTune to count FLOPS and FP stalls. 2) Check for denormal penalties - denormalized numbers (very small values near zero) can be 100x slower; consider flushing to zero with _MM_SET_FLUSH_ZERO_MODE. 3) Identify precision requirements - float (32-bit) is 2x throughput of double (64-bit) for SIMD; use float if precision allows. 4) Use FMA instructions - fused multiply-add has lower latency than separate mul+add and may be more accurate. Enable with -mfma. 5) Consider -ffast-math - enables aggressive optimizations (reassociation, reciprocal approximations) that may change results. Use -fno-math-errno, -ffinite-math-only, -fno-trapping-math individually for finer control. 6) Reduce division - multiply by reciprocal when denominator is loop-invariant; division is 15-20x slower than multiplication. 7) Use intrinsics for special functions - approximate rsqrt, rcp are much faster than precise versions when acceptable. 8) Vectorize FP loops - SIMD provides 4x (SSE/float) to 16x (AVX-512/float) throughput. 9) Check for unnecessary type conversions - int-to-float conversions have latency. 10) Order operations for accuracy - sum small numbers first to reduce rounding error. 11) Verify numerical results - aggressive optimizations can change results; compare against reference implementation.

Follow this 9-step instruction count reduction process: 1) Profile instruction mix - use perf stat to get total instructions, breakdown by type if available. 2) Identify high-instruction-count regions - use perf annotate to see instruction counts per source line. 3) Look for redundant computations - common subexpressions, loop-invariant calculations, repeated checks. 4) Apply strength reduction - replace expensive ops: multiply by power of 2 -> shift, divide -> multiply by reciprocal, modulo -> bitwise AND for power-of-2 divisors. 5) Use lookup tables - for complex calculations with small input domain, precompute results. 6) Leverage SIMD - one vector instruction replaces 4-16 scalar instructions. 7) Use specialized instructions - POPCNT for bit counting, LZCNT for leading zeros, FMA for multiply-add. 8) Simplify control flow - merge similar branches, eliminate dead code, simplify predicates. 9) Measure actual impact - fewer instructions doesn't always mean faster if new instructions are higher latency or cause other bottlenecks. Focus on hot code paths; reducing cold code instructions has minimal impact.

Follow this 10-point cross-vendor optimization checklist: 1) Identify target CPUs - determine if code will run on Intel-only, AMD-only, or both. 2) Check instruction availability - AVX-512 availability varies; AMD added support in Zen 4. 3) Consider cache differences - AMD typically has larger L3, different associativity; Intel has larger L2 per core. 4) Check SIMD performance - some SIMD instructions have different throughput/latency between vendors. 5) Profile on both architectures - performance characteristics can differ significantly. 6) Use vendor-agnostic intrinsics - prefer generic _mm* over vendor-specific extensions. 7) Check branch predictor differences - some patterns predicted differently; profile branch misses on both. 8) Consider NUMA topology - AMD chiplet design has different NUMA characteristics than Intel monolithic. 9) Test AVX2 vs AVX-512 - on AMD, AVX-512 may not be faster due to frequency scaling; benchmark. 10) Use runtime dispatch - detect CPU features and dispatch to optimized code paths: __builtin_cpu_supports(). For portable code: optimize for common subset (AVX2), add special paths for vendor-specific features with runtime detection.

Follow this 10-step memory leak debugging process: 1) Confirm leak exists - monitor memory usage over time; growing usage without corresponding workload increase indicates leak. 2) Reproduce reliably - identify workload pattern that triggers leak; create minimal reproducer. 3) Quantify leak rate - measure bytes leaked per operation or per time period. 4) Run with leak detector - Valgrind Memcheck, AddressSanitizer (-fsanitize=address), or Dr. Memory. 5) Identify allocation site - detector reports where leaked memory was allocated. 6) Trace ownership - follow code path from allocation to understand intended deallocation point. 7) Identify missing free - find where deallocation should occur but doesn't. 8) Categorize leak type - true leak (lost pointer), logical leak (growing cache/queue), or reference cycle (garbage-collected languages). 9) Implement fix - add missing deallocation, limit cache size, break reference cycles. 10) Verify fix - rerun leak detector, monitor memory usage over extended period. For production: use sampling-based leak detectors (TCMalloc heap profiler) that have lower overhead than Valgrind.

Sorting cost model (comparison-based): Comparisons: O(N log N), typically 1.5N log N for quicksort, 1.0N log N for mergesort. Memory accesses: quicksort mostly in-place, mergesort needs N extra space. Cache behavior: quicksort better cache locality, mergesort more predictable. At scale (N > L3/sizeof(element)): Quicksort: ~2N log N * 200 cycles (random access). Mergesort: more sequential, ~1.5N log N * 40 cycles (better prefetching). Radix sort (non-comparison): O(N * key_width), better for integers. Example: sorting 1M 64-bit integers. std::sort: ~5 million comparisons, ~200ms. Radix sort: 8 passes * 1M = 8M operations, ~50ms. Rule: radix sort wins for large arrays of fixed-size keys.

An integer ADD instruction has a latency of 1 cycle on modern x86 CPUs (Intel and AMD). The throughput is typically 3-4 operations per cycle due to multiple execution units. This means while each individual ADD takes 1 cycle to produce its result, the CPU can execute 3-4 independent ADDs simultaneously. For dependency chains, count 1 cycle per ADD. For independent operations, divide total ADDs by 3-4 for approximate cycle count.

Unaligned access cost on modern x86: Within cache line: 0 extra cycles (handled by hardware). Crossing cache line boundary: +4-10 cycles (two cache accesses needed). Crossing page boundary: very expensive, potentially 100+ cycles (two TLB lookups). SIMD unaligned loads (VMOVDQU vs VMOVDQA): historically 1-2 cycles more, now essentially free on Haswell+. Cost model: ensure arrays are aligned to 16/32/64 bytes for SIMD. For structures with mixed sizes, use alignas() or manual padding. Unaligned atomics may not be atomic (split across cache lines). Rule: align to max(element_size, SIMD_width) for best performance.

Division by constant is optimized by compilers: Compile-time constant divisor: replaced with multiply + shift, ~4-6 cycles. Power of 2: becomes shift, 1 cycle. Runtime variable divisor: full division, 26-40+ cycles. Savings: 5-10x faster for constant divisors. Cost model for repeated division: If dividing N values by same runtime divisor: precompute reciprocal once, then N multiplications. libdivide library automates this. Single division: full cost unavoidable. Modulo by constant: also optimized, same ~4-6 cycles. Example: x / 7 becomes (x * 0x2492492...) >> 32, about 4 cycles. Use const or constexpr for divisors when possible to enable optimization.

Basic function call overhead is 2-5 cycles for the CALL/RET instructions themselves, but total overhead includes: (1) Stack frame setup: PUSH RBP, MOV RBP,RSP = 2-3 cycles. (2) Register saves if needed: 1 cycle per register. (3) Stack alignment: potentially 1-2 cycles. (4) Return: POP RBP, RET = 2-3 cycles. Typical total: 5-15 cycles for small functions. However, if function is not inlined and causes instruction cache miss, add 10-50+ cycles. For tiny functions (1-3 instructions), call overhead can exceed function body cost by 5-10x.

Memory bandwidth = Memory_Clock * 2 (DDR) * Bus_Width * Channels / 8. Example for DDR4-3200 dual channel: 1600 MHz * 2 * 64 bits * 2 channels / 8 = 51.2 GB/s. DDR5-6400 dual channel: 3200 * 2 * 64 * 2 / 8 = 102.4 GB/s. Real-world efficiency is 70-90% of theoretical maximum due to refresh cycles, command overhead, and access patterns. Single-threaded code typically achieves only 15-30% of peak bandwidth due to limited memory-level parallelism (need ~64 outstanding requests to saturate bandwidth).

Float vs double on modern x86: Scalar operations: same latency and throughput (both use 64-bit FP unit). SIMD operations: float has 2x throughput (8 floats vs 4 doubles in AVX). Memory: float uses half the bandwidth and cache. Specific costs: float ADD/MUL: 4 cycles latency, 2/cycle throughput (same as double). Division: float ~11 cycles, double ~13-14 cycles (float slightly faster). SIMD ADD (AVX): 8 floats or 4 doubles per instruction, same latency. Cost model: memory-bound code benefits 2x from float (half the bytes). Compute-bound SIMD code: float 2x faster. Pure scalar compute: roughly equal. Choose float for performance unless precision requires double.

Modulo has the same cost as division since it uses the same hardware (DIV/IDIV produces both quotient and remainder). For 32-bit modulo: 26-35 cycles latency, throughput of one every 6 cycles on Intel. Key optimizations: (1) Modulo by power of 2 becomes AND operation (1 cycle): x % 8 = x & 7. (2) For constant divisors, compilers use multiply-by-reciprocal: about 4 cycles total (multiply + shift). (3) For runtime divisors, precompute reciprocal if dividing many values by same divisor. Avoid modulo in tight loops.

L1 cache access latency is 4-5 cycles on modern Intel and AMD processors (approximately 1-1.5 nanoseconds at 3-4 GHz). L1 data cache (L1D) is typically 32-48KB per core. L1 instruction cache (L1I) is typically 32KB per core. The L1 cache can sustain 2 loads and 1 store per cycle. For cost estimation: assume 4 cycles for any memory access that hits L1. This is your best-case memory latency and baseline for comparison with other cache levels.

Hash table lookup cost: Hash computation: 5-50 cycles depending on hash function (CRC32: ~5, SHA: ~100+). Table lookup: 4-200 cycles depending on table size vs cache. Collision handling: adds one lookup per collision. Best case (small table in L1, no collision): ~10-15 cycles. Typical case (table in L3, avg 0.5 collisions): ~50-80 cycles. Worst case (table in DRAM, several collisions): ~400+ cycles. Cost model: lookup_cost = hash_cycles + expected_probes * memory_latency_for_table_size. Keep tables sized to fit in cache when possible. For high-performance: use cache-line-aligned buckets, minimize pointer chasing.

Integer to string conversion cost: Naive div/mod by 10 approach: ~26 cycles per digit (division cost). 64-bit integer (up to 20 digits): ~520 cycles worst case. Optimized approaches: lookup table for 00-99: ~10 cycles per 2 digits. Multiply by reciprocal: ~5 cycles per digit. Modern libraries (fmt, to_chars): 50-100 cycles for typical integers. Cost model: digit_count = floor(log10(n)) + 1. Naive: digit_count * 26 cycles. Optimized: digit_count * 5-10 cycles. sprintf overhead: adds 100-500 cycles for format parsing. For high throughput: use specialized integer formatting (fmt library is 5-10x faster than sprintf).

Loop unrolling tradeoffs: Benefits: reduces loop overhead (test, branch) by factor of unroll. 15x unroll eliminates ~94% of branches. Typical speedup: 1.2-2x for unroll factor 4-8. Costs: code size grows linearly with unroll factor. Excessive unrolling causes: instruction cache misses, defeats micro-op cache (typically holds ~1500 micro-ops). Sweet spot: unroll 4-8x usually optimal, beyond 16x rarely helps. Cost model: unrolled_cycles = base_cycles / unroll_factor + overhead. But if code exceeds L1I cache (32KB), add i-cache miss penalty (10-20 cycles per miss). Diminishing returns beyond instruction_cache_size / loop_body_size iterations.

Array of Structs (AoS) vs Struct of Arrays (SoA): AoS: struct Point { float x, y, z; } points[N]; - loads 12 bytes per point, may waste cache if only accessing x. SoA: struct Points { float x[N], y[N], z[N]; }; - loads only needed components, SIMD-friendly. Cache efficiency: if using 1 field: AoS wastes 2/3 of loaded cache lines. SIMD vectorization: SoA naturally aligns for SIMD (8 x values contiguous). AoS requires gather or shuffle. Cost model: AoS processing all fields: ~equal to SoA. AoS processing one field: 3x memory bandwidth wasted (for 3-field struct). SoA with SIMD: potential 8x speedup from vectorization. Rule: use SoA for hot data processed in bulk; AoS for random access of complete records.

Memory barrier/fence costs on x86: MFENCE (full barrier): 30-100 cycles on Intel, varies by microarchitecture. SFENCE (store barrier): 5-30 cycles. LFENCE (load barrier): near zero cycles (serializing, mainly for timing). LOCK prefix (implicit barrier): 12-35 cycles (same as atomic operation). On x86, most barriers are cheap due to strong memory model - stores already have release semantics. Cost model: MFENCE dominates when used; avoid in tight loops. std::atomic with sequential consistency uses MFENCE on stores. Prefer acquire/release semantics when possible (free on x86). ARM/PowerPC: barriers are more expensive (weaker memory model), 50-200 cycles typical.

Page fault costs: Minor fault (page in memory, just needs mapping): 1-10 microseconds (3,000-30,000 cycles). Major fault (page must be read from disk): 1-10 milliseconds for SSD (3-30 million cycles). HDD: 10-100 milliseconds (30-300 million cycles). Kernel overhead per fault: ~1000-5000 cycles for trap handling. Cost model: first touch of allocated memory triggers minor faults. mmap'd file access triggers major faults if not cached. For performance: pre-fault memory with memset, use madvise(MADV_WILLNEED) for file mappings. Huge pages reduce fault frequency by 512x (2MB vs 4KB pages). Detection: perf stat -e page-faults shows fault count.

Indirect branch cost depends on prediction: Predicted correctly: 1-2 cycles (similar to direct branch). Mispredicted: 15-20 cycles (full pipeline flush). Prediction accuracy depends on call site pattern: always same target = near 100% predicted. few targets, stable pattern = well predicted. many targets or random = poorly predicted. Cost model: average_cost = 1 + (1 - prediction_rate) * 15. For virtual function calls: usually well-predicted if object type is consistent. For switch statements compiled to jump tables: depends on case distribution. Profile-guided optimization (PGO) significantly improves indirect branch prediction.

L3 cache access latency is 30-50 cycles on modern CPUs (approximately 10-20 nanoseconds). L3 is shared across all cores, typically 8-96MB total. Accessing a local L3 slice takes about 20 cycles, while accessing a remote slice (owned by another core) can take 40+ cycles. For cost estimation: L3 hit adds 25-45 cycles over L1 baseline. This is 5-10x slower than L1. If working set exceeds L2 but fits in L3, expect average latency around 35-40 cycles.

Floating-point to string is much more expensive than integer: Simple cases (small integers, simple decimals): 200-500 cycles. Complex cases (large exponents, many decimal places): 1000-5000 cycles. Full precision (17 digits for double): often requires arbitrary precision arithmetic. Algorithms: Grisu2/Grisu3: 100-300 cycles for simple cases. Ryu (newer): ~100 cycles average, handles all cases correctly. Dragonbox: similar to Ryu, different tradeoffs. Cost model: ~5-10x slower than integer conversion. printf/sprintf: adds parsing overhead, total 500-2000 cycles. For high throughput: use Ryu or Dragonbox-based libraries (10x faster than naive approaches).

Cache miss costs (cycles added over L1 hit baseline of 4 cycles): L1 miss, L2 hit: +8-10 cycles (total ~12-14). L1+L2 miss, L3 hit: +26-36 cycles (total ~30-40). L1+L2+L3 miss, DRAM: +150-250 cycles (total ~160-260). Cost model for array access: if array_size <= 32KB (L1): 4 cycles/access. if array_size <= 256KB (L2): mix of 4 and 12 cycles. if array_size <= 8MB (L3): mix including ~40 cycle accesses. if array_size > L3: approaching 200+ cycles for random access. Sequential access amortizes: one miss per 64 bytes (8 doubles), so effective cost = miss_latency / 8 per element.

Latency-bound: each operation depends on previous, limited by instruction latency. Example: sum += array[i] - each add waits for previous add (3-4 cycles each). Rate: 1 add per 4 cycles = 0.25 adds/cycle. Throughput-bound: operations are independent, limited by execution units. Example: four parallel sums merged at end. Rate: 2 adds/cycle (using both FP add units). Speedup: 8x by using 4 accumulators. Cost model: dependency_chain_length * latency vs total_ops / throughput. Take maximum. Optimization: unroll loops with multiple accumulators to convert latency-bound to throughput-bound. Typical improvement: 4-8x for reduction operations.

Reduction operation costs: Scalar sum of N elements: latency-bound at ~4 cycles per add (dependency chain). Total: 4N cycles. Multi-accumulator (4 accumulators): throughput-bound at 2 adds/cycle. Total: N/2 cycles (8x faster). SIMD reduction (AVX with 8 floats): vector adds at 8 elements per instruction, then horizontal reduce. Vertical: N/8 vector adds = N/16 cycles. Horizontal reduction: ~10-15 cycles (shuffle + add tree). Total: N/16 + 15 cycles. Cost model: scalar_reduction = N * op_latency. Optimized: N / (accumulators * throughput) + horizontal_reduction. Memory-bound check: if N * element_size > L3, time = N * element_size / bandwidth.

IPC varies dramatically by workload: Compute-bound vectorized code: 2-4 IPC (utilizing multiple execution units). Integer-heavy general code: 1-2 IPC. Memory-bound code: 0.2-0.5 IPC (waiting for cache misses). Branch-heavy code: 0.5-1 IPC (misprediction stalls). Database workloads: often 0.3-0.7 IPC (random memory access). Modern CPUs can retire 4-6 instructions per cycle theoretically. Rule of thumb: IPC < 0.7 indicates optimization opportunity (likely memory-bound). Measure with: perf stat -e instructions,cycles your_program. IPC = instructions / cycles.

Network operation costs: Syscall overhead: 500-1500 cycles per send/recv. Localhost roundtrip: 10-50 microseconds. Same datacenter roundtrip: 0.5-2 milliseconds. Cross-datacenter: 10-100+ milliseconds. TCP overhead: connection setup 3-way handshake adds 1.5x RTT. Kernel network stack: ~10 microseconds processing per packet. Cost model: network_time = syscall + RTT + size/bandwidth. For small messages: RTT dominates. For large transfers: bandwidth dominates. Optimization: batch small messages, use TCP_NODELAY to disable Nagle, use kernel bypass (DPDK) for lowest latency. 10 Gbps network: 1.25 GB/s = 400 cycles per byte at 3 GHz.

Branch misprediction penalty is 15-20 cycles on modern Intel and AMD processors. Intel Skylake: approximately 16-17 cycles. AMD Zen 1/2: approximately 19 cycles. When mispredicted, the pipeline must be flushed and refilled from the correct target. For cost estimation: if branch prediction accuracy is P, average cost = (1-P) * 15-20 cycles per branch. Random branches (50% predictable) cost about 8-10 cycles on average. Well-predicted branches (>95%) cost <1 cycle average. Avoid data-dependent branches in hot loops.

Garbage collection pause costs: Minor GC (young generation): 1-10 milliseconds typically. Major GC (full heap): 100ms to several seconds depending on heap size. Concurrent collectors (G1, ZGC, Shenandoah): target 10ms max pause. Cost model: pause_time proportional to live_objects for copying collectors. For stop-the-world GC: pause = heap_size / scan_rate (~1GB/s typical). Rule of thumb: 1ms per 100MB of live data for minor GC. Mitigation: reduce allocation rate, tune heap size, use low-pause collectors. For latency-critical: budget 10-20% of cycle time for GC. Allocation cost: JIT-optimized bump pointer = 10-20 cycles. Measured: Java allocation can be faster than malloc.

Min/max operation costs: Integer: compare + conditional move = 2 cycles. Or using bit tricks: 3-4 cycles for branchless. Floating point (MINSS/MAXSS): 3-4 cycles latency. SIMD (VPMINSB, etc.): 1 cycle for packed integers, 4 cycles for packed floats. Branching min/max: 1 cycle if predicted, 15-20 cycles if mispredicted. Cost model: for predictable comparisons (e.g., clamping), branches may be faster. For random comparisons, branchless (CMOV or SIMD) wins. Reduction to find min/max of array: N comparisons, but SIMD can do 8-16 per instruction. SIMD min/max of N elements: N/16 cycles for AVX2, plus horizontal reduction (10 cycles).

Cache line size is 64 bytes on x86 (Intel/AMD) and 128 bytes on Apple M-series. Memory is transferred in whole cache lines - accessing 1 byte loads 64 bytes. Performance implications: (1) Sequential access: effectively 64 bytes per cache miss. (2) Strided access: if stride >= 64 bytes, every access is a cache miss. (3) False sharing: two threads modifying different variables on same cache line cause ping-pong. Cost model: array traversal with stride S bytes: cache_misses = array_size / max(S, 64). For stride 8 (double): miss every 8 elements. For stride 64+: miss every element.

Bitwise operation costs: AND, OR, XOR, NOT: 1 cycle latency, 3-4 per cycle throughput. Shifts (SHL, SHR, SAR): 1 cycle latency, 2 per cycle throughput. Variable shift: 1-2 cycles latency (depends on whether count is CL register). Rotate (ROL, ROR): 1 cycle latency. Population count (POPCNT): 3 cycles latency, 1 per cycle throughput. Leading zeros (LZCNT): 3 cycles latency. Bit test (BT): 1 cycle for register, more for memory. Cost model: bitwise operations are extremely cheap - essentially free compared to memory access. Use bit manipulation for flags, masks, and compact data structures. SIMD bitwise: processes 256-512 bits in 1 cycle.

Log and exp function costs: Library exp/log (double): 50-100 cycles typically. Fast approximations: 15-30 cycles with reduced precision. SIMD (Intel SVML): ~10-15 cycles per element vectorized. pow(x,y) = exp(ylog(x)): ~200 cycles (two transcendentals). exp2/log2: slightly faster than exp/ln (base matches hardware). Cost model: transcendental = ~80 cycles rule of thumb. For bulk computation: always vectorize with SIMD libraries. Integer power (x^n for integer n): use exponentiation by squaring, log2(n) multiplies = ~10 cycles for typical n. Avoid pow() for integer exponents - use xx*x or multiplication loop.

Thread creation/destruction costs: Linux pthread_create: 10-50 microseconds (30,000-150,000 cycles). Windows CreateThread: 20-100 microseconds. Thread destruction: similar cost to creation. Stack allocation (typically 1-8MB): may cause page faults if touched. Cost model: thread_overhead = creation_time + work_time + destruction_time. Break-even: work must exceed 100 microseconds to justify thread creation. For short tasks: use thread pool to amortize creation cost. Pool dispatch overhead: ~1-5 microseconds (mutex + condition variable). Maximum useful threads: typically number_of_cores for CPU-bound work, more for I/O-bound. Oversubscription causes context switch overhead (30 microseconds each).

Gather/scatter is much slower than contiguous access: Contiguous vector load: 4-7 cycles from L1 cache for 256-512 bits. Gather (AVX2 VGATHERPS): ~32 cycles for 8 elements from L1 - approximately 8x slower. Each gather element is a separate cache access. AVX-512 gather: improved to ~1.2-1.8x speedup vs scalar in best cases. Cost model: gather_cycles = elements * L1_latency (approximately). Only use gather when data is truly scattered. For rearrangement, prefer: load contiguous + permute (3 cycles) over gather. Scatter (AVX-512 only): similar cost to gather, avoid when possible.

SIMD operations process multiple elements with similar latency to scalar: SSE (128-bit): 4 floats or 2 doubles per instruction. Same latency as scalar (3-4 cycles for add/mul). AVX (256-bit): 8 floats or 4 doubles per instruction. Same latency, double throughput vs SSE. AVX-512 (512-bit): 16 floats or 8 doubles. May cause frequency throttling on some CPUs. Cost model: SIMD_time = Scalar_time / Vector_width (ideal). Real speedup typically 2-6x due to overhead, alignment, and remainder handling. For N elements: cycles = N / vector_width * latency (throughput bound) or N * latency / vector_width (latency bound).

CMOV vs branch tradeoffs: CMOV: 1-2 cycles latency, always executed (no prediction). Branch: 1 cycle if correctly predicted, 15-20 cycles if mispredicted. Break-even point: if branch prediction accuracy < 85-90%, CMOV wins. If accuracy > 95%, branch is typically faster. Cost model: branch_cost = 1 + (1 - prediction_rate) * misprediction_penalty. CMOV_cost = 2 cycles (always). Example: 75% predictable branch: 1 + 0.25 * 17 = 5.25 cycles average (CMOV wins). 99% predictable branch: 1 + 0.01 * 17 = 1.17 cycles (branch wins). Compiler heuristics: often conservative with CMOV. Use profile-guided optimization to help compiler choose correctly.

Main memory (DRAM) access latency is 150-300+ cycles (50-100 nanoseconds) on modern systems. This is approximately 50-100x slower than L1 cache. At 3 GHz, 100ns equals 300 cycles. Latency components: L3 miss detection (10-20 cycles) + memory controller (10-20 cycles) + DRAM access (40-60ns). For cost estimation: every cache miss that goes to DRAM costs roughly 200 cycles. A random access pattern in array larger than L3 will average close to DRAM latency.

Little's Law: Concurrency = Throughput * Latency. For memory systems: Outstanding_requests = Bandwidth * Latency. Example: to achieve 50 GB/s with 100ns latency: Requests = (50e9 bytes/s) * (100e-9 s) / 64 bytes = 78 cache lines in flight. A single core typically supports 10-12 outstanding L1D misses. To saturate memory bandwidth, need multiple cores or threads. Cost model: max_single_thread_bandwidth = max_outstanding_misses * cache_line_size / memory_latency. With 10 misses, 64B lines, 100ns: 10 * 64 / 100ns = 6.4 GB/s per thread (far below 50 GB/s peak). This explains why single-threaded code rarely achieves peak memory bandwidth.

Memory hierarchy cost ratios (normalized to L1=1): L1 hit: 1x (4 cycles baseline). L2 hit: 3x (12 cycles). L3 hit: 10x (40 cycles). DRAM: 50-75x (200-300 cycles). NUMA remote: 75-150x (300-600 cycles). Bandwidth ratios: L1: 64-128 bytes/cycle. L2: 32-64 bytes/cycle (0.5x L1). L3: 16-32 bytes/cycle (0.25x L1). DRAM: 10-20 bytes/cycle shared (0.1-0.15x L1). Cost model rule of thumb: each cache level is 3-4x slower than previous. Missing all caches is 50-100x slower than L1 hit. Design data structures to maximize L1/L2 hits - the latency difference is dramatic.

Arithmetic intensity (AI) = FLOPs / Bytes moved from memory. Count operations and data movement: FLOPs = adds + multiplies + divides + sqrts (count FMA as 2 FLOPs). Bytes = unique cache lines touched * 64 (for cold cache) or actual bytes for hot cache. Example - dot product of N floats: FLOPs = 2N (one mul + one add per element). Bytes = 2 * 4N = 8N (read two vectors). AI = 2N / 8N = 0.25 FLOPs/byte. Example - matrix multiply (NxN, naive): FLOPs = 2N^3. Bytes = 3 * 4N^2 (read two matrices, write one). AI = 2N^3 / 12N^2 = N/6 FLOPs/byte. For N=1000: AI = 166 FLOPs/byte (compute-bound).

System call overhead: 150-1500 cycles depending on the syscall and CPU mitigations. Minimal syscall (e.g., getpid): ~760 cycles, ~250 nanoseconds. Typical syscall (e.g., read): 1000-1500 cycles. With Spectre/Meltdown mitigations: can add 100-500 cycles. vDSO optimization (clock_gettime, gettimeofday): ~150 cycles, ~50 nanoseconds - about 10x faster than true syscall. For cost estimation: budget 500-1000 cycles per syscall in hot paths. Batch operations when possible to amortize overhead. Prefer vDSO functions for high-frequency calls.

Cache thrashing occurs when working set exceeds cache, causing repeated evictions: Thrashing signatures: L1 miss rate > 10%, L3 miss rate > 5%. Cost model: if working_set > cache_size, every access potentially misses. Effective latency approaches next level: L1 thrash -> L2 latency (12 cycles). L2 thrash -> L3 latency (40 cycles). L3 thrash -> DRAM latency (200 cycles). Example: matrix multiply without blocking, N=1000. Working set per row: 8KB (1000 doubles). L1 (32KB) holds 4 rows - heavy L1 thrashing. Performance: 10-50x slower than cache-blocked version. Detection: perf stat -e cache-misses,cache-references. Fix: restructure algorithm for cache-oblivious or explicit blocking to fit working set in cache.

Memory bandwidth formula: Required_BW = (bytes_read + bytes_written) * iterations / time. For array sum of N floats: reads 4N bytes, no writes. At 50 GB/s bandwidth: minimum time = 4N / 50e9 seconds. Compare to compute: N additions at 8 adds/cycle on 3GHz = N/24e9 seconds. Memory-bound when 4N/50e9 > N/24e9, simplifying: 4/50 > 1/24, or 0.08 > 0.04 - always true for simple operations. Rule of thumb: operation is memory-bound if arithmetic intensity < 10-15 FLOPS/byte (the 'ridge point').

CPU performance notation explained: Latency: cycles from instruction start to result availability. Used for dependency chains. Throughput (reciprocal): cycles between starting consecutive independent instructions. Example: 4L1T means 4 cycles latency, 1 cycle throughput (start one per cycle). 4L0.5T means 4 cycles latency, 0.5 cycle throughput (start two per cycle). Throughput 0.33 means 3 instructions per cycle. Reading Agner Fog tables: columns show latency and reciprocal throughput separately. uops.info format: similar, also shows micro-op breakdown. Cost model application: dependent chain: multiply latencies. Independent operations: divide by throughput. Real code: somewhere between, use profiling to measure actual performance.

Virtual function call overhead is 10-20 cycles in the best case (warm cache, predicted branch). Components: (1) Load vptr from object: 4 cycles if L1 hit. (2) Load function pointer from vtable: 4 cycles if L1 hit. (3) Indirect branch: 1-3 cycles if predicted, 15-20 cycles if mispredicted. Cold cache worst case: 100+ cycles (two cache misses + misprediction). Rule of thumb: virtual calls are 3-10x slower than direct calls when cache is warm. In tight loops, devirtualization or template polymorphism can eliminate overhead entirely.

L2 cache access latency is 12-14 cycles on modern CPUs (approximately 3-5 nanoseconds). L2 cache is typically 256KB-1MB per core. This is roughly 3x slower than L1 cache. For cost estimation: L2 miss but L1 hit adds about 8-10 cycles over L1 baseline. Memory access pattern analysis: if your working set fits in L2 (256KB-1MB per core), expect average latency around 12-14 cycles. L2 bandwidth is typically 32-64 bytes per cycle.

Context switch direct cost: 1-3 microseconds (3,000-10,000 cycles at 3 GHz). Components: (1) Save registers and state: 100-200 cycles. (2) Scheduler decision: 200-500 cycles. (3) Load new page tables: 100-200 cycles. (4) Restore registers: 100-200 cycles. (5) Pipeline refill: 10-50 cycles. Indirect costs dominate: TLB flush (100+ cycles per subsequent miss), cache pollution (potentially 1000s of cycles to rewarm). With virtualization: 2.5-3x more expensive. Rule of thumb: budget 30 microseconds total cost including indirect effects.

File I/O cost model: Syscall overhead (read/write): 500-1500 cycles per call. Disk latency (SSD): 50-200 microseconds (150,000-600,000 cycles). Disk latency (HDD): 5-10 milliseconds (15,000,000-30,000,000 cycles). SSD throughput: 500MB/s - 7GB/s depending on interface (SATA vs NVMe). Cost model: small_read_time = syscall + disk_latency + size/bandwidth. For many small reads: syscall overhead dominates. For large sequential reads: bandwidth dominates. Optimization: batch small reads, use mmap for random access, use async I/O. Buffered I/O (fread): fewer syscalls but memory copy overhead. For maximum throughput: use direct I/O with aligned buffers, multiple in-flight requests.

Floating-point division is expensive and not fully pipelined: Single precision (DIVSS): Latency 11 cycles, throughput 0.33/cycle (one every 3 cycles). Double precision (DIVSD): Latency 13-14 cycles, throughput 0.25/cycle (one every 4 cycles). This is 3-4x slower than multiplication. Optimization: multiply by reciprocal when dividing by constant. For approximate division, use RCPSS (4 cycles) then Newton-Raphson refinement. For cost estimation in loops: N divisions = N * 3-4 cycles minimum (throughput bound), or N * 11-14 cycles if dependent (latency bound).

Integer absolute value costs: Branching (if x < 0) x = -x: 1 cycle if predicted, 15-20 if mispredicted. Branchless using CMOV: 2-3 cycles. Branchless arithmetic: (x ^ (x >> 31)) - (x >> 31) = 3 cycles for 32-bit. SIMD (PABSD): 1 cycle for 8 int32s in AVX2. Cost model: for random signs (50/50), branchless wins. For mostly positive or mostly negative, branch may win due to prediction. Unsigned has no absolute value - already positive. Floating point: ANDPS with sign mask = 1 cycle (just clears sign bit). For bulk processing: always use SIMD PABS instructions (1 cycle per 8-16 elements).

Software prefetch (PREFETCH) cost: Instruction overhead: 1-4 cycles to issue. No immediate benefit - just initiates memory fetch. Prefetch must arrive before data is needed: prefetch_distance = cache_miss_latency / loop_iteration_cycles. Example: 200 cycle miss latency, 7 cycles per iteration = prefetch 28 iterations ahead. Too early: data evicted before use. Too late: no hiding of latency. Cost model: effective if hiding latency exceeds instruction overhead. For irregular access patterns, prefetch is often counterproductive. Modern CPUs have good hardware prefetchers for regular patterns - software prefetch mainly helps irregular but predictable patterns.

Floating-point square root cost: Single precision (SQRTSS): Latency 12-15 cycles, throughput ~0.33/cycle. Double precision (SQRTSD): Latency 15-20 cycles, throughput ~0.25/cycle. Not pipelined - one sqrt must complete before next starts in same unit. Approximate alternatives: RSQRTSS (reciprocal sqrt): 4 cycles, ~12-bit precision. RSQRTSS + Newton-Raphson: 8-10 cycles, full precision. For cost estimation: treat sqrt like division - expensive, avoid in tight loops. If precision allows, use rsqrt approximation (3-4x faster).

malloc/free cost varies by size and allocator: Small allocation (<256 bytes): 20-100 cycles with modern allocators (tcmalloc, jemalloc). Medium allocation (<1MB): 100-500 cycles. Large allocation (>1MB, uses mmap): 1000+ cycles, involves syscall. Multithreaded overhead: glibc ptmalloc has lock contention; tcmalloc/jemalloc use per-thread caches. Google data: malloc consumes ~7% of datacenter CPU cycles. Cost model: minimize allocations in hot paths. Use object pools, stack allocation, or arena allocators. Reusing buffers eliminates allocation overhead entirely.

Mutex lock/unlock cost depends on contention: Uncontended (fast path): 15-25 nanoseconds (45-75 cycles). Uses single atomic instruction, no syscall. Contended (must wait): 1-10 microseconds (3,000-30,000 cycles). Includes context switch if blocking. Heavily contended: can serialize to 100x slower than uncontended. Linux futex fast path: ~25ns. Windows CRITICAL_SECTION: ~23ns. For cost estimation: uncontended mutex adds ~50-100 cycles per lock/unlock pair. Design to minimize contention; use lock-free structures or fine-grained locking for hot paths.

Atomic CAS (LOCK CMPXCHG) cost varies dramatically by contention: Uncontended (exclusive cache line): 12-40 cycles. Intel: ~35 cycles on Core 2, ~20 cycles on Skylake. AMD: ~12-15 cycles on Zen. Contended (cache line bouncing): 70-200+ cycles per operation due to cache coherency traffic. Highly contended: effectively serializes, can be 100x slower than uncontended. For cost estimation: budget 20-40 cycles for uncontended atomics, but design to minimize contention. A contended atomic is worse than a mutex in most cases.

C++ exception cost (zero-cost exception model used by modern compilers): No exception thrown: 0 cycles overhead in hot path (tables consulted only on throw). Exception thrown: extremely expensive, 10,000-100,000+ cycles. Components of throw cost: stack unwinding, destructor calls, table lookups, dynamic type matching. Exception construction: typical exception object allocation + string formatting = 1000+ cycles. Cost model: never use exceptions for control flow. Throw rate should be < 0.1% for negligible impact. Code size: exception tables add 10-20% to binary size. For performance-critical code: prefer error codes or std::expected, reserve exceptions for truly exceptional cases.

Instruction mix by workload: Scientific/HPC: 30-50% FP operations, 20-30% loads/stores, 10-20% branches. Integer-heavy (databases): 40-50% integer ALU, 30-40% loads/stores, 10-15% branches. Web servers: heavy load/store (40-50%), many branches (15-20%), string operations. Games: 30-40% FP/SIMD, 30% loads/stores, 15-20% branches. Compilers: 50%+ branches (control flow heavy), moderate loads/stores. Cost model impact: high branch count = misprediction dominates. High load/store = cache behavior dominates. High FP/SIMD = execution unit throughput matters. Profile your workload to understand which category applies, then optimize accordingly.

Integer multiplication (IMUL) has a latency of 3-4 cycles on modern Intel and AMD CPUs. On Intel Skylake and later, 64-bit IMUL has 3-cycle latency with throughput of 1 per cycle. The 128-bit result (RDX:RAX) from MUL r64 has 3-cycle latency for the low 64 bits (RAX) and 4-cycle latency for the high 64 bits (RDX). AMD Zen processors show similar characteristics. For cost estimation: count 3 cycles per dependent multiply, or total_multiplies / throughput for independent operations.

AVX-512 instructions can cause CPU frequency reduction: Light AVX-512 (most instructions): 0-100 MHz reduction. Heavy AVX-512 (FMA, multiply): 100-200 MHz reduction. On Skylake-X: ~0.85x base frequency for heavy AVX-512. Throttling transition: 10-20 microseconds on early Xeon, near-zero on 3rd gen Xeon. Cost model: if AVX-512 section is short, transition overhead may exceed benefit. Break-even: typically need 100+ microseconds of AVX-512 work. Non-AVX code after AVX-512 runs at reduced frequency until transition back. Consider AVX2 for short bursts.

SIMD permute costs vary by type: In-lane permute (within 128-bit lane): 1 cycle latency, 1/cycle throughput. Examples: PSHUFB, PSHUFD. Cross-lane permute (across 128-bit boundaries): 3 cycles latency, 1/cycle throughput. Examples: VPERMPS, VPERMD. Full permute (AVX-512 VPERMB): 3-6 cycles. Cost model for data rearrangement: prefer in-lane shuffles (1 cycle) over cross-lane (3 cycles). Two in-lane shuffles often faster than one cross-lane if possible. VPERMPS for float permutation: 3-cycle latency, handles arbitrary 8-element permutation in AVX2.

Type conversion costs on x86: int to float (CVTSI2SS): 4-6 cycles latency. float to int (CVTTSS2SI): 4-6 cycles latency. int32 to int64 (sign extend): 1 cycle. float to double: 1 cycle (just register renaming on modern CPUs). double to float: 4 cycles (rounding). int64 to float: 4-6 cycles. Narrowing conversions may have additional checking cost in safe languages. Cost model: conversions are cheap relative to memory access but expensive relative to basic ALU. Avoid conversions in inner loops when possible. SIMD conversion: 8 int32 to 8 float in 3 cycles (VCVTDQ2PS). Bulk data: convert once, operate in target format.

Memory operation costs: memset (REP STOSB optimized): 32-64 bytes per cycle for large sizes. memcpy (REP MOVSB optimized): 16-32 bytes per cycle for large sizes. Small sizes (<64 bytes): 10-30 cycles overhead. SIMD explicit copy: can achieve 32-64 bytes per cycle from L1. Cost model: Large memcpy (N bytes) from L1: N / 32 cycles. From L3: N / 16 cycles (limited by L3 bandwidth). From DRAM: N / (DRAM_bandwidth_bytes_per_cycle). Example: memcpy of 1MB from DRAM at 50 GB/s: 1MB / 17 bytes-per-cycle = 62,000 cycles = 20 microseconds at 3 GHz. For small copies: inline code often faster than function call overhead. memmove (handles overlap): similar cost to memcpy.

Binary search cost model: Comparisons: log2(N). Memory accesses: log2(N), all potentially cache misses (random access pattern). If array fits in L1 (N < 4K for 4-byte elements): ~4 cycles per comparison. If array fits in L3 (N < 2M elements): ~40 cycles per comparison. If array exceeds L3: ~200 cycles per comparison (DRAM). Example: binary search in 1 million integers exceeding L3. Comparisons = 20. Cost = 20 * 200 = 4000 cycles = 1.3 microseconds. Optimization: for small arrays, linear search may win due to prefetching. For huge sorted arrays, consider B-tree (multiple elements per cache line) or interpolation search.

SIMD speedup estimation: Theoretical maximum: vector_width / scalar_width. SSE: 4x for float, 2x for double. AVX: 8x for float, 4x for double. AVX-512: 16x for float, 8x for double. Real speedup factors: Vectorization overhead (setup, remainder): reduces by 10-20%. Memory-bound code: limited by bandwidth, not compute. Complex control flow: may not vectorize. Measured typical speedups: compute-bound: 60-80% of theoretical. Memory-bound: 20-50% of theoretical (bandwidth limited). Mixed: 40-70% of theoretical. Cost model: actual_speedup = min(theoretical_speedup, memory_bandwidth_ratio). For bandwidth-bound: speedup = bytes_loaded_per_scalar / bytes_loaded_per_SIMD (often ~1-2x, not 8x).

DRAM refresh overhead: Each row refreshed every 64ms (DDR4 standard). Refresh takes 350ns, blocks access to that bank. Average impact: 5-10% of bandwidth lost to refresh. Worst case: request hits refreshing bank, adds 350ns (1000 cycles) to latency. Temperature effects: above 85C, refresh rate doubles (per DDR4 spec). Cost model: for latency-sensitive code, 99th percentile latency can be 2-3x median due to refresh collisions. Mitigation: modern memory controllers schedule around refresh when possible. For real-time systems: account for refresh-induced jitter. Server-grade memory: higher refresh rates for reliability can increase performance impact.

TLB miss penalty ranges from 20-150 cycles depending on page table depth and caching. Best case (page table in L2): 20-40 cycles. Typical case: 40-80 cycles. Worst case (page table in DRAM): 100-150+ cycles. x86-64 uses 4-level page tables, requiring up to 4 memory accesses. With virtualization (nested page tables): 6x more lookups, penalty can exceed 500 cycles. Mitigation: use huge pages (2MB/1GB) to reduce TLB pressure. TLB typically holds 1500-2000 4KB page entries or 32-64 huge page entries.

Use arithmetic intensity (AI) = FLOPs / Bytes transferred. Ridge point = Peak_FLOPS / Peak_Bandwidth. If AI < ridge_point: memory-bound. If AI > ridge_point: compute-bound. Modern x86 example: Peak = 100 GFLOPS, Bandwidth = 50 GB/s, Ridge = 2 FLOPS/byte. For dot product (2 FLOPs per 8 bytes loaded): AI = 0.25 < 2, memory-bound. For matrix multiply (2N FLOPs per element, amortized): AI can exceed ridge with blocking. Cost model: Memory_bound_time = Bytes / Bandwidth. Compute_bound_time = FLOPs / Peak_FLOPS. Actual_time = max(memory_time, compute_time).

String operation costs: Comparison (strcmp): best case 1 cycle (first char differs), worst case = length cycles + cache misses. SIMD comparison: 16-32 chars per cycle with SSE/AVX. Copy (memcpy): for small strings (<64 bytes): 10-30 cycles. For large strings: limited by memory bandwidth (10-20 GB/s). SIMD copy: 32-64 bytes per cycle from L1. Search (strstr): naive O(nm), optimized (SIMD + hashing) approaches O(n). Cost model: memcpy of N bytes = max(20, N / effective_bandwidth_bytes_per_cycle) cycles. For N=1KB from L1: ~30-50 cycles. For N=1MB from DRAM: ~50,000 cycles at 20 GB/s. Small string optimization (SSO) in std::string: avoids allocation for strings <15-23 chars.

Trigonometric function costs on x86: Hardware x87 (FSIN/FCOS): 50-120 cycles, variable based on input range. Library implementations (libm): typically 50-100 cycles for double precision. Fast approximations (polynomial): 10-30 cycles for single precision, reduced accuracy. SIMD vectorized (Intel SVML): 10 cycles per element for 8 floats. Cost model: use fast approximations when accuracy allows (games, graphics). Library sin/cos: assume 80 cycles per call. For bulk computation: use SIMD versions (vectorize the loop). sincos() computes both for price of one (100 cycles). Avoid sin/cos in tight loops if possible; precompute lookup tables.

False sharing occurs when threads modify different variables on the same cache line. Cost: 40-200 cycles per access instead of 4 cycles (10-50x slowdown). The cache line ping-pongs between cores via coherency protocol. Each modification invalidates other cores' copies. Measured impact: 25-50% performance degradation typical, can be 10x in extreme cases. Detection: look for high cache coherency traffic in perf counters (HITM events). Prevention: pad shared structures to cache line boundaries (64 bytes on x86, 128 bytes on ARM). In C++: alignas(64) or compiler-specific attributes.

Prefetch distance formula: distance = (cache_miss_latency * IPC) / instructions_per_element. Or simpler: distance = miss_latency_cycles / cycles_per_iteration. Example: L3 miss = 200 cycles, loop body = 25 cycles, distance = 200/25 = 8 iterations ahead. For arrays: prefetch &array[i + distance] while processing array[i]. Tuning: measure actual cache miss rate. Start with distance = 8-16, adjust based on profiling. Too short: still waiting for data. Too long: prefetched data evicted before use. Bandwidth consideration: don't prefetch faster than memory bandwidth allows.

Execution time estimation: time = max(compute_time, memory_time, branch_time). Compute_time = sum(instruction_count[i] * cycles[i]) / IPC. Memory_time = cache_misses * miss_penalty / memory_level_parallelism. Branch_time = mispredictions * misprediction_penalty. Simplified model: total_cycles = instructions / IPC + L3_misses * 200 + mispredictions * 17. Example: 1M instructions at IPC=2, 1000 L3 misses, 5000 mispredictions. Cycles = 1M/2 + 1000200 + 500017 = 500K + 200K + 85K = 785K cycles. Time at 3GHz = 262 microseconds. Validate with: perf stat -e cycles,instructions,cache-misses,branch-misses. Adjust model based on measured vs predicted discrepancies.

Pointer chasing is latency-bound because each load depends on previous: If list fits in L1: ~4 cycles per node. If list fits in L2: ~12 cycles per node. If list fits in L3: ~40 cycles per node. If list exceeds L3: ~200 cycles per node (DRAM latency). Total cost = nodes * memory_latency_at_that_cache_level. Example: 1000-node list in DRAM = 200,000 cycles = 67 microseconds at 3 GHz. Optimization: convert to array when possible (sequential access is 10-50x faster). Software prefetching rarely helps (can't prefetch next without completing current load). B-trees beat linked lists precisely because of this cost model.

Memory throughput at each level: L1 cache: 64-128 bytes/cycle (2 loads + 1 store of 32-64 bytes each). L2 cache: 32-64 bytes/cycle. L3 cache: 16-32 bytes/cycle per core. DRAM: ~10-20 bytes/cycle per core (but shared across all cores). Example: DDR4-3200 dual channel = 51.2 GB/s total. At 3 GHz = 17 bytes/cycle shared. Single thread typically achieves 5-8 bytes/cycle from DRAM due to limited memory-level parallelism. Cost model: for bandwidth-bound code, time = bytes / effective_bandwidth_bytes_per_cycle cycles.

Integer division is expensive: 32-bit DIV takes 26 cycles on Intel Skylake, and 8-bit DIV takes about 25 cycles on Coffee Lake. 64-bit division can take 35-90 cycles depending on operand values. AMD processors are generally faster: Zen 2/3 significantly improved division performance. Throughput is very low (one division every 6+ cycles). For cost estimation: assume 26-40 cycles per 32-bit division in dependency chains. Avoid division in hot loops; use multiplication by reciprocal when divisor is constant.

Roofline model: Attainable_FLOPS = min(Peak_FLOPS, Arithmetic_Intensity * Memory_Bandwidth). Where Arithmetic_Intensity (AI) = Work (FLOPs) / Data (Bytes). Example: Peak = 200 GFLOPS, BW = 50 GB/s. If AI = 1 FLOP/byte: Attainable = min(200, 150) = 50 GFLOPS (memory-bound). If AI = 10 FLOPS/byte: Attainable = min(200, 1050) = 200 GFLOPS (compute-bound). Ridge point (crossover): 200/50 = 4 FLOPS/byte. Hierarchical roofline uses different bandwidths for L1/L2/L3/DRAM to identify which cache level is the bottleneck.

NUMA remote memory access costs 1.5-2x more than local: Local node latency: 90-100 nanoseconds (300 cycles at 3 GHz). Remote node latency: 150-250 nanoseconds (450-750 cycles). Bandwidth reduction: 1.5-2x lower for remote access. Measured examples: local 118ns vs remote 242ns (2.0x). Under contention: remote can reach 1200 cycles vs 300 local (4x). Cost model: for NUMA-aware allocation, bind memory to same node as compute thread. Random access across NUMA domains: average_latency = local_latency * local_fraction + remote_latency * remote_fraction.

Floating-point ADD/MUL on modern CPUs: Single precision (float): Latency 3-4 cycles, throughput 2 per cycle. Double precision (double): Latency 3-4 cycles, throughput 2 per cycle. FMA (fused multiply-add): Latency 4-5 cycles, throughput 2 per cycle. Intel Skylake: ADD latency 4 cycles, MUL latency 4 cycles, FMA latency 4 cycles - all symmetric. For cost estimation: floating-point math is nearly as fast as integer math on modern CPUs. Dependency chains are the limiting factor, not throughput. Use FMA when possible (a*b+c in one instruction).

BEFORE: for(i=0; i<n; i++) { if(a[i]>0) sum += a[i]; }. AFTER: for(i=0; i<n; i++) { sum += a[i] & -(a[i]>0); } or using arithmetic selection: sum += (a[i]>0) ? a[i] : 0; which compilers convert to CMOV. The bitwise version works because -(a[i]>0) produces all 1s (0xFFFFFFFF) when true, all 0s when false. AND with the value keeps or zeros it. Speedup: 2-4x when branch misprediction rate exceeds 20%. On modern CPUs, a mispredicted branch costs 15-20 cycles. Branchless code has constant latency of 2-3 cycles regardless of data patterns. Profile with perf stat to check branch-misses; if above 5%, consider branchless. Best for random/unpredictable data; predictable patterns may be faster with branches due to speculative execution.

BEFORE: for(i=0; i<n; i++) arr[i] = 0;. AFTER: memset(arr, 0, n * sizeof(*arr)); or SIMD: __m256i zero = _mm256_setzero_si256(); for(i=0; i<n; i+=8) _mm256_storeu_si256((__m256i*)&arr[i], zero);. For large zeroing (>1MB), use non-temporal stores: _mm256_stream_si256. Special case: calloc() may get zero pages from OS without memset (lazy allocation). For non-zero patterns: __m256i pattern = _mm256_set1_epi32(value);. Speedup: Similar to memcpy, 3-5x over naive loop. The compiler may optimize arr = {} or std::fill to memset internally. For partial zeroing of structs, use = {} initialization which compilers optimize well.

BEFORE: uint32_t swap = ((x >> 24) & 0xFF) | ((x >> 8) & 0xFF00) | ((x << 8) & 0xFF0000) | ((x << 24) & 0xFF000000);. AFTER: uint32_t swap = __builtin_bswap32(x); compiles to single BSWAP instruction. For 16-bit: __builtin_bswap16(x) or use ROL by 8 bits. For 64-bit: __builtin_bswap64(x). SIMD byte shuffle: _mm_shuffle_epi8(vec, shuffle_mask) with mask reversing byte order within each element. Speedup: Shift-and-OR is 8+ operations, BSWAP is 1 instruction (1-2 cycles). Critical for network protocols (ntohl/htonl), file format parsing, cross-platform data exchange. Use htobe32/be32toh (POSIX) or std::byteswap (C++23) for portability.

BEFORE: result = x * 8;. AFTER: result = x << 3;. General pattern: x * (2^n) = x << n. Compilers do this automatically, but understanding helps when reading assembly or writing SIMD. For SIMD: _mm256_slli_epi32(vec, 3) shifts all 8 integers left by 3. Combined patterns: x * 10 = (x << 3) + (x << 1) = x8 + x2. x * 7 = (x << 3) - x = x*8 - x. Speedup: Shift is 1 cycle, multiply is 3-4 cycles on modern x86. However, modern CPUs have fast multipliers, so only matters in extremely hot paths. For division by power-of-2: unsigned x/8 = x >> 3; signed requires adjustment for negative numbers.

BEFORE: for(i=0;i<n;i++) arr[i] = value;. AFTER (AVX): __m256 val_vec = _mm256_set1_ps(value); for(i=0;i<n;i+=8) _mm256_storeu_ps(&arr[i], val_vec);. For large arrays (>L2 cache), use non-temporal stores: _mm256_stream_ps(&arr[i], val_vec); to avoid cache pollution. For sequential values (0,1,2,...): __m256i indices = _mm256_setr_epi32(0,1,2,3,4,5,6,7); __m256i increment = _mm256_set1_epi32(8); for(i=0;i<n;i+=8) { _mm256_storeu_si256((__m256i*)&arr[i], indices); indices = _mm256_add_epi32(indices, increment); }. Speedup: 4-8x for fill, near memory bandwidth for streaming stores. memset uses this internally for byte patterns.

BEFORE: for(i=0; i<n; i++) dst[i] = src[i];. AFTER: memcpy(dst, src, n * sizeof(*dst)); or SIMD: for(i=0; i<n; i+=8) { _mm256_storeu_ps(&dst[i], _mm256_loadu_ps(&src[i])); }. For large copies (>1MB), use non-temporal stores: _mm256_stream_ps(dst, _mm256_loadu_ps(src)); bypasses cache to avoid polluting it. For tiny copies (<64 bytes), rep movsb may be optimal on modern Intel (ERMSB). Speedup: Naive loop achieves ~20% bandwidth, optimized memcpy achieves >90%. glibc memcpy uses SIMD with runtime CPU detection. For moves (overlapping): memmove handles overlap correctly; memcpy may not. Use __builtin_memcpy for compiler optimization opportunities.

BEFORE: sum = a[0]; for(i=1; i<n; i++) sum += a[i]; (serial dependency chain, 3-4 cycles per add). AFTER: sum0=sum1=sum2=sum3=0; for(i=0; i<n; i+=4) { sum0+=a[i]; sum1+=a[i+1]; sum2+=a[i+2]; sum3+=a[i+3]; } sum=sum0+sum1+sum2+sum3;. This creates 4 independent dependency chains that execute in parallel via out-of-order execution. Speedup: 2-4x on modern CPUs with 4+ execution ports. The critical insight: floating-point addition is associative mathematically but not in IEEE 754 (slight precision differences). GCC -ffast-math or -fassociative-math enables automatic reassociation. For exact results, use Kahan summation instead.

BEFORE: uint64_t product = (uint64_t)a * b; uint32_t high = product >> 32;. AFTER: Use compiler intrinsic or inline asm: uint32_t high = __umulh(a, b); (MSVC) or use asm for MULX. For 64-bit: unsigned __int128 prod = (unsigned __int128)a * b; uint64_t high = prod >> 64;. Or: __uint128_t support in GCC/Clang. SIMD: _mm256_mulhi_epu16 for 16-bit, _mm256_mul_epu32 returns 64-bit products. For modular arithmetic and Montgomery multiplication, mulhi is essential. Speedup: Avoiding 128-bit types can be 1.5-2x faster on 32-bit systems. On 64-bit, compilers handle it well, but direct mulhi intrinsics guarantee optimal code generation.

BEFORE: for(i=0;i<n;i++) gray[i] = 0.299fr[i] + 0.587fg[i] + 0.114f*b[i];. AFTER (SoA with AVX): __m256 coef_r = _mm256_set1_ps(0.299f); __m256 coef_g = _mm256_set1_ps(0.587f); __m256 coef_b = _mm256_set1_ps(0.114f); for(i=0;i<n;i+=8) { __m256 rv = _mm256_loadu_ps(&r[i]); __m256 gv = _mm256_loadu_ps(&g[i]); __m256 bv = _mm256_loadu_ps(&b[i]); __m256 gray_v = _mm256_fmadd_ps(rv, coef_r, _mm256_fmadd_ps(gv, coef_g, _mm256_mul_ps(bv, coef_b))); _mm256_storeu_ps(&gray[i], gray_v); }. For packed RGB bytes: deinterleave first, convert to float, compute, convert back. Speedup: 4-8x. Use FMA for 3-multiply-add pattern.

BEFORE: int16_t result = a + b; if(result > 32767) result = 32767; if(result < -32768) result = -32768;. AFTER (SIMD): __m256i result = _mm256_adds_epi16(a, b); for signed, _mm256_adds_epu16 for unsigned. These automatically saturate instead of wrapping. For scalar: int32_t sum = (int32_t)a + b; result = (sum > 32767) ? 32767 : (sum < -32768) ? -32768 : sum; with branchless: int32_t sum = a + b; sum = sum < -32768 ? -32768 : sum; sum = sum > 32767 ? 32767 : sum;. ARM NEON: vqaddq_s16 (saturating add). Speedup: 2-4x with SIMD saturation instructions. Essential for audio (preventing clipping), image processing (pixel clamping), DSP applications.

BEFORE: int factorial(int n) { if(n<=1) return 1; return n * factorial(n-1); }. AFTER: int factorial(int n) { int result=1; while(n>1) { result*=n; n--; } return result; }. For tree traversal: BEFORE: void dfs(Node* n) { if(!n) return; process(n); dfs(n->left); dfs(n->right); }. AFTER: stack<Node*> s; s.push(root); while(!s.empty()) { Node* n=s.top(); s.pop(); if(!n) continue; process(n); s.push(n->right); s.push(n->left); }. Speedup: 1.5-3x from avoiding function call overhead and potential stack overflow. Use explicit stack sized to max expected depth. Tail recursion can be optimized by compiler (-O2), but complex recursion requires manual transformation.

BEFORE: float rsqrt = 1.0f / sqrtf(x);. AFTER (fast inverse square root): float rsqrt(float x) { int i = (int)&x; i = 0x5f3759df - (i >> 1); float y = (float)&i; y = y * (1.5f - 0.5f * x * y * y); return y; }. One Newton-Raphson iteration. The magic constant approximates by exploiting IEEE 754 float format. Modern CPUs: _mm_rsqrt_ps provides hardware approximation (~12 bits accuracy), follow with Newton-Raphson for more precision. Speedup: 4x over sqrtf+division. Used in graphics normalization, physics engines. Note: Modern SSE/AVX rsqrt instructions are preferred over the integer trick, as they're faster and more accurate.

BEFORE: for(i=0; i<N; i++) for(j=0; j<N; j++) C[i][j] += A[i][k] * B[k][j]; (cache-thrashing for large N). AFTER: for(ii=0; ii<N; ii+=BLOCK) for(jj=0; jj<N; jj+=BLOCK) for(kk=0; kk<N; kk+=BLOCK) for(i=ii; i<min(ii+BLOCK,N); i++) for(j=jj; j<min(jj+BLOCK,N); j++) for(k=kk; k<min(kk+BLOCK,N); k++) C[i][j] += A[i][k] * B[k][j];. Choose BLOCK so 3BLOCKBLOCK*sizeof(element) fits in L1 cache (~32KB). For doubles: BLOCK=32-64. Speedup: 2-10x for matrices larger than cache. Reduces cache misses from O(N^3) to O(N^3/BLOCK). This is the foundation of high-performance BLAS implementations.

BEFORE: if(x<a) f0(); else if(x<b) f1(); else if(x<c) f2(); else if(x<d) f3(); else f4();. AFTER (binary decision tree for uniform distribution): if(x<c) { if(x<a) f0(); else if(x<b) f1(); else f2(); } else { if(x<d) f3(); else f4(); }. This ensures average 2-3 comparisons instead of worst-case 4. For sorted thresholds: use binary search then dispatch. For very many cases: int idx = binary_search(thresholds, x); handlersidx;. Speedup: O(n) to O(log n) comparisons for n cases. The balanced tree minimizes expected comparisons when all branches are equally likely. Profile branch frequencies to optimize tree shape for skewed distributions.

BEFORE: for(j=0; j<N; j++) for(i=0; i<M; i++) sum += matrix[i][j]; (stride of N elements between accesses, cache thrashing). AFTER: Either transpose first, then access row-major: transpose(matrix, transposed); for(i=0; i<M; i++) for(j=0; j<N; j++) sum += transposed[j][i];. Or interchange loops: for(i=0; i<M; i++) for(j=0; j<N; j++) sum += matrix[i][j];. In-place transpose for square matrices: for(i=0; i<N; i++) for(j=i+1; j<N; j++) swap(matrix[i][j], matrix[j][i]);. Speedup: 3-10x depending on stride and cache size. Strided access with stride >= cache line wastes entire cache line per access. Blocking/tiling helps when full transpose isn't feasible.

BEFORE: result = a * b + c; (2 operations: MUL then ADD, potential intermediate rounding). AFTER: result = fma(a, b, c); or use compiler flag -ffp-contract=fast. FMA computes ab+c in single instruction with single rounding. In intrinsics: __m256 r = _mm256_fmadd_ps(a, b, c);. Benefits: (1) Single cycle throughput vs 2 cycles for separate MUL+ADD on Haswell+, (2) Higher precision - no intermediate rounding, (3) 2x FLOPS potential. Variants: fmadd (ab+c), fmsub (ab-c), fnmadd (-ab+c), fnmsub (-a*b-c). Speedup: 1.5-2x for FMA-bound code. Available on x86 since Haswell (2013), ARM since Cortex-A15. Check with: __builtin_cpu_supports('fma').

BEFORE: for(i=0; i<n; i++) if(arr[i]==target) return i;. AFTER (AVX2): __m256i target_vec = _mm256_set1_epi32(target); for(i=0; i<n; i+=8) { __m256i data = _mm256_loadu_si256((__m256i*)&arr[i]); __m256i cmp = _mm256_cmpeq_epi32(data, target_vec); int mask = _mm256_movemask_ps(_mm256_castsi256_ps(cmp)); if(mask) return i + __builtin_ctz(mask); }. Compares 8 integers simultaneously. Speedup: 4-8x for large arrays. For strings, use _mm256_cmpeq_epi8 and process 32 bytes at once. SIMD search beats binary search for n<1000 due to sequential memory access. Combine approaches: binary search to narrow range, then SIMD scan the final segment.

BEFORE: for(i=0;i<n;i++) for(j=0;j<n;j++) if(matrix[i][j]) process(i, j, matrix[i][j]); O(n^2) even for sparse. AFTER (CSR format): int row_ptr[n+1], col_idx[nnz]; float values[nnz]; for(i=0;i<n;i++) for(k=row_ptr[i]; k<row_ptr[i+1]; k++) process(i, col_idx[k], values[k]); O(nnz). SpMV (sparse matrix-vector multiply): for(i=0;i<n;i++) { y[i] = 0; for(k=row_ptr[i];k<row_ptr[i+1];k++) y[i] += values[k] * x[col_idx[k]]; }. Speedup: For 99% sparse 1000x1000 matrix, from 1M iterations to 10K (100x faster). CSR is the standard format for scientific computing, graph algorithms, and sparse linear algebra.

BEFORE (direct): for(i=0;i<n;i++) for(j=0;j<k;j++) out[i] += in[i+j] * kernel[j]; O(n*k) complexity. AFTER (FFT): FFT(in), FFT(kernel), pointwise multiply, IFFT(result). O(n log n) complexity. Use when kernel size k > ~64. Implementation: pad both to next power of 2 >= n+k-1, use FFT library (FFTW, Intel MKL). Speedup: For n=1M, k=1K: direct is 10^9 ops, FFT is ~60M ops (15x faster). For small kernels (k<16), direct convolution with SIMD is faster. Libraries like cuDNN use FFT internally for large convolutions. The crossover point depends on FFT implementation efficiency.

BEFORE: uint32_t hash = 0; for(i=0;i<len;i++) hash = hash*31 + data[i];. AFTER (process 16 bytes at once): Use CRC32 instruction: for(i=0;i<len;i+=8) hash = _mm_crc32_u64(hash, (uint64_t)&data[i]);. Or xxHash/MurmurHash3 SIMD: process 32-byte blocks with AVX2, vectorized multiplication and mixing. Example (simplified xxHash-like): __m256i acc = seed_vec; for(i=0;i<len;i+=32) { __m256i data = _mm256_loadu_si256(&input[i]); acc = _mm256_add_epi64(acc, _mm256_mul_epu32(data, prime_vec)); acc = _mm256_xor_si256(acc, _mm256_srli_epi64(acc, 17)); }. Speedup: 5-10x. Modern hash functions (xxHash3, wyhash) achieve >10GB/s using SIMD.

BEFORE: if(fabs(a - b) < epsilon) (expensive fabs, floating-point subtract). AFTER for IEEE 754 positive floats: Reinterpret as integers and compare: int32_t ia = (int32_t)&a; int32_t ib = (int32_t)&b; if(abs(ia - ib) < ulps). This uses ULPs (Units in Last Place) for comparison. Works because IEEE 754 floats are ordered like integers when positive. For signed floats, adjust: if(ia < 0) ia = 0x80000000 - ia;. SIMD: Cast to integer, compare with _mm256_cmpgt_epi32. Speedup: 1.5-2x for comparison-heavy code. This technique is used in physics engines and numerical software. Caveat: Fails for NaN and infinity; add special handling if needed.

BEFORE: int result = x / 3;. AFTER (unsigned): result = ((uint64_t)x * 0xAAAAAAABULL) >> 33;. AFTER (signed): More complex due to rounding toward zero. The magic constant 0xAAAAAAAB = ceil(2^33 / 3). For x/7: multiply by 0x24924925 and shift right 34. For x/10: multiply by 0xCCCCCCCD and shift right 35. Compilers generate this automatically for constant divisors (inspect assembly!). The technique from Granlund/Montgomery 1994 handles any constant. Speedup: Division is 20-90 cycles, multiply-shift is 3-4 cycles (5-20x faster). For repeated division by same dynamic value, compute reciprocal once: inv = ((1ULL << 32) + d - 1) / d; then result = (x * inv) >> 32;.

BEFORE: for(i=0;i<n;i++) if(arr[i] == target) return i;. AFTER (AVX2): __m256i target_vec = _mm256_set1_epi32(target); for(i=0; i<n; i+=8) { __m256i data = _mm256_loadu_si256((__m256i*)&arr[i]); __m256i cmp = _mm256_cmpeq_epi32(data, target_vec); int mask = _mm256_movemask_ps(_mm256_castsi256_ps(cmp)); if(mask) return i + __builtin_ctz(mask); } return -1;. Checks 8 elements per iteration. For bytes: check 32 per iteration with _mm256_cmpeq_epi8 and _mm256_movemask_epi8. Speedup: 4-8x for large arrays. Critical insight: early-exit preserves first-match semantics. For find-all, remove early exit and collect all positions.

BEFORE: for(i=0; i<8; i++) result[i] = data[indices[i]];. AFTER (AVX2): __m256i idx = _mm256_loadu_si256((__m256i*)indices); __m256 result = _mm256_i32gather_ps(data, idx, sizeof(float));. Scale parameter (4 for float) handles element size. AVX-512 adds mask support: _mm512_mask_i32gather_ps(src, mask, idx, base, scale). Speedup: Varies widely. Gather is NOT parallel memory access - it serializes internally. Effective when: indices fit in cache, or when combined with other SIMD operations. For truly random access, explicit loads may be faster. Benchmark your specific case. Gather is 12-20 cycles on Intel, faster on AMD Zen4+.

BEFORE: size_t len = 0; while(str[len]) len++;. AFTER (SSE2): __m128i zero = _mm_setzero_si128(); size_t i = 0; while(1) { __m128i chunk = _mm_loadu_si128((__m128i*)(str + i)); __m128i cmp = _mm_cmpeq_epi8(chunk, zero); int mask = _mm_movemask_epi8(cmp); if(mask) return i + __builtin_ctz(mask); i += 16; }. This checks 16 bytes per iteration. PCMPISTRI (SSE4.2) handles null termination implicitly: return _mm_cmpistri(_mm_loadu_si128(str), zero, _SIDD_UBYTE_OPS | _SIDD_CMP_EQUAL_EACH);. Speedup: 8-16x for long strings. glibc strlen uses this approach with alignment handling. Watch for reading past string end crossing page boundary - align start to 16 bytes.

BEFORE: for each 3 bytes, split into 4 6-bit values, look up in table. AFTER (SSE/AVX): Load 12 bytes (4 groups of 3). Reshuffle to align 6-bit fields: __m128i shuffled = _mm_shuffle_epi8(input, shuffle_mask); Shift and mask to extract: __m128i indices = ...; Use _mm_shuffle_epi8 as 16-entry lookup table for encoding. Or use comparison and add-if-greater for the base64 alphabet ranges (A-Z, a-z, 0-9, +/). Speedup: 5-10x. The key insight: base64 is a deterministic character-by-character transformation, perfect for SIMD. Modern implementations (like Turbo-Base64) achieve 4-8 GB/s encode speed. See: https://github.com/lemire/fastbase64 for production implementations.

BEFORE (AoS): struct Particle { float x, y, z, mass; }; Particle particles[N]; for(i=0; i<N; i++) particles[i].x += dt * particles[i].vx;. AFTER (SoA): struct Particles { float x[N], y[N], z[N], mass[N]; }; Particles p; for(i=0; i<N; i++) p.x[i] += dt * p.vx[i];. Speedup: 2-4x for SIMD operations, 1.5-2x for scalar due to cache efficiency. AoS loads entire struct (16+ bytes) when you need one field (4 bytes), wasting 75% bandwidth. SoA enables: (1) SIMD processing of contiguous x values, (2) Better cache utilization when accessing single field across many objects, (3) Streaming stores. Use AoS when all fields accessed together; SoA when iterating over single field.