Mixed Atmospheres Research notes / 01About the measurements
Performance investigation Updated 07 November 2026

Faster colonies.
The same simulation?

What makes a large colony slow, which optimizations preserve its state, and where faster computation changes the answer.

BLUF Recommendation first

Rebuild main with exact changes.
Keep the numerical defaults.

The exact parcel caches plus const reads show 8.67% less native work and +8.39% observed base throughput. All 66 Linux scenarios passed; the changes landed on main and are ready for your Windows rebuild. No useful SO gain is established. Keep extra overlap unadopted. Sustained, smooth 3× remains unproven.

See the strongest evidence
Linux research · two large coloniesLanded on main · 40a1465

01 / Latest exact candidate · 07 Nov

Less repeated work.
Identical endpoints.

The candidate combines two pass-local parcel wire caches with const reads that avoid copying untouched cell chunks. Physical operations, solver arithmetic, checkpoint format and the existing inventory limits are preserved.

The full 3,000-tick ABBA replay is complete. Its result measures native work, not an automatic whole-game speedup.

Measured · Linux checks passed

07 Nov · matched native replay

8.67% less native work

Lower is better
Control Exact candidate
Mean owner tick−8.67%
93.746 ms
85.619 ms
Mean transfer stage−53.03%
19.218 ms
9.027 ms
Worst owner tick1,003 → 150 ms
1,003.417 ms
150.318 ms
Each pair has its own scale. Four fresh 3,000-tick replays in ABBA order: control, candidate, candidate, control. The first 150 ticks per run are excluded, leaving 5,700 warmed samples per side.

All four final full-owner hashes match. All 128 short owner images also match across both colonies at 1 and 12 workers. Full-cycle equality compares the endpoints, not every intermediate checkpoint.

Replay spread, tail latency and memory limits

The two control run means were 96.1888 and 91.3033 ms; candidate means were 85.6332 and 85.6048 ms. The aggregate uses both controls. Lower mean work corresponds to about 9.49% more native capacity, with no automatic equivalent game-speed claim.

Owner p99 fell from 215.236 to 123.837 ms; worst transfer time fell from 919.964 to 38.960 ms. Maximum mass/energy errors are unchanged at 3.58023e−15 / 2.62020e−16.

Mean peak replay RSS was 4,378.1 → 4,387.5 MiB. No memory saving was demonstrated. Replay memory includes the large journal and parsed inputs; it is not game RSS.

What the exact changes do

The admission cache maintains the encoded-size total during a transfer pass. The release cache validates the retained inventory once, then checks the changed entry and the same aggregate limits. Refused changes preserve the original parcel and cached totals. These caches add no persistent save state.

Const reads for occupied-volume initialization, neighbor snapshots and heat/energy queries inspect untouched cell storage without triggering copy-on-write chunk copies. The synthetic operation benchmarks above explain that mechanism; their RSS reductions do not establish game-memory savings.

Historical comparison · 6 November experiment

The earlier parcel-cache-only ABBA experiment measured 89.754 → 78.639 ms per native tick (12.38% less work), 18.433 → 8.504 ms in transfers, and 967.313 → 141.571 ms worst owner ticks. Its endpoints also matched, and no meaningful memory saving was demonstrated.

Those are historical results from a separate cohort. The current headline uses the fresh 7 November control/candidate comparison, including the const reads.

02 / Latest in-game result · 07 Nov

The base improves.
SO remains constrained.

Game speed is game seconds per wall second. A 1.00× result is real time; 3.00× is the requested speed.

These are ordered live pairs. Inputs vary with scheduling, and external video work continued on the shared host. Observed changes are not isolated causal estimates or exactness proofs.

32-duplicant industrial base

Fresh full cycle · ≈600 game seconds
ConfigurationGame speed
Unchanged Fresh control
1.402×
Exact candidate Two parcel caches + const reads
1.520×

Bar scale: 0–3×. Observed throughput +8.39%, calculated from the full-precision game/wall durations. Both runs retained 32 duplicants, completed a natural Cycle 2 autosave, passed telemetry and had no owner fault. Mean Unity-frame time was effectively unchanged at 44.32 → 44.24 ms: fewer owner stalls do not establish smoother input.

Live timing denominators and memory samples

Control: 601.125351 game seconds / 428.755517 wall seconds. Candidate: 600.925278 / 395.422162. Warm throughput was 1.405179 → 1.527181× (+8.68% observed); warm owner time was 110.03684 → 97.38421 ms.

Peak sampled game RSS was 4.154499 → 4.191223 GiB; managed heap was 1.639282 → 1.611649 GiB. These samples do not demonstrate a whole-game memory saving.

Spaced Out! · fresh 900-tick pair · 07 Nov

No useful SO gain established

1.069× Control1.038× Exact candidate

This live pair observed −2.93% throughput, or −4.10% after warmup. Both runs retained all 14 duplicants, passed telemetry and had no owner fault. A fresh fixed-input follow-up did not reproduce that penalty; it also established no useful SO gain.

