Accelerating 'get_detcost' function

[draganaurosgrbic]

Performance Optimization: Accelerating the A* Heuristic Function with Data Locality and Early-Exit Logic

This Pull Request introduces two major optimizations to the get_detcost function, a critical component of Tesseract's A* heuristic. These changes resolve a severe performance bottleneck, leading to dramatic speedups of up to 5X faster decoding in some configurations.

---

The Problem: The get_detcost Bottleneck

Tesseract's decoding process relies on an admissible A* heuristic, which requires the precise calculation of a lower-bound cost for each search state. This calculation is performed by the get_detcost function, which aggregates the minimum cost of unblocked errors affecting a given detector.

My profiling consistently identified get_detcost as the primary performance bottleneck across all code families, consuming:

• Over 60% of total decoding time in Color Codes.
• Over 70% (and sometimes up to 90%) in Bivariate-Bicycle Codes.
• Around 40% in Surface Codes and Transversal CNOT Protocols.

The core inefficiency stemmed from high-frequency accesses to elements at arbitrary, non-contiguous indices within two large pre-computed vectors. This scattered memory access pattern led to numerous CPU cache misses, severely degrading performance. However, a key observation was that accesses to these vectors exhibited a consistent co-access pattern: elements at the same arbitrary index in both vectors were frequently accessed together. The original implementation was missing this crucial insight.

---

The Solution: A Two-Pronged Optimization Strategy

To address this bottleneck, I implemented two key optimizations:

1. Improved Data Locality:
   Leveraging the co-access pattern, I redesigned the two conceptual vectors into a single std::vector of a custom data structure. Each element of this new vector is a custom struct with two uint32_t fields: one for the blocked error flag and the other for the fired detector count. This reorganization dramatically improved data locality, ensuring that co-accessed data resided contiguously in memory. With a total size of 8 bytes per struct, this design aligns well with typical 64-byte CPU cache lines, maximizing the benefits of hardware pre-fetching. This optimization builds on the std::vector<bool> to std::vector<char> optimization from PR Replace std::vector<bool> with std::vector<char> for faster computations #25.

2. Early-Exit Strategy:
   The cost calculation loop within get_detcost was made more efficient by implementing an early-exit strategy. I now pre-compute a lower bound on the cost of each error before decoding begins. Errors are pre-sorted based on this lower bound. When calculating a detector's cost, the function can now terminate its loop early if the current minimum cost is less than or equal to the lower bound of the next error to be considered. This clever strategy significantly prunes unnecessary iterations.

---

Performance Impact: Up to 5X Faster Decoding

These optimizations yielded remarkable results, validated through two distinct sets of experiments.

• Initial Benchmarks (Smaller Number of Shots):
  For smaller benchmarks, I specifically analyzed the impact of the optimizations in this PR. This demonstrated a reduction in cache misses in the get_detcost function by over 70% in Color Codes and over 50% in Bivariate-Bicycle Codes. Speedups from these two optimizations alone reached almost 40% in Color Codes and over 50% in Bivariate-Bicycle Codes.

• Extensive Benchmarks (1000 Shots):
  I then performed extensive benchmarks on 1000 shots to measure the cumulative speedup from both the optimization in PR Replace std::vector<bool> with std::vector<char> for faster computations #25 and the two new optimizations in this PR. The combined effect resulted in massive decoding speedups:

  • Bivariate-Bicycle Codes: 41.2% to 79.6% (up to 5X faster)
  • Surface Codes: 45.4% to 52.3% (up to 2X faster)
  • Transversal CNOT Protocols: 45% to 51.8% (up to 2X faster)
  • Color Codes: 37.2% to 52.1% (up to 2X faster)

The attached graphs provide a detailed breakdown of these performance improvements across various configurations.

---

Key Contributions

• Pinpointed a Critical Bottleneck: Performed extensive profiling to identify get_detcost as the main performance bottleneck, consuming up to 90% of decoding time.
• Engineered Two Optimizations: Implemented a dual strategy of improving data locality by reorganizing co-accessed data into a single custom struct and introducing an early-exit strategy to prune redundant computations.
• Validated Performance Improvements: Conducted thorough benchmarks on both small-scale experiments (measuring cache misses and speedup from this PR alone) and large-scale (1000-shot) experiments to demonstrate the cumulative impact.
• Achieved Massive Speedups: Delivered a cumulative performance boost of up to 5X faster decoding, making a major improvement to the overall efficiency of Tesseract.

---

Plots for Smaller Benchmarks

Decoding Speedup in Color Codes

Cache Misses Improvement in Color Codes

---

Decoding Speedup in Bivariate-Bicycle Codes

Cache Misses Improvement in Bivariate-Bicycle Codes

---

Decoding Speedup in NLR5 Bivariate-Bicycle Codes

Cache Misses Improvement in NLR5 Bivariate-Bicycle Codes

---

Decoding Speedup in NLR10 Bivariate-Bicycle Codes

Cache Misses Improvement in NLR10 Bivariate-Bicycle Codes

---

Plots for Broad Benchmarks (1000 shots)

Decoding Speedup in Color Codes

---

Decoding Speedup in Bivariate-Bicycle Codes

---

Decoding Speedup in Surface Codes

---

Decoding Speedup in Transversal CNOT Protocols

[LalehB]

@draganaurosgrbic amazing plots and speedup! I was wondering if these cache misses are cache misses of the total program or only the get_detcost program because it says "cache misses in the get_detcost function" in the title of plots

[draganaurosgrbic]

@LalehB Cache misses are for the get_detcost function only. On a plot, when I say cache misses for get_detcost are 50%, this means that 50% of all cache misses spent in the application were spent in get_detcost. On plots for cache misses, for each optimization strategy, I also plotted a number that says the improvement in percentage (if cache misses were initially 35.74% and after optimization they were 11.25%, this means we achieved a 68.5% improvement).

[LalehB]

LGTM!
Thanks Dragana. very nice speedups 👏🏻