PauLIB: Efficient Pauli Algebra Processing

• PauLIB is a high-performance library for processing generalized Pauli strings and sums in quantum computing.
• It uses a compact bit-packed binary symplectic representation with sorted array and struct-of-arrays layouts to enable SIMD and multi-threaded efficiency.
• Benchmark results show up to 660× speedups over competitors and significant memory reductions for large-scale quantum workloads.

Searching arXiv for PauLIB and closely related Pauli-processing work to ground the article. PauLIB is a header-only C++20 library for high-performance processing of generalized Pauli strings and Pauli sums, introduced to remove performance bottlenecks that arise when quantum software must manipulate very large collections of Pauli terms in quantum chemistry, Pauli propagation, and Pauli-based compilation (Krötz, 25 May 2026). Its design centers on three architectural choices stated explicitly in the 2026 paper: a bit-packed binary symplectic representation, a sorted array layout rather than hash maps, and a struct-of-arrays (SoA) memory layout that exposes contiguous word arrays for explicit SIMD vectorization. The library is open source and provides both C++ and Python interfaces (Krötz, 25 May 2026).

1. Terminology and scope

In the 2026 arXiv paper, PauLIB denotes a software library for Pauli-string processing in quantum computing workloads (Krötz, 25 May 2026). The name should be distinguished from Pabulib, a separate resource in computational social choice described as a participatory budgeting data library and website at http://pabulib.org/ (Stolicki et al., 2020). The two projects are unrelated in purpose, data model, and application domain.

Within the quantum-computing context, PauLIB targets workloads in which Hamiltonians and observables are represented as large Pauli sums. The motivating use cases listed in the source material are molecular Hamiltonians mapped to Pauli sums, Pauli propagation / observable evolution through circuits, Pauli-based compilation and gate reordering, and related symbolic algebra tasks in quantum software stacks (Krötz, 25 May 2026). This framing places the library at the backend layer of quantum software, where constant-factor costs in symbolic Pauli algebra can dominate end-to-end runtime.

A plausible implication is that PauLIB is intended less as a user-facing algorithmic framework than as a systems-level substrate for higher-level quantum workflows. That interpretation follows from the emphasis on representation, memory layout, SIMD exposure, and multi-threaded merging rather than on new variational, compilation, or chemistry algorithms.

2. Computational setting and motivating bottlenecks

The paper defines an $n$-qubit Pauli string as

$$P = \bigotimes_{i=1}^{n} P_i, \quad P_i \in \{I,X,Y,Z\},$$

and a Pauli sum as

$H = \sum_j c_j P_j,\quad c_j \in \mathbb{C}.$

It emphasizes that practical quantum-chemistry Hamiltonians can contain millions of terms, and that many workflows repeatedly require Pauli-string multiplication, commutation testing, Hamiltonian outer-product multiplication, grouping into commuting subsets, and propagation through Clifford/non-Clifford gates (Krötz, 25 May 2026).

The reported bottlenecks in existing tools are specific and implementation-oriented: Python interpreter overhead for per-term operations, memory-heavy boolean-array layouts in Qiskit, hash-map based storage that prevents efficient SIMD processing and makes merging difficult, and poor cache locality for large-scale bulk operations (Krötz, 25 May 2026). The paper therefore treats performance degradation as a consequence not merely of asymptotic complexity, but of data representation and memory-traffic patterns.

The propagation example given in the source is a single non-Clifford rotation that can double the number of tracked terms: $Q' = \cos(\theta)\,Q - i\sin(\theta)\,PQ.$ In that setting, the Pauli backend becomes the dominant runtime cost (Krötz, 25 May 2026). This suggests that PauLIB is designed for regimes in which term growth is intrinsic to the physics or compiler transformation, so reducing the overhead of each symbolic operation is operationally more important than changing the formal workload.

3. Binary symplectic encoding and Pauli algebra

