ArcTN: Efficient Tensor-Network Contraction Planning for Quantum Circuit Simulation

arXiv:2610.31554 · quant-ph, cs.MS · Submitted 2026-10-22 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Quantum Radio. Generated commentary on the latest quantum physics and condensed matter papers.

Kai: I'm Kai.

Mira: And I'm Mira, here with Lev.

Kai: We're looking at the paper: "ArcTN: Efficient Tensor-Network Contraction Planning for Quantum Circuit Simulation".

Mira: Here's the gist of the paper. ArcTN, a contraction-order optimization framework, addresses challenges in tensor-network simulation by providing adaptive search and memory-aware slicing to minimize computational cost without excessive optimization overhead or large intermediate tensors Contraction Planning Problem Tensor networks provide a common representation for quantum circuit simulations where contraction evaluates the requested quantity by multiplying tensor entries and summing over non-output indices However, an unsuitable order can make a contraction unnecessarily expensive or produce tensors too large to store Efficient simulation therefore depends on contraction planning, which selects an order that reduces computational cost while accounting for the resources needed to find and execute it The difficulty in this planning problem is balancing three coupled concerns: low computational cost, minimal planning time, and accommodation of tensor-size constraints ArcTN Framework ArcTN provides two complementary search presets, Light and Heavy, that combine diversified initial orders with adaptive randomized-greedy search and selective subtree reconfiguration Light prioritizes low planning overhead, whereas Heavy performs more extensive refinement to obtain lower-cost contraction orders The framework also supports Fixed and Dynamic slicing to control intermediate tensor sizes, together with numerical execution using optimized contraction orders ArcTN implements this workflow in Rust with Python interfaces, allowing users to validate the input, search for an order, optionally construct a sliced plan, and support numerical execution through a native CPU executor or an external array backend Search Presets and Refinement The Light preset emphasizes low planning overhead while Heavy devotes more effort to obtaining lower-cost orders Both presets use the cross-entropy method to adapt random-greedy candidate generation and retain multiple starting orders, allowing refinement to explore orders whose initial costs may not reflect their eventual quality Selective refinement involves changing small parts of each selected contraction tree using subtree reconfiguration, and if local changes do not improve the order sufficiently, the planner uses parallel tempering to explore alternatives beyond those reached by local improvement For Heavy, an additional search on the simplified network through parallel tempering followed by optional fixed-leaf-order dynamic programming is performed to find lower-cost ways to combine input tensors while preserving their sequence Slicing Methods For tensor-size constraints, ArcTN provides Fixed and Dynamic slicing Fixed slicing selects sliced indices while preserving the chosen contraction order, progressively selecting labels from results that exceed the size limit to bring all results within the limit Dynamic slicing alternates slice selection with local changes to the order, first applying Fixed slicing and then representing one slice by setting selected index dimensions to one and applying subtree reconfiguration, accepting a revised order if it does not increase the cost of that slice This allows the order to be reconsidered as slicing changes the computation, rather than treating slicing solely as a postprocessing step Evaluation and Results ArcTN was evaluated on QC32, a benchmark comprising 32 quantum-circuit tensor networks, against established contraction optimizers On the 30 circuits completed by all eight main configurations, ArcTN Light reduces contraction FLOPs by 61.32% with a 1.62× planning-time speedup over Cotengra Auto/CMA-ES ArcTN Heavy reduces FLOPs by 43.83% with a 7.21× planning-time speedup over Cotengra AutoHQ/Optuna, and by 11.85% with a 1.33× speedup over OMECO TreeSA-8 For memory-constrained contractions, Dynamic slicing reduces total sliced FLOPs by 31.99% relative to Fixed slicing, at the cost of additional planning time Experiments with a common NumPy executor further demonstrate that ArcTN Heavy achieves the lowest combined planning and execution time among five evaluated configurations on their shared successful cases On 672 additional networks built from 320 MQT Bench circuits for amplitude, expectation-value, and state tasks, ArcTN Heavy obtains the lowest geometric-mean FLOPs on the 142 large networks while planning 3.1× and 31× faster than Cotengra AutoHQ and Hyper128 ArcTN successfully integrates contraction-order search, slicing, and reusable execution plans through Python interfaces to a Rust implementation The results demonstrate the practical benefits of coordinating order search and slicing to balance planning effort, contraction cost, and tensor size Future work includes improving Heavy on expectation-value networks and extending the native executor to accelerators References The paper cites various tools for comparison including Cotengra, OMECO, and Google TNCO, as well as libraries like quimb and opt einsum.

