Faster than what, exactly?

Experiment identifier

obp-cpu-reassociation-n1024

Original title

Certified reassociation, slices and memo against native paths at n=1024

Measurement boundary

Eight timed operations on one fixed structured f64 fixture, measured on a single local CPU. Timings include the operation and demanded array construction; oracle checks run outside the timer. Comparison targets are NumPy paths in the same process, not remote or distributed implementations.

Hardware

Intel Core i7-8665U, 4 cores / 8 logical processors, Windows 11, shared laptop with uncontrolled power and thermal state.

Software

Python 3.12.10, NumPy 2.2.6, one-thread BLAS configuration per process; 2 warmups and 5 calibration trials before 30 held-out blocks.

Input

Structured integer-valued f64 fixture at n=1024, 16785408 recorded input bytes.

Samples

30 held-out timing blocks per operation; 8 operations measured at this size.

Statistical method

median of 30 held-out blocks per operation

Cold / warm state

Warm within each held-out block; the memo row reuses a previously computed result.

Network

None; local process only.

Serialization

None; arrays stay in process memory.

Correctness checks

Each case records the reference sum, reference vector sum, vector digest and oracle time alongside the timed rows; the oracle runs outside the timer.

CALCULATED FROM THE MEASUREMENTSLeft-to-right f64 reassociation ÷ Certified right-associated f64 boundary path = 26.154009×96.176494% lower time for Certified right-associated f64 boundary path.

CALCULATED FROM THE MEASUREMENTSNumPy multi_dot f64 library path ÷ Certified right-associated f64 boundary path = 1.0633233×5.9552263% lower time for Certified right-associated f64 boundary path.

CALCULATED FROM THE MEASUREMENTSFull demanded f64 slice ÷ Direct demanded f64 slice = 182.57402×99.452277% lower time for Direct demanded f64 slice.

Experimental limitations

• One shared laptop with uncontrolled power and thermal state; results are not normalised to a machine class.
• Structured integer-valued f64 fixture; not an arbitrary floating-point matrix.
• 30 held-out blocks per operation; medians and paired intervals are local to this session.
• The multi_dot library path matches the certified path at n=2048, so no library advantage is claimed.
• Timings include operation and demanded array construction; oracle checks are excluded.

At n=1024 the certified right-associated path records 1.18045 ms against 30.8735 ms for the left-to-right reassociation; the unrounded quotient left/right is 26.15400906433987. The direct demanded slice records 0.16515000000000002 ms against 30.1521 ms for the full slice, quotient 182.57402361489554. NumPy multi_dot records 1.2551999999999999 ms; the paired 95 % interval for right against multi_dot is [-0.16762036306235184, 0.26931737976002423], which includes zero, so no separation from the library is claimed at this size. The paired 95 % savings interval for right against left is [0.9591752037242719, 0.965061189065956] and for the direct slice against the full slice [0.9940634151752087, 0.9949016100178891].

Experiment identifier

obp-cpu-reassociation-n2048

Original title

Certified reassociation, slices and memo against native paths at n=2048

Measurement boundary

Eight timed operations on one fixed structured f64 fixture, measured on a single local CPU. Timings include the operation and demanded array construction; oracle checks run outside the timer. Comparison targets are NumPy paths in the same process, not remote or distributed implementations.

Hardware

Intel Core i7-8665U, 4 cores / 8 logical processors, Windows 11, shared laptop with uncontrolled power and thermal state.

Software

Python 3.12.10, NumPy 2.2.6, one-thread BLAS configuration per process; 2 warmups and 5 calibration trials before 30 held-out blocks.

Input

Structured integer-valued f64 fixture at n=2048, 67125248 recorded input bytes.

Samples

30 held-out timing blocks per operation; 8 operations measured at this size.

Statistical method

median of 30 held-out blocks per operation

Cold / warm state

Warm within each held-out block; the memo row reuses a previously computed result.

Network

None; local process only.

Serialization

None; arrays stay in process memory.

Correctness checks

Each case records the reference sum, reference vector sum, vector digest and oracle time alongside the timed rows; the oracle runs outside the timer.

CALCULATED FROM THE MEASUREMENTSLeft-to-right f64 reassociation ÷ Certified right-associated f64 boundary path = 45.670017×97.810380% lower time for Certified right-associated f64 boundary path.

CALCULATED FROM THE MEASUREMENTSNumPy multi_dot f64 library path ÷ Certified right-associated f64 boundary path = 0.99462699×0.54020362% higher time for Certified right-associated f64 boundary path.

CALCULATED FROM THE MEASUREMENTSFull demanded f64 slice ÷ Direct demanded f64 slice = 767.80684×99.869759% lower time for Direct demanded f64 slice.

Experimental limitations

• One shared laptop with uncontrolled power and thermal state; results are not normalised to a machine class.
• Structured integer-valued f64 fixture; not an arbitrary floating-point matrix.
• 30 held-out blocks per operation; medians and paired intervals are local to this session.
• The multi_dot library path matches the certified path at n=2048, so no library advantage is claimed.
• Timings include operation and demanded array construction; oracle checks are excluded.

At n=2048 the certified right-associated path records 4.59705 ms against 209.94735 ms for the left-to-right reassociation; the unrounded quotient left/right is 45.67001664110679. The direct demanded slice records 0.3321 ms against 254.98865 ms for the full slice, quotient 767.8068352905751. NumPy multi_dot records 4.57235 ms and is the strongest observed vector method; the paired 95 % interval for right against multi_dot is [-0.18961868122873282, 0.18461703811543084], which includes zero, so no advantage over the library is claimed at this size. The paired 95 % savings interval for right against left is [0.9749434555072917, 0.9805127237538717] and for the direct slice against the full slice [0.9985821359777526, 0.9987835241950881].

Experiment identifier

obp-cpu-reassociation-n256

Original title

Certified reassociation, slices and memo against native paths at n=256

Measurement boundary

Eight timed operations on one fixed structured f64 fixture, measured on a single local CPU. Timings include the operation and demanded array construction; oracle checks run outside the timer. Comparison targets are NumPy paths in the same process, not remote or distributed implementations.

Hardware

Intel Core i7-8665U, 4 cores / 8 logical processors, Windows 11, shared laptop with uncontrolled power and thermal state.

Software

Python 3.12.10, NumPy 2.2.6, one-thread BLAS configuration per process; 2 warmups and 5 calibration trials before 30 held-out blocks.

Input

Structured integer-valued f64 fixture at n=256, 1050624 recorded input bytes.

Samples

30 held-out timing blocks per operation; 8 operations measured at this size.

Statistical method

median of 30 held-out blocks per operation

Cold / warm state

Warm within each held-out block; the memo row reuses a previously computed result.

Network

None; local process only.

Serialization

None; arrays stay in process memory.

Correctness checks

Each case records the reference sum, reference vector sum, vector digest and oracle time alongside the timed rows; the oracle runs outside the timer.

CALCULATED FROM THE MEASUREMENTSLeft-to-right f64 reassociation ÷ Certified right-associated f64 boundary path = 5.2376951×80.907632% lower time for Certified right-associated f64 boundary path.

CALCULATED FROM THE MEASUREMENTSNumPy multi_dot f64 library path ÷ Certified right-associated f64 boundary path = 1.0736295×6.8579948% lower time for Certified right-associated f64 boundary path.

CALCULATED FROM THE MEASUREMENTSFull demanded f64 slice ÷ Direct demanded f64 slice = 10.365651×90.352753% lower time for Direct demanded f64 slice.

Experimental limitations

• One shared laptop with uncontrolled power and thermal state; results are not normalised to a machine class.
• Structured integer-valued f64 fixture; not an arbitrary floating-point matrix.
• 30 held-out blocks per operation; medians and paired intervals are local to this session.
• The multi_dot library path matches the certified path at n=2048, so no library advantage is claimed.
• Timings include operation and demanded array construction; oracle checks are excluded.

At n=256 the certified right-associated path records 0.12495 ms against 0.65445 ms for the left-to-right reassociation; the unrounded quotient left/right is 5.237695078031212. The direct demanded slice records 0.054150000000000004 ms against 0.5613 ms for the full slice, quotient 10.365650969529085. NumPy multi_dot records 0.13415 ms; the paired 95 % interval for right against multi_dot is [-0.046984831668516636, 0.21581670362158156], which includes zero, so no separation from the library is claimed at this size. The paired 95 % savings interval for right against left is [0.7895256916996047, 0.840942448821939] and for the direct slice against the full slice [0.8884469880686778, 0.9187415881561238].

Experiment identifier

obp-gen1-verification-assertions

Original title

Gen-1 verification batch: deterministic algorithm, trace reanalysis and model simulation

Measurement boundary

Recorded verification batch for the Gen-1 generation: deterministic algorithm checks, trace reanalysis and model simulation. No new external GPU experiment and no paid infrastructure were used.

Hardware

not recorded

Software

Python 3.12.10 on Windows 11; exact CPU model not recorded.

Input

Recorded Gen-1 traces and algorithm fixtures.

Samples

2,919 assertions recorded under status PASS.

Statistical method

exact recorded assertion count

Cold / warm state

not recorded

Network

None; recorded traces and deterministic checks.

Serialization

not recorded

Correctness checks

The recorded batch status is PASS with 2,919 checks.

Experimental limitations

• The 2,919 count is a single recorded total; a per-suite breakdown is not present in the file.
• Deterministic checks and trace reanalysis, not a new external measurement.
• The batch classification excludes new GPU measurements.

The Gen-1 batch records status PASS with 2,919 checks. It is the aggregate verification count for that generation and must not be added to the 1,381 OBP v2 assertions as if they were the same run.

Experiment identifier

obp-registered-vs-untracked-n1024

Original title

Registered immutable cache against untracked exact-scan cache at n=1024

Measurement boundary

Local CPU comparison of an optimised BLAS recomputation, a registered immutable cache hit and an untracked exact-scan cache hit on one synthetic immutable repeat. The registered path avoids re-copying the output; the untracked path is charged a full output copy.

Hardware

not recorded

Software

One-thread BLAS configuration recorded in the source; exact Python and NumPy versions not recorded.

Input

One synthetic immutable repeat at n=1024, with the full output published.

Samples

30 held-out blocks per method; 3 methods measured.

Statistical method

median of 30 blocks per method

Cold / warm state

Warm cache hits for both cached rows; the optimised BLAS row recomputes.

Network

None; local process only.

Serialization

None; full output published in the source file.

Correctness checks

Both recorded checks pass: all warm results are byte and value exact with fresh ownership, and a changed input rejected the cached result.

CALCULATED FROM THE MEASUREMENTSOptimised BLAS recomputation ÷ Registered immutable cache hit = 10.371742×90.358418% lower time for Registered immutable cache hit.

CALCULATED FROM THE MEASUREMENTSUntracked exact-scan cache hit with full copy ÷ Registered immutable cache hit = 6.5801438×84.802764% lower time for Registered immutable cache hit.

Experimental limitations

• Synthetic immutable repeat, not a production workload.
• Only n=1024 measured; no other size in this file.
• The untracked exact-scan path is charged a full output copy while the registered path is not re-copied.
• Reported working and peak memory counters read zero in this file.

The registered cache row records 1.24495 ms against 12.912299999999998 ms for optimised BLAS, quotient 10.371741837021565, and 8.19195 ms for the untracked exact-scan cache, quotient 6.580143780874734 against the registered row. The registered path avoids both recomputation and the full output copy charged to the untracked scan; the 10.371741837021565 quotient over recomputation is a cache-reuse result, not a distributed-execution result.

Experiment identifier

obp-v2-fixture-assertions

Original title

OBP v2 fixture assertions across four evidence artifacts

Measurement boundary

Finite deterministic fixtures: reference correctness and discrete simulation, exact algebraic checks, block byte-conformance vectors and rematerialisation states. These are assertion totals, not throughput measurements and not GPU measurements.

Hardware

not recorded

Software

not recorded

Input

Four finite artifact suites recorded in the OBP v2 evidence package.

Samples

1,381 assertions in total: 1,020 + 225 + 126 + 10.

Statistical method

exact assertion count per artifact

Cold / warm state

not recorded

Network

None; finite fixtures.

Serialization

Block header and patch byte vectors only; an authenticated envelope is assumed and not implemented.

Correctness checks

The four artifacts record reference checks and exact checks; counts are assertion totals, not a pass rate.

Experimental limitations

• Assertion totals are not external validation and not a measure of throughput.
• Structured integer and bit-exact fixtures; not arbitrary floating-point matrices.
• The discrete simulations carry no GPU timing.
• Object-store and authenticated-envelope behaviour is assumed, not implemented.

The four artifacts contribute 1,020, 225, 126 and 10 assertions, summing to 1,381. Every summand is recorded in its own artifact, so the aggregate can be recomputed without re-running an experiment.

Experiment identifier

obp-warm-cache-n1024

Original title

Warm result cache against uncached compute at n=1024

Measurement boundary

