One More Einsum Contraction Order (OMECO)
Tensor network contraction order optimization in Rust.
Ported from OMEinsumContractionOrders.jl.
Documentation
📖 Read the full documentation (mdBook)
- Getting Started Guide
- Algorithm Comparison
- GPU Optimization
- PyTorch Integration
- API Reference
- Rust API Docs
Overview
When contracting multiple tensors together, the order of contractions significantly affects computational cost. Finding the optimal contraction order is NP-complete, but good heuristics can find near-optimal solutions quickly.
This library provides:
- GreedyMethod: Fast O(n² log n) greedy algorithm for contraction order
- TreeSA: Simulated annealing for higher quality contraction orders
- TreeSASlicer: Automatic slicing optimization to reduce memory usage
Installation
Python
Rust
Add to your Cargo.toml:
[]
= "0.1"
Python Quick Start
# Matrix chain: A[0,1] × B[1,2] × C[2,3] → D[0,3]
=
=
=
# 1) Optimize contraction order
=
=
# 2) Slice to reduce memory (automatic optimization)
=
=
=
# Use with PyTorch (see examples/pytorch_tensor_network_example.py)
= # Convert to dict for traversal
Rust Quick Start
Two core features are exposed in the quick start below: optimizing contraction orders and slicing for lower peak memory.
use ;
use HashMap;
// Matrix chain: A[i,j] * B[j,k] * C[k,l] -> D[i,l]
let code = new;
// Define tensor dimensions
let mut sizes = new;
sizes.insert;
sizes.insert;
sizes.insert;
sizes.insert;
// 1) Optimize contraction order
let optimized = optimize_code.unwrap;
let complexity = contraction_complexity;
println!;
println!;
// 2) Slice to reduce memory (automatic optimization)
let slicer = fast.with_sc_target;
let sliced = slice_code.unwrap;
let sliced_comp = sliced_complexity;
println!;
Additional Resources
- Examples: See
examples/for complete working examples - Troubleshooting: See the troubleshooting guide
- API Reference: Python & Rust API docs
Algorithms
GreedyMethod
Iteratively contracts the tensor pair with minimum cost:
use ;
let code = new;
let sizes = uniform_size_dict;
// Default: deterministic greedy
let result = optimize_code;
// Stochastic greedy with temperature
let stochastic = new;
let result = optimize_code;
Parameters:
alpha: Balances output size vs input size reduction (0.0 to 1.0)temperature: Enables Boltzmann sampling (0.0 = deterministic)
TreeSA
Simulated annealing with local tree mutations:
use ;
let code = new;
let sizes = uniform_size_dict;
// Fast configuration (fewer iterations)
let result = optimize_code;
// Default configuration (higher quality)
let result = optimize_code;
// Custom configuration with space constraint
let custom = default
.with_sc_target // Target space complexity
.with_ntrials; // More parallel trials
let result = optimize_code;
Parameters:
betas: Inverse temperature schedulentrials: Number of parallel trials (uses rayon)niters: Iterations per temperature levelscore: Scoring function with complexity weights
Complexity Metrics
Three complexity metrics are computed (all in log2 scale):
use ;
let code = new;
let mut sizes = new;
sizes.insert;
sizes.insert;
sizes.insert;
let optimized = optimize_code.unwrap;
let c = contraction_complexity;
println!;
println!;
println!;
Custom Scoring
Control the trade-off between time and space complexity:
use ;
// Optimize primarily for time (ignore space)
let time_score = time_optimized;
// Optimize for space with target of 2^15 elements
let space_score = space_optimized;
// Custom weights
let custom_score = new;
let config = TreeSA ;
Working with NestedEinsum
The optimized result is a NestedEinsum representing the contraction tree:
use ;
let code = new;
let sizes = uniform_size_dict;
let tree = optimize_code.unwrap;
// Inspect the tree
println!;
println!;
println!;
// Get contraction order (leaf indices)
let order = tree.leaf_indices;
println!;
Sliced Contractions
For memory-constrained scenarios, use SlicedEinsum:
use ;
// Assume we have an optimized tree
let leaf0 = leaf;
let leaf1 = leaf;
let eins = new;
let tree = node;
// Slice over index 'j' to reduce memory
let sliced = new;
println!;
Integer Labels
For programmatic use, integer labels are often more convenient:
use ;
use HashMap;
// Using usize labels instead of char
let code: = new;
let mut sizes = new;
sizes.insert;
sizes.insert;
sizes.insert;
sizes.insert;
let result = optimize_code;
Performance Tips
- Use TreeSA::fast() for quick results - Fewer iterations, single trial
- Increase ntrials for large problems - More parallel exploration
- Set sc_target based on available memory - Constrains space complexity
- Use GreedyMethod for very large networks - O(n² log n) vs O(n² × iterations)
Benchmarks
We benchmark TreeSA performance by comparing the Rust implementation (exposed to Python via PyO3) against the original Julia implementation (OMEinsumContractionOrders.jl).
Hardware: Intel Xeon Gold 6226R @ 2.90GHz
Configuration: ntrials=1, niters=50-100, βs=0.01:0.05:15.0
TreeSA Results
| Problem | Tensors | Indices | Rust (ms) | Julia (ms) | Rust tc | Julia tc | Speedup |
|---|---|---|---|---|---|---|---|
| chain_10 | 10 | 11 | 22.9 | 31.6 | 23.10 | 23.10 | 1.38x |
| grid_4x4 | 16 | 24 | 132.4 | 150.7 | 9.18 | 9.26 | 1.14x |
| grid_5x5 | 25 | 40 | 264.0 | 297.7 | 10.96 | 10.96 | 1.13x |
| reg3_250 | 250 | 372 | 4547 | 5099 | 48.01 | 47.17 | 1.12x |
Key observations:
- Rust is 10-40% faster than Julia for TreeSA optimization
- Both implementations find solutions with comparable time complexity (tc)
- The
reg3_250benchmark (random 3-regular graph with 250 nodes) shows TreeSA reduces tc from ~66 (greedy) to ~48, a 27% improvement
To run the benchmarks yourself:
# Rust (via Python)
&&
# Julia
&&
License
MIT