The first architectural choice is a bit-packed binary symplectic representation. Each qubit is encoded by two bits, an $x$-bit and a $z$-bit: $$I \mapsto (0,0),\quad Z \mapsto (0,1),\quad X \mapsto (1,0),\quad Y \mapsto (1,1).$$ An $n$-qubit Pauli string then fits into $\lceil n/64\rceil$ 64-bit words for the $X$ bits and the same for the $$P = \bigotimes_{i=1}^{n} P_i, \quad P_i \in \{I,X,Y,Z\},$$0 bits, plus a small phase field (Krötz, 25 May 2026).

The central computational consequence is that Pauli multiplication reduces to wordwise XOR on the packed bit vectors,

$$P = \bigotimes_{i=1}^{n} P_i, \quad P_i \in \{I,X,Y,Z\},$$1

with phase tracking determined by parity or popcount-style arithmetic. The paper states that phase tracking follows a symplectic-inner-product approach “following the same general approach as Stim” (Krötz, 25 May 2026). A compact summary given in the source is

$$P = \bigotimes_{i=1}^{n} P_i, \quad P_i \in \{I,X,Y,Z\},$$2

with composition

$$P = \bigotimes_{i=1}^{n} P_i, \quad P_i \in \{I,X,Y,Z\},$$3

up to a phase factor determined by the symplectic overlap (Krötz, 25 May 2026).

Commutation testing is formulated through the binary symplectic inner product. The paper states that two Pauli strings commute iff

$$P = \bigotimes_{i=1}^{n} P_i, \quad P_i \in \{I,X,Y,Z\},$$4

has even parity; odd parity implies anti-commutation (Krötz, 25 May 2026). In the equivalent summary form,

$$P = \bigotimes_{i=1}^{n} P_i, \quad P_i \in \{I,X,Y,Z\},$$5

This is the algebraic basis for both multiplication and greedy commutation grouping.

The source attributes much of PauLIB’s performance to this encoding itself, rather than to SIMD or threading alone. That distinction is important because it locates the principal optimization at the representational level: the library compresses semantic structure into a form that matches bitwise machine operations.

4. Storage model and memory layout

The second architectural choice is a sorted array layout. Rather than storing Pauli sums in hash maps, PauLIB stores terms in sorted contiguous vectors (Krötz, 25 May 2026). The workflow described in the paper is: build an index array, sort by a fixed-width lexicographic key made from the packed words, and then perform one linear scan to combine duplicates. The stated consequences are branch-predictable access, sequential memory traffic, SIMD-friendly bulk operations, easy binary-search lookup, and simpler multi-threaded merging than hash maps. The sort is $$P = \bigotimes_{i=1}^{n} P_i, \quad P_i \in \{I,X,Y,Z\},$$6 for $$P = \bigotimes_{i=1}^{n} P_i, \quad P_i \in \{I,X,Y,Z\},$$7 terms, and deduplication is a linear pass (Krötz, 25 May 2026).

The third architectural choice is explicit support for both array-of-structs (AoS) and struct-of-arrays (SoA) layouts for Pauli sums (Krötz, 25 May 2026). In AoS, each term stores its packed $$P = \bigotimes_{i=1}^{n} P_i, \quad P_i \in \{I,X,Y,Z\},$$8-words, $$P = \bigotimes_{i=1}^{n} P_i, \quad P_i \in \{I,X,Y,Z\},$$9-words, phase flags, and coefficient together. In SoA, all $H = \sum_j c_j P_j,\quad c_j \in \mathbb{C}.$0-words for a given word index are stored contiguously across terms, with analogous contiguous storage for $H = \sum_j c_j P_j,\quad c_j \in \mathbb{C}.$1-words, flags, and coefficients.

The paper gives a concrete rationale for SoA in bulk Clifford gate application: a gate on qubit $H = \sum_j c_j P_j,\quad c_j \in \mathbb{C}.$2 touches only word $H = \sum_j c_j P_j,\quad c_j \in \mathbb{C}.$3, so the relevant data for all $H = \sum_j c_j P_j,\quad c_j \in \mathbb{C}.$4 terms resides in one contiguous array, enabling vectorized loops and reducing cache pollution (Krötz, 25 May 2026). Conversely, for some multiplication workloads at 500 qubits, AoS slightly outperforms SoA because keeping all words of one term contiguous improves cache-line locality.