Local CPU comparison of recomputation against reuse of a warm, immutable result at one fixture size. The cached rows measure a hit, not a miss, and the cache population cost is outside the timed rows.

Hardware

not recorded

Software

NumPy 2.2.6 with the recorded one-thread BLAS configuration; exact Python build not recorded.

Input

Structured integer-valued f64 fixture at n=1024, the same fixture as the reassociation cohort.

Samples

30 warm timing blocks per method; 7 methods measured at this size.

Statistical method

median of 30 warm blocks per method

Cold / warm state

Warm: the cached row reuses a previously computed immutable result; the compute row recomputes.

Network

None; local process only.

Serialization

None; results stay in process memory.

Correctness checks

Not recorded as a pass or fail field in this file.

CALCULATED FROM THE MEASUREMENTSVector result computed, no cache ÷ Vector result reused from warm cache = 185.69231×99.461475% lower time for Vector result reused from warm cache.

CALCULATED FROM THE MEASUREMENTSDemanded slice computed, no cache ÷ Demanded slice reused from warm cache = 22.009615×95.456531% lower time for Demanded slice reused from warm cache.

CALCULATED FROM THE MEASUREMENTSDense product computed, no cache ÷ Dense product reused from warm cache = 8.5589204×88.316283% lower time for Dense product reused from warm cache.

Experimental limitations

• Cache rows price a hit; a cold miss and cache population cost are not included.
• Cache size, eviction policy and population cost are not recorded in this file.
• One fixture family and one host; results do not transfer to other shapes or machines.
• Cache reuse is not evidence that remote execution is faster.

At n=1024 the vector cache row records 0.0052 ms against 0.9656 ms for uncached compute (quotient 185.6923076923077); the slice pair is 0.0052 ms against 0.11445 ms (quotient 22.009615384615383) and the dense pair 1.0318999999999998 ms against 8.831949999999999 ms (quotient 8.558920438026941). Paired 95 % savings intervals are [0.9944119212346993, 0.9949641005185481], [0.9514298683613255, 0.9575191163976211] and [0.8781194784797848, 0.8927497674821016]. Cache reuse is the measured gain in this file; it is not a remote execution result.

Experiment identifier

obp-warm-cache-n2048

Original title

Warm result cache against uncached compute at n=2048

Measurement boundary

Local CPU comparison of recomputation against reuse of a warm, immutable result at one fixture size. The cached rows measure a hit, not a miss, and the cache population cost is outside the timed rows.

Hardware

not recorded

Software

NumPy 2.2.6 with the recorded one-thread BLAS configuration; exact Python build not recorded.

Input

Structured integer-valued f64 fixture at n=2048, the same fixture as the reassociation cohort.

Samples

30 warm timing blocks per method; 7 methods measured at this size.

Statistical method

median of 30 warm blocks per method

Cold / warm state

Warm: the cached row reuses a previously computed immutable result; the compute row recomputes.

Network

None; local process only.

Serialization

None; results stay in process memory.

Correctness checks

Not recorded as a pass or fail field in this file.

CALCULATED FROM THE MEASUREMENTSVector result computed, no cache ÷ Vector result reused from warm cache = 488.68500×99.795369% lower time for Vector result reused from warm cache.

CALCULATED FROM THE MEASUREMENTSDemanded slice computed, no cache ÷ Demanded slice reused from warm cache = 33.717277×97.034161% lower time for Demanded slice reused from warm cache.

CALCULATED FROM THE MEASUREMENTSDense product computed, no cache ÷ Dense product reused from warm cache = 12.990695×92.302182% lower time for Dense product reused from warm cache.

Experimental limitations

• Cache rows price a hit; a cold miss and cache population cost are not included.
• Cache size, eviction policy and population cost are not recorded in this file.
• One fixture family and one host; results do not transfer to other shapes or machines.
• Cache reuse is not evidence that remote execution is faster.

At n=2048 the vector cache row records 0.01 ms against 4.88685 ms for uncached compute (quotient 488.685); the slice pair is 0.00955 ms against 0.322 ms (quotient 33.717277486910994) and the dense pair 5.80325 ms against 75.38825 ms (quotient 12.990694869254297). Paired 95 % savings intervals are [0.9977743876953942, 0.9982086707956169], [0.9688770722552393, 0.9721424468696152] and [0.9173956278390004, 0.9291419982910156]. Cache reuse is the measured gain in this file; it is not a remote execution result.

Experiment identifier

obp-warm-cache-n256

Original title

Warm result cache against uncached compute at n=256

Measurement boundary

Local CPU comparison of recomputation against reuse of a warm, immutable result at one fixture size. The cached rows measure a hit, not a miss, and the cache population cost is outside the timed rows.

Hardware

not recorded

Software

NumPy 2.2.6 with the recorded one-thread BLAS configuration; exact Python build not recorded.

Input

Structured integer-valued f64 fixture at n=256, the same fixture as the reassociation cohort.

Samples

30 warm timing blocks per method; 7 methods measured at this size.

Statistical method

median of 30 warm blocks per method

Cold / warm state

Warm: the cached row reuses a previously computed immutable result; the compute row recomputes.

Network

None; local process only.

Serialization

None; results stay in process memory.

Correctness checks

Not recorded as a pass or fail field in this file.

CALCULATED FROM THE MEASUREMENTSVector result computed, no cache ÷ Vector result reused from warm cache = 19.732394×94.932191% lower time for Vector result reused from warm cache.

CALCULATED FROM THE MEASUREMENTSDemanded slice computed, no cache ÷ Demanded slice reused from warm cache = 6.8604651×85.423729% lower time for Demanded slice reused from warm cache.

CALCULATED FROM THE MEASUREMENTSDense product computed, no cache ÷ Dense product reused from warm cache = 16.689474×94.008199% lower time for Dense product reused from warm cache.

Experimental limitations

• Cache rows price a hit; a cold miss and cache population cost are not included.
• Cache size, eviction policy and population cost are not recorded in this file.
• One fixture family and one host; results do not transfer to other shapes or machines.
• Cache reuse is not evidence that remote execution is faster.

At n=256 the vector cache row records 0.00355 ms against 0.07005 ms for uncached compute (quotient 19.732394366197184); the slice pair is 0.0043 ms against 0.0295 ms (quotient 6.8604651162790695) and the dense pair 0.019 ms against 0.31710000000000005 ms (quotient 16.68947368421053). Paired 95 % savings intervals are [0.9457478005865103, 0.9566265060240964], [0.8444055944055944, 0.8716417910447761] and [0.9314096499526964, 0.9479326186830015]. Cache reuse is the measured gain in this file; it is not a remote execution result.

Experiment identifier

aspr-baseline-forecast-accuracy

Original title

Baseline linear and GRU placement forecasters on the held-out synthetic test split

Measurement boundary

Held-out classification metrics for two forecasters trained on a synthetic trace. The measured part is the model metric; the workload latency attached to these forecasts elsewhere is simulated.

Hardware

not recorded

Software

Python 3.12.10, NumPy 2.2.6, BLAS as recorded in the source.

Input

Synthetic trace split into train [0, 4290], validation [4320, 5730] and test [5760, 7170] as recorded in the source; 26 operations in the modeled workload.

Samples

Linear test counts: 640 true positives, 180 false positives, 126 false negatives. GRU test counts: 602 true positives, 167 false positives, 164 false negatives.

Statistical method

precision, recall, joint class accuracy and exact-bundle accuracy on the held-out test split

Cold / warm state

not recorded

Network

None; classification only. Workload placement cost is simulated in a separate file.

Serialization

not recorded

Correctness checks

Precision, recall, exact-bundle accuracy and the confusion counts are recorded together, so each fraction can be recomputed from the counts in the same file.

Experimental limitations

• Synthetic trace metrics; not real CAD or production workloads.
• The test split is a held-out slice of the same synthetic trace family.
• Exact-bundle accuracy is zero for the linear model and near zero for the GRU at this threshold.
• Thresholds were selected on the original validation split.

Precision and recall are usable for both baseline classifiers, while candidate exact-bundle accuracy is 0.0 for linear and 0.010443864229765013 for GRU. A forecaster that identifies plausible operations does not thereby reproduce a complete bundle; the simulated workload results must be read with that gap in view.

Experiment identifier

aspr-cache-placement-simulation

Original title

Modeled placement with a 64 MiB local result cache: reactive, heuristic and learned

Measurement boundary

Arithmetic simulation of a strengthened local baseline with a 64 MiB result cache and a full copy charged on every reuse. Remote operations are costed arithmetically; no network, remote CPU or GPU was exercised.

Hardware

not recorded

Software

not recorded

Input

Synthetic trace of 134 operations with 33 recorded cache hits and a 52462080-byte cache footprint.

Samples

134 simulated operations per mode; 33 cache hits per mode.

Statistical method

modeled mean and 95th-percentile operation latency

Cold / warm state

Warm cache throughout; cache population cost is outside the modeled trace.

Network

Simulated only; no network was exercised.

Serialization

not recorded

Correctness checks

Recorded unknown-bundle rejections are zero in every mode below.

CALCULATED FROM THE MEASUREMENTSReactive placement, mean ÷ Learned linear placement, mean = 1.4274630×29.945644% lower time for Learned linear placement, mean.

CALCULATED FROM THE MEASUREMENTSHeuristic placement, mean ÷ Learned linear placement, mean = 1.0129886×1.2822107% lower time for Learned linear placement, mean.

CALCULATED FROM THE MEASUREMENTSLearned linear placement, mean ÷ Learned GRU placement, mean = 0.73885621×35.344332% higher time for Learned GRU placement, mean.

Experimental limitations

• Arithmetic simulation; no measured remote latency is included.
• The remote operation cost model is not independently validated in this file.
• The 95th percentile is unchanged at 120.6 ms in every mode, so the mean gain does not move the tail.
• GRU-driven learned placement is slower than the heuristic on the same trace.

Reactive placement records a mean of 42.92724552238806 ms, the heuristic 30.4630051641791 ms and learned linear placement 30.072405238805974 ms. Learned GRU placement records 40.70129598507462 ms and is worse than the heuristic. The 95th percentile remains 120.6 ms for every mode, so no tail-latency improvement is claimed.

Experiment identifier

aspr-codec-random-1mib

Original title

Lossless codec screening on a 1 MiB random-byte buffer

Measurement boundary

Measured CPU encode and decode of a 1 MiB random-byte buffer through six lossless profiles. This is the negative case for compression: a codec that helps smooth data may expand or barely help incompressible data.

Hardware

Windows 11 host; CPU model not recorded.

Software

NumPy 2.2.6; exact Python and BLAS build not recorded.

Input

One 1048576-byte random_bytes buffer.

Samples

10 encode and 10 decode samples per profile; 6 profiles.

Statistical method

exact coded bytes and median encode time of 10 samples

Cold / warm state

Warm in-process buffers; repeated encodes of the same buffer.

Network

None; byte buffers only, no transport was exercised.

Serialization

Coded byte buffers; no request or response envelope is modeled.

Correctness checks

Round-trip correctness is not recorded as a pass or fail field in this file.

Experimental limitations

• Byte buffers only; no transport and no authenticated envelope.
• 10 samples per profile on one host.
• zlib expands this buffer at both levels tested.
• Random synthetic bytes are not a CAD payload.

The raw buffer is 1048576 bytes. zlib level 1 and level 9 both expand it to 1048902 bytes; lzma preset 1 gives 674572 bytes, lzma preset 6 848528 and the XOR-plane transform with zlib level 9 558573. Compression gain on random bytes is small and codec-dependent, so a single corpus cannot justify a codec choice.

Experiment identifier

aspr-codec-smooth-1mib

Original title

Lossless codec screening on a 1 MiB smooth buffer

Measurement boundary

Measured CPU encode and decode of a 1 MiB smooth byte buffer through six lossless profiles. Coded size is the published result; encode and decode medians are recorded alongside it in the source.

Hardware

Windows 11 host; CPU model not recorded.

Software

NumPy 2.2.6; exact Python and BLAS build not recorded.

Input

One 1048576-byte smooth buffer.

Samples

10 encode and 10 decode samples per profile; 6 profiles.

Statistical method

exact coded bytes and median encode time of 10 samples

Cold / warm state

Warm in-process buffers; repeated encodes of the same buffer.

Network

None; byte buffers only, no transport was exercised.

Serialization

Coded byte buffers; no request or response envelope is modeled.

Correctness checks

Round-trip correctness is not recorded as a pass or fail field in this file.

Experimental limitations

• Byte buffers only; no transport and no authenticated envelope.
• 10 samples per profile on one host.
• Coded size is exact; encode and decode medians are session-local.
• Smooth synthetic data is not a CAD payload.

The raw buffer is 1048576 bytes. zlib level 1 gives 148083 bytes, zlib level 9 148474, lzma preset 1 59940, lzma preset 6 23940 and the XOR-plane transform with zlib level 9 2397. The transform pair is the smallest encoding on this corpus, and the gap between zlib levels shows that a higher level can enlarge the output on smooth data.

Experiment identifier

