GB-scale joint prune tables (CEE/CCE/C4C5C6) via mmap. eo peaks ~24GB working set but only ~0.1GB private — tables are read-only shared mmap.
The staged cube-solver fleet: native analyzers (feeding the scramble distribution + per-comp precompute) and browser WASM (live solve on the gen page) — coverage, throughput, memory.
slot-decoupled + strong pruning, fastest
strongest joint-table pruning, full 5 stages
corner/edge slot coupling, heavier search
weak deep-stage pruning, no huge tables; 2 seed comps only
same as f2leo, 2 seed comps only
off the default weekly run, full backfill ~165h
xxxxcross full enumeration ~13M nodes/case — the long pole
GB-scale joint prune tables (CEE/CCE/C4C5C6) via mmap. eo peaks ~24GB working set but only ~0.1GB private — tables are read-only shared mmap.
~40MB: mt_edge2/4 + corn + edge + pt_cross + on-the-fly BFS xcross pruning. No huge tables, so deep stages are slow.
Each analyzer runs rayon par_iter over a whole chunk across all 16 cores; tables shared read-only via mmap. Running variants concurrently loads distinct GB-scale tables → blows past 32GB, so they run serially.
Browsers cannot hold GB-scale huge tables, so deep stages (xxxxcross) are orders of magnitude slower than native; no SharedArrayBuffer means workers do not share tables. Common comps are served instantly from comp_steps precompute — live solve is only a fallback for uncovered comps.