SO slowdown investigation: live pair and matched follow-up

The control advanced 180.939209 game seconds in 169.249933 wall seconds; the candidate advanced 180.739258 in 174.164151. Warm rates were 1.103635 → 1.058389×, with warm owner means 160.52 → 165.94 ms.

The live result prompted a fresh 450-tick captured-input ABBA comparison: 50 warmup ticks excluded per run, leaving 800 warmed samples per side. Old run means were 157.693 / 150.583 ms; new means were 151.158 / 153.153 ms. Combined means were 154.138 → 152.156 ms (1.29% less work), with overlapping run ranges.

This 90-game-second fixed-input test did not reproduce the live penalty and does not establish a useful SO gain. It does not replace the approximately 180-game-second live observation. All four follow-up endpoint hashes match; maximum relative mass/energy errors match at 5.503e−15 / 2.201e−15. The extra capture was diagnostic, not another timed live comparison.

SO sampled RSS was 4.971 → 4.861 GiB and managed heap 2.131 → 2.053 GiB. A single pair does not establish a lasting memory reduction. The observed mean Unity-frame times were 30.65 → 31.36 ms.

Historical live results · 6 November

The earlier base cohort observed 1.297 → 1.559× with parcel caches (+20.22%). Its multigrid + 1 mL detail run reached 1.932×, and the full numerical/cache combination reached 2.093×. These ordered, shared-host observations do not establish precise causal gains.

The earlier 900-tick SO pair observed 0.986 → 0.983×, with 14 duplicants retained in both. It established no useful cache gain or meaningful regression. These historical results remain separate from the completed fresh SO comparison above.

Historical mean Unity-frame times were 47.1, 43.0, 51.5 and 53.0 ms for the base control, caches, numerical options and full combination. Faster simulation did not establish smoother input.

Why sustained, smooth 3× is still unproven

At 3×, each 0.2-game-second owner tick has a 66.7 ms wall-time budget. The fresh candidate replay still averages 85.6 ms before native/game overhead. The observed base live pair remains well below 3×.

The historical numerical combination reached 50.3 ms natively, but changed the trajectory, and native handoff, publication and game work still need time. SO needs work on repeated substeps and transport. This budget is not a combined-speed forecast.

03 / Historical experiments · 06 Nov

Keep exactness and numerical
tradeoffs separate.

The 6 November numerical and overlap experiments changed when data was read or how the fluid equations were solved. They remain separate from the current exact candidate; numerical defaults are unchanged and extra overlap is not adopted.

Redesign before use

Additional overlap exposes stale state.

The game thread and owner solver already overlap. The prototype overlaps additional native work with the solver using an older publication, adding 0.2 game seconds of lag.

Short runs observed +14.6% base throughput and +7.6% SO throughput. Focused synthetic controls show that the prototype can disagree about mass and skip heat. Passing the owner-only ledger does not catch these failures.

Synthetic counterexamples

0.25 kgFreeze mass discrepancy
0.15 kgWithdrawal shortfall
4,000 JHeat captured but skipped at an emptied cell

These counterexamples were demonstrated in focused tests. They are not claims of corruption observed in the large-colony runs.

Explicit numerical choices

Multigrid and tiny-liquid detail change the trajectory.

Both rows include the exact parcel caches. Differences are measured after 600 game seconds against the unchanged algorithm, using the same requested inputs. This is algorithm deviation, not physical ground truth.

The 1 mL setting suppresses interface sharpening for tiny liquid fractions or remaining voids in a 1 m³ cell. Constituent mass and heat remain in the simulation.

Multigrid

65.962 ms / owner tick

Temperature RMS / max difference
3.719 / 38.868 K
Liquid-volume L1 difference
0.5734 m³
Largest single-cell liquid difference
0.1725 m³
Gas-cell constituent L1
1.0995%

Multigrid + 1 mL interface detail

50.321 ms / owner tick

Temperature RMS / max difference
2.852 / 136.063 K
Liquid-volume L1 difference
9.9800 m³
Largest single-cell liquid difference
0.8448 m³
Gas-cell constituent L1
1.0347%

Temperature compares populated cells. The 136 K maximum is in a cell with about 3 g remaining; for gas above 100 g, that configuration’s maximum is 49.143 K. L1 is the sum of absolute differences. These liquid changes reflect redistribution, rather than lost mass.

Mass and energy conservation close, wall masks match, and no negative or nonfinite values appear. Those checks do not make the local temperature and liquid differences negligible. Keep these as explicit tradeoffs for gameplay review; keep the selected 1 g thin-gas-drag default.

04 / Where to spend the work

Follow the remaining
critical path.

After parcel caching, fluid flow remains the principal native cost. The industrial base and SO stress case need different approaches.