Kai: The evaluation compares planning performance, execution through a shared numerical backend, and the costs of sliced plans.

Mira: The comparison includes various search configurations such as Light and Heavy against baselines like Cotengra Auto/CMA-ES and OMECO TreeSA-8.

Kai: The experiments were conducted on a server equipped with Intel Xeon Platinum 8253 processors at 2.20 GHz and approximately 2.95 TiB of memory.

Title and authors: Kai: So we're looking at the paper titled ArcTN: Efficient Tensor-Network Contraction Planning for Quantum Circuit Simulation. It sounds like they're tackling the core problem of how to simulate quantum circuits efficiently by finding a good contraction order.

Mira: Exactly, it’s about how you multiply those tensors and sum over indices to get what you actually want, but if you pick the wrong order, the resulting tensors can get huge or the math becomes way too slow.

Lev: Yeah, and that planning part is tricky because you have to balance three things: the actual computation cost, how long it takes to find that order, and making sure those intermediate tensors don't overflow your memory.

Kai: Right, so this paper introduces ArcTN as a framework that tries to handle all of those coupled concerns at once using adaptive search and memory-aware slicing.

Mira: It’s interesting because they aren't just proposing one solution, but they give us two distinct search presets, Light and Heavy.

Lev: And that distinction between Light and Heavy is important for real hardware because it lets you choose whether you want a quick plan or a really good plan that might take more time to find.

Kai: Right, so we’re going to look at what this framework actually does in detail in the next part.

Mira: We need to understand how they approach that planning problem before we get into the specifics of their results.

Lev: It’s helpful to see how they handle the trade-off between planning effort and actual contraction cost, because that’s where real overhead creeps in.

The paper's summary: Kai: Okay, so ArcTN essentially provides two search presets, Light and Heavy. Light is designed for when you need low planning overhead; it prioritizes speed of finding an order even if the resulting contraction cost isn't the absolute lowest possible.

Mira: And Heavy is for when you really want to minimize the computational cost of that contraction, even if it means spending more time searching and refining the initial orders.

Lev: That makes sense from a hardware perspective; on real superconducting chips, planning time is often just as important as execution time because you have to schedule those operations carefully.

Kai: And they use adaptive randomized-greedy search for both presets, meaning they don't just pick one starting point and stick with it; the search adapts based on what it finds.

Mira: Plus, they incorporate selective subtree reconfiguration and parallel tempering to refine those initial orders, which is a smart way to explore the solution space beyond just simple greedy construction.

Lev: Exploring alternative structures is key because sometimes a local improvement isn't enough; you need something more global, and parallel tempering helps with that kind of deep search.

Kai: And they also have these slicing methods, Fixed and Dynamic slicing, which lets you control the size of those intermediate tensors to keep them manageable.

Mira: That’s the memory-aware part—they aren't just optimizing for speed or cost in isolation; they are managing the tensor size constraints alongside it.

Lev: Controlling those intermediate tensor sizes is crucial because if a tensor gets too big, you just can't store it on the available hardware, so that control is non-negotiable.

The paper's improvements: Kai: Moving into the specific improvements they detail, they focus on making this entire workflow more coordinated. They organize their adaptive candidate generation and stopping criteria into those Light and Heavy presets.