aspr-inference-budget

Original title

Measured CPU inference and adaptation cost for both forecasters

Measurement boundary

Fresh-process CPU timing of feature construction plus one model call, repeated 5000 times per model. This is an inference budget, not workload latency and not a power measurement.

Hardware

not recorded

Software

not recorded

Input

The same feature construction and loaded weights used by the synthetic-trace forecasters.

Samples

5000 timed calls per model; adaptation timed separately.

Statistical method

median, 95th percentile and CPU milliseconds per call

Cold / warm state

Warm process; the first call is included in the recorded samples.

Network

None; local CPU only.

Serialization

not recorded

Correctness checks

Not the subject of this measurement.

Experimental limitations

• CPU inference only; no power telemetry and no GPU path.
• 5000 calls per model on one unrecorded host.
• The model and feature memory counters read zero in this file.
• Inference cost is not workload latency.

The linear model records a median of 0.0446 ms and a 95th percentile of 0.07280500000000002 ms at 0.053125 CPU milliseconds per call; the GRU records 0.0741 ms, 0.126505 ms and 0.084375 CPU milliseconds per call. Both budgets are well below the modeled operation latencies, so inference cost does not explain the simulated placement results.

Experiment identifier

aspr-interference-short-bursts

Original title

Short-burst response under no background work, unlimited background work and a ten-percent budget

Measurement boundary

Local CPU short-burst measurement of a fixed operation under three background-work conditions. This is not a battery-energy test and does not model sustained multi-tenant load.

Hardware

Local host with 8 threads; CPU model not recorded.

Software

not recorded

Input

Fixed burst operation repeated 30 times per condition.

Samples

30 timed bursts per condition; 3 conditions.

Statistical method

median and 95th percentile of 30 bursts

Cold / warm state

Warm; bursts run back to back after the condition is established.

Network

None; local CPU only.

Serialization

not recorded

Correctness checks

Not the subject of this measurement.

Experimental limitations

• Short bursts; not a battery-energy test.
• Background work is recorded as CPU seconds and compressed bytes, but its source is not described in this file.
• One host and 8 threads; no multi-tenant or remote interference.
• All interference conditions are slower than the no-background condition.

The no-background median is 9.663250000000001 ms; unlimited background work gives 11.544599999999999 ms and the ten-percent budget gives 11.56305 ms. The 95th percentile rises from 11.99265 ms to 13.505559999999997 ms and 13.307719999999998 ms. Background work, whether unlimited or budgeted, does not reduce burst latency in this measurement.

Experiment identifier

aspr-local-precompute-simulation

Original title

Modeled learned local precomputation and dual placement at one-times and four-times CPU work

Measurement boundary

Arithmetic simulation only, assuming a fluid ten-percent CPU budget for background work. Two CPU work factors are modeled so that the sensitivity of the result to background cost is visible.

Hardware

not recorded

Software

not recorded

Input

Synthetic trace of 134 operations; background results, useful speculated results and pending work are recorded per mode.

Samples

Six simulated mode and work-factor combinations; 134 operations per combination.

Statistical method

modeled mean and 95th-percentile operation latency with background CPU work

Cold / warm state

Warm cache in every combination.

Network

Simulated only; no network was exercised.

Serialization

not recorded

Correctness checks

Pending work after the trace is zero and unknown-bundle rejections are not raised in the rows below.

CALCULATED FROM THE MEASUREMENTSCache baseline, one-times CPU work, mean ÷ Dual placement, one-times CPU work, mean = 1.6355762×38.859467% lower time for Dual placement, one-times CPU work, mean.

CALCULATED FROM THE MEASUREMENTSCache baseline, one-times CPU work, mean ÷ Dual placement, four-times CPU work, mean = 1.5086850×33.717109% lower time for Dual placement, four-times CPU work, mean.

CALCULATED FROM THE MEASUREMENTSLearned local predictive, one-times CPU work, mean ÷ Dual placement, one-times CPU work, mean = 1.1619891×13.940670% lower time for Dual placement, one-times CPU work, mean.

Experimental limitations

• Arithmetic simulation with a ten-percent CPU budget assumption.
• The 95th percentile is 120.6 ms in all six combinations; no tail improvement is modeled.
• Background work is charged but not validated against a real scheduler.
• Four-times CPU work erodes the gain of predictive precomputation.

At one-times CPU work the cache baseline records 42.92724552238806 ms, learned local predictive precomputation 30.49750298507462 ms and dual placement 26.245946686567162 ms. At four-times CPU work the predictive mode degrades to 38.22850298507463 ms and dual placement to 28.453419223880598 ms. Every combination keeps a 120.6 ms 95th percentile, so precomputation is a mean-cost result only.

Experiment identifier

aspr-memory-corrected

Original title

Fresh-process runtime and loaded-weight memory for both forecasters

Measurement boundary

Fresh process measured with the NumPy runtime loaded plus model weights, both models loaded sequentially. This is a corrected footprint that includes the runtime, not model-only storage.

Hardware

not recorded

Software

not recorded

Input

Loaded linear and GRU weights plus the feature construction path.

Samples

One fresh process per model; working and peak counters recorded.

Statistical method

working bytes, peak bytes and recorded parameter bytes

Cold / warm state

Fresh process.

Network

None; local process only.

Serialization

not recorded

Correctness checks

Not the subject of this measurement.

Experimental limitations

• The footprint includes the runtime, so it is larger than weights alone.
• Both models were loaded sequentially; a combined deployment is not measured.
• No power telemetry.

Linear working memory is 26984448 bytes with 4192 parameter bytes; the GRU is 27070464 bytes with 12928 parameter bytes. The difference between the two models is dominated by the shared runtime, so parameter count is not a proxy for deployment footprint.

Experiment identifier

aspr-refined-forecast-fresh-trace

Original title

Frozen-threshold forecaster refinement on a fresh synthetic trace

Measurement boundary

Exploratory refinement evaluated on a fresh synthetic trace with thresholds frozen from the original validation split. The classification metrics below are measured; the workload latency attached to those forecasts elsewhere is simulated. Threshold sweeps over 0.3, 0.5, 0.7 and 0.9 are recorded separately in the source and are not the rows below.

Hardware

not recorded

Software

not recorded

Input

Fresh synthetic trace, separate from the original train and test split.

Samples

Linear fresh counts: 3284 true positives, 852 false positives, 706 false negatives. GRU fresh counts: 3213 true positives, 793 false positives, 777 false negatives.

Statistical method

precision, recall, joint class accuracy and exact-bundle accuracy at a frozen threshold

Cold / warm state

not recorded

Network

None; classification only.

Serialization

not recorded

Correctness checks

The frozen threshold, fresh counts and each fraction are recorded in the same file, so every fraction can be recomputed from its counts.

Experimental limitations

• Exploratory refinement on a synthetic trace; not a new experiment family.
• Thresholds were frozen from the original validation split, not tuned on the fresh trace.
• Exact-bundle accuracy stays low even where precision and recall are stable.
• The fresh trace is synthetic; it is not real CAD.

On the fresh trace the linear model records precision 0.7940038684719536 and recall 0.8230576441102757 with exact-bundle accuracy 0.0; the GRU records precision 0.8020469296055917 and recall 0.8052631578947368 with exact-bundle accuracy 0.008771929824561403. The refinement stabilises the discriminative metrics but does not turn forecasting into complete-bundle reproduction.

Experiment identifier

rt-cn-codec-link-matrix

Original title

Codec matrix and authenticated tunnel timing, structured and random payloads, cold and warm profile

Measurement boundary

Two related measurements on one node. The first is a codec matrix over a loopback link, run once for a structured payload and once for a random payload across raw, two zstd levels and lz4. The second is the same stack over an authenticated local tunnel, where the profile cost of the first transfer is compared against later transfers to show the effect of the bounded profile cache.

Hardware

A Linux CPU node with 8 dedicated EPYC-Milan vCPUs, 30 GiB of memory and 4 GiB of swap, running Ubuntu 26.04.1 with no accelerator present.

Software

The runtime transport with the codec component and its bounded stratified profile cache, an authenticated local tunnel, and a system CBLAS provider. The toolchain version for this campaign is 1.99.1.

Input

A fixed pair of payloads: one structured and one random, of the same logical size, transferred through the codec envelope in both directions.

Samples

One measured transfer per codec per payload condition in the codec matrix. Three recorded transfers per payload kind and codec in the tunnel measurement, where the first is cold and the third is warm.

Statistical method

Single recorded values per codec and condition in the codec matrix. Median-equivalent values in the tunnel log are three recorded transfers, with the first and third published here.

Cold / warm state

The profile cache is bounded to a small number of entries with a five minute time to live. On the first recorded transfer the worker-side profile cost is tens of times larger than on the third, which is the cache becoming warm. The codec matrix is a single transfer per condition and is not repeated.

Network

Loopback for the codec matrix and an authenticated local tunnel for the second measurement. No external link, encryption or retransmission overhead is involved or recorded.

Serialization

The codec envelope carries a fixed header and a length prefix, and upload and download byte counts are recorded separately for every case.

Correctness checks

Every case in the codec matrix is recorded as correct, and the tunnel measurement records a per-call worker decode, encode and profile cost alongside the elapsed time.

CALCULATED FROM THE MEASUREMENTSrandom payload, zstd level 3: upload bytes ÷ random payload, raw: upload bytes = 0.89981781×11.133608% higher value for random payload, raw: upload bytes.

CALCULATED FROM THE MEASUREMENTSstructured payload, zstd level 3: upload bytes ÷ structured payload, raw: upload bytes = 0.0059109312×16817.808% higher value for structured payload, raw: upload bytes.

CALCULATED FROM THE MEASUREMENTSrandom payload, zstd level 3: elapsed ÷ random payload, raw: elapsed = 0.93807519×6.6012632% higher time for random payload, raw: elapsed.

Experimental limitations

• The codec matrix is a single transfer per condition, so the byte figures are reproducible counts but the timings are single observations.
• The tunnel measurement publishes three recorded transfers per group and no distribution.
• These are node loopback baselines and are explicitly not evidence for the frozen useful-workload gate.
• A separate chunked-transfer benchmark in the same campaign is blocked by an admission constraint on that operating system and produced no measurement.
• The structural payload compresses to a few hundred bytes while the random payload barely compresses, so the two conditions are not interchangeable inputs.

The codec stack behaves as a compression stack should and honestly: on a structured payload it removes almost all of the bytes, while on a random payload zstd level 3 saves about a tenth of the upload and level 1 slightly less, and lz4 saves nothing at all. The tunnel measurement then shows the cost side of profiling: the first transfer pays a profile cost tens of times larger than the third, which is the bounded profile cache warming, and that warm-up cost is charged to the first call rather than hidden.

Experiment identifier

rt-transfer-calculations

Original title

Transfer byte and latency accounting, calculation-derived operands

Measurement boundary

A matched four-call workload whose operands are derived from calculations rather than being random or structured, measured across the transport and representation modes. Every mode was run against the same logical input demand and the same matched raw workload, so the byte columns are directly comparable across modes and the avoided-byte column is a difference against the raw mode rather than an absolute saving.

Hardware

A Linux CPU host running the transport harness with a system CBLAS provider. The host CPU model, core count and memory size are not recorded in this report.

Software

The runtime transport with its representation modes, a pinned reference BLAS provider, and an authenticated local tunnel. Compiler and operating system versions are not recorded in this report.

Input

The calculations operand regime of the matched four-call workload, with a logical input demand of 786432 bytes in the single-input modes and 786432 bytes for the resident mode of the chain regime.

Samples

One matched four-call workload per mode, with the raw mode as the byte-difference reference. No repeated trials or distributions are published for this campaign.

Statistical method

Measured application-stream byte totals and total user wait for the matched four-call workload. The avoided-byte figure is the difference against the matched raw workload and can be negative.

Cold / warm state

The measured totals include cold setup, calibration and cleanup. The adaptive mode additionally charges its own calibration, which is identified separately in the raw records.

Network

The measured byte columns are application-stream bytes only. IP, TCP and tunnel overhead and retransmissions are not recorded and are explicitly unknown.

Serialization

Logical, packed, encoded and framed byte counts are kept separate in the raw records; the published column is the framed application-stream total.

Correctness checks

Every mode in this class is recorded as passing the correctness check.

CALCULATED FROM THE MEASUREMENTSlocal execution, no transport: total user wait ÷ raw transport: total user wait = 0.29283111×241.49378% higher time for raw transport: total user wait.

CALCULATED FROM THE MEASUREMENTSraw transport: total wire bytes ÷ lz4-compressed transport: total wire bytes = 4.0145820×75.090807% lower value for lz4-compressed transport: total wire bytes.

Experimental limitations

• One matched workload per mode with no repeated trials and no distribution.
• Physical packet, tunnel and retransmission overhead are not recorded, so the wire column is an application-stream measure.
• The avoided-byte figure can be negative and is not a saving in every case.
• The timings overlap and must not be summed, and the encode and decode counters cover the call phase only.
• This is a Linux CPU transport measurement and is not a Windows or accelerator measurement.

