One More Einsum Contraction Order (OMECO)
Tensor network contraction order optimization in Rust.
Ported from OMEinsumContractionOrders.jl.
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 two optimization algorithms:
- GreedyMethod: Fast O(n² log n) greedy algorithm
- TreeSA: Simulated annealing for higher quality solutions
Installation
Add to your Cargo.toml:
[]
= "0.1"
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 (trade time for space)
let sliced = new;
let sliced_complexity = sliced_complexity;
println!;
Documentation
API documentation is available via cargo doc --open or at docs.rs/omeco.
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