Beyond the measured exact candidate, these are source-grounded research directions. Their speedups have not been measured.

  1. Rebuild main and playtest on Windows

    The parcel caches plus const reads passed Linux qualification and clean old/new native comparisons. The exact changes landed in main commit 40a1465. Rebuild current main, then assess Windows gameplay, performance and responsiveness in the user’s playtest.

    Ready

  2. Reduce moving-parcel retry and publication work

    Investigate moving-parcel admission and retry staging, which still begins with a private state copy. Ordinary game-kernel transfers already use an edit journal. A larger moving-parcel rollback design must preserve atomic refusal, energy/face/passive accounting and immutable publications; no speed gain is measured.

    Investigate receipt/object churn and bounded pipe-contact scratch allocation. Existing presentation buffers are already pooled.

    Next

  3. Respect dependencies inside interface work

    The industrial base has a large connected interface cluster. Finer scheduling must include neighbor reads and preserve each cell’s face order, then prove identical owner bytes.

    Next

  4. Target SO substeps and transport

    A diagnostic vented region needs 66 substeps and 83 attempts. Pressure-only work leaves repeated transport. Conservative local subcycling or reuse requires new conservation and thread-count controls.

    Research

  5. Reuse unchanged texture blocks

    SO’s managed texture work makes cross-frame reuse worth studying, with complete invalidation and the existing byte oracle. Compact sampling already exists; owner-limited throughput gains remain unproven.

    Research
Diagnostic hotspots and smaller leads

In one industrial-base diagnostic frame, pressure takes 27.57 ms, interface correction 16.05 ms and transport 4.32 ms. In one SO vented-region frame, pressure takes 61.38 ms and transport 69.26 ms, versus 2.56 ms for interface work. These are explanatory samples, not whole-cycle averages.

Native handoff averages about 13.38 ms for UpdateData, plus 0.90 ms shadow writing, 1.17 ms contact capture and 1.42 ms game copying. Process/next waits are nested owner waits and must not be counted again as independent work.

Managed diagnostic timings point to texture updates and publication/receipt handling. Allocation-counter validation failed, so heap-growth readings are proxies, not exact allocated bytes; parent and child timings overlap.

Three additional exact surface caches produced no established extra full-cycle speedup. Lower worker counts may help CPU/memory budgets, but showed no reliable speed advantage. The GPU route remains closed by the project’s existing decision.

05 / Evidence & limits

Linux checks passed.
Windows playtest next.

Fresh 7 November native and live measurements, the SO follow-up, and all Linux scenario batches are complete. The exact changes landed in main commit 40a1465 and are ready for the user’s Windows rebuild. Actual Windows gameplay and performance remain to be tested.

93/93Native tests passed
66/66Linux scenarios passed
2Colony workloads

All 15 Linux batches and the strict unchanged-input/bound checker passed. Managed, Python and integration suites also passed. Wine controls do not qualify the Windows game; extra overlap remains unadopted.

Benchmark setup

Industrial base: prepared 32-duplicant benchmark with 1,474 building/floor/wire/conduit objects and 34,441 owned cells. It was instantly prepared, rather than played from cycle 1.

Spaced Out!: unchanged 14-duplicant stress save with 1,147 such objects and about 67,857 owned cells, including a compact base venting toward near vacuum.

Host: Linux, Ryzen 9 5900X (12 physical cores / 24 threads), about 60 GiB RAM and RTX 5090. The game logged a 640 × 480 window. Windows performance remains unmeasured.

Timing and exactness controls

Full native replays use the same initial state, the same 3,000 requested boundary inputs, 12 workers and fixed CPU affinity. Timing excludes the first 150 ticks. Four runs alternate unchanged/cached/cached/unchanged to reduce ordering bias.

Live runs request game speed 3. Reported throughput includes simulation startup and excludes loading before the first measured owner interval. Project locks control project workloads, not external host activity. External video work continued during the current base live pair. The historical live cohort also had background host activity.

Short SO comparisons use their own 900-tick controls because the vented region settles over a full cycle. Native replay, live game, and managed diagnostic timings have different scopes and must not be added together indiscriminately.

Main integration and Windows playtest

All 15 Linux batches / 66 scenarios and the strict unchanged-input/bound checker passed. Both fresh live pairs, native ABBA and the SO follow-up are complete. All 88 old/new diagnostics match with timing fields masked; 8 nonzero baseline diagnoses remain unchanged. Both Windows DLLs cross-built and focused Wine controls passed. Main commit 40a1465 contains the exact changes; Windows OS/game qualification remains for the user’s rebuild/playtest. No test inputs, grids or acceptance bounds were changed.

Additional safe overlap requires owner-confirmed mass/phase receipts, heat reconciliation, a native-frame ownership snapshot, and save/load/topology fencing. The removed-wait prototype is not ready to adopt.

Public evidence and provenance

This page leads with the 7 November exact-candidate replay and base live comparison, checked against aggregate integration results. It separately retains the 6 November research experiments, numerical comparisons and their limitations. Operation microbenchmarks are labeled separately from native replay and game timing.

Only aggregate findings and original explanatory text are published here. Research inputs and captures remain private.

Download public aggregate data