The published rows let the representation modes be read against each other on the same logical input. The mode that wins depends entirely on the operand regime: a general-purpose codec helps most where the operands are structured and does nothing where they are not, and the adaptive mode does not dominate every regime. No single figure from this table should be quoted without its class.

Experiment identifier

rt-transfer-chain

Original title

Transfer byte and latency accounting, dependent operand chain

Measurement boundary

A matched workload whose operands form a dependent chain, so the later operands depend on the earlier results. Only five of the eight modes were run in this regime and the absent modes are recorded as absent rather than inferred. Every mode was run against the same logical input demand and the same matched raw workload, so the byte columns are directly comparable across modes and the avoided-byte column is a difference against the raw mode rather than an absolute saving.

Hardware

A Linux CPU host running the transport harness with a system CBLAS provider. The host CPU model, core count and memory size are not recorded in this report.

Software

The runtime transport with its representation modes, a pinned reference BLAS provider, and an authenticated local tunnel. Compiler and operating system versions are not recorded in this report.

Input

The chain operand regime of the matched four-call workload, with a logical input demand of 1572864 bytes in the single-input modes and 786432 bytes for the resident mode of the chain regime.

Samples

One matched four-call workload per mode, with the raw mode as the byte-difference reference. No repeated trials or distributions are published for this campaign.

Statistical method

Measured application-stream byte totals and total user wait for the matched four-call workload. The avoided-byte figure is the difference against the matched raw workload and can be negative.

Cold / warm state

The measured totals include cold setup, calibration and cleanup. The adaptive mode additionally charges its own calibration, which is identified separately in the raw records.

Network

The measured byte columns are application-stream bytes only. IP, TCP and tunnel overhead and retransmissions are not recorded and are explicitly unknown.

Serialization

Logical, packed, encoded and framed byte counts are kept separate in the raw records; the published column is the framed application-stream total.

Correctness checks

Every mode in this class is recorded as passing the correctness check.

CALCULATED FROM THE MEASUREMENTSlocal execution, no transport: total user wait ÷ raw transport: total user wait = 0.36069483×177.24268% higher time for raw transport: total user wait.

CALCULATED FROM THE MEASUREMENTSraw transport: total wire bytes ÷ lz4-compressed transport: total wire bytes = 6.3900690×84.350717% lower value for lz4-compressed transport: total wire bytes.

Experimental limitations

• One matched workload per mode with no repeated trials and no distribution.
• Physical packet, tunnel and retransmission overhead are not recorded, so the wire column is an application-stream measure.
• The avoided-byte figure can be negative and is not a saving in every case.
• The timings overlap and must not be summed, and the encode and decode counters cover the call phase only.
• This is a Linux CPU transport measurement and is not a Windows or accelerator measurement.

The published rows let the representation modes be read against each other on the same logical input. The mode that wins depends entirely on the operand regime: a general-purpose codec helps most where the operands are structured and does nothing where they are not, and the adaptive mode does not dominate every regime. No single figure from this table should be quoted without its class.

Experiment identifier

rt-transfer-full-outputs

Original title

Transfer byte and latency accounting, full outputs requested

Measurement boundary

A matched four-call workload in which the full output is requested every time, measured across the transport and representation modes. Every mode was run against the same logical input demand and the same matched raw workload, so the byte columns are directly comparable across modes and the avoided-byte column is a difference against the raw mode rather than an absolute saving.

Hardware

A Linux CPU host running the transport harness with a system CBLAS provider. The host CPU model, core count and memory size are not recorded in this report.

Software

The runtime transport with its representation modes, a pinned reference BLAS provider, and an authenticated local tunnel. Compiler and operating system versions are not recorded in this report.

Input

The full outputs operand regime of the matched four-call workload, with a logical input demand of 786432 bytes in the single-input modes and 786432 bytes for the resident mode of the chain regime.

Samples

One matched four-call workload per mode, with the raw mode as the byte-difference reference. No repeated trials or distributions are published for this campaign.

Statistical method

Measured application-stream byte totals and total user wait for the matched four-call workload. The avoided-byte figure is the difference against the matched raw workload and can be negative.

Cold / warm state

The measured totals include cold setup, calibration and cleanup. The adaptive mode additionally charges its own calibration, which is identified separately in the raw records.

Network

The measured byte columns are application-stream bytes only. IP, TCP and tunnel overhead and retransmissions are not recorded and are explicitly unknown.

Serialization

Logical, packed, encoded and framed byte counts are kept separate in the raw records; the published column is the framed application-stream total.

Correctness checks

Every mode in this class is recorded as passing the correctness check.

CALCULATED FROM THE MEASUREMENTSlocal execution, no transport: total user wait ÷ raw transport: total user wait = 0.32201646×210.54313% higher time for raw transport: total user wait.

CALCULATED FROM THE MEASUREMENTSraw transport: total wire bytes ÷ lz4-compressed transport: total wire bytes = 1.7640017×43.310711% lower value for lz4-compressed transport: total wire bytes.

Experimental limitations

• One matched workload per mode with no repeated trials and no distribution.
• Physical packet, tunnel and retransmission overhead are not recorded, so the wire column is an application-stream measure.
• The avoided-byte figure can be negative and is not a saving in every case.
• The timings overlap and must not be summed, and the encode and decode counters cover the call phase only.
• This is a Linux CPU transport measurement and is not a Windows or accelerator measurement.

The published rows let the representation modes be read against each other on the same logical input. The mode that wins depends entirely on the operand regime: a general-purpose codec helps most where the operands are structured and does nothing where they are not, and the adaptive mode does not dominate every regime. No single figure from this table should be quoted without its class.

Experiment identifier

rt-transfer-incompressible

Original title

Transfer byte and latency accounting, incompressible operands

Measurement boundary

A matched four-call workload whose operands resist compression, measured across the transport and representation modes. This is the regime where compression should pay nothing and may cost. Every mode was run against the same logical input demand and the same matched raw workload, so the byte columns are directly comparable across modes and the avoided-byte column is a difference against the raw mode rather than an absolute saving.

Hardware

A Linux CPU host running the transport harness with a system CBLAS provider. The host CPU model, core count and memory size are not recorded in this report.

Software

The runtime transport with its representation modes, a pinned reference BLAS provider, and an authenticated local tunnel. Compiler and operating system versions are not recorded in this report.

Input

The incompressible operand regime of the matched four-call workload, with a logical input demand of 786432 bytes in the single-input modes and 786432 bytes for the resident mode of the chain regime.

Samples

One matched four-call workload per mode, with the raw mode as the byte-difference reference. No repeated trials or distributions are published for this campaign.

Statistical method

Measured application-stream byte totals and total user wait for the matched four-call workload. The avoided-byte figure is the difference against the matched raw workload and can be negative.

Cold / warm state

The measured totals include cold setup, calibration and cleanup. The adaptive mode additionally charges its own calibration, which is identified separately in the raw records.

Network

The measured byte columns are application-stream bytes only. IP, TCP and tunnel overhead and retransmissions are not recorded and are explicitly unknown.

Serialization

Logical, packed, encoded and framed byte counts are kept separate in the raw records; the published column is the framed application-stream total.

Correctness checks

Every mode in this class is recorded as passing the correctness check.

CALCULATED FROM THE MEASUREMENTSlocal execution, no transport: total user wait ÷ raw transport: total user wait = 0.30547518×227.35883% higher time for raw transport: total user wait.

CALCULATED FROM THE MEASUREMENTSraw transport: total wire bytes ÷ lz4-compressed transport: total wire bytes = 1.7640017×43.310711% lower value for lz4-compressed transport: total wire bytes.

Experimental limitations

• One matched workload per mode with no repeated trials and no distribution.
• Physical packet, tunnel and retransmission overhead are not recorded, so the wire column is an application-stream measure.
• The avoided-byte figure can be negative and is not a saving in every case.
• The timings overlap and must not be summed, and the encode and decode counters cover the call phase only.
• This is a Linux CPU transport measurement and is not a Windows or accelerator measurement.

The published rows let the representation modes be read against each other on the same logical input. The mode that wins depends entirely on the operand regime: a general-purpose codec helps most where the operands are structured and does nothing where they are not, and the adaptive mode does not dominate every regime. No single figure from this table should be quoted without its class.

Experiment identifier

rt-transfer-mixed

Original title

Transfer byte and latency accounting, mixed operand regime

Measurement boundary

A matched four-call workload combining operand regimes within one workload, measured across the transport and representation modes. The adaptive mode records negative avoided bytes in this regime. Every mode was run against the same logical input demand and the same matched raw workload, so the byte columns are directly comparable across modes and the avoided-byte column is a difference against the raw mode rather than an absolute saving.

Hardware

A Linux CPU host running the transport harness with a system CBLAS provider. The host CPU model, core count and memory size are not recorded in this report.

Software

The runtime transport with its representation modes, a pinned reference BLAS provider, and an authenticated local tunnel. Compiler and operating system versions are not recorded in this report.

Input

The mixed operand regime of the matched four-call workload, with a logical input demand of 786432 bytes in the single-input modes and 786432 bytes for the resident mode of the chain regime.

Samples

One matched four-call workload per mode, with the raw mode as the byte-difference reference. No repeated trials or distributions are published for this campaign.

Statistical method

Measured application-stream byte totals and total user wait for the matched four-call workload. The avoided-byte figure is the difference against the matched raw workload and can be negative.

Cold / warm state

The measured totals include cold setup, calibration and cleanup. The adaptive mode additionally charges its own calibration, which is identified separately in the raw records.

Network

The measured byte columns are application-stream bytes only. IP, TCP and tunnel overhead and retransmissions are not recorded and are explicitly unknown.

Serialization

Logical, packed, encoded and framed byte counts are kept separate in the raw records; the published column is the framed application-stream total.

Correctness checks

Every mode in this class is recorded as passing the correctness check.

CALCULATED FROM THE MEASUREMENTSlocal execution, no transport: total user wait ÷ raw transport: total user wait = 0.45740005×118.62700% higher time for raw transport: total user wait.

CALCULATED FROM THE MEASUREMENTSraw transport: total wire bytes ÷ lz4-compressed transport: total wire bytes = 2.6761023×62.632221% lower value for lz4-compressed transport: total wire bytes.

Experimental limitations

• One matched workload per mode with no repeated trials and no distribution.
• Physical packet, tunnel and retransmission overhead are not recorded, so the wire column is an application-stream measure.
• The avoided-byte figure can be negative and is not a saving in every case.
• The timings overlap and must not be summed, and the encode and decode counters cover the call phase only.
• This is a Linux CPU transport measurement and is not a Windows or accelerator measurement.

The published rows let the representation modes be read against each other on the same logical input. The mode that wins depends entirely on the operand regime: a general-purpose codec helps most where the operands are structured and does nothing where they are not, and the adaptive mode does not dominate every regime. No single figure from this table should be quoted without its class.

Experiment identifier

rt-transfer-small-changes

Original title

Transfer byte and latency accounting, small operand changes

Measurement boundary

A matched four-call workload in which the operands change slightly between calls, measured across the transport and representation modes. This is the regime that byte-level delta encoding is designed for. Every mode was run against the same logical input demand and the same matched raw workload, so the byte columns are directly comparable across modes and the avoided-byte column is a difference against the raw mode rather than an absolute saving.

Hardware

A Linux CPU host running the transport harness with a system CBLAS provider. The host CPU model, core count and memory size are not recorded in this report.

Software

The runtime transport with its representation modes, a pinned reference BLAS provider, and an authenticated local tunnel. Compiler and operating system versions are not recorded in this report.

Input

The small changes operand regime of the matched four-call workload, with a logical input demand of 786432 bytes in the single-input modes and 786432 bytes for the resident mode of the chain regime.

Samples

One matched four-call workload per mode, with the raw mode as the byte-difference reference. No repeated trials or distributions are published for this campaign.

Statistical method

Measured application-stream byte totals and total user wait for the matched four-call workload. The avoided-byte figure is the difference against the matched raw workload and can be negative.

Cold / warm state

The measured totals include cold setup, calibration and cleanup. The adaptive mode additionally charges its own calibration, which is identified separately in the raw records.

Network

The measured byte columns are application-stream bytes only. IP, TCP and tunnel overhead and retransmissions are not recorded and are explicitly unknown.

Serialization

Logical, packed, encoded and framed byte counts are kept separate in the raw records; the published column is the framed application-stream total.

Correctness checks

Every mode in this class is recorded as passing the correctness check.

CALCULATED FROM THE MEASUREMENTSlocal execution, no transport: total user wait ÷ raw transport: total user wait = 0.31653827×215.91757% higher time for raw transport: total user wait.

CALCULATED FROM THE MEASUREMENTSraw transport: total wire bytes ÷ lz4-compressed transport: total wire bytes = 2.9257215×65.820396% lower value for lz4-compressed transport: total wire bytes.

Experimental limitations