This layout duality is significant because the paper does not present a single universally optimal representation. Instead, it states that layout choice depends on the operation: SoA is best for single-qubit gate sweeps and some vectorized bulk tasks, while AoS wins slightly for outer-product multiplication at the reported qubit count (Krötz, 25 May 2026). A plausible implication is that PauLIB is organized around workload-specific data-motion optimization rather than a single abstract container interface.

5. Core operations

PauLIB’s single-string multiplication kernel consists of XOR on packed $H = \sum_j c_j P_j,\quad c_j \in \mathbb{C}.$5 and $H = \sum_j c_j P_j,\quad c_j \in \mathbb{C}.$6 words together with a popcount or symplectic-parity-based phase calculation (Krötz, 25 May 2026). For 500 qubits, the paper notes that each string occupies 8 words in each of the $H = \sum_j c_j P_j,\quad c_j \in \mathbb{C}.$7 and $H = \sum_j c_j P_j,\quad c_j \in \mathbb{C}.$8 components, so multiplication is handled by a very small bitwise kernel. In the SoA variant, the compiler can emit wide vector instructions such as AVX-512 XOR and popcount operations (Krötz, 25 May 2026).

For Hamiltonian outer-product multiplication, where $H = \sum_j c_j P_j,\quad c_j \in \mathbb{C}.$9 and $Q' = \cos(\theta)\,Q - i\sin(\theta)\,PQ.$0 generate $Q' = \cos(\theta)\,Q - i\sin(\theta)\,PQ.$1 pairwise products, the paper describes four acceleration mechanisms: pre-allocation of the output array, OpenMP parallelization across right-hand-side blocks, explicit SIMD via Google Highway, and the packed bit kernel for each pair (Krötz, 25 May 2026). At 500 qubits, the AoS layout is reported to be slightly better than SoA for this operation because each term spans 8 words and contiguous per-term storage improves cache locality.

For greedy commutation grouping, the dominant inner loop is repeated commutation testing, so the binary symplectic representation again becomes decisive (Krötz, 25 May 2026). The commutation predicate reduces to the parity of anti-commuting overlaps, computed by bitwise symplectic-inner-product logic rather than by higher-level symbolic or string processing. The source notes that at 500 qubits, SIMD and threading give little extra benefit beyond the bit-packed representation because each check already spans the full 8-word width of the Pauli string (Krötz, 25 May 2026).

The paper therefore presents PauLIB not simply as an implementation of Pauli algebra, but as a family of kernels whose data layout is tuned to the access pattern of the target operation. That characterization follows directly from the different AoS/SoA trade-offs reported for multiplication and gate application.

6. Empirical performance and memory footprint

All reported benchmarks were run at 500 qubits on a dual-socket Intel Xeon Max 9468 system with AVX-512, using GCC 13.2 and 96 physical cores for threaded tests (Krötz, 25 May 2026). The paper compares PauLIB against PauliEngine, Qiskit, and, for commutation grouping, PennyLane.

For single Pauli multiplication, the reported numbers for 100, 200, 500, and 1,000 random pairs are 25 ns/op for PauLIB SoA, about 350 ns/op for PauliEngine, and about 16.5 µs/op for Qiskit. The stated speedups are 14× faster than PauliEngine and 660× faster than Qiskit, with timing reported to be flat across pair counts (Krötz, 25 May 2026).

For Hamiltonian outer-product multiplication, the paper reports that PauLIB AoS and SoA lie in the lower performance band and are roughly 10× faster than PauliEngine and Qiskit overall (Krötz, 25 May 2026). At $Q' = \cos(\theta)\,Q - i\sin(\theta)\,PQ.$2, producing $Q' = \cos(\theta)\,Q - i\sin(\theta)\,PQ.$3 output terms, PauLIB AoS is about 10× faster than PauliEngine and 45× faster than Qiskit. At 200 × 200 terms and 500 qubits, the SoA variant completes in 98 µs, which the paper states is about 140× faster than PauliEngine and Qiskit at that scale. It also reports that at 500 qubits, AoS slightly outperforms SoA by about 1.3× for the outer product (Krötz, 25 May 2026).