Mira: And then they integrate the slicing methods directly into that planning process so slicing isn't just something you do after you find an order; it changes how the computation is done from the start.

Lev: That coordination between search and slicing is what really matters for practical use, especially if we think about running these simulations repeatedly on a fixed circuit structure.

Kai: They also highlight that they provide an executable contraction tool, a Rust implementation with Python interfaces, which lets you connect the order search and the slicing directly to numerical execution.

Mira: And they make sure that execution plans can be retained and reused with new tensor values without having to repeat the entire expensive order search process every single time.

Lev: Reusing those plans is a huge win for iterative algorithms, because you avoid doing the whole planning search over and over again just because your input numbers changed slightly.

Kai: And they even introduce rate-based stopping criteria, which lets you stop planning early if the expected execution time looks too long based on a calculated estimate.

Mira: That’s a way to manage computational resources during optimization; you don't let the planning run wild if it looks like it’s going to take too long for real hardware.

Lev: If we think about running this on actual hardware, knowing when to stop planning early based on an estimate is something that could save significant time during development cycles.

Conclusion: Kai: So, wrapping up the ArcTN paper, what they’ve done is give us a coordinated planning framework that combines adaptive search and memory-aware slicing.

Mira: It’s about balancing the need for low computational cost against the reality of resource constraints like tensor size.

Lev: From an engineering standpoint, their ability to provide reusable execution plans really connects the theoretical search part to actual, repeated computations on hardware.

Kai: And they also offer two presets, Light and Heavy, letting you dial in exactly how much planning effort you want to spend for a given simulation task.

Mira: The results show that ArcTN Light can reduce contraction FLOPs by sixty-one point three two percent compared to some baselines, while Dynamic slicing cuts total sliced FLOPs by thirty-one point nine nine percent relative to Fixed slicing when memory is tight.

Lev: And for the heavy preset, they found it achieves the lowest combined planning and execution time on shared successful cases when run with a common NumPy executor.

Kai: It really shows that coordinating the order search and slicing is a practical way to manage the trade-offs between planning effort, contraction cost, and tensor size in these simulations.

Mira: The main limitation they mention is that dynamic slicing does come at the cost of additional planning time to achieve those memory savings.

Lev: And when you look at their findings on large networks from three hundred twenty MQT Bench circuits, ArcTN Heavy obtained the lowest geometric-mean FLOPs with planning times that were three point one times and thirty-one times faster than Cotengra AutoHQ and Hyper128.

Kai: So, this ArcTN framework is a solid tool for anyone working on tensor network simulations who needs to balance finding an efficient order with keeping those intermediate tensors small enough to handle.

Mira: It’s a practical system that integrates the search, slicing, and execution plans through that Rust implementation with Python interfaces.

Lev: For us building error correction tools, knowing how you can generate reusable execution plans without repeating the order search is a pretty significant improvement for iterative work on real hardware.

Arclight Quantum Computing Inc. · HYGON Institute of Software, Chinese Academy of Sciences · Nanjing Tech University

quant-ph, cs.MS

Submitted: 2026-10-22

Updated: 2026-10-23

Comments: 29 pages, 4 figures, 15 tables. Code and benchmarks: https://github.com/Quill-ArcLight/ArcTN

Code: https://github.com/Quill-ArcLight/ArcTN

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 90/100

The gist: The gist: ArcTN, a contraction-order optimization framework, addresses challenges in tensor-network simulation by providing adaptive search and memory-aware slicing to minimize computational cost

Key concepts