• One matched workload per mode with no repeated trials and no distribution.
• Physical packet, tunnel and retransmission overhead are not recorded, so the wire column is an application-stream measure.
• The avoided-byte figure can be negative and is not a saving in every case.
• The timings overlap and must not be summed, and the encode and decode counters cover the call phase only.
• This is a Linux CPU transport measurement and is not a Windows or accelerator measurement.

The published rows let the representation modes be read against each other on the same logical input. The mode that wins depends entirely on the operand regime: a general-purpose codec helps most where the operands are structured and does nothing where they are not, and the adaptive mode does not dominate every regime. No single figure from this table should be quoted without its class.

Experiment identifier

rt-transfer-structured

Original title

Transfer byte and latency accounting, structured operands

Measurement boundary

A matched four-call workload whose operands are structured rather than random, measured across the transport and representation modes. This is the regime where a general-purpose compressor should pay the most. Every mode was run against the same logical input demand and the same matched raw workload, so the byte columns are directly comparable across modes and the avoided-byte column is a difference against the raw mode rather than an absolute saving.

Hardware

A Linux CPU host running the transport harness with a system CBLAS provider. The host CPU model, core count and memory size are not recorded in this report.

Software

The runtime transport with its representation modes, a pinned reference BLAS provider, and an authenticated local tunnel. Compiler and operating system versions are not recorded in this report.

Input

The structured operand regime of the matched four-call workload, with a logical input demand of 786432 bytes in the single-input modes and 786432 bytes for the resident mode of the chain regime.

Samples

One matched four-call workload per mode, with the raw mode as the byte-difference reference. No repeated trials or distributions are published for this campaign.

Statistical method

Measured application-stream byte totals and total user wait for the matched four-call workload. The avoided-byte figure is the difference against the matched raw workload and can be negative.

Cold / warm state

The measured totals include cold setup, calibration and cleanup. The adaptive mode additionally charges its own calibration, which is identified separately in the raw records.

Network

The measured byte columns are application-stream bytes only. IP, TCP and tunnel overhead and retransmissions are not recorded and are explicitly unknown.

Serialization

Logical, packed, encoded and framed byte counts are kept separate in the raw records; the published column is the framed application-stream total.

Correctness checks

Every mode in this class is recorded as passing the correctness check.

CALCULATED FROM THE MEASUREMENTSlocal execution, no transport: total user wait ÷ raw transport: total user wait = 0.35004948×185.67390% higher time for raw transport: total user wait.

CALCULATED FROM THE MEASUREMENTSraw transport: total wire bytes ÷ lz4-compressed transport: total wire bytes = 23.367805×95.720608% lower value for lz4-compressed transport: total wire bytes.

Experimental limitations

• One matched workload per mode with no repeated trials and no distribution.
• Physical packet, tunnel and retransmission overhead are not recorded, so the wire column is an application-stream measure.
• The avoided-byte figure can be negative and is not a saving in every case.
• The timings overlap and must not be summed, and the encode and decode counters cover the call phase only.
• This is a Linux CPU transport measurement and is not a Windows or accelerator measurement.

The published rows let the representation modes be read against each other on the same logical input. The mode that wins depends entirely on the operand regime: a general-purpose codec helps most where the operands are structured and does nothing where they are not, and the adaptive mode does not dominate every regime. No single figure from this table should be quoted without its class.

Experiment identifier

rt-transfer-unchanged

Original title

Transfer byte and latency accounting, unchanged operands

Measurement boundary

A matched four-call workload whose operands do not change between calls, measured across the transport and representation modes. This is the regime where holding an operand resident should pay the most. Every mode was run against the same logical input demand and the same matched raw workload, so the byte columns are directly comparable across modes and the avoided-byte column is a difference against the raw mode rather than an absolute saving.

Hardware

A Linux CPU host running the transport harness with a system CBLAS provider. The host CPU model, core count and memory size are not recorded in this report.

Software

The runtime transport with its representation modes, a pinned reference BLAS provider, and an authenticated local tunnel. Compiler and operating system versions are not recorded in this report.

Input

The unchanged operand regime of the matched four-call workload, with a logical input demand of 786432 bytes in the single-input modes and 786432 bytes for the resident mode of the chain regime.

Samples

One matched four-call workload per mode, with the raw mode as the byte-difference reference. No repeated trials or distributions are published for this campaign.

Statistical method

Measured application-stream byte totals and total user wait for the matched four-call workload. The avoided-byte figure is the difference against the matched raw workload and can be negative.

Cold / warm state

The measured totals include cold setup, calibration and cleanup. The adaptive mode additionally charges its own calibration, which is identified separately in the raw records.

Network

The measured byte columns are application-stream bytes only. IP, TCP and tunnel overhead and retransmissions are not recorded and are explicitly unknown.

Serialization

Logical, packed, encoded and framed byte counts are kept separate in the raw records; the published column is the framed application-stream total.

Correctness checks

Every mode in this class is recorded as passing the correctness check.

CALCULATED FROM THE MEASUREMENTSlocal execution, no transport: total user wait ÷ raw transport: total user wait = 0.23050562×333.82891% higher time for raw transport: total user wait.

CALCULATED FROM THE MEASUREMENTSraw transport: total wire bytes ÷ lz4-compressed transport: total wire bytes = 4.0145820×75.090807% lower value for lz4-compressed transport: total wire bytes.

Experimental limitations

• One matched workload per mode with no repeated trials and no distribution.
• Physical packet, tunnel and retransmission overhead are not recorded, so the wire column is an application-stream measure.
• The avoided-byte figure can be negative and is not a saving in every case.
• The timings overlap and must not be summed, and the encode and decode counters cover the call phase only.
• This is a Linux CPU transport measurement and is not a Windows or accelerator measurement.

The published rows let the representation modes be read against each other on the same logical input. The mode that wins depends entirely on the operand regime: a general-purpose codec helps most where the operands are structured and does nothing where they are not, and the adaptive mode does not dominate every regime. No single figure from this table should be quoted without its class.

Experiment identifier

rt-s5-windows-linux-object-interop

Original title

Windows client exchanging objects with a Linux worker

Measurement boundary

A live functional exchange across operating systems: a Windows client uploads objects to a Linux worker, references them, executes one multiplication and releases them, with three negative paths. It is a functional interoperability milestone rather than a performance result.

Hardware

A Windows client and a Linux CPU worker on the same admitted host family. The worker process is bounded by an enforced process memory envelope; the accelerator is not involved.

Software

One exact source revision shared by the client and the worker, with the Windows binary and the worker binary identified by digest in the receipts.

Input

A 4 by 4 f32 object set: 16 final output elements checked, 3 references and 1 execution, with stale-epoch, released-handle and wrong-worker negatives.

Samples

One recorded live session with one execution and three references.

Statistical method

Counts of references, executions, checked elements and negatives, plus one recorded end-to-end duration and the directional stream counters. No distribution is published.

Cold / warm state

A single session against a ready worker. No cold-start cost is published.

Network

Loopback between the client and the worker, with 2,053 bytes outbound and 1,141 bytes inbound recorded for the session.

Serialization

The session moved 2,053 bytes outbound and 1,141 bytes inbound, and the worker released all resident bytes at the end.

Correctness checks

The result was recorded as a pass with all 16 final output elements checked. Stale-epoch handle use, released-handle use and a wrong-worker handshake were each rejected, and the worker released to zero resident bytes. The cleanup receipt reported a successful exit with the local key removed and the owned worker absent.

Experimental limitations

• One session and one execution; no distribution and no timing qualification.
• The object shape is small, so nothing is established about large-message behaviour or throughput.
• This is a client to worker direction only; the reverse direction is not represented.
• The result is functional and carries no performance or acceleration meaning.
• The reviewer note records that the original raw path remains separate malformed-record functional evidence with its own limitations.

The object protocol works across operating systems for the demonstrated path: correct results, three working negative paths, a clean release to zero resident bytes and a clean cleanup. What it does not establish is scale, throughput or the reverse direction, and it is not a performance result.

Experiment identifier

rt-win-native-c-baseline

Original title

Independent native C baseline for the frozen 2048-square workload on a personal Windows machine

Measurement boundary

A separately written C fixture that loads a pinned optimised BLAS and calls it directly, independent of the runtime and of the interception layer. It exists to provide the native arithmetic reference against which the runtime path is read.

Hardware

A personal Windows 11 Pro machine, build 10.0.26200, with an Intel i7-8665U, 4 cores and 8 logical processors, 8,325,652,480 bytes of memory and Intel UHD Graphics 620. Existing user processes were left running, so the machine was not otherwise idle.

Software

A pinned official OpenBLAS 0.3.34 x64 LP64 dynamic library of 51,379,251 bytes, whose upstream release archive digest was verified against the publisher release interface. The library is unsigned and no signature claim is made. The fixture was compiled with the Microsoft toolchain and holds non-reparse ancestor handles against rename and provider file handles against writes and deletion, restricting dependency search to the system directory.

Input

The frozen 2048 by 2048 f32 operands with recorded input digests, alpha 1, beta 0, producing a fully materialised 16,777,216-byte output.

Samples

Two calls in a single fresh child process, one first and one repeated.

Statistical method

Single recorded values per interval from one two-call child; there is no repeated-sample distribution and no statistical qualification.

Cold / warm state

One cold child performs setup, then the two calls. The repeated call is the only warm observation.

Network

None. The fixture is a local process with no transport.

Serialization

None. The fixture produces no request or response frame.

Correctness checks

Each output is exactly 16,777,216 bytes, passes a full finite scan, a full SHA-256 and 64 deterministic f64 scalar dot-product checks at 1e-4 absolute plus 1e-4 relative. The maximum sampled absolute error was 0.000529259600171 and the repeated output digest matched the first.

CALCULATED FROM THE MEASUREMENTSdirect native multiplication, repeated call ÷ call total including validation, repeated call = 0.75396715×32.631773% higher time for call total including validation, repeated call.

Experimental limitations

• One child and two calls; no distribution and no statistical qualification.
• A four-thread configuration of the same fixture failed to allocate under a 512 MiB process cap and emitted no valid timing, so the eight-thread configuration was not attempted.
• The failure does not establish the exact requested workspace, host-wide exhaustion or an arithmetic defect, and no cap was raised or retry unbounded.
• The machine was not idle; the fixture used a shared host.
• The direct call is an arithmetic baseline and is not an end-to-end latency.
• This is not a statistical or qualification result and no frozen-workload conclusion can be drawn from it.

The native arithmetic floor on this machine is about 162 to 165 ms for a 2048-square f32 multiplication, and a call that also snapshots the operands and fully validates the result costs about 214 to 218 ms. That is the floor any external execution path has to beat, and it is the number the runtime path is read against.

Experiment identifier

rt-win-native-rust-runtime

Original title

Runtime path and interception path for the same native workload on a personal Windows machine

Measurement boundary

The same frozen workload executed through the runtime and through the compiled C interception path on a personal Windows machine, with the native provider loaded and admitted, plus the traffic accounting for the session. The native C baseline is a separate cohort.

Hardware

A personal Windows 11 Pro machine, build 10.0.26200, with an Intel i7-8665U, 4 cores and 8 logical processors, 8,325,652,480 bytes of memory and Intel UHD Graphics 620. Available memory was limited and builds and benchmarks ran sequentially with one compiler job; existing user processes were left running.

Software

The same pinned official OpenBLAS 0.3.34 x64 LP64 dynamic library of 51,379,251 bytes, loaded through a validating provider that checks the image, locks file and ancestor directory identities against write, deletion and rename, restricts dependency search to the system directory and validates imports and loaded function ownership.

Input

The frozen 2048 by 2048 f32 operands with recorded input digests, alpha 1, beta 0, producing a fully materialised 16,777,216-byte output.

Samples

Two calls per configuration in single fresh child processes. The offline test suite run reported 145 passed and 0 failed with no ignored case; the interception unit suite reported 17 passed and 0 failed with 1 ignored child helper that the parent executes as a fail-stop child; the compiled C to interception to runtime to native library path reported 52 cases passed, of which 48 were intercepted and 4 were exactly-once original fallbacks.

Statistical method

Single recorded values per interval; no repeated-sample distribution.

Cold / warm state

One cold child per configuration performs provider admission, input generation and hashing, then the two calls. The repeated call is the only warm observation.

Network

No remote worker is contacted. The two-operation session recorded zero outbound and zero inbound object-stream bytes over 1,722,169 microseconds of active observation.

Serialization

The two-operation session recorded zero outbound and zero inbound object-stream bytes, zero reservations and zero remote transfers. The traffic budget assessment records the policy target of 100,000,000 decimal bytes per active hour, that a full active hour was not observed, and that a remote raw comparison was not measured.

Correctness checks

Both calls produced a full 16,777,216-byte output with a SHA-256 matching the independent C fixture exactly, and the runtime additionally checked 64 independent f64 scalar dot products per call. Publication preflights output pages and, once any publication write is attempted, a failure reports uncertainty rather than recomputing the scaled output term.