For greedy commutation grouping, the benchmarked range for a random 500-qubit Pauli sum is about 1.04 s to 27.3 s for PennyLane at 200 to 1,000 terms, versus about 50 µs to 5.6 ms for PauLIB variants (Krötz, 25 May 2026). The key result given is up to 21,000× speedup over PennyLane, around 18,000× at 1,000 terms, and about 20,000× speedup at 2,000 terms for the OMP+SIMD variant in the interface discussion. The paper explicitly stresses that these gains arise mostly from the compact binary symplectic representation rather than from SIMD or threading alone.

The reported memory-footprint comparison for a 1,000,000-term Hamiltonian at 500 qubits is 142 MB for PauLIB versus 1,036 MB for Qiskit, a 7.3× reduction (Krötz, 25 May 2026). The paper explains the PauLIB estimate as $Q' = \cos(\theta)\,Q - i\sin(\theta)\,PQ.$4 64-bit words for $Q' = \cos(\theta)\,Q - i\sin(\theta)\,PQ.$5, 8 words for $Q' = \cos(\theta)\,Q - i\sin(\theta)\,PQ.$6, plus an 8-byte double coefficient, giving about 137 bytes per term. Qiskit, by contrast, is described as storing two full boolean arrays of shape $Q' = \cos(\theta)\,Q - i\sin(\theta)\,PQ.$7 with additional Python object overhead (Krötz, 25 May 2026).

Workload at 500 qubits	Reported PauLIB result	Comparison stated in the paper
Single Pauli multiplication	25 ns/op	14× faster than PauliEngine; 660× faster than Qiskit
Outer-product multiplication at $Q' = \cos(\theta)\,Q - i\sin(\theta)\,PQ.$8	98 µs for SoA	about 140× faster than PauliEngine and Qiskit at that scale
Greedy commutation grouping	about 50 µs to 5.6 ms	up to 21,000× faster than PennyLane
1,000,000-term Hamiltonian memory	142 MB	7.3× smaller than Qiskit

7. Significance, interfaces, and limitations

The practical significance attributed to PauLIB is that it makes Pauli algebra “fast enough to be a usable backend for large-scale quantum workloads,” specifically quantum chemistry, Pauli propagation through circuits, and Pauli-based compilation and reordering (Krötz, 25 May 2026). The paper ties this significance directly to three implementation properties: bit-level compactness, cache-friendly sorted storage, and SIMD / OpenMP parallelism.

The source also states that PauLIB is open source and exposes both C++ and Python interfaces (Krötz, 25 May 2026). This dual-interface model suggests an attempt to combine low-level throughput with integration into higher-level quantum software stacks, although the paper’s emphasis remains on the C++ implementation strategy rather than on Python ergonomics.

Several limitations or boundaries are implicit in the reported evaluation. The benchmark section is fixed to 500 qubits and to specific platforms and competitor frameworks (Krötz, 25 May 2026). In addition, the paper repeatedly emphasizes that performance depends on the operation and the chosen layout: SoA is especially useful for bulk Clifford gate application, while AoS slightly wins for outer-product multiplication at the reported size. This suggests that PauLIB should not be understood as asserting one universally dominant in-memory representation.

A further caution is conceptual rather than critical: the paper’s strongest claims are about symbolic Pauli processing kernels, not about complete quantum-application pipelines. A plausible implication is that end-to-end gains in chemistry, simulation, or compilation will depend on how much total runtime is attributable to Pauli-string manipulation and on whether surrounding stages preserve the same data-locality advantages. Within that scope, PauLIB is presented as a specialized systems library whose contribution is the reduction of Pauli algebra to compact, vectorizable, and merge-friendly machine-level operations (Krötz, 25 May 2026).