Contraction Planning Problem: Tensor network simulations require multiplying large tensors together. Choosing the wrong sequence for this multiplication can lead to extremely high computational costs or unmanageably large intermediate data structures. Contraction planning is the task of selecting an order that minimizes this cost while respecting memory limits.
ArcTN Light and Heavy Presets: These are two search strategies: Light prioritizes quick planning with low overhead, while Heavy performs a deeper, more extensive search to find lower-cost orders. Both use adaptive methods to refine initial guesses, allowing the user to choose between speed and maximum optimization effort.
Fixed and Dynamic Slicing: These methods control the size of intermediate tensors. Fixed slicing selects specific indices while keeping the order constant, progressively trimming results if they exceed a limit. Dynamic slicing mixes fixed selection with local order changes, allowing the system to revise the contraction path based on memory constraints.
Parallel Tempering and Subtree Reconfiguration: These are advanced refinement techniques used during search. Parallel tempering explores different contraction orders simultaneously by exchanging states at various 'temperatures,' while subtree reconfiguration allows small parts of a chosen order tree to be swapped out if local improvements stall, helping find better solutions.

Summary

The gist: ArcTN, a contraction-order optimization framework, addresses challenges in tensor-network simulation by providing adaptive search and memory-aware slicing to minimize computational cost without excessive optimization overhead or large intermediate tensors

Contraction Planning Problem

Tensor networks provide a common representation for quantum circuit simulations where contraction evaluates the requested quantity by multiplying tensor entries and summing over non-output indices However, an unsuitable order can make a contraction unnecessarily expensive or produce tensors too large to store Efficient simulation therefore depends on contraction planning, which selects an order that reduces computational cost while accounting for the resources needed to find and execute it The difficulty in this planning problem is balancing three coupled concerns: low computational cost, minimal planning time, and accommodation of tensor-size constraints

ArcTN Framework

ArcTN provides two complementary search presets, Light and Heavy, that combine diversified initial orders with adaptive randomized-greedy search and selective subtree reconfiguration Light prioritizes low planning overhead, whereas Heavy performs more extensive refinement to obtain lower-cost contraction orders The framework also supports Fixed and Dynamic slicing to control intermediate tensor sizes, together with numerical execution using optimized contraction orders ArcTN implements this workflow in Rust with Python interfaces, allowing users to validate the input, search for an order, optionally construct a sliced plan, and support numerical execution through a native CPU executor or an external array backend

Search Presets and Refinement

The Light preset emphasizes low planning overhead while Heavy devotes more effort to obtaining lower-cost orders Both presets use the cross-entropy method to adapt random-greedy candidate generation and retain multiple starting orders, allowing refinement to explore orders whose initial costs may not reflect their eventual quality Selective refinement involves changing small parts of each selected contraction tree using subtree reconfiguration, and if local changes do not improve the order sufficiently, the planner uses parallel tempering to explore alternatives beyond those reached by local improvement For Heavy, an additional search on the simplified network through parallel tempering followed by optional fixed-leaf-order dynamic programming is performed to find lower-cost ways to combine input tensors while preserving their sequence

Slicing Methods

For tensor-size constraints, ArcTN provides Fixed and Dynamic slicing Fixed slicing selects sliced indices while preserving the chosen contraction order, progressively selecting labels from results that exceed the size limit to bring all results within the limit Dynamic slicing alternates slice selection with local changes to the order, first applying Fixed slicing and then representing one slice by setting selected index dimensions to one and applying subtree reconfiguration, accepting a revised order if it does not increase the cost of that slice This allows the order to be reconsidered as slicing changes the computation, rather than treating slicing solely as a postprocessing step

Evaluation and Results

ArcTN was evaluated on QC32, a benchmark comprising 32 quantum-circuit tensor networks, against established contraction optimizers On the 30 circuits completed by all eight main configurations, ArcTN Light reduces contraction FLOPs by 61.32% with a 1.62× planning-time speedup over Cotengra Auto/CMA-ES ArcTN Heavy reduces FLOPs by 43.83% with a 7.21× planning-time speedup over Cotengra AutoHQ/Optuna, and by 11.85% with a 1.33× speedup over OMECO TreeSA-8 For memory-constrained contractions, Dynamic slicing reduces total sliced FLOPs by 31.99% relative to Fixed slicing, at the cost of additional planning time Experiments with a common NumPy executor further demonstrate that ArcTN Heavy achieves the lowest combined planning and execution time among five evaluated configurations on their shared successful cases On 672 additional networks built from 320 MQT Bench circuits for amplitude, expectation-value, and state tasks, ArcTN Heavy obtains the lowest geometric-mean FLOPs on the 142 large networks while planning 3.1× and 31× faster than Cotengra AutoHQ and Hyper128

Conclusion

ArcTN successfully integrates contraction-order search, slicing, and reusable execution plans through Python interfaces to a Rust implementation The results demonstrate the practical benefits of coordinating order search and slicing to balance planning effort, contraction cost, and tensor size Future work includes improving Heavy on expectation-value networks and extending the native executor to accelerators

References

The paper cites various tools for comparison including Cotengra, OMECO, and Google TNCO, as well as libraries like quimb and opt einsum. The evaluation compares planning performance, execution through a shared numerical backend, and the costs of sliced plans. The comparison includes various search configurations such as Light and Heavy against baselines like Cotengra Auto/CMA-ES and OMECO TreeSA-8. The experiments were conducted on a server equipped with Intel Xeon Platinum 8253 processors at 2.20 GHz and approximately 2.95 TiB of memory. The results are presented across various circuit families from MQT Bench, including amplitude estimation, phase estimation, and quantum neural networks. The paper also details the exact integer cost arithmetic used for dynamic programs to ensure exact comparisons for tied orders. The evaluation of MQT Bench circuits involves building four networks for each circuit, including amplitude, expectation-value, and state networks. The results show that Heavy has the lowest geometric-mean FLOPs on large networks with much less planning time than Cotengra AutoHQ and Hyper128 The comparison across different network sizes reveals that ArcTN Light is 1.29× faster than its baseline in about half its time on large networks. The final evaluation on the Hygon cluster shows both presets reduce planning and contraction time, achieving speedups in total time of 5.91× for Light and 6.53× for Heavy The results show that Dynamic reduces total sliced FLOPs relative to Fixed by 31.99% for scalar outputs and 27.04% for tensor outputs, with additional planning time.

Improvements for AI systems

Adaptive Contraction Planning via ArcTN Light and Heavy presets allows AI systems to dynamically balance planning overhead against contraction cost. This enables a system to select between a fast but less optimal order (Light) or an extensive search for the lowest cost order (Heavy) based on the required planning effort.
Tensor-Size Aware Slicing via Fixed and Dynamic slicing allows the system to control intermediate tensor sizes by fixing selected index variables or iteratively revising the contraction order when constraints are violated. This capability enables AI systems to handle memory-constrained simulations while maintaining a low total FLOPs cost, as shown by ArcTN Light reducing FLOPs by 61.32% and Dynamic reducing total sliced FLOPs by 31.99%.
Reusable Execution Plans enable the AI system to store and reuse contraction plans for repeated computations without repeating the expensive order search. This allows for repeated computations with the same network structure and shapes, significantly improving efficiency when simulating circuits multiple times or running iterative algorithms on fixed structures.
Planning Control via rate-based stopping criteria enables the system to stop planning early if the expected execution time exceeds a calculated estimate, thus preventing excessive planning overhead. This feature ensures that finding a cheaper order can also shorten the remaining search, effectively managing computational resources during the optimization phase.
Parallel Tempering and Subtree Reconfiguration allow for sophisticated refinement of contraction orders beyond simple greedy construction, exploring alternative structures by exchanging orders at different temperatures. This enables AI systems to find lower-cost contraction orders that may not reflect their eventual quality from initial searches alone by exploring the solution space more thoroughly.
Hardware Acceleration via native CPU or external array backends allows the system to execute the optimized contraction plans directly on appropriate hardware, such as NumPy or CuPy. This ensures that planning efficiency translates into actual execution speed, with ArcTN Heavy achieving the lowest combined planning and execution time among five evaluated configurations on shared successful cases.