CALCULATED FROM THE MEASUREMENTSrelease runtime automatic local dispatcher, repeated call ÷ release paired direct, runtime and diagnostic comparison, repeated call = 0.33299207×200.30745% higher time for release paired direct, runtime and diagnostic comparison, repeated call.

CALCULATED FROM THE MEASUREMENTSrelease runtime automatic local dispatcher, first call ÷ release runtime automatic local dispatcher, repeated call = 1.0925030×8.4670710% lower time for release runtime automatic local dispatcher, repeated call.

Experimental limitations

• Two calls per configuration with no statistical qualification and no 30-block campaign.
• The traffic accounting covers eligible local calls only and explicitly does not cover arbitrary application usage.
• The installation traffic of a 40,860,061-byte provider archive was not captured and is outside the per-operation counters, so no claim of zero total session traffic is made.
• The provider archive is unsigned and the library loader does not sandbox library initialisers.
• A four-thread native configuration failed to allocate under a 512 MiB cap, so the observed shape of the threading cost is incomplete.
• No remote worker, remote traffic or accelerator execution is represented.

Through the full runtime dispatcher the frozen workload takes about 202 to 220 ms per call, essentially the same as the independent native C baseline of about 214 to 218 ms, and the whole call including the paired direct and runtime comparison plus diagnostics takes about 605 to 636 ms. The overhead of routing through the runtime on this machine is therefore small in absolute terms. The session moved no network bytes at all, because eligible local execution opens no transport. None of this is an acceleration claim and none of it is a remote comparison.

Experiment identifier

rt-nw1-windows-object-roundtrip

Original title

Windows object-worker interoperability round trip and its negatives

Measurement boundary

A live Windows object-worker round trip: upload, fetch, digest comparison, and three negative paths covering a wrong key, a non-loopback connection and an upload above the managed maximum. A separate protocol defect found during the work is recorded in the same receipt.

Hardware

A Windows host running the native object worker with an enforced process memory envelope. The Linux leg is evidenced by an earlier qualification at the same source lineage and was not re-run live.

Software

A native Windows worker binary with the custody module supplying the 32-byte handshake nonce through the operating system cryptography interface on Windows and byte-identically from the system random source on Unix, with no change to the wire format.

Input

A single object of 512 f64 values, 4,096 bytes, uploaded and fetched back.

Samples

4 live round-trip cases. The full Windows suite reported 43 passed and 0 failed, comprising 37 library, 3 probe and 3 command-line tool cases.

Statistical method

Counts of passed and failed cases. No timing distribution is published.

Cold / warm state

Not recorded as a separate factor; the worker was started for the session.

Network

Loopback only. A non-loopback connection was rejected as a binding error.

Serialization

The uploaded object was 4,096 bytes; the fetched bytes and their digest matched the upload exactly.

Correctness checks

The fetched payload was byte-identical to the upload and its digest matched. A wrong key, a non-loopback connection and an oversized upload were each rejected with the expected binding or limit error.

Experimental limitations

• The live session used a 4 KB object; the larger-message wire path was proven elsewhere rather than here.
• Reparse rejection is implemented but was not live-exercised because it needs an administrative or developer-mode symbolic link.
• Adversarial access-control rejection was code-reviewed rather than black-box tested.
• The Linux leg is evidenced by earlier qualification and was not re-run live; platform differences are environmental only.
• The Linux and Windows process-enclosure mechanisms are not equivalent and the receipt states that explicitly.
• No timing, performance or accelerator claim is made.

The object protocol round-trips correctly on Windows and fails closed in the three ways that matter for admission: a wrong key, a connection from outside loopback and an oversized upload. The receipt also records a real portability defect found by this work, where a hard-coded Unix random source broke every Windows handshake until the operating system cryptography path was substituted.

Experiment identifier

cad-campus-nov11-cold-warm

Original title

Repeat measurement of the 16384-crossing operation on a later day

Measurement boundary

The same geometry operation repeated on a later day on a separately built non-test candidate adapter, measured at the geometry-call boundary. Establishes whether the produced result and the warm cost reproduce across days and builds.

Hardware

Windows workstation (CPU model not recorded).

Software

AutoCAD 2021 R24.0.47.0.0; separately built non-test candidate adapter; Rust release build of the intersection primitive.

Input

Owned integer route pair, 128 routes, 16384 crossings.

Samples

3 call-boundary samples: cold 3163.7208 ms on 2026-11-11, warm 57.7135 ms on 2026-11-11, and warm 89.1877 ms on 2026-11-10 from the earlier session.

Statistical method

single sample per case; the two warm figures are one run each on different days with different builds

Cold / warm state

One cold sample and two warm samples; the cold sample is the first use of the snapshot in its session.

Network

None in this candidate; the computation is in process, so no worker and no tunnel were started.

Serialization

No transport; the result was written directly by the measurement harness.

Correctness checks

The 16384-point result digest was byte-identical across the 2026-11-10 and 2026-11-11 runs for both the cold and the warm case, so the produced array did not change between builds. The complete-operation figures for this run were 3233.5733 ms cold and 81.4891 ms warm.

CALCULATED FROM THE MEASUREMENTSwarm geometry call, 2026-11-10 ÷ warm geometry call, 2026-11-11 = 1.5453525×35.289844% lower time for warm geometry call, 2026-11-11.

Experimental limitations

• One sample per case; no repetition within a session.
• The two warm figures come from different sessions on different days with different builds, so their difference is not a controlled measurement of drift.
• The candidate still pins machine-specific paths and an owned fixture, loads unsigned and interactively, and has no hot unload or cancellation qualification.
• This is an engineering candidate, not an installer and not a release.
• The complete-operation figures for this run are recorded here as text rather than as rows because they belong to a different measurement boundary from the call-boundary rows.

The same geometry produced a byte-identical array on a later day with a different build, and the warm call cost was in the same range as before. That supports reproducibility of the result, not of the timing.

Experiment identifier

cad-sdk-direct-qa-8-cases

Original title

Direct application-interface differential qualification, eight cases

Measurement boundary

Eight differential cases executed directly against the application interface: the first exact pair, the same pair warm, a caller prefix, a duplicated prefix, a shifted operand that creates endpoint contacts, reversed operands cold and warm, and a document create-and-close followed by a return. Each case compares the complete native enumeration and coordinates, not only digests. Covers routing correctness and cache invalidation; it is not a performance measurement and the case timings are explicitly not benchmark figures.

Hardware

Windows workstation (CPU model not recorded).

Software

AutoCAD 2021 R24.0.47.0.0; test-build-only interface qualification command; Rust release build of the intersection primitive.

Input

Owned pinned 128-route fixture: 16384 intersections; the prefix cases returned 16385 and 16386 points; the shifted-operand case returned 18400 points.

Samples

8 cases, one run each.

Statistical method

count of cases by outcome

Cold / warm state

Mixed: the first, reversed and post-document cases were cold and required native qualification; the warm cases reused a qualified snapshot.

Network

None: the local kernel path was used, so no worker and no tunnel were started.

Serialization

Not applicable; no transport frames were produced on this path.

Correctness checks

All eight cases returned status 0 and compared the complete native enumeration and coordinates. The warm cases matched the native ordering with a maximum original-order difference of 1.8189894035458565e-12 against the 1.25e-11 budget. The prefix cases preserved the caller's prefix and delegated natively. The shifted-operand case was rejected by the local kernel and fell back natively with the original array and status preserved. Creating and closing another document invalidated the cache and forced fresh qualification.

Experimental limitations

• One run per case and one owned fixture; not representative student geometry.
• All observed native statuses were 0, so preservation of nonzero native errors remains untested.
• The differential oracle is the native implementation itself; it runs first and warms the kernel, so these case timings are not unbiased performance evidence.
• Entity erase and recreate, address reuse, undo and redo, invalidation during an active computation, cancellation and third-party overrule interaction remain unqualified.
• The qualification command exists only in a test build and its absence from ordinary builds was verified separately.
• The recommendation in the independent review remains no student release.

The external path behaves correctly at the interface boundary for the cases that were tried, including the ones designed to break it: a non-empty prefix and an endpoint-contact geometry both fall back to native rather than producing an answer. The remaining gaps are lifecycle and error coverage, not the cases exercised here.

Experiment identifier

cad-campus-nov10-128-api

Original title

Matched geometry-call comparison, 16384 crossings

Measurement boundary

The same matched geometry operation measured at the call boundary only, excluding marshalling and file output. Reported separately from the complete-operation measurement because the two boundaries differ substantially for the remote path.

Hardware

Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.

Software

AutoCAD 2021 R24.0.47.0.0; local candidate adapter build with an in-process Rust primitive; frozen remote adapter build.

Input

Owned integer route pair, 128 routes, 16384 crossings.

Samples

Native: 1 sample. Local warm: 3 samples (60.773, 132.8728 and 89.1877 ms). Remote warm: 2 samples (1035.6564 and 984.7917 ms).

Statistical method

median of warm samples; native is a single sample

Cold / warm state

Warm for the local and remote medians.

Network

Local mode ran with no worker and no tunnel. Remote mode used an encrypted tunnel to the CPU node with a bounded local forwarding proxy that adds a small hop.

Serialization

The remote response used the compressed frame; the local path produced the result in process.

Correctness checks

The same full-array and integer-grid assertions as the complete-operation measurement, and the warm original-order difference stayed within 1.25e-11.

CALCULATED FROM THE MEASUREMENTSnative geometry call ÷ local warm geometry call, median = 43.805422×97.717178% lower time for local warm geometry call, median.

CALCULATED FROM THE MEASUREMENTSlocal warm geometry call, median ÷ remote warm geometry call, median = 0.088285069×1032.6944% higher time for remote warm geometry call, median.

Experimental limitations

• Native is a single sample while the local and remote medians rest on three and two samples.
• The call boundary excludes automation marshalling and output writing, so it understates what a user waits for in the remote case.
• Sequential sessions and synthetic fixed geometry.
• The remote medians include the local forwarding hop.
• The campus verdict for this work is NO-GO for a student campus demonstration; nothing here is a student-readiness statement.

At the call boundary both external paths are far faster than native, but the local candidate is far ahead of the remote path. The remote path's advantage over native comes from the algorithm and implementation, not from the network.

Experiment identifier

cad-campus-nov10-128-complete

Original title

Matched complete-operation comparison, 16384 crossings

Measurement boundary

Identical integer route geometry and control points, the same geometry operation through the application automation interface, an empty output prefix and full numerical arrays in the original native order. The complete timer covers entity lookup, the geometry call and any interception, qualification, execution and transfer where applicable, automation marshalling, byte conversion and binary file output. It excludes process startup, installation and account sign-in.

Hardware

Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.

Software

AutoCAD 2021 R24.0.47.0.0; local candidate adapter build with an in-process Rust primitive; frozen remote adapter build.

Input

Owned integer route pair, 128 routes, 16384 crossings.

Samples

Native complete operation: 1 sample. Local warm: 3 samples (82.7683, 1209.915 and 123.1285 ms complete). Remote warm: 2 samples (1067.1995 and 1012.2782 ms complete).

Statistical method

median of warm samples; native is a single sample

Cold / warm state

Warm for the local and remote medians. The cold first-use cost is recorded as a separate experiment and is not folded into these rows.

Network

Local mode ran with no worker and no tunnel. Remote mode used an encrypted tunnel to the CPU node with a bounded local forwarding proxy that adds a small hop.

Serialization

The remote response used the compressed frame; the local path produced the result in process.

Correctness checks

Full arrays, unique complete integer-grid sets and output digests were asserted. The warm original-order difference stayed at or below 1.25e-11, with the largest observed value 7.275957614183426e-12 in the larger case. Warm local returns and alternating pairs made zero native calls.

CALCULATED FROM THE MEASUREMENTSnative complete operation ÷ local warm complete operation, median = 32.249846×96.899210% lower time for local warm complete operation, median.

CALCULATED FROM THE MEASUREMENTSlocal warm complete operation, median ÷ remote warm complete operation, median = 0.11842253×744.43395% higher time for remote warm complete operation, median.

Experimental limitations

• Native is a single sample while the local and remote medians rest on three and two samples, so the comparison is indicative rather than statistically qualified.
• Sessions were sequential, not randomised.
• Synthetic fixed geometry precludes any general or student-performance statement.
• The retained local outlier of 1209.915 ms complete is one of the three recorded local samples and is not hidden.
• The remote adapter still used the older single-entry cache, and both warm medians compare already-qualified empty-prefix operations.
• The campus verdict for this work is NO-GO for a student campus demonstration; nothing here is a student-readiness statement.

The local candidate is the fastest path measured for this workload by a wide margin and the remote path is second. The gain comes from the implementation, not from placement.

Experiment identifier

cad-campus-nov10-256-api

Original title

Matched geometry-call comparison, 65536 crossings

Measurement boundary

The larger fixture measured at the call boundary only, excluding marshalling and file output, using the same matched geometry and the same three paths as the 16384-crossing comparison.

Hardware

Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.

Software

