TNCO: The Tensor Optimizer That Makes Impossible Problems Fit

A hybrid Python and C++ engine that searches contraction trees, uses simulated annealing, and slices giant tensor networks into exact pieces when memory is the wall.

11 min read • View on GitHub • More from google-research

A lone surveyor stands above a vast lattice of tensor nodes suspended over a white landscape. A narrow route threads through the network, while a few bonds are marked as cut points, showing that the problem becomes feasible only when the graph is carefully partitioned. — TNCO's core promise is not just a better path. It is a path that still exists under a real memory cap.

TNCO is a heuristic tool that optimizes tensor network contraction paths. It represents the contraction as a tree – with the initial tensors as leaves and the final tensor as the root – and explores possible paths by manipulating this tree's structure.

Salvatore Mandrà, Primary Contributor/Maintainer · google-research/tnco README

Key Takeaways

TNCO is built for tensor networks where the best contraction path still fails if the intermediate tensors do not fit in memory.
Slicing is its defining move because it turns one impossible network into smaller exact jobs instead of one larger approximation.
The Python and C++ split keeps the tool approachable while the hot loop stays fast enough for extreme search.
TNCO occupies a narrow specialist slot between general einsum optimizers and broader tensor-network toolkits.

The real bottleneck is not FLOPs, it is memory

Tensor network contraction has a brutal failure mode: the cheapest path on paper can still collapse under a giant intermediate tensor before the answer appears. TNCO exists for that second problem. It searches for a route that is not only cheap, but survivable.

That shift matters. In TNCO's finite width mode, the objective is not just to reduce total work. It is to keep the peak intermediate small enough that the computation can actually finish.

Why TNCO exists

TNCO comes out of Google Research, and the repository frames it as a heuristic optimizer for tensor network contraction paths. That sounds narrow until you remember the setting: quantum simulation work where the search space is enormous, the memory ceiling is real, and exactness still matters. The README also ties the project to the 2025 Nature paper on constructive interference at the edge of quantum ergodicity.

That origin explains the tone of the code. TNCO is not polished for casual curiosity. It is opinionated because the underlying problem is opinionated, and it was shaped by workloads where a toy answer is useless.

TNCO's real trick: cut the problem, keep the answer exact

TNCO's differentiator is slicing. Instead of insisting on one monolithic contraction, it can cut selected bonds and solve the result as smaller exact subproblems. The trade-off is blunt: more total work, far less peak memory. That is often the difference between failure and a result.

A close-up of a dense knot of cords being split into smaller bundles by a precise blade. A ledger and a scale sit beside the knot, signaling the trade-off between peak memory and total work. — Slicing lowers the memory peak by turning one hard contraction into smaller exact subproblems.

Interactive diagram: move the memory budget and watch TNCO shift from one feasible plan to another while preserving exactness.

How the engine works under the hood

TNCO treats contraction as a binary tree. The leaves are the input tensors, the root is the final tensor, and the optimizer searches by rearranging subtrees rather than only walking a linear list of steps. That gives simulated annealing a richer space to explore.

The hot loop lives in C++. The Python side handles the public API, the CLI, and parallel runs with joblib, while pybind11, CMake, and scikit-build-core keep the bridge between the two languages usable. The C++ core also leans on bitset operations and high precision cost arithmetic, including float128 and float1024 paths, because the numbers involved can outgrow ordinary floating-point ranges.

That precision detail is not a curiosity. If the search scores overflow, the optimizer starts guessing. TNCO's tests and explicit seed handling show a project that treats reproducibility as part of the algorithm, not as a polish pass.

TNCO versus cotengra and opt_einsum

TNCO does not replace the other names in this space. It sits in a narrower slot, where the main question is not just how to optimize a contraction, but how to make the contraction feasible at all.

Tool	Primary job	Search style	Memory strategy	Best fit
opt_einsum	Optimize einsum expression order	Broad, practical baseline	Useful optimization, but not built around extreme slicing workflows	Everyday tensor users and general Python libraries
cotengra	Search tensor contraction paths	Flexible toolkit with many heuristics	Strong memory-aware options and a broad algorithmic palette	Researchers who want a versatile Python optimizer
TNCO	Optimize contraction trees under hard constraints	Simulated annealing with a C++ hot loop	Treats memory as the central constraint and can slice into exact subproblems	Quantum simulation and other extreme-scale tensor networks

The cleanest way to read that table is simple. If you need a broad baseline, opt_einsum is the default. If you want a flexible Python toolbox, cotengra has more knobs. If the real problem is a huge network that must fit in memory without approximation, TNCO is the specialist.

What TNCO says about scientific tooling

TNCO is a useful reminder that serious scientific software is often built around constraints, not convenience. The breakthrough is not just a faster path finder. It is a solver that knows when the right answer is to slice, search again, and stay exact.