AutoCAD 2021 R24.0.47.0.0; local candidate adapter build with an in-process Rust primitive; frozen remote adapter build.

Input

Owned integer route pair, 256 routes, 65536 crossings.

Samples

Native: 1 sample. Local warm: 3 samples (237.2181, 227.0093 and 130.3307 ms). Remote warm: 3 samples (990.1554, 799.2974 and 731.0696 ms).

Statistical method

median of warm samples; native is a single sample

Cold / warm state

Warm for the local and remote medians.

Network

Local mode ran with no worker and no tunnel. Remote mode used an encrypted tunnel to the CPU node with a bounded local forwarding proxy that adds a small hop.

Serialization

The remote response used the compressed frame; the local path produced the result in process.

Correctness checks

The same full-array and integer-grid assertions as the complete-operation measurement, and the warm original-order difference stayed within 1.25e-11.

CALCULATED FROM THE MEASUREMENTSnative geometry call ÷ local warm geometry call, median = 290.95248×99.656301% lower time for local warm geometry call, median.

CALCULATED FROM THE MEASUREMENTSlocal warm geometry call, median ÷ remote warm geometry call, median = 0.28401106×252.09897% higher time for remote warm geometry call, median.

Experimental limitations

• Native is a single sample while the local and remote medians rest on three samples each.
• The call boundary excludes automation marshalling and output writing, so it understates what a user waits for in the remote case.
• Sequential sessions and synthetic fixed geometry.
• The remote medians include the local forwarding hop.
• The campus verdict for this work is NO-GO for a student campus demonstration; nothing here is a student-readiness statement.

The ordering is the same as at the smaller size and the separation between the three paths is wider. The external paths win against native because of the algorithm and implementation; the remote placement adds a large constant cost that local execution does not pay.

Experiment identifier

cad-campus-nov10-256-complete

Original title

Matched complete-operation comparison, 65536 crossings

Measurement boundary

The larger fixture measured with the same complete-operation timer as the 16384-crossing comparison: entity lookup, the geometry call and any interception, qualification, execution and transfer where applicable, automation marshalling, byte conversion and binary file output, excluding startup, installation and account sign-in.

Hardware

Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.

Software

AutoCAD 2021 R24.0.47.0.0; local candidate adapter build with an in-process Rust primitive; frozen remote adapter build.

Input

Owned integer route pair, 256 routes, 65536 crossings.

Samples

Native complete operation: 1 sample. Local warm: 3 samples (321.5011, 297.3346 and 190.6477 ms complete). Remote warm: 3 samples (1035.5508, 845.1547 and 775.9802 ms complete).

Statistical method

median of warm samples; native is a single sample

Cold / warm state

Warm for the local and remote medians. The cold first-use cost is recorded as a separate experiment and is not folded into these rows.

Network

Local mode ran with no worker and no tunnel. Remote mode used an encrypted tunnel to the CPU node with a bounded local forwarding proxy that adds a small hop.

Serialization

The remote response used the compressed frame; the local path produced the result in process.

Correctness checks

Full arrays, unique complete integer-grid sets and output digests were asserted. The warm original-order difference stayed at or below 1.25e-11, with the largest observed value 7.275957614183426e-12 for this case.

CALCULATED FROM THE MEASUREMENTSnative complete operation ÷ local warm complete operation, median = 222.36651×99.550292% lower time for local warm complete operation, median.

CALCULATED FROM THE MEASUREMENTSlocal warm complete operation, median ÷ remote warm complete operation, median = 0.35181086×184.24364% higher time for remote warm complete operation, median.

Experimental limitations

• Native is a single sample while the local and remote medians rest on three samples each, so the comparison is indicative rather than statistically qualified.
• Sessions were sequential, not randomised.
• Synthetic fixed geometry precludes any general or student-performance statement.
• The local warm range was 190.6477 to 321.5011 ms complete and is recorded rather than reduced to the median alone.
• The remote adapter still used the older single-entry cache, and both warm medians compare already-qualified empty-prefix operations.
• The campus verdict for this work is NO-GO for a student campus demonstration; nothing here is a student-readiness statement.

At the larger size the ordering is unchanged and the gap widens: the local candidate is the fastest path, the remote path is second and the native path is far behind both. The native single sample in this session was also substantially slower than the native baseline captured in an earlier session, which is itself a warning about session-to-session variation.

Experiment identifier

cad-campus-nov10-cold-qualification

Original title

First-use cost of a geometry snapshot in local and remote modes

Measurement boundary

The complete-operation cost of the first use of an exact geometry snapshot in local mode and in remote mode, where the application must establish the ordering and status semantics natively before a remote result can be accepted. Sessions were sequential and each figure is a single sample.

Hardware

Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.

Software

AutoCAD 2021 R24.0.47.0.0; local candidate adapter build with an in-process Rust primitive; frozen remote adapter build.

Input

Owned integer route pairs at 128 and 256 routes.

Samples

4 cold complete-operation samples: local 16384 at 3437.6661 ms, remote 16384 at 4938.6445 ms, local 65536 at 57597.9075 ms, remote 65536 at 63164.2667 ms.

Statistical method

single sample per case

Cold / warm state

Cold by definition: each case is the first use of that snapshot in its session, so the native qualification runs.

Network

Local mode ran with no worker and no tunnel. Remote mode used the encrypted tunnel and the bounded forwarding proxy.

Serialization

As in the matched comparison measurements.

Correctness checks

Every cold case produced the complete array with the native output and status preserved, with a maximum original-order difference of 0.

CALCULATED FROM THE MEASUREMENTSlocal cold complete operation, 16384 crossings ÷ remote cold complete operation, 16384 crossings = 0.69607482×43.662716% higher time for remote cold complete operation, 16384 crossings.

CALCULATED FROM THE MEASUREMENTSlocal cold complete operation, 65536 crossings ÷ remote cold complete operation, 65536 crossings = 0.91187487×9.6641691% higher time for remote cold complete operation, 65536 crossings.

Experimental limitations

• Single sample per case; these are not statistically qualified figures.
• The native baselines for the same fixture vary between sessions, so the difference between the 65536-crossing local and remote cold figures is not a controlled result.
• First-use latency blocks the application and cancellation is not qualified.
• The earlier campaign's 65536-crossing remote first-use API time of 73265 ms is preserved separately and is not overwritten by these figures.
• A session-only cache of exact orderings removes repeated native work when alternating between drawings, but it does not remove the first cost.
• The campus verdict for this work is NO-GO for a student campus demonstration; nothing here is a student-readiness statement.

Session caching removes repeated native work when alternating between drawings, but the first use of an unseen drawing still costs about a minute at the larger size. That is the dominant usability problem and the main reason the verdict is negative.

Experiment identifier

cad-intersection-live-nov10-cold-qualification

Original title

Live intersection consumption: native qualification of a first-seen snapshot

Measurement boundary

The first use of an exact geometry snapshot still requires the application to compute the answer natively once, to establish the ordering and status semantics that a remote result must reproduce. These are the qualification operations and they dominate the cost of the first use of a drawing.

Hardware

Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.

Software

AutoCAD 2021 R24.0.47.0.0; the owner-approved intersection adapter build; Rust release build of the intersection primitive and its bridge.

Input

Owned integer orthogonal route fixture at 128 and 256 routes, plus a translated-operand case and a reversed-operand case.

Samples

4 qualification operations, one per case.

Statistical method

single sample per case

Cold / warm state

Cold: each of these is a first-seen snapshot or a changed operand set, so the native path runs first.

Network

Encrypted tunnel to the CPU node. Where a remote computation was attempted it returned, for example 22491 microseconds for the 65536-crossing qualification.

Serialization

Compressed response frames 24555 and 55545 bytes for the two fixture sizes.

Correctness checks

Each qualification preserved the native output and status exactly, with a maximum original-order difference of 0, and established the ordering that later remote returns had to follow.

Experimental limitations

• Single sample per case.
• These are the cases that determine first-use latency and are not the steady-state case; they must not be reported as the operation's typical cost.
• The reversed-operand case qualified natively but did not obtain a zero-native remote return in this run.
• The 65536-crossing qualification is the slowest single operation measured in this campaign.
• First-use latency is unqualified for cancellation: the application blocks while the native qualification runs.
• A session-only cache of exact orderings removes repeated native work when alternating between drawings, but it does not remove the first cost.

The cost that matters to a user is the first operation on a drawing, and that first operation is still native work. This, not the steady-state remote return, is the dominant usability problem.

Experiment identifier

cad-intersection-live-nov10-fallback-native

Original title

Live intersection consumption: native fallback when the exchange fails

Measurement boundary

Cases where the remote exchange failed or timed out and the application computed the answer natively instead. One case is a deliberately stopped worker; two are unexplained client-side failures. Recorded so that the failure behaviour stays visible instead of being averaged away.

Hardware

Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.

Software

AutoCAD 2021 R24.0.47.0.0; the owner-approved intersection adapter build; Rust release build of the intersection primitive and its bridge.

Input

Owned integer orthogonal route fixture at 128 and 256 routes.

Samples

3 fallback operations, one per case.

Statistical method

single sample per case

Cold / warm state

Warm for the two failed exchanges; the stopped-worker case followed an already qualified snapshot.

Network

Encrypted tunnel to the CPU node. For the two unexplained failures the worker computed the answer successfully in 5685 and 4147 microseconds and logged the response send, yet the client failed; the exact failing stage was not recorded.

Serialization

Request 8226 and 16418 bytes; compressed response frames 24555 and 55545 bytes where a response was produced.

Correctness checks

Every fallback returned the correct native array and status, with no cached remote result substituted. The stopped-worker case returned the full 65536-point array with status 0.

Experimental limitations

• Single sample per case.
• The two unexplained failures have no proven root cause and are not claimed to be fixed: the recorded evidence cannot distinguish a network read failure from a validation failure from an end-to-end deadline.
• The hook time in these cases includes the eventual native work and so cannot isolate the failing stage.
• Native fallback is correct but far slower than the remote path it replaces.
• The case names in the original receipt are optimistic for the two failed exchanges and must not be quoted as qualification successes.

The failure path is safe but expensive, and two of the three recorded failures remain unexplained. That unresolved reliability gap, together with the first-use cost, is the main obstacle to treating the external path as ready.

Experiment identifier

cad-intersection-live-nov10-warm-128

Original title

Live intersection consumption, warm 16384-crossing returns

Measurement boundary

The application's own intersection operation returned arrays computed by the remote worker through the official geometry overrule, and the application consumed them with zero native calls. API time and full export time are reported as separate rows because they are different boundaries: the API time is the geometry call, while the export time additionally includes enumerating, formatting and writing the result.

Hardware

Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.

Software

AutoCAD 2021 R24.0.47.0.0; the owner-approved intersection adapter build; Rust release build of the intersection primitive and its bridge.

Input

Owned integer orthogonal route fixture, 128 routes (16384 crossings), plus a case with both operands translated by one unit and a repeated return of the translated case.

Samples

3 live remote returns, one per case.

Statistical method

single sample per case

Cold / warm state

Warm: the exact snapshot had already been qualified natively, so these returns used no native call.

Network

Encrypted tunnel to the CPU node; remote worker compute was 5315, 4733 and 4885 microseconds. The transport proxy logged request receipt, upstream connection and send, response header and body, and forwarding, with no credential logging.

Serialization

Compressed response frame 24555 bytes for the 16384-crossing case against a 262179-byte uncompressed payload.

Correctness checks

Returned arrays matched the original native enumeration and coordinates within the unchanged 1.25e-11 budget, and the maximum original-order difference was 1.8189894035458565e-12 for these returns. An independent exact integer grid verified the complete sets, not only digests.

Experimental limitations

• Single sample per case.
• Synthetic owned route geometry, not a representative student drawing.
• The path exercised was the automation interface of the geometry operation, not an ordinary interactive command.
• Export totals are dominated by enumeration, formatting and disk output and are not interactive-command timings.
• The native baselines for the same fixture come from a different session and are not a matched pair with these returns.
• Translated operands forced a fresh native qualification before the remote returns could be accepted.

The host accepted remotely computed intersection arrays and consumed them without computing them natively. The correctness is strong; latency and export overhead are the open problems.

Experiment identifier

cad-intersection-live-nov10-warm-256

Original title

Live intersection consumption, warm 65536-crossing returns and worker recovery

Measurement boundary

The same live geometry-overrule path with the larger fixture. The second case follows a stopped remote worker and shows the remote path resuming after recovery. API and export times are separate boundaries and are not compared with each other.

Hardware

Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.

Software

AutoCAD 2021 R24.0.47.0.0; the owner-approved intersection adapter build; Rust release build of the intersection primitive and its bridge.

Input

Owned integer orthogonal route fixture, 256 routes (65536 crossings).

Samples

2 live remote returns, one per case.

Statistical method

single sample per case

Cold / warm state

Warm for both returns; the recovered case reused the qualification established before the worker was stopped.

Network

Encrypted tunnel to the CPU node; remote worker compute was 22579 and 23356 microseconds.

Serialization

Compressed response frame 55545 bytes for the 65536-crossing case against a 1048611-byte uncompressed payload.

Correctness checks

Both returns matched the native enumeration within 1.25e-11 with a maximum original-order difference of 7.30437932361383e-12, and no native call was made on either return.

Experimental limitations

• Single sample per case.
• Synthetic owned route geometry, not a student drawing.
• Not an ordinary interactive command path.
• Export totals include enumeration, formatting and disk output.
• The native baseline for this fixture comes from a different session and is not a matched pair with these returns.

The larger case behaves like the smaller one: the application consumes a remote array without a native call, and the remote path resumes after the worker is restored. The remaining cost is transport and output formatting, not computation.

Experiment identifier

cad-intersection-native-baseline-r1

Original title

Native intersection baseline captured in a separate session

Measurement boundary

The application's own intersection computation run natively on the owned route fixture in its own session, before the matched live consumption run. Recorded separately so that the native cost is never attributed to the matched run: the two are different sessions, and the live run's first operation still had to qualify natively.

Hardware

Windows workstation (CPU model not recorded).

Software

AutoCAD 2021 R24.0.47.0.0 (R24.0 branch).

Input

Owned integer orthogonal route fixture at 128 routes (16384 crossings) and 256 routes (65536 crossings).

Samples

One native run per fixture size.

Statistical method

single run per size

Cold / warm state

Cold in the sense that the native path needs no qualification, but this is a standalone native execution and not the first operation of the later run.

Network

None; native local execution only.

Serialization

Not applicable.

Correctness checks

The captured arrays were the reference against which the later remote results were compared within the 1.25e-11 budget.

Experimental limitations

• Single run per size.
• The application reports API time in quantised milliseconds; the send-and-idle wall time additionally includes command dispatch.
• These baselines come from a different session than the matched live run and must not be presented as a matched pair with it.
• Host CPU model not recorded, and the native cost varies between sessions on the same host: the 65536-crossing native API time was recorded as 41219 ms here and as 66048.9191 ms in a later campus session.

The native cost of the intersection workload is large and varies between sessions on the same host. Any speed statement must name which native measurement it is compared against, because the choice changes the result materially.

Experiment identifier

cad-student-installer-readiness

Original title

Student installation and deployment readiness status

Measurement boundary

A readiness count taken from the installed-workflow reconnaissance and the independent review, covering the four conditions that must hold before an external geometry path could be offered to students. This cohort records what is qualified and what is not; it contains no timing.

Hardware

Windows workstation (CPU model not recorded). No second Windows machine and no campus device access was established.

Software

AutoCAD 2021 R24.0.47.0.0; a signed-in pilot desktop control plane with a device account and credential encryption, but no geometry payload.

Input

Existing pilot desktop installation and account enrollment; a candidate geometry adapter that still pins machine-specific paths and one owned fixture.

Samples

4 readiness conditions, each recorded as qualified or not qualified.

Statistical method

count of qualified conditions

Cold / warm state

Not applicable.

Network

The control plane's portal and device endpoints answered healthy during reconnaissance, but this is not a full authenticated journey and does not qualify a geometry data plane.

Serialization

Not applicable.

Correctness checks

The existing pilot installation was preserved and its encrypted credential survived an upgrade; the pilot application was verified to install, launch and reconnect automatically. None of this concerns the geometry path.

Experimental limitations

• The existing installer packages the pilot executable and an optional numerical library, but not the geometry adapter, its runtime or any application registration, so an installed control-plane state is not a geometry-ready state.
• No geometry-bearing installer exists and no automatic or approved loading path is implemented; loading remains operator-mediated.
• Student installation verified: not recorded as complete.
• Second Windows machine clean install verified: not recorded as complete.
• Representative student drawing workloads verified: not recorded as complete.
• Portal connection integrated with the geometry path verified: not recorded as complete.
• The campus verdict for this work is NO-GO for a student campus demonstration.
• Credentials for the operator's remote shell must never be bundled into an installer and were not.

The control-plane half of the journey exists and is signed in on one machine. The geometry half has no installer, no automatic loading, no representative student data and no second machine. Publishing this as a student capability would misdescribe the state of the work.

Experiment identifier

cad-intersection-bridge-compressed-r2-128

Original title

Captured-array intersection bridge, lossless-compressed run r2, 16384 crossings

Measurement boundary

The same captured-array measurement as the uncompressed run, repeated in a separate second run with a lossless compressed response encoding. Bridge wall time only; excludes host capture, native qualification and result installation.

Hardware

Windows workstation for the local placement (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1 for the remote placement.

Software

Rust release build of the intersection primitive and its bridge with the compressed response codec; arrays captured earlier from AutoCAD 2021 R24.0.47.0.0.

Input

128 owned integer orthogonal route pairs producing 16384 intersection points; request payload 8226 bytes.

Samples

3 repeats per placement. Local bridge wall 9.9361, 9.2408 and 9.4044 ms. Remote bridge wall 856.7324, 1703.9614 and 819.2004 ms.

Statistical method

median of 3 repeats

Cold / warm state

Warm: the same captured array and worker session were reused.

Network

Remote placement used an encrypted tunnel to the CPU node, where the worker spent a median 5.330 ms; the local placement worker spent a median 2.713 ms.

Serialization

Compressed run: request 8226 bytes, compressed response frame 24555 bytes, uncompressed response payload 262179 bytes and decoded payload 262169 bytes. The frame digest is recorded and matches the uncompressed run's payload digest.

Correctness checks

Maximum per-point difference against the captured native array was 1.8190449138500806e-12 against a 1.25e-11 comparison budget, identical to the uncompressed run. The response digest was identical for local and remote placement and identical to the uncompressed run.

CALCULATED FROM THE MEASUREMENTSequivalent local rust bridge, median wall ÷ remote bridge over encrypted tunnel, median wall = 0.010977057×9009.9103% higher time for remote bridge over encrypted tunnel, median wall.

Experimental limitations

• Bridge wall time only; excludes host capture, native qualification and result installation.
• No application process was running.
• Synthetic owned integer geometry, not a student drawing.
• 3 repeats per placement, sequential, on one workstation and one remote node.
• Workstation CPU model not recorded.
• This is a separate run from the uncompressed one and the two must be quoted as distinct runs, not merged.

Compressing the response shortened the remote bridge wall substantially while the decoded payload and the numerical result stayed identical. The local bridge also moved slightly, so the compression effect is visible on the remote path and not cleanly isolated from run-to-run variation.

Experiment identifier

cad-intersection-bridge-compressed-r2-256

Original title

Captured-array intersection bridge, lossless-compressed run r2, 65536 crossings

Measurement boundary

The larger captured-array case of the compressed bridge run, a separate second run from the uncompressed measurement. Bridge wall time only; excludes host capture, native qualification and result installation.

Hardware

Windows workstation for the local placement (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1 for the remote placement.

Software

Rust release build of the intersection primitive and its bridge with the compressed response codec; arrays captured earlier from AutoCAD 2021 R24.0.47.0.0.

Input

256 owned integer orthogonal route pairs producing 65536 intersection points; request payload 16418 bytes.

Samples

3 repeats per placement. Local bridge wall 49.9515, 34.5341 and 34.7191 ms. Remote bridge wall 1243.5812, 1179.1173 and 1376.5190 ms.

Statistical method

median of 3 repeats

Cold / warm state

Warm: the same captured array and worker session were reused.

Network

Remote placement used an encrypted tunnel to the CPU node, where the worker spent a median 21.299 ms; the local placement worker spent a median 11.303 ms.

Serialization

Compressed run: request 16418 bytes, compressed response frame 55545 bytes, uncompressed response payload 1048611 bytes and decoded payload 1048601 bytes. The frame digest is recorded and matches the uncompressed run's payload digest.

Correctness checks

Maximum per-point difference against the captured native array was 7.30437932361383e-12 against a 1.25e-11 comparison budget, identical to the uncompressed run. The response digest was identical for local and remote placement and identical to the uncompressed run.

CALCULATED FROM THE MEASUREMENTSequivalent local rust bridge, median wall ÷ remote bridge over encrypted tunnel, median wall = 0.027918643×3481.8359% higher time for remote bridge over encrypted tunnel, median wall.

Experimental limitations

• Bridge wall time only; excludes host capture, native qualification and result installation.
• No application process was running.
• Synthetic owned integer geometry, not a student drawing.
• 3 repeats per placement, sequential, on one workstation and one remote node.
• Workstation CPU model not recorded.
• This is a separate run from the uncompressed one and the two must be quoted as distinct runs, not merged.

At the larger size the compressed remote path remains far behind the equivalent local computation. The compressed and uncompressed runs are two separate historical runs and are reported separately rather than averaged.

Experiment identifier

cad-intersection-bridge-failure-handling

Original title

Bridge fail-closed behaviour: nine injected fault cases and a stopped remote worker

Measurement boundary

Deliberately corrupted, truncated, oversized, misidentified and deadlined responses were injected at the bridge boundary, and a separate run stopped the remote worker outright. Confirms that a failure never publishes a wrong or partial result and never mutates the caller's output buffer. Bridge boundary only: it is not an application-level native-fallback test and not a live-consumption test.

Hardware

Windows workstation (CPU model not recorded); remote CPU node with 8 cores and 31331228 KiB available memory running Ubuntu 26.04.1 for the stopped-worker case.

Software

Rust release build of the intersection bridge with the compressed response codec.

Input

A captured 16384-crossing array (request 8226 bytes); eight malformed responses derived from it plus one well-formed control, and one run with the worker stopped.

Samples

Nine injected cases, one run each, plus one stopped-worker run.

Statistical method

single run per case

Cold / warm state

Warm: the same bridge session and the same pinned bridge binary were used for every case.

Network

The eight malformed responses were injected at the bridge boundary; the stopped-worker case used the remote placement over the encrypted tunnel.

Serialization

The pinned bridge binary digest and the response frame digests are recorded with the case matrix; the compressed frames are 24555 bytes for 16384 crossings and 55545 bytes for 65536 crossings.

Correctness checks

All eight injected failure cases returned status 2 with the output buffer untouched, and the well-formed positive control returned status 0 in 4.3912 ms. The stopped-worker case returned status 2 in 310.8613 ms with the failure output untouched, publishing no remote result and substituting no cached result.

Experimental limitations

• Bridge-level only; no application process was running.
• One run per case.
• The deadline case exercises the bridge's own absolute deadline and is not an application-level cancellation guarantee.
• The stopped-worker case is a single run and does not establish a failure rate.
• The native API baseline for the same fixture was captured separately and is not a matched pair with these runs.

The bridge refuses to publish anything it cannot validate. Failing closed quickly and without touching the output is the precondition that lets a host-side native fallback be trusted, and it is measured here rather than asserted.

Experiment identifier

cad-intersection-bridge-uncompressed-r1-128

Original title

Captured-array intersection bridge, uncompressed run r1, 16384 crossings

Measurement boundary

Arrays actually captured from the application were handed to a new opt-in Rust bridge and transported to a CPU worker. Measures bridge wall time only. Excludes host capture, native qualification and result installation, so it is neither an end-to-end application speed measurement nor proof that the application consumed a remote result.

Hardware

Windows workstation for the local placement (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1 for the remote placement.

Software

Rust release build of the intersection primitive and its bridge; the arrays were captured earlier from AutoCAD 2021 R24.0.47.0.0.

Input

128 owned integer orthogonal route pairs producing 16384 intersection points; request payload 8226 bytes.

Samples

3 repeats per placement. Local bridge wall 9.3496, 7.5732 and 7.3365 ms. Remote bridge wall 4184.3715, 2049.9590 and 3193.4464 ms.

Statistical method

median of 3 repeats

Cold / warm state

Warm: the same captured array and the same worker session were reused, so no cold qualification cost is included.

Network

Remote placement used an encrypted tunnel to the CPU node, where the worker spent a median 5.499 ms. Local placement ran the same worker code in process with no socket.

Serialization

Uncompressed run: request 8226 bytes and response 262179 bytes, with an identical response digest across all six repeats of both placements.

Correctness checks

Maximum per-point difference against the captured native array was 1.8190449138500806e-12 against a 1.25e-11 comparison budget. The response digest was identical for the local and the remote placement.

CALCULATED FROM THE MEASUREMENTSequivalent local rust bridge, median wall ÷ remote bridge over encrypted tunnel, median wall = 0.0023714818×42067.728% higher time for remote bridge over encrypted tunnel, median wall.

Experimental limitations

• Bridge wall time only; excludes host capture, native qualification and result installation.
• No application process was running; this run did not measure host consumption.
• Synthetic owned integer geometry, not a student drawing.
• 3 repeats per placement, sequential, on one workstation and one remote node.
• Workstation CPU model not recorded.
• The native API cost of the same fixture was captured separately and is not a matched pair with this run.

The remote path is far slower than the equivalent local computation of the same arrays, while the application's own native call for the same fixture was recorded separately as 2703 ms. The gain in this workload comes from the implementation, not from relocating the work.