{ "schema": "naught-public-measurements/v1", "presentationVersion": 1, "extractionReviewed": "2026-11-12", "experiments": [ { "id": "cad-campus-nov11-cold-warm", "title": "Running the same operation again a day later with a fresh build", "topic": "AutoCAD", "date": "2026-11-11", "evidence": "Measured", "scope": "The cold call on 11 November against the warm call on the same day, with the warm call from the 10 November session beside them.", "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.", "statistic": "single sample per case; the two warm figures are one run each on different days with different builds", "warmCold": "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": "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.", "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." ], "interpretation": "The output was byte-identical across both days and both builds, with the cold call at 3.16 s and the warm call at 58 ms on the later day against 89 ms on the earlier one.", "href": "/research/autocad/", "sourceIds": [ "cad-campus-prod-cold128-20261111", "cad-campus-prod-warm128-20261111", "cad-campus-local-warm128c-20261110", "cad-sdk-qa-result" ], "rows": [ { "label": "cold geometry call, 2026-11-11", "value": 3163.7208, "unit": "ms", "role": "local", "n": 1, "statistic": "single sample" }, { "label": "warm geometry call, 2026-11-11", "value": 57.7135, "unit": "ms", "role": "local", "n": 1, "statistic": "single sample" }, { "label": "warm geometry call, 2026-11-10", "value": 89.1877, "unit": "ms", "role": "local", "n": 1, "statistic": "single sample" } ], "comparisons": [ { "baseline": 2, "candidate": 1, "kind": "historical" } ], "chart": true, "presentation": { "title": "Running the same operation again a day later with a fresh build", "question": "A result that reproduces only once is a fluke, so I rebuilt the candidate and repeated the 16,384-crossing operation the next day to see whether the answer and the warm cost survived.", "comparison": "The cold call on 11 November against the warm call on the same day, with the warm call from the 10 November session beside them.", "finding": "The output was byte-identical across both days and both builds, with the cold call at 3.16 s and the warm call at 58 ms on the later day against 89 ms on the earlier one.", "lesson": "The result reproduces across days and builds; the timing does not, so only the correctness carries over.", "caveat": "One sample per case with no repetition inside a session, and the two warm figures come from different days and different builds so their difference is not a controlled measure of drift; this is an engineering candidate rather than an installer.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "Cold local call, 11 November", "1": "Warm local call, 11 November", "2": "Warm local call, 10 November" }, "featuredRows": [ 1, 2 ] }, "technical": { "original": { "title": "Repeat measurement of the 16384-crossing operation on a later day", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-sdk-direct-qa-8-cases", "title": "Eight interface cases designed to break the external path", "topic": "AutoCAD", "date": "2026-11-11", "evidence": "Validation", "scope": "A first pair, the same pair warm, a caller prefix, a duplicated prefix, a shifted operand creating endpoint contacts, reversed operands cold and warm, and a document create-and-close followed by a return.", "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.", "statistic": "count of cases by outcome", "warmCold": "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": "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.", "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." ], "interpretation": "All eight returned a clean status and compared equal to the application's own enumeration; two were answered by the local kernel with no native call and six were handed back to the application, which is exactly what I wanted the prefixed and shifted cases to do.", "href": "/research/autocad/", "sourceIds": [ "cad-sdk-qa-result", "cad-sdk-qa-independent-review" ], "rows": [ { "label": "differential interface cases executed", "value": 8, "unit": "cases", "role": "metric", "n": 1, "statistic": "count of cases" }, { "label": "cases resolved by the local kernel with zero native calls", "value": 2, "unit": "cases", "role": "local", "n": 1, "statistic": "count of cases" }, { "label": "cases delegated to the native implementation", "value": 6, "unit": "cases", "role": "native", "n": 1, "statistic": "count of cases" }, { "label": "rust test suites passing in the same build", "value": 74, "unit": "cases", "role": "metric", "n": 1, "statistic": "count of tests" }, { "label": "native policy checks passing in the same build", "value": 74, "unit": "cases", "role": "metric", "n": 1, "statistic": "count of checks" } ], "comparisons": [], "chart": false, "presentation": { "title": "Eight interface cases designed to break the external path", "question": "I wanted a correctness check that did not rely on timing at all, so I drove eight cases straight at the application interface, including ones I expected to fail.", "comparison": "A first pair, the same pair warm, a caller prefix, a duplicated prefix, a shifted operand creating endpoint contacts, reversed operands cold and warm, and a document create-and-close followed by a return.", "finding": "All eight returned a clean status and compared equal to the application's own enumeration; two were answered by the local kernel with no native call and six were handed back to the application, which is exactly what I wanted the prefixed and shifted cases to do.", "lesson": "The interface boundary holds for the cases I tried, including the ones designed to break it, and what is still missing is lifecycle and error coverage rather than correctness in the cases exercised.", "caveat": "One run per case on one drawing of mine, every observed native status was zero so non-zero error handling is untested, and the reference implementation runs first, which makes the case timings unusable as performance evidence; the independent review still recommends no student release.", "kind": "Functional check", "area": "AutoCAD", "labels": { "0": "Differential cases executed", "1": "Cases answered by the local kernel", "2": "Cases handed back to the application", "3": "Rust test suites passing", "4": "Native policy checks passing" }, "featuredRows": [ 0, 1, 2 ] }, "technical": { "original": { "title": "Direct application-interface differential qualification, eight cases", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-campus-nov10-128-api", "title": "The same three paths measured only at the geometry call", "topic": "AutoCAD", "date": "2026-11-10", "evidence": "Measured", "scope": "The same 128-route geometry operation timed at the call boundary only, for the native, local and remote paths.", "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).", "statistic": "median of warm samples; native is a single sample", "warmCold": "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": "The same full-array and integer-grid assertions as the complete-operation measurement, and the warm original-order difference stayed within 1.25e-11.", "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." ], "interpretation": "The native call took 3.91 s, the local implementation 89 ms and the remote worker 1.01 s.", "href": "/research/autocad/", "sourceIds": [ "cad-campus-result-20261110", "cad-campus-remote-transport-20261110" ], "rows": [ { "label": "native geometry call", "value": 3906.9048, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "local warm geometry call, median", "value": 89.1877, "unit": "ms", "role": "local", "n": 3, "statistic": "median of 3 samples" }, { "label": "remote warm geometry call, median", "value": 1010.22405, "unit": "ms", "role": "remote", "n": 2, "statistic": "median of 2 samples" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "implementation" }, { "baseline": 1, "candidate": 2, "kind": "remote-vs-local" } ], "chart": true, "presentation": { "title": "The same three paths measured only at the geometry call", "question": "I wanted to separate the cost of the geometry call itself from the cost of marshalling and writing the result, so I measured the call boundary on its own.", "comparison": "The same 128-route geometry operation timed at the call boundary only, for the native, local and remote paths.", "finding": "The native call took 3.91 s, the local implementation 89 ms and the remote worker 1.01 s.", "lesson": "Both external paths beat the application by a wide margin at this boundary, but the remote advantage still comes from the implementation rather than from the network.", "caveat": "One native sample against three local and two remote, and excluding marshalling and output understates what a user waits for on the remote path; sessions were sequential and the student campus demonstration remains a no-go.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "Native geometry call", "1": "Local implementation, median", "2": "Remote execution, median" }, "featuredRows": [ 0, 1, 2 ] }, "technical": { "original": { "title": "Matched geometry-call comparison, 16384 crossings", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-campus-nov10-128-complete", "title": "The full intersection operation measured three ways at 16,384 crossings", "topic": "AutoCAD", "date": "2026-11-10", "evidence": "Measured", "scope": "The same geometry and control points through the application's automation interface, with one native sample, three local samples and two remote samples.", "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).", "statistic": "median of warm samples; native is a single sample", "warmCold": "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": "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.", "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." ], "interpretation": "The native complete operation took 3.97 s, the local implementation 123 ms and the remote worker 1.04 s, so the local path was about 32 times faster than native and the remote about 3.8 times faster.", "href": "/research/autocad/", "sourceIds": [ "cad-campus-result-20261110", "cad-campus-remote-transport-20261110", "cad-campus-independent-review" ], "rows": [ { "label": "native complete operation", "value": 3970.8752, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "local warm complete operation, median", "value": 123.1285, "unit": "ms", "role": "local", "n": 3, "statistic": "median of 3 samples" }, { "label": "remote warm complete operation, median", "value": 1039.73885, "unit": "ms", "role": "remote", "n": 2, "statistic": "median of 2 samples" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "implementation" }, { "baseline": 1, "candidate": 2, "kind": "remote-vs-local" } ], "chart": true, "presentation": { "title": "The full intersection operation measured three ways at 16,384 crossings", "question": "To judge the whole operation rather than one call inside it, I timed the complete task end to end, covering lookup, the geometry call, any transfer, marshalling and writing the output, for the native path, a local implementation and a remote worker.", "comparison": "The same geometry and control points through the application's automation interface, with one native sample, three local samples and two remote samples.", "finding": "The native complete operation took 3.97 s, the local implementation 123 ms and the remote worker 1.04 s, so the local path was about 32 times faster than native and the remote about 3.8 times faster.", "lesson": "The gain comes from the implementation rather than from moving the work; placing it on a remote node makes it roughly eight times slower than doing it in process.", "caveat": "One native sample against three local and two remote samples in sequential, unrandomised sessions on synthetic fixed geometry; one of the three local samples was 1.21 s and I have kept it visible, and a student campus demonstration of this work remains a no-go.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "Original implementation", "1": "Local execution (warm)", "2": "Remote execution (warm)" }, "featuredRows": [ 0, 1, 2 ] }, "technical": { "original": { "title": "Matched complete-operation comparison, 16384 crossings", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-campus-nov10-256-api", "title": "The call-boundary comparison at 65,536 crossings", "topic": "AutoCAD", "date": "2026-11-10", "evidence": "Measured", "scope": "The 256-route geometry operation at the call boundary, native against local against remote.", "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).", "statistic": "median of warm samples; native is a single sample", "warmCold": "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": "The same full-array and integer-grid assertions as the complete-operation measurement, and the warm original-order difference stayed within 1.25e-11.", "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." ], "interpretation": "Native took 66 s, the local implementation 227 ms and the remote worker 799 ms, so the three paths are further apart than at the smaller size.", "href": "/research/autocad/", "sourceIds": [ "cad-campus-result-20261110", "cad-campus-remote-transport-20261110" ], "rows": [ { "label": "native geometry call", "value": 66048.9191, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "local warm geometry call, median", "value": 227.0093, "unit": "ms", "role": "local", "n": 3, "statistic": "median of 3 samples" }, { "label": "remote warm geometry call, median", "value": 799.2974, "unit": "ms", "role": "remote", "n": 3, "statistic": "median of 3 samples" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "implementation" }, { "baseline": 1, "candidate": 2, "kind": "remote-vs-local" } ], "chart": true, "presentation": { "title": "The call-boundary comparison at 65,536 crossings", "question": "I repeated the call-only measurement on the larger geometry to check the ordering again where the arithmetic is heavy.", "comparison": "The 256-route geometry operation at the call boundary, native against local against remote.", "finding": "Native took 66 s, the local implementation 227 ms and the remote worker 799 ms, so the three paths are further apart than at the smaller size.", "lesson": "The local implementation carries the workload and the remote placement adds a large fixed cost on top of it.", "caveat": "One native sample against three each, sequential sessions, synthetic fixed geometry, the remote medians include a local forwarding hop, and the student campus demonstration remains a no-go.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "Native geometry call", "1": "Local implementation, median", "2": "Remote execution, median" }, "featuredRows": [ 0, 1, 2 ] }, "technical": { "original": { "title": "Matched geometry-call comparison, 65536 crossings", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-campus-nov10-256-complete", "title": "The same complete-operation comparison at 65,536 crossings", "topic": "AutoCAD", "date": "2026-11-10", "evidence": "Measured", "scope": "Identical 256-route geometry through the same timer, with one native sample and three samples each for the local and remote paths.", "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).", "statistic": "median of warm samples; native is a single sample", "warmCold": "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": "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.", "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." ], "interpretation": "Native took 66.1 s, the local implementation 297 ms and the remote worker 845 ms, so the local path was roughly 220 times faster than native, and the native sample here was slower than the 41.2 s recorded in an earlier session.", "href": "/research/autocad/", "sourceIds": [ "cad-campus-result-20261110", "cad-campus-remote-transport-20261110", "cad-campus-independent-review" ], "rows": [ { "label": "native complete operation", "value": 66117.2571, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "local warm complete operation, median", "value": 297.3346, "unit": "ms", "role": "local", "n": 3, "statistic": "median of 3 samples" }, { "label": "remote warm complete operation, median", "value": 845.1547, "unit": "ms", "role": "remote", "n": 3, "statistic": "median of 3 samples" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "implementation" }, { "baseline": 1, "candidate": 2, "kind": "remote-vs-local" } ], "chart": true, "presentation": { "title": "The same complete-operation comparison at 65,536 crossings", "question": "I repeated the complete-operation measurement on the larger geometry to see whether the ordering of the three paths held as the work grew.", "comparison": "Identical 256-route geometry through the same timer, with one native sample and three samples each for the local and remote paths.", "finding": "Native took 66.1 s, the local implementation 297 ms and the remote worker 845 ms, so the local path was roughly 220 times faster than native, and the native sample here was slower than the 41.2 s recorded in an earlier session.", "lesson": "The gap widens with size and still comes from the algorithm and implementation, and the movement in the native figure between sessions is itself a warning.", "caveat": "One native sample against three each for the other paths, sequential sessions, synthetic fixed geometry, local samples spanning 191 to 322 ms, and the student campus demonstration remains a no-go.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "Original implementation", "1": "Local execution (warm)", "2": "Remote execution (warm)" }, "featuredRows": [ 0, 1, 2 ] }, "technical": { "original": { "title": "Matched complete-operation comparison, 65536 crossings", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-campus-nov10-cold-qualification", "title": "What the first use of a drawing costs in each mode", "topic": "AutoCAD", "date": "2026-11-10", "evidence": "Measured", "scope": "Four first-use complete operations, local and remote at each of the two geometry sizes.", "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.", "statistic": "single sample per case", "warmCold": "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": "Every cold case produced the complete array with the native output and status preserved, with a maximum original-order difference of 0.", "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." ], "interpretation": "First use cost 3.44 s locally against 4.94 s remotely at 16,384 crossings, and 57.6 s locally against 63.2 s remotely at 65,536 crossings.", "href": "/research/autocad/", "sourceIds": [ "cad-campus-result-20261110", "cad-campus-local-cold128-20261110", "cad-intersection-live-nov10" ], "rows": [ { "label": "local cold complete operation, 16384 crossings", "value": 3437.6661, "unit": "ms", "role": "local", "n": 1, "statistic": "single sample" }, { "label": "remote cold complete operation, 16384 crossings", "value": 4938.6445, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "local cold complete operation, 65536 crossings", "value": 57597.9075, "unit": "ms", "role": "local", "n": 1, "statistic": "single sample" }, { "label": "remote cold complete operation, 65536 crossings", "value": 63164.2667, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "remote-vs-local" }, { "baseline": 2, "candidate": 3, "kind": "remote-vs-local" } ], "chart": true, "presentation": { "title": "What the first use of a drawing costs in each mode", "question": "Since the steady state looked good, I went back to the part a user notices first: the very first operation on a drawing, in both the local and the remote mode.", "comparison": "Four first-use complete operations, local and remote at each of the two geometry sizes.", "finding": "First use cost 3.44 s locally against 4.94 s remotely at 16,384 crossings, and 57.6 s locally against 63.2 s remotely at 65,536 crossings.", "lesson": "The first use of an unseen drawing is still about a minute at the larger size in either mode, and that is what keeps this work from being ready for students.", "caveat": "One sample per case, the native figures move between sessions so the gap between the local and remote first-use numbers is not a controlled result, the application blocks with no cancellation available, and the student campus demonstration remains a no-go.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "Local implementation, 16384 crossings", "1": "Remote execution, 16384 crossings", "2": "Local implementation, 65536 crossings", "3": "Remote execution, 65536 crossings" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "First-use cost of a geometry snapshot in local and remote modes", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-intersection-live-nov10-cold-qualification", "title": "The first time the application meets a drawing it must compute it itself", "topic": "AutoCAD", "date": "2026-11-10", "evidence": "Measured", "scope": "Four first-use operations on the 128- and 256-route geometry sets, plus a shifted-operand and a reversed-operand case, timed at the API boundary and across the export.", "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.", "statistic": "single sample per case", "warmCold": "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": "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.", "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." ], "interpretation": "Each first use ran natively before any remote answer could be accepted: 9.61 s at the API for 16,384 crossings and 73.3 s for 65,536, with full exports of 13.0 s and 153.0 s.", "href": "/research/autocad/", "sourceIds": [ "cad-intersection-live-nov10", "cad-intersection-live-seal-nov10" ], "rows": [ { "label": "API time, 16384-crossing first qualification", "value": 9610, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "full export time, 16384-crossing first qualification", "value": 13016, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "API time, 65536-crossing first qualification", "value": 73265, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "full export time, 65536-crossing first qualification", "value": 153047, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "API time, translated-operand first qualification", "value": 5672, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "full export time, translated-operand first qualification", "value": 8156, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "API time, reversed-operand case requalified natively", "value": 8703, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "full export time, reversed-operand case requalified natively", "value": 11234, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" } ], "comparisons": [], "chart": false, "presentation": { "title": "The first time the application meets a drawing it must compute it itself", "question": "I had to understand what a user actually waits for the first time they touch a drawing, because that turned out to matter more than the steady state.", "comparison": "Four first-use operations on the 128- and 256-route geometry sets, plus a shifted-operand and a reversed-operand case, timed at the API boundary and across the export.", "finding": "Each first use ran natively before any remote answer could be accepted: 9.61 s at the API for 16,384 crossings and 73.3 s for 65,536, with full exports of 13.0 s and 153.0 s.", "lesson": "The first operation on a drawing is still the application's own work, and that is the dominant usability problem rather than the remote return.", "caveat": "One sample per case, and the reversed-operand case ran natively without ever producing a remote answer in that run; the application blocks while this happens and cancellation is not supported.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "API time, 16384 crossings, first use", "1": "Full export, 16384 crossings, first use", "2": "API time, 65536 crossings, first use", "3": "Full export, 65536 crossings, first use", "4": "API time, shifted operands, first use", "5": "Full export, shifted operands, first use", "6": "API time, reversed operands, first use", "7": "Full export, reversed operands, first use" }, "featuredRows": [ 0, 2, 4, 6 ] }, "technical": { "original": { "title": "Live intersection consumption: native qualification of a first-seen snapshot", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-intersection-live-nov10-fallback-native", "title": "When the remote exchange fails, AutoCAD still answers", "topic": "AutoCAD", "date": "2026-11-10", "evidence": "Validation", "scope": "One deliberately stopped worker and two unexplained client-side failures, each timed at the API boundary and across the full export.", "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.", "statistic": "single sample per case", "warmCold": "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": "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.", "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." ], "interpretation": "All three returned the correct native array and status with no cached remote result substituted, at 15.2 s, 14.8 s and 64.1 s of API time.", "href": "/research/autocad/", "sourceIds": [ "cad-intersection-live-nov10", "cad-intersection-live-seal-nov10" ], "rows": [ { "label": "API time, stopped-worker fallback, 65536 crossings", "value": 64110, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "full export time, stopped-worker fallback", "value": 125281, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "API time, failed exchange, 16384 crossings", "value": 15156, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "full export time, failed exchange, 16384 crossings", "value": 18219, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "API time, failed exchange, reversed operands", "value": 14844, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "full export time, failed exchange, reversed operands", "value": 17422, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" } ], "comparisons": [], "chart": false, "presentation": { "title": "When the remote exchange fails, AutoCAD still answers", "question": "I wanted the failure path on the record rather than averaged away, so I recorded three cases where the exchange broke and the application had to do the work itself.", "comparison": "One deliberately stopped worker and two unexplained client-side failures, each timed at the API boundary and across the full export.", "finding": "All three returned the correct native array and status with no cached remote result substituted, at 15.2 s, 14.8 s and 64.1 s of API time.", "lesson": "The fallback is safe but expensive, and two of the three failures still have no established cause, which is the main reliability gap I have not closed.", "caveat": "One sample per case, and the recorded evidence cannot distinguish a network read failure from a validation failure from an overall deadline; the timings include the native work that followed.", "kind": "Functional check", "area": "AutoCAD", "labels": { "0": "API time, stopped worker, 65536 crossings", "1": "Full export, stopped worker", "2": "API time, failed exchange, 16384 crossings", "3": "Full export, failed exchange, 16384 crossings", "4": "API time, failed exchange, reversed operands", "5": "Full export, failed exchange, reversed operands" }, "featuredRows": [ 0, 2, 4 ] }, "technical": { "original": { "title": "Live intersection consumption: native fallback when the exchange fails", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-intersection-live-nov10-warm-128", "title": "AutoCAD consuming a remotely computed intersection array", "topic": "AutoCAD", "date": "2026-11-10", "evidence": "Measured", "scope": "Three live returns on the 16,384-crossing route geometry, including one with both operands shifted by a unit and a repeat of that case, timed at the API boundary and again across the full export.", "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.", "statistic": "single sample per case", "warmCold": "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": "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.", "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." ], "interpretation": "The application consumed the remote arrays with no native call, the largest difference against the native enumeration being 1.8e-12, while the API call took 672 to 2.06 s and the export 2,016 to 3.28 s.", "href": "/research/autocad/", "sourceIds": [ "cad-intersection-live-nov10", "cad-intersection-live-seal-nov10", "cad-intersection-host-build-r5" ], "rows": [ { "label": "API time, warm return", "value": 2063, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "full export time, warm return", "value": 2938, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "API time, translated-operand warm return", "value": 672, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "full export time, translated-operand warm return", "value": 2016, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "API time, repeated warm return", "value": 2000, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "full export time, repeated warm return", "value": 3281, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" } ], "comparisons": [], "chart": false, "presentation": { "title": "AutoCAD consuming a remotely computed intersection array", "question": "The real question was whether the application would accept a whole intersection result computed elsewhere and use it, so I let the remote worker answer the application's own geometry call.", "comparison": "Three live returns on the 16,384-crossing route geometry, including one with both operands shifted by a unit and a repeat of that case, timed at the API boundary and again across the full export.", "finding": "The application consumed the remote arrays with no native call, the largest difference against the native enumeration being 1.8e-12, while the API call took 672 to 2.06 s and the export 2,016 to 3.28 s.", "lesson": "Correctness here is strong, checked against an independent exact integer grid; the open problems are latency and the cost of writing the result out.", "caveat": "One sample per case, synthetic route geometry, and the path exercised was the automation interface of the geometry operation rather than an ordinary interactive command; the native figures come from a different session.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "API time, warm return", "1": "Full export, warm return", "2": "API time, shifted operands", "3": "Full export, shifted operands", "4": "API time, repeated return", "5": "Full export, repeated return" }, "featuredRows": [ 0, 2, 4 ] }, "technical": { "original": { "title": "Live intersection consumption, warm 16384-crossing returns", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-intersection-live-nov10-warm-256", "title": "The same remote acceptance at 65,536 crossings, including a recovery", "topic": "AutoCAD", "date": "2026-11-10", "evidence": "Measured", "scope": "Two live returns on the 256-route geometry, one normal and one taken after the remote worker had been stopped and restored.", "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.", "statistic": "single sample per case", "warmCold": "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": "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.", "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." ], "interpretation": "Both returns matched the native enumeration to within 7.3e-12 with no native call, and the second worked immediately after the worker was restored, though the export cost rose to 28.6 s and 32.5 s.", "href": "/research/autocad/", "sourceIds": [ "cad-intersection-live-nov10", "cad-intersection-live-seal-nov10" ], "rows": [ { "label": "API time, warm return", "value": 2266, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "full export time, warm return", "value": 28625, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "API time, return after worker recovery", "value": 1469, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "full export time, return after worker recovery", "value": 32484, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" } ], "comparisons": [], "chart": false, "presentation": { "title": "The same remote acceptance at 65,536 crossings, including a recovery", "question": "I wanted to check that a remote answer still worked when the result was large, and that the path came back after the worker was stopped, so I ran the bigger geometry twice.", "comparison": "Two live returns on the 256-route geometry, one normal and one taken after the remote worker had been stopped and restored.", "finding": "Both returns matched the native enumeration to within 7.3e-12 with no native call, and the second worked immediately after the worker was restored, though the export cost rose to 28.6 s and 32.5 s.", "lesson": "Large results are accepted as cleanly as small ones, and what remains expensive is transport and formatting the output rather than the intersection itself.", "caveat": "One sample per case, synthetic geometry, the automation interface rather than an interactive command, and the native comparison came from a separate session.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "API time, warm return", "1": "Full export, warm return", "2": "API time, after worker recovery", "3": "Full export, after worker recovery" }, "featuredRows": [ 0, 2 ] }, "technical": { "original": { "title": "Live intersection consumption, warm 65536-crossing returns and worker recovery", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-intersection-native-baseline-r1", "title": "What AutoCAD alone costs for the same intersections", "topic": "AutoCAD", "date": "2026-11-10", "evidence": "Measured", "scope": "Native only, at 16,384 and at 65,536 crossings, with the API call, the full export and the overall wall time measured apart from one another.", "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.", "statistic": "single run per size", "warmCold": "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": "The captured arrays were the reference against which the later remote results were compared within the 1.25e-11 budget.", "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." ], "interpretation": "At 16,384 crossings the API call took 2.95 s and the full export 4.55 s; at 65,536 crossings the API call took 41.2 s and the export 90.7 s.", "href": "/research/autocad/", "sourceIds": [ "cad-intersection-native-baseline-128", "cad-intersection-native-baseline-256", "cad-intersection-live-nov10" ], "rows": [ { "label": "native API time, 16384 crossings", "value": 2953, "unit": "ms", "role": "native", "n": 1, "statistic": "single run" }, { "label": "native full export, 16384 crossings", "value": 4546, "unit": "ms", "role": "native", "n": 1, "statistic": "single run" }, { "label": "native send-and-idle wall, 16384 crossings", "value": 4596.5722, "unit": "ms", "role": "native", "n": 1, "statistic": "single run" }, { "label": "native API time, 65536 crossings", "value": 41219, "unit": "ms", "role": "native", "n": 1, "statistic": "single run" }, { "label": "native full export, 65536 crossings", "value": 90703, "unit": "ms", "role": "native", "n": 1, "statistic": "single run" }, { "label": "native send-and-idle wall, 65536 crossings", "value": 90743.6336, "unit": "ms", "role": "native", "n": 1, "statistic": "single run" } ], "comparisons": [], "chart": false, "presentation": { "title": "What AutoCAD alone costs for the same intersections", "question": "I needed a native figure to read the remote path against, so I ran the application's own intersection operation separately and recorded its internal timing and its export timing.", "comparison": "Native only, at 16,384 and at 65,536 crossings, with the API call, the full export and the overall wall time measured apart from one another.", "finding": "At 16,384 crossings the API call took 2.95 s and the full export 4.55 s; at 65,536 crossings the API call took 41.2 s and the export 90.7 s.", "lesson": "The native cost is large and it moves between sessions on the same machine, so any speed statement has to name which native figure it is being read against.", "caveat": "A single run per size, reported in coarse millisecond steps, taken in a different session from the live remote run so the two are not a matched pair; the same 65,536-crossing native call later recorded 66 s.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "Native API time, 16384 crossings", "1": "Native full export, 16384 crossings", "2": "Native wall time, 16384 crossings", "3": "Native API time, 65536 crossings", "4": "Native full export, 65536 crossings", "5": "Native wall time, 65536 crossings" }, "featuredRows": [ 0, 3 ] }, "technical": { "original": { "title": "Native intersection baseline captured in a separate session", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-student-installer-readiness", "title": "What is and is not ready for a student release", "topic": "AutoCAD", "date": "2026-11-10", "evidence": "Validation", "scope": "The four conditions, a verified student install, a clean install on a second Windows machine, representative student drawings and a working portal link into the geometry path, against what actually exists.", "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.", "statistic": "count of qualified conditions", "warmCold": "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": "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.", "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." ], "interpretation": "None of the four is satisfied: zero student installs, zero verified second machines, zero qualified student drawing workloads, and the existing installer packages the control application and a numeric library but not the geometry component, so loading it stays a manual step.", "href": "/research/autocad/", "sourceIds": [ "cad-install-auth-recon", "cad-campus-independent-review", "cad-pilot-install-013", "cad-pilot-reconnect-013" ], "rows": [ { "label": "readiness conditions qualified", "value": 0, "unit": "cases", "role": "metric", "n": 1, "statistic": "count of qualified conditions" }, { "label": "student installations verified", "value": 0, "unit": "cases", "role": "metric", "n": 1, "statistic": "count of installations" }, { "label": "second Windows machines with a verified clean install", "value": 0, "unit": "cases", "role": "metric", "n": 1, "statistic": "count of machines" }, { "label": "representative student drawing workloads qualified", "value": 0, "unit": "cases", "role": "metric", "n": 1, "statistic": "count of workloads" }, { "label": "pilot desktop control-plane install and reconnect receipts", "value": 2, "unit": "cases", "role": "metric", "n": 1, "statistic": "count of receipts" } ], "comparisons": [], "chart": false, "presentation": { "title": "What is and is not ready for a student release", "question": "I wanted to state honestly how close this work is to being usable on a student's own machine, so I checked the four conditions that have to hold first.", "comparison": "The four conditions, a verified student install, a clean install on a second Windows machine, representative student drawings and a working portal link into the geometry path, against what actually exists.", "finding": "None of the four is satisfied: zero student installs, zero verified second machines, zero qualified student drawing workloads, and the existing installer packages the control application and a numeric library but not the geometry component, so loading it stays a manual step.", "lesson": "The account and control half of the journey works and is signed in on one machine; the geometry half has no installer, no automatic loading and no representative student data, and calling this a student capability would misdescribe it.", "caveat": "The pilot application installs, launches and reconnects and keeps its encrypted credentials across an upgrade, but no second Windows machine or campus device access was established, and the campus demonstration verdict stays negative.", "kind": "Functional check", "area": "AutoCAD", "labels": { "0": "Readiness conditions met", "1": "Student installs verified", "2": "Second machines with a clean install", "3": "Student drawing workloads qualified", "4": "Control-plane install and reconnect records" }, "featuredRows": [ 0, 1, 2, 3 ] }, "technical": { "original": { "title": "Student installation and deployment readiness status", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-intersection-bridge-compressed-r2-128", "title": "Compressing the intersection reply and repeating the whole test", "topic": "AutoCAD", "date": "2026-11-08", "evidence": "Measured", "scope": "I ran the 16,384-crossing case again as a separate second run with a compressed response frame, three repeats locally and three remotely.", "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.", "statistic": "median of 3 repeats", "warmCold": "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": "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.", "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." ], "interpretation": "The remote bridge fell from 3.19 s to 857 ms while the decoded payload and the numerical answer stayed identical, and the local bridge moved slightly too, from 7.6 ms to 9.4 ms.", "href": "/research/autocad/", "sourceIds": [ "cad-bridge-benchmark-compressed-r2", "cad-bridge-progress-compressed-r2" ], "rows": [ { "label": "equivalent local rust bridge, median wall", "value": 9.4044, "unit": "ms", "role": "local", "n": 3, "statistic": "median of 3 samples" }, { "label": "remote bridge over encrypted tunnel, median wall", "value": 856.7324, "unit": "ms", "role": "remote", "n": 3, "statistic": "median of 3 samples" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "remote-vs-local" } ], "chart": true, "presentation": { "title": "Compressing the intersection reply and repeating the whole test", "question": "The first remote runs sent the entire answer as plain bytes, so I asked whether a lossless compressed reply would cut enough of the transfer to change the result.", "comparison": "I ran the 16,384-crossing case again as a separate second run with a compressed response frame, three repeats locally and three remotely.", "finding": "The remote bridge fell from 3.19 s to 857 ms while the decoded payload and the numerical answer stayed identical, and the local bridge moved slightly too, from 7.6 ms to 9.4 ms.", "lesson": "Compression helps a great deal on the wire, but the effect is entangled with ordinary run-to-run variation, so I do not present it as a clean isolated saving.", "caveat": "This is a separate run from the uncompressed one and the two must stay separate, the measurement is bridge wall time only with no application running, and there were three repeats per placement.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "Local execution, median", "1": "Remote execution, median" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "Captured-array intersection bridge, lossless-compressed run r2, 16384 crossings", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-intersection-bridge-compressed-r2-256", "title": "The compressed reply at the larger crossing count", "topic": "AutoCAD", "date": "2026-11-08", "evidence": "Measured", "scope": "The 256-route case with the compressed reply, three repeats in the local bridge and three through the encrypted tunnel.", "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.", "statistic": "median of 3 repeats", "warmCold": "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": "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.", "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." ], "interpretation": "Local took 34.7 ms and remote 1.24 s, still roughly 36 times slower, while the compressed frame carried 55,545 bytes instead of a 1,048,611-byte payload.", "href": "/research/autocad/", "sourceIds": [ "cad-bridge-benchmark-compressed-r2", "cad-bridge-progress-compressed-r2" ], "rows": [ { "label": "equivalent local rust bridge, median wall", "value": 34.7191, "unit": "ms", "role": "local", "n": 3, "statistic": "median of 3 samples" }, { "label": "remote bridge over encrypted tunnel, median wall", "value": 1243.5812, "unit": "ms", "role": "remote", "n": 3, "statistic": "median of 3 samples" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "remote-vs-local" } ], "chart": true, "presentation": { "title": "The compressed reply at the larger crossing count", "question": "I wanted to know whether the compressed path still beat the uncompressed one once the answer grew to 65,536 points.", "comparison": "The 256-route case with the compressed reply, three repeats in the local bridge and three through the encrypted tunnel.", "finding": "Local took 34.7 ms and remote 1.24 s, still roughly 36 times slower, while the compressed frame carried 55,545 bytes instead of a 1,048,611-byte payload.", "lesson": "Compression narrows the remote path considerably but cannot close a gap this large, because what remains is transfer and turn-around rather than arithmetic.", "caveat": "Bridge wall time only with no application consuming the result, a separate second run from the uncompressed measurement, synthetic geometry and three repeats per placement.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "Local execution, median", "1": "Remote execution, median" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "Captured-array intersection bridge, lossless-compressed run r2, 65536 crossings", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-intersection-bridge-failure-handling", "title": "What the bridge does when the answer cannot be trusted", "topic": "AutoCAD", "date": "2026-11-08", "evidence": "Validation", "scope": "I injected a wrong response identity, a missing point, a wrong point, a truncated reply, an oversized frame, an oversized expansion, a deadline overrun and a disconnected transport, plus one good control, and then stopped the remote worker outright.", "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.", "statistic": "single run per case", "warmCold": "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": "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.", "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." ], "interpretation": "Every damaged case returned a refusal between 1.3 ms and 116 ms with the caller's output buffer untouched, and the stopped worker produced a refusal after 311 ms rather than a fabricated or cached answer.", "href": "/research/autocad/", "sourceIds": [ "cad-intersection-faults-compressed-r2", "cad-intersection-disconnect-compressed-r2" ], "rows": [ { "label": "injected: well-formed positive control", "value": 4.3912, "unit": "ms", "role": "metric", "n": 1, "statistic": "single run" }, { "label": "injected: wrong response identity", "value": 1.7716, "unit": "ms", "role": "metric", "n": 1, "statistic": "single run" }, { "label": "injected: missing point", "value": 4.6635, "unit": "ms", "role": "metric", "n": 1, "statistic": "single run" }, { "label": "injected: wrong point", "value": 4.7661, "unit": "ms", "role": "metric", "n": 1, "statistic": "single run" }, { "label": "injected: truncated response", "value": 2.6091, "unit": "ms", "role": "metric", "n": 1, "statistic": "single run" }, { "label": "injected: oversized frame", "value": 1.4088, "unit": "ms", "role": "metric", "n": 1, "statistic": "single run" }, { "label": "injected: oversized expansion", "value": 1.4524, "unit": "ms", "role": "metric", "n": 1, "statistic": "single run" }, { "label": "injected: absolute deadline", "value": 116.2836, "unit": "ms", "role": "metric", "n": 1, "statistic": "single run" }, { "label": "injected: disconnected transport", "value": 1.2906, "unit": "ms", "role": "metric", "n": 1, "statistic": "single run" }, { "label": "stopped remote worker, real disconnect", "value": 310.8613, "unit": "ms", "role": "metric", "n": 1, "statistic": "single run" } ], "comparisons": [], "chart": false, "presentation": { "title": "What the bridge does when the answer cannot be trusted", "question": "A fast path is worthless if a damaged reply can be published, so I deliberately broke the response in nine different ways and checked that the bridge refuses to hand anything back.", "comparison": "I injected a wrong response identity, a missing point, a wrong point, a truncated reply, an oversized frame, an oversized expansion, a deadline overrun and a disconnected transport, plus one good control, and then stopped the remote worker outright.", "finding": "Every damaged case returned a refusal between 1.3 ms and 116 ms with the caller's output buffer untouched, and the stopped worker produced a refusal after 311 ms rather than a fabricated or cached answer.", "lesson": "Failing closed quickly is the property that lets a native fallback be trusted, so I measured it instead of assuming it.", "caveat": "This exercises the bridge boundary alone with no application running, one run per case, so it says nothing about how often real drawings would be refused; the deadline case is the bridge's own timer rather than an application-level cancellation guarantee.", "kind": "Functional check", "area": "AutoCAD" }, "technical": { "original": { "title": "Bridge fail-closed behaviour: nine injected fault cases and a stopped remote worker", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-intersection-bridge-uncompressed-r1-128", "title": "Sending captured intersection arrays to a remote worker", "topic": "AutoCAD", "date": "2026-11-08", "evidence": "Measured", "scope": "I sent 128 route pairs producing 16,384 crossings through the local bridge and again over an encrypted tunnel to the remote node, three repeats each, with the plain uncompressed reply.", "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.", "statistic": "median of 3 repeats", "warmCold": "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": "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.", "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." ], "interpretation": "The local bridge took a median of 7.57 ms and the remote bridge 3.19 s, about 420 times longer, even though the worker itself only spent 5.5 ms computing.", "href": "/research/autocad/", "sourceIds": [ "cad-bridge-benchmark-uncompressed-r1", "cad-bridge-progress-compressed-r2" ], "rows": [ { "label": "equivalent local rust bridge, median wall", "value": 7.5732, "unit": "ms", "role": "local", "n": 3, "statistic": "median of 3 samples" }, { "label": "remote bridge over encrypted tunnel, median wall", "value": 3193.4464, "unit": "ms", "role": "remote", "n": 3, "statistic": "median of 3 samples" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "remote-vs-local" } ], "chart": true, "presentation": { "title": "Sending captured intersection arrays to a remote worker", "question": "I wanted to know whether pushing geometry out to a remote CPU node could ever beat computing it on the machine that already holds the drawing, so I captured arrays from AutoCAD and ran the same intersection routine in two places.", "comparison": "I sent 128 route pairs producing 16,384 crossings through the local bridge and again over an encrypted tunnel to the remote node, three repeats each, with the plain uncompressed reply.", "finding": "The local bridge took a median of 7.57 ms and the remote bridge 3.19 s, about 420 times longer, even though the worker itself only spent 5.5 ms computing.", "lesson": "Most of the remote delay was outside the worker’s arithmetic. Sending the same routine elsewhere did not help this workload.", "caveat": "This is bridge wall time only, with no application running to consume the answer, on synthetic geometry, with three repeats per placement and no recorded processor model.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "Local execution, median", "1": "Remote execution, median" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "Captured-array intersection bridge, uncompressed run r1, 16384 crossings", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "cad-intersection-bridge-uncompressed-r1-256", "title": "The same uncompressed bridge test at four times the crossings", "topic": "AutoCAD", "date": "2026-11-08", "evidence": "Measured", "scope": "Two hundred and fifty-six route pairs produced 65,536 crossings, sent through the local bridge and over the encrypted tunnel, three repeats each.", "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; 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 32.0563, 29.8997 and 29.6041 ms. Remote bridge wall 6785.4213, 3291.7662 and 4851.7924 ms.", "statistic": "median of 3 repeats", "warmCold": "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 20.254 ms. Local placement ran the same worker code in process.", "serialization": "Uncompressed run: request 16418 bytes and response 1048611 bytes, with an identical response digest across all six repeats of both placements.", "correctness": "Maximum per-point difference against the captured native array was 7.30437932361383e-12 against a 1.25e-11 comparison budget. The response digest was identical for the local and the remote placement.", "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.", "The native API cost of the same fixture was captured separately and is not a matched pair with this run." ], "interpretation": "Local stayed ahead at 29.9 ms against 4.85 s on the remote path, and the gap widened rather than narrowed.", "href": "/research/autocad/", "sourceIds": [ "cad-bridge-benchmark-uncompressed-r1", "cad-bridge-progress-compressed-r2" ], "rows": [ { "label": "equivalent local rust bridge, median wall", "value": 29.8997, "unit": "ms", "role": "local", "n": 3, "statistic": "median of 3 samples" }, { "label": "remote bridge over encrypted tunnel, median wall", "value": 4851.7924, "unit": "ms", "role": "remote", "n": 3, "statistic": "median of 3 samples" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "remote-vs-local" } ], "chart": true, "presentation": { "title": "The same uncompressed bridge test at four times the crossings", "question": "I repeated the uncompressed captured-array test on the larger geometry set to see whether the ordering of local and remote would survive a fourfold increase in work.", "comparison": "Two hundred and fifty-six route pairs produced 65,536 crossings, sent through the local bridge and over the encrypted tunnel, three repeats each.", "finding": "Local stayed ahead at 29.9 ms against 4.85 s on the remote path, and the gap widened rather than narrowed.", "lesson": "Increasing the work did not change which path was faster. Local execution remained the useful baseline.", "caveat": "Bridge wall time only with no application consuming the result, synthetic integer geometry, three repeats per placement, and the native cost of the same geometry was recorded in a different session.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "Local execution, median", "1": "Remote execution, median" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "Captured-array intersection bridge, uncompressed run r1, 65536 crossings", "scope": "The larger captured-array case of the same uncompressed bridge run. Bridge wall time only; excludes host capture, native qualification and result installation.", "interpretation": "At the larger size the remote path remains far behind the equivalent local computation, and the application's own native call for the same fixture was recorded separately as 40531 ms. Scaling the workload did not change the ordering of the three paths." } }, "chartSeries": [] }, { "id": "cad-intersection-wire-compression", "title": "How many bytes the intersection answer actually takes", "topic": "AutoCAD", "date": "2026-11-08", "evidence": "Measured", "scope": "I compared the request frame, the compressed response frame and the uncompressed payload for 16,384 crossings and for 65,536 crossings.", "hardware": "Windows workstation (CPU model not recorded); remote CPU node with 8 cores and 31331228 KiB available memory running Ubuntu 26.04.1.", "software": "Rust release build of the intersection bridge with and without the compressed response codec.", "input": "Captured AutoCAD intersection arrays for 16384 and 65536 crossings.", "samples": "Two fixture sizes, one encoding measurement each; the compressed encoding was measured again in a separate second run and produced the same frame digests.", "statistic": "single measurement per value", "warmCold": "Not applicable; byte counts do not depend on warm or cold state.", "network": "Remote placement over the encrypted tunnel. Frame counts are application frames and exclude transport, tunnel and handshake overhead.", "serialization": "Lossless compressed response encoding with a recorded frame digest for each size and an unchanged decoded payload.", "correctness": "The decoded payload was 262169 bytes for 16384 crossings and 1048601 bytes for 65536 crossings, matching the uncompressed payload sizes, and the frame digests were identical between the two runs.", "limitations": [ "Byte counts only; no timing is implied by this measurement.", "Application frames only; transport, tunnel and handshake overhead are excluded.", "No compression ratio is asserted here; only the measured byte counts are recorded.", "Measured on one transport implementation only." ], "interpretation": "At 16,384 crossings a 262,179-byte payload became a 24,555-byte frame, and at 65,536 crossings a 1,048,611-byte payload became 55,545 bytes, with the decoded contents unchanged in both cases.", "href": "/research/autocad/", "sourceIds": [ "cad-bridge-benchmark-compressed-r2", "cad-intersection-faults-compressed-r2" ], "rows": [ { "label": "request frame, 16384 crossings", "value": 8226, "unit": "bytes", "role": "metric", "n": 1, "statistic": "single measurement" }, { "label": "compressed response frame, 16384 crossings", "value": 24555, "unit": "bytes", "role": "metric", "n": 1, "statistic": "single measurement" }, { "label": "uncompressed response payload, 16384 crossings", "value": 262179, "unit": "bytes", "role": "metric", "n": 1, "statistic": "single measurement" }, { "label": "request frame, 65536 crossings", "value": 16418, "unit": "bytes", "role": "metric", "n": 1, "statistic": "single measurement" }, { "label": "compressed response frame, 65536 crossings", "value": 55545, "unit": "bytes", "role": "metric", "n": 1, "statistic": "single measurement" }, { "label": "uncompressed response payload, 65536 crossings", "value": 1048611, "unit": "bytes", "role": "metric", "n": 1, "statistic": "single measurement" } ], "comparisons": [ { "baseline": 2, "candidate": 1, "kind": "compression" }, { "baseline": 5, "candidate": 4, "kind": "compression" } ], "chart": true, "presentation": { "title": "How many bytes the intersection answer actually takes", "question": "Before I could reason about transfer cost I needed the raw byte counts, so I measured request and response sizes for both crossing counts with and without lossless compression.", "comparison": "I compared the request frame, the compressed response frame and the uncompressed payload for 16,384 crossings and for 65,536 crossings.", "finding": "At 16,384 crossings a 262,179-byte payload became a 24,555-byte frame, and at 65,536 crossings a 1,048,611-byte payload became 55,545 bytes, with the decoded contents unchanged in both cases.", "lesson": "Compression changes the size of what travels without changing what it means, which is why I keep the compressed and uncompressed runs apart rather than averaging them together.", "caveat": "These are byte counts with no timing attached, measured on a single transport, and I make no compression-ratio claim beyond the numbers themselves.", "kind": "Performance", "area": "AutoCAD", "labels": { "0": "Request frame, 16384 crossings", "1": "Compressed response, 16384 crossings", "2": "Uncompressed response, 16384 crossings", "3": "Request frame, 65536 crossings", "4": "Compressed response, 65536 crossings", "5": "Uncompressed response, 65536 crossings" }, "featuredRows": [ 2, 1 ] }, "technical": { "original": { "title": "Intersection wire-frame sizes with and without lossless compression", "scope": "Request and response byte counts on the same intersection bridge transport for the two fixture sizes, measured with and without the lossless compressed response encoding. A size measurement only; it contains no timing.", "interpretation": "Compression changes the size of the transported result while leaving the decoded payload unchanged. This is why the compressed and uncompressed bridge runs are retained as separate experiments rather than merged into one figure." } }, "chartSeries": [] }, { "id": "cad-length-crossdrawing-r1", "title": "Reading remote curve lengths on three different drawings", "topic": "AutoCAD", "date": "2026-11-08", "evidence": "Measured", "scope": "Six live returns across the three drawings, with the analytic reference and the native check recorded alongside each one.", "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; Rust release build of the curve primitive and its bridge.", "input": "Three independently generated pinned drawings with unit-weight degree-1 geometry. Original lengths 7, 14 and 21; three-dimensional edited lengths 10.211102550927979, 16 and 22.416407864998739.", "samples": "6 live remote returns, one per geometry state, plus a separate native qualification command for each of the six.", "statistic": "single sample per return", "warmCold": "Warm for the six returns; each exact geometry was qualified on a separate command first.", "network": "Encrypted tunnel to the CPU node. Every successful return was a fresh worker request, not a cached result substitution; 17 worker requests were verified against worker identifiers and timings.", "serialization": "Application frames 194 bytes for the request and 51 bytes for the successful reply.", "correctness": "All six returns made zero intercepted native calls and matched the analytic reference at the unchanged 1e-10 tolerance with a 1.25e-11 comparison budget. Weighted and curved cases on the third drawing stayed native on measured disagreement.", "limitations": [ "Single sample per return.", "Median successful hook time was 569.81405 ms against native calibration in the microsecond range, so this is not acceleration.", "Terminal lockout: an identical copy at an unpinned path stays native and interception does not resume in that process, which is an explicit student-experience limitation.", "No independent review of the larger remote-execution difference was performed.", "Three incompatible cases deliberately stayed native and are recorded separately." ], "interpretation": "All six returns matched the analytic reference with no native length call, including edited geometry that changed the length, though the hook time ranged from about 512 ms to 4.76 s.", "href": "/research/autocad/", "sourceIds": [ "cad-crossdrawing-live-20261108" ], "rows": [ { "label": "remote hook, first drawing original geometry", "value": 566.7866, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote hook, first drawing edited geometry", "value": 2119.9736, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote hook, second drawing original geometry", "value": 511.6534, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote hook, second drawing edited geometry", "value": 572.8415, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote hook, third drawing original geometry", "value": 2168.865, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote hook, third drawing edited geometry", "value": 4759.4218, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" } ], "comparisons": [], "chart": false, "presentation": { "title": "Reading remote curve lengths on three different drawings", "question": "A result that only works on one drawing is not a result, so I repeated the remote length path on three separately created drawings, each with its own geometry.", "comparison": "Six live returns across the three drawings, with the analytic reference and the native check recorded alongside each one.", "finding": "All six returns matched the analytic reference with no native length call, including edited geometry that changed the length, though the hook time ranged from about 512 ms to 4.76 s.", "lesson": "Host acceptance survives across drawings, which is meaningfully stronger than a single-drawing demonstration; the timing still says the transport dominates.", "caveat": "One sample per return, the transport cost is far above the native check, and an identical copy of a drawing placed at a different path stays on the native route with interception not resuming in that session.", "kind": "Functional check", "area": "AutoCAD" }, "technical": { "original": { "title": "Cross-drawing curve lengths consumed remotely, first campaign", "scope": "Six live remote returns across three independently created and pinned drawings, each geometry first qualified against the native implementation on a separate command. Ordinary LIST commands. Demonstrates host acceptance on more than one drawing; it is not a speed comparison and not a student workload.", "interpretation": "The host consumed remote lengths on three different drawings without falling back to native, which is stronger evidence than a single-drawing result. The transport cost still dominates the native compute cost, so the value here is correctness, not speed." } }, "chartSeries": [] }, { "id": "cad-length-crossdrawing-r2-recovery", "title": "Losing the remote worker mid-session and still getting an answer", "topic": "AutoCAD", "date": "2026-11-08", "evidence": "Validation", "scope": "I recorded two native fallbacks while the worker was down and then two remote returns after a fresh worker started, on the same drawing and geometry.", "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; Rust release build of the curve primitive and its bridge.", "input": "The first drawing of the first campaign with the same pinned geometry and length 7.", "samples": "2 live remote returns, 1 native qualification and 2 native fallbacks.", "statistic": "single sample per case", "warmCold": "Warm for the returns after a fresh native qualification in the same process.", "network": "Encrypted tunnel to the CPU node. The worker unit was stopped, then a new capped unit was started and the remote path resumed.", "serialization": "Application frames 194 bytes for the request and 51 bytes for the successful reply.", "correctness": "Both remote returns returned the analytic length 7 with zero intercepted native calls, and both worker-failure cases returned the native value 7 with one native call each and no remote consumption.", "limitations": [ "Single sample per case.", "The case labelled as a reconnection is in fact a second expected native fallback: the stopped transient unit had been collected, so the restart attempt failed and the application fell back natively.", "The fallback path is correct but slower than the remote path it replaces.", "One drawing and one geometry." ], "interpretation": "With the worker gone the application answered with its own length in 271 ms and 272 ms after exactly one native call each, and once a worker was back the remote path resumed at about 555 ms and 561 ms with no native calls.", "href": "/research/autocad/", "sourceIds": [ "cad-crossdrawing-live-20261108" ], "rows": [ { "label": "remote hook, connected return", "value": 554.2698, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote hook, return after worker recovery", "value": 560.6583, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "native hook, worker disconnected fallback", "value": 271.0759, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "native hook, collected unit could not be restarted", "value": 272.33299999999997, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" } ], "comparisons": [], "chart": false, "presentation": { "title": "Losing the remote worker mid-session and still getting an answer", "question": "I wanted to know whether the application survives the remote side disappearing, so I stopped the worker during a session and watched what the user would actually get.", "comparison": "I recorded two native fallbacks while the worker was down and then two remote returns after a fresh worker started, on the same drawing and geometry.", "finding": "With the worker gone the application answered with its own length in 271 ms and 272 ms after exactly one native call each, and once a worker was back the remote path resumed at about 555 ms and 561 ms with no native calls.", "lesson": "The user always gets the right number, and the service can come back without the application changing anything.", "caveat": "One sample per case and one drawing; what the original record calls a reconnection is really a second expected native fallback, because the stopped unit had already been collected and could not be restarted.", "kind": "Functional check", "area": "AutoCAD" }, "technical": { "original": { "title": "Cross-drawing curve lengths with a stopped and restarted remote worker", "scope": "A second campaign in which the remote worker was stopped and a new capped worker was started. One native fallback while the worker was unavailable, a second native fallback when a collected unit could not be restarted, then a fresh remote return with zero native calls after the new worker started. Covers failure and recovery, not throughput.", "interpretation": "When the remote worker disappears the application still returns the correct answer using its own implementation, and once a worker is available again the remote path resumes without the application changing anything. The labels in the original receipt overstate the recovery and must not be quoted as successes." } }, "chartSeries": [] }, { "id": "cad-length-geometry-multisegment", "title": "Three multi-segment curves consumed from the remote worker", "topic": "AutoCAD", "date": "2026-11-08", "evidence": "Measured", "scope": "I measured the remote hook for each curve against the native check the application ran on the same geometry beforehand.", "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; Rust release build of the curve primitive and its bridge.", "input": "Owned multi-segment geometries with true lengths 7, 17 (three-dimensional) and 22; one drawing, two in-memory geometry variants, never saved.", "samples": "3 geometries; remote hook samples 600.1093, 553.8481 and 589.4221 ms, one per geometry.", "statistic": "single sample per geometry", "warmCold": "Warm for the remote returns; each exact snapshot was first qualified against the native implementation on a separate ordinary command.", "network": "Encrypted tunnel to the CPU node; remote worker compute was 8, 4 and 9 microseconds.", "serialization": "Application frames 194 bytes for the request and 51 bytes for the successful reply.", "correctness": "Remote values 7, 17 and 22 matched the analytic reference and the native value at the unchanged 1e-10 tolerance with a 1.25e-11 comparison budget, and four LIST returns made zero intercepted native calls.", "limitations": [ "Single sample per geometry; not a statistically qualified comparison.", "Remote calls took roughly half a second while native calibration took 14.7 to 1146.7 microseconds, so this path is slower than native and is explicitly not an acceleration.", "One owned drawing only; cross-drawing behaviour was measured separately.", "AREA consumed one remote length but still executed a second native length call and computed area locally, so no fully external AREA execution is claimed.", "Native enumeration stability and the general error enclosure of the native approximation are empirical, not proven." ], "interpretation": "All three remote lengths, 7, 17 and 22, matched the analytic reference exactly and the successful commands made no native length call, but each remote hook took roughly half a second against native checks of 15 microseconds to 1.1 ms.", "href": "/research/autocad/", "sourceIds": [ "cad-geometry-multisegment-live" ], "rows": [ { "label": "remote hook, length 7 geometry", "value": 600.1093, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote hook, length 17 geometry", "value": 553.8481, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote hook, length 22 geometry", "value": 589.4221, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "native calibration, length 7 geometry", "value": 1.1467, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "native calibration, length 17 geometry", "value": 0.0147, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "native calibration, length 22 geometry", "value": 0.0178, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" } ], "comparisons": [], "chart": false, "presentation": { "title": "Three multi-segment curves consumed from the remote worker", "question": "I wanted to see whether acceptance holds for geometry that is not a single straight span, so I built three multi-segment curves and let ordinary commands read their lengths.", "comparison": "I measured the remote hook for each curve against the native check the application ran on the same geometry beforehand.", "finding": "All three remote lengths, 7, 17 and 22, matched the analytic reference exactly and the successful commands made no native length call, but each remote hook took roughly half a second against native checks of 15 microseconds to 1.1 ms.", "lesson": "Correctness generalised across the three shapes; speed did not, because the round trip costs thousands of times what the native computation costs.", "caveat": "A single sample per curve, one drawing, and an area command still made a second native length call and computed its result locally, so no fully external area computation is claimed.", "kind": "Functional check", "area": "AutoCAD" }, "technical": { "original": { "title": "Multi-segment curve lengths consumed remotely by the application", "scope": "Three degree-1, unit-weight, non-periodic multi-segment geometries on one owned drawing with two in-memory edits. Remote lengths were consumed by ordinary LIST commands with zero intercepted native calls on the successful returns. Does not cover curved or weighted geometry, other drawings, or a fully external AREA command.", "interpretation": "Remote curve lengths were consumed correctly by the host for a bounded geometry class, but the transport cost dominates the native compute cost by three to four orders of magnitude. The result establishes host acceptance, not usefulness." } }, "chartSeries": [] }, { "id": "cad-length-incompatible-geometry-native", "title": "Curved and weighted curves going back to AutoCAD", "topic": "AutoCAD", "date": "2026-11-08", "evidence": "Validation", "scope": "For each of the six geometry classes I compared the native check against the remote exchange and then looked at which result reached the user.", "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; Rust release build of the curve primitive and its bridge.", "input": "Parabola, cubic with a point, rational arc, joined cubic spans, spatial cubic and a non-unit-weight degree-1 geometry on one owned drawing.", "samples": "6 geometry classes, one qualification attempt each.", "statistic": "single sample per class", "warmCold": "Cold qualification attempts; each was the first encounter with that exact snapshot.", "network": "Encrypted tunnel to the CPU node. The worker answered each case, for example 14 microseconds for the parabola and 41 microseconds for the spatial cubic.", "serialization": "Request frames between 202 and 370 bytes depending on the geometry class; the successful reply frame is 51 bytes.", "correctness": "In every class the remote value disagreed with the native value beyond the allowed budget, the remote result was not published, the native result was returned, and one native call was made. Recorded disagreements include 1.4789428575445975 against 1.478970602513636 for the parabola and 4.0 against 4.000023265118353 for the cubic. No tolerance was widened and no vendor ordering was imitated.", "limitations": [ "Single sample per class.", "Rejection here means the remote value was discarded; it does not measure how often a real drawing would be rejected.", "One owned drawing; a rejection observed here is not a general statement about a geometry class.", "The native calibration and the remote exchange are different measurement boundaries and are not directly comparable with one another." ], "interpretation": "Every remote value disagreed with the native one beyond the allowed tolerance, so none was published: the application kept its own answer and made one native call each time, with no tolerance widened and no vendor ordering copied.", "href": "/research/autocad/", "sourceIds": [ "cad-geometry-multisegment-live" ], "rows": [ { "label": "native calibration, parabola", "value": 0.0586, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "native calibration, cubic with a point", "value": 0.0226, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "native calibration, rational arc", "value": 0.0632, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "native calibration, joined cubic spans", "value": 0.0337, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "native calibration, spatial cubic", "value": 0.047, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "native calibration, non-unit-weight degree 1", "value": 0.0288, "unit": "ms", "role": "native", "n": 1, "statistic": "single sample" }, { "label": "remote exchange, parabola", "value": 522.0557, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote exchange, cubic with a point", "value": 532.2203, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote exchange, rational arc", "value": 516.7703, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote exchange, joined cubic spans", "value": 587.8673, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote exchange, spatial cubic", "value": 595.4548, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" }, { "label": "remote exchange, non-unit-weight degree 1", "value": 540.8037, "unit": "ms", "role": "remote", "n": 1, "statistic": "single sample" } ], "comparisons": [], "chart": false, "presentation": { "title": "Curved and weighted curves going back to AutoCAD", "question": "I had to know what happens with geometry my analytic path cannot vouch for, so I sent six curved and weighted cases to the worker and checked which answer the application actually used.", "comparison": "For each of the six geometry classes I compared the native check against the remote exchange and then looked at which result reached the user.", "finding": "Every remote value disagreed with the native one beyond the allowed tolerance, so none was published: the application kept its own answer and made one native call each time, with no tolerance widened and no vendor ordering copied.", "lesson": "Refusing to publish a number I cannot justify is what makes the external path safe to leave switched on, and it costs a native call whenever it fires.", "caveat": "One attempt per class on one drawing, so a refusal here says nothing about how often a real drawing would be refused, and the native check and the remote exchange are different measurement boundaries.", "kind": "Functional check", "area": "AutoCAD" }, "technical": { "original": { "title": "Curved and weighted curve geometries were rejected and left on the native path", "scope": "Six geometry classes that were captured, sent to the worker and then rejected on measured disagreement with the native value, leaving the application with its own result. This is the conservative fallback behaviour, not a speed comparison.", "interpretation": "The interceptor refuses to publish a value it cannot vouch for and leaves the application with its own answer. This is the safety property that makes the remote path admissible at all, and it costs a native call every time it fires." } }, "chartSeries": [] }, { "id": "cad-length-restricted-r3", "title": "Getting a computed curve length accepted by AutoCAD", "topic": "AutoCAD", "date": "2026-11-08", "evidence": "Measured", "scope": "I compared the worker's own compute time against the full time the intercepted call took inside the application, on a straight spline with an integer control polygon and unit weights.", "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; Rust release build of the curve primitive and its bridge.", "input": "Owned spline handle 36: 32 control points, clamped non-periodic, integer affine control polygon, unit weights, full interval. For this profile the true arc length is the endpoint distance rather than the application's own approximation.", "samples": "One ordinary command, one remote request.", "statistic": "single run", "warmCold": "Cold for this geometry: the exact snapshot was qualified against the native implementation on a separate command before the remote return was accepted.", "network": "Encrypted tunnel to the CPU node; the worker spent 168 microseconds computing.", "serialization": "Application frames 194 bytes for the request and 51 bytes for the successful reply on this primitive.", "correctness": "The remote value 93 was printed by the application as Length: 93.0000, the admitted native length calls on the successful return were zero, and the validated analytic error bound was 1.4210854715202007e-14 against a requested tolerance of 1e-10.", "limitations": [ "One ordinary command on one owned spline; no repeated measurement.", "Restricted profile only: integer affine control polygon, unit weights, full clamped non-periodic interval. Other geometry types are not qualified.", "The intercepted-call wall time includes capture, transfer, wait and validation and is not native compute time.", "Whole-operation latency is not qualified: the recorded wall time includes human pagination inside the command window.", "Not integrated into an installed desktop enrollment, not signed, and not student-release qualified.", "The larger remote-execution difference had no independent review at the time of this run." ], "interpretation": "AutoCAD printed the remote value as Length: 93.0000 and made no native length call on that path, while the worker spent 168 microseconds computing and the intercepted call still took 673 ms.", "href": "/research/autocad/", "sourceIds": [ "cad-length-restricted-r3" ], "rows": [ { "label": "remote worker compute", "value": 0.168, "unit": "ms", "role": "remote", "n": 1, "statistic": "single run" }, { "label": "intercepted call inclusive wall time", "value": 673.1773, "unit": "ms", "role": "remote", "n": 1, "statistic": "single run" } ], "comparisons": [], "chart": false, "presentation": { "title": "Getting a computed curve length accepted by AutoCAD", "question": "The real test of an external geometry path is whether the application will use the answer, so I served one ordinary LIST command's length call from the remote worker and watched what the program did with it.", "comparison": "I compared the worker's own compute time against the full time the intercepted call took inside the application, on a straight spline with an integer control polygon and unit weights.", "finding": "AutoCAD printed the remote value as Length: 93.0000 and made no native length call on that path, while the worker spent 168 microseconds computing and the intercepted call still took 673 ms.", "lesson": "The host accepts externally computed results, which is the part that had to be proven; the round trip is far too slow to be useful on its own.", "caveat": "One command on one spline of mine, so nothing here generalises to other geometry; the timing includes the operator paging through output inside the command window, and the larger remote-execution difference had no independent review at the time.", "kind": "Functional check", "area": "AutoCAD" }, "technical": { "original": { "title": "Restricted analytic curve length replaced inside an ordinary application command", "scope": "One ordinary LIST command on an owned, analytically qualified straight spline. The intercepted length call was served from the remote CPU worker and the returned value was consumed and printed by the application. Demonstrates that a returned result is accepted by the host. It does not demonstrate acceleration, general-curve support or a student result.", "interpretation": "The host accepted a remotely computed value and printed it, with zero native calls on the successful path. The remote worker spent 168 microseconds computing while the intercepted call itself took 673.1773 ms, so the mechanism is a correctness demonstration rather than a useful acceleration for this workload." } }, "chartSeries": [] }, { "id": "cad-native-operation-profile", "title": "What an engineering operation costs inside AutoCAD itself", "topic": "AutoCAD", "date": "2026-11-08", "evidence": "Measured", "scope": "I ran route intersections, spatial stationing, a perforated plate and a dense regeneration through the application's own API, three repeats each, and kept the median.", "hardware": "Windows workstation: CPU model, memory and operating-system build not recorded. Remote CPU node used elsewhere in this dataset: 8 cores, 31331228 KiB available memory, 209 GB free disk, Ubuntu 26.04.1.", "software": "AutoCAD 2021 R24.0.47.0.0 (R24.0 branch).", "input": "Owned synthetic fixtures: an integer orthogonal route network, spatial stationing over the same network, a perforated plate and a dense regeneration field. Fixture authoring used ezdxf 1.4.5 and numpy 2.5.4 with a fixed hash seed so repeated builds were byte-identical.", "samples": "3 repeats per operation; 11 operations measured.", "statistic": "median of 3 repeats", "warmCold": "Warm: the same unchanged fixture was executed repeatedly. No cold qualification cost exists on this path.", "network": "None. Native local execution only; no transport was involved.", "serialization": "None recorded; this path produces no request or response frame.", "correctness": "Not the subject of this measurement. The profile records operation cost together with the operation magnitude it produced: crossing count, station total, area and entity count.", "limitations": [ "Synthetic owned fixtures, not student or production drawings.", "Timer resolution and process warm-up are not separated from the measured operation.", "Host CPU model not recorded, so the baseline cannot be normalised to a machine class.", "Each row is a different operation and a different magnitude, so rows are not comparable with one another.", "The key name used for these figures in the original summary means native local execution and must not be read as an external local Rust implementation." ], "interpretation": "The native cost spans a wide range: 16 ms for a small intersection set and for the perforated plate, about 781 ms for 32,000 stationing queries, and roughly 43 seconds for 256 routes producing 65,536 crossings.", "href": "/research/autocad/", "sourceIds": [ "cad-native-profile-20261108", "cad-usefulness-result-20261108" ], "rows": [ { "label": "route intersections, 16 routes, 256 crossings", "value": 16, "unit": "ms", "role": "native", "n": 3, "statistic": "median of 3 samples" }, { "label": "route intersections, 64 routes, 4096 crossings", "value": 359, "unit": "ms", "role": "native", "n": 3, "statistic": "median of 3 samples" }, { "label": "route intersections, 128 routes, 16384 crossings", "value": 2718, "unit": "ms", "role": "native", "n": 3, "statistic": "median of 3 samples" }, { "label": "route intersections, 256 routes, 65536 crossings", "value": 43031, "unit": "ms", "role": "native", "n": 3, "statistic": "median of 3 samples" }, { "label": "spatial stationing, 1000 queries", "value": 31, "unit": "ms", "role": "native", "n": 3, "statistic": "median of 3 samples" }, { "label": "spatial stationing, 8000 queries", "value": 203, "unit": "ms", "role": "native", "n": 3, "statistic": "median of 3 samples" }, { "label": "spatial stationing, 32000 queries", "value": 781, "unit": "ms", "role": "native", "n": 3, "statistic": "median of 3 samples" }, { "label": "perforated plate, 16 bores", "value": 16, "unit": "ms", "role": "native", "n": 3, "statistic": "median of 3 samples" }, { "label": "perforated plate, 64 bores", "value": 109, "unit": "ms", "role": "native", "n": 3, "statistic": "median of 3 samples" }, { "label": "dense regeneration, 2000 entities", "value": 31, "unit": "ms", "role": "native", "n": 3, "statistic": "median of 3 samples" }, { "label": "dense regeneration, 10000 entities", "value": 63, "unit": "ms", "role": "native", "n": 3, "statistic": "median of 3 samples" } ], "comparisons": [], "chart": false, "presentation": { "title": "What an engineering operation costs inside AutoCAD itself", "question": "Before I could claim that an external path was faster, I needed to know what the application costs on its own work, so I profiled eleven synthetic operations entirely inside AutoCAD with nothing intercepted.", "comparison": "I ran route intersections, spatial stationing, a perforated plate and a dense regeneration through the application's own API, three repeats each, and kept the median.", "finding": "The native cost spans a wide range: 16 ms for a small intersection set and for the perforated plate, about 781 ms for 32,000 stationing queries, and roughly 43 seconds for 256 routes producing 65,536 crossings.", "lesson": "This is the figure every later comparison has to beat, and it is also the figure that moves between sessions on the same machine.", "caveat": "The geometry is synthetic and mine, the host processor was never recorded, and warm-up time is folded into the same number, so these are reference costs rather than a machine-independent baseline.", "kind": "Performance", "area": "AutoCAD" }, "technical": { "original": { "title": "Native AutoCAD synthetic engineering-operation profile", "scope": "Baseline cost of the same synthetic engineering operations executed entirely by the application's own API, with no interception, no external execution and no result substitution. This is the cost that later measurements replace.", "interpretation": "This fixes the native reference against which every later row in this dataset is read. A published speed figure must quote the matching native row for the same operation, on the same host, and must state that the native figure itself varies between sessions." } }, "chartSeries": [] }, { "id": "rt-cli-desktop-local-remote", "title": "Running the shipped desktop command line both ways", "topic": "Runtime", "date": "2026-11-05", "evidence": "Measured", "scope": "Two matrix sizes, 32 and 128, each computed three times per route, measuring the whole process from start to close.", "hardware": "A personal Windows machine with 8 GB of memory. The CPU model and core count are not recorded in this receipt.", "software": "A native Microsoft-toolchain build of the desktop application with a pinned numeric runtime library beside it. The library is the same pinned 0.3.34 build used elsewhere in this dataset.", "input": "Two square matrix problem sizes, 32 and 128, each computed three times per route. The fixtures are described as owned synthetic fixtures.", "samples": "Three process calls per route per size, six in total. The run also produced six actual authenticated remote computations and two safe local fallbacks.", "statistic": "Median spawn-to-close time over three calls per route per size. The receipt states these are not a full benchmark distribution or an acceleration result.", "warmCold": "Each observation is a complete process start to close, so process start-up is inside the measured interval.", "network": "The remote route includes provider, input and authentication handling, native execution, full native verification, cleanup and publication. It excludes external tunnel and worker preparation, which are not separately measured.", "serialization": "Not recorded as a separate figure in this receipt.", "correctness": "Every remote computation was checked against a full scalar bitwise oracle. The two local fallbacks, taken when the epoch was wrong and when the tunnel was absent, were also recorded as correct, and all cleanup checks passed.", "limitations": [ "Three calls per route per size; the receipt states this is not a full benchmark distribution.", "Concurrent memory observation may have perturbed the timings.", "External tunnel and worker preparation are excluded from the remote interval, so the remote figure is not an end-to-end user wait.", "The observed peak working set is a sample, not a memory qualification.", "An earlier shorter campaign remains failed and is retained separately.", "No 4 GB device behaviour is qualified." ], "interpretation": "At size 32 the local route took a median of 317 ms and the remote route 7.59 s, about 24 times longer; at size 128 the local route took 312 ms and the remote 9.83 s, about 32 times longer.", "href": "/research/runtime/", "sourceIds": [ "rt-src-win-dev-progress" ], "rows": [ { "label": "local route, size 32, median spawn to close", "value": 317.0849, "unit": "ms", "role": "local", "n": 3, "statistic": "median of 3 process calls" }, { "label": "remote route, size 32, median spawn to close", "value": 7584.6283, "unit": "ms", "role": "remote", "n": 3, "statistic": "median of 3 process calls" }, { "label": "local route, size 128, median spawn to close", "value": 312.4579, "unit": "ms", "role": "local", "n": 3, "statistic": "median of 3 process calls" }, { "label": "remote route, size 128, median spawn to close", "value": 9829.4951, "unit": "ms", "role": "remote", "n": 3, "statistic": "median of 3 process calls" }, { "label": "authenticated remote computations executed", "value": 6, "unit": "calls", "role": "remote", "n": 6, "statistic": "six actual authenticated remote computations" }, { "label": "safe local fallbacks taken", "value": 2, "unit": "calls", "role": "local", "n": 2, "statistic": "one for a wrong epoch and one for an absent tunnel" }, { "label": "desktop library tests passed", "value": 104, "unit": "cases", "role": "metric", "n": 1, "statistic": "104 of 104 library tests passed, hashes checked before and after" }, { "label": "observed peak working set, lower bound of the reported range", "value": 76546048, "unit": "bytes", "role": "metric", "n": 1, "statistic": "the reported approximate range of 73 to 74 MiB, lower bound expressed in bytes" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "remote-vs-local" }, { "baseline": 2, "candidate": 3, "kind": "remote-vs-local" } ], "chart": false, "presentation": { "title": "Running the shipped desktop command line both ways", "question": "I wanted to see what a real user of the shipped desktop tool experiences on the local route versus the remote one, so I ran the installed command line end to end.", "comparison": "Two matrix sizes, 32 and 128, each computed three times per route, measuring the whole process from start to close.", "finding": "At size 32 the local route took a median of 317 ms and the remote route 7.59 s, about 24 times longer; at size 128 the local route took 312 ms and the remote 9.83 s, about 32 times longer.", "lesson": "On the same machine the remote route is dramatically slower for these small problems, and the local route even got slightly faster at the larger size, which is the opposite of the usual intuition.", "caveat": "Three calls per route per size, concurrent memory observation may have perturbed the timings, the external tunnel and worker preparation are excluded from the remote interval so the real figure would be worse, and the peak working set is a sample rather than a measurement of memory behaviour.", "kind": "Performance", "area": "Runtime", "labels": { "0": "Local execution, size 32", "1": "Remote execution, size 32", "2": "Local execution, size 128", "3": "Remote execution, size 128" }, "featuredRows": [ 0, 1, 2, 3 ] }, "technical": { "original": { "title": "Desktop command-line path, local execution against remote execution on the same machine", "scope": "The shipped desktop command line exercised end to end on a personal machine: authenticated remote computations, local fallback when the remote path is unavailable, and the elapsed time from process start to close for both routes at two problem sizes.", "interpretation": "On the same machine the remote route is between 23 and 24 times the local median at size 32 and between 31 and 32 times the local median at size 128. The local route is also slightly faster at the larger size, which is the opposite of the usual intuition. The honest summary is that this build of the remote path is substantially slower than the local path for these small problems, and that the measurement deliberately excludes the parts of a real deployment that would make the remote number worse." } }, "chartSeries": [] }, { "id": "rt-installer-msi-milestones", "title": "Packaging the desktop application and checking it installs", "topic": "Runtime", "date": "2026-11-05", "evidence": "Validation", "scope": "Two builds compared byte for byte, the embedded payload and exported tables inspected, and an unprivileged install-then-uninstall of the earlier version.", "hardware": "A personal Windows machine that is the existing development machine rather than a clean device. No 4 GB device was available for testing.", "software": "A native installer packaging source compiled with the installed toolchain, the embedded payload containing the application executable and its pinned numeric runtime library, and a toolchain archive that is an observed snapshot rather than a hermetic environment.", "input": "Not applicable. This is a packaging qualification.", "samples": "Two installer builds from one archived packaging binary, plus the install and uninstall scenario for the previous version.", "statistic": "Byte counts and digest comparisons. No timing distribution.", "warmCold": "Not applicable.", "network": "No network use; the toolchain archive was assembled locally with no downloads.", "serialization": "The installer embeds one archive and three payload files: the application executable, the pinned numeric runtime library and its licence text. Fourteen exported tables were compared between the two builds.", "correctness": "Both builds exported fourteen tables, expanded their embedded archive, and produced exactly three payload files; all fourteen exported table files matched byte for byte between the two builds, and every embedded file matched its exact pin. The previous version recorded a successful unelevated current-user install and uninstall with exact payload and shortcut checks and preservation of unowned files.", "limitations": [ "The two builds are not byte-reproducible: exactly four bytes differ, at offsets 8300 to 8303, and no cause is asserted.", "The install and uninstall evidence belongs to the previous version and does not qualify the version built here.", "Nothing was installed or launched for the version built here: no installation, no command-line negative tests, no installer validation, no dependency closure, no rollback, no upgrade or downgrade refusal, no administrative or unprivileged behaviour and no configuration preservation were exercised.", "Same-host, same-tool repeatability of the normalised build does not establish cross-toolchain reproducible compilation, signing or authenticity.", "The installer is unsigned and not fully qualified.", "The toolchain archive is an observed binary snapshot and not a redistributable environment.", "The existing development machine was used; a clean device was not available." ], "interpretation": "Both builds produced 13,127,680 bytes with fourteen exported tables matching byte for byte and exactly three embedded payload files each matching their expected checksums, and the earlier version installed and uninstalled cleanly for a current user without touching files it does not own.", "href": "/research/runtime/", "sourceIds": [ "rt-src-msi-build-evidence", "rt-src-win-dev-progress" ], "rows": [ { "label": "installer, first build", "value": 13127680, "unit": "bytes", "role": "metric", "n": 2, "statistic": "byte size of the first of two builds from one packaging binary" }, { "label": "installer, second build", "value": 13127680, "unit": "bytes", "role": "metric", "n": 2, "statistic": "byte size of the second build, equal to the first" }, { "label": "differing bytes between the two builds", "value": 4, "unit": "bytes", "role": "metric", "n": 2, "statistic": "exactly four differing bytes, at zero-based offsets 8300 to 8303" }, { "label": "embedded payload archive", "value": 13089923, "unit": "bytes", "role": "metric", "n": 2, "statistic": "extracted from each build and compared" }, { "label": "application executable in the payload", "value": 8041984, "unit": "bytes", "role": "metric", "n": 2, "statistic": "matches its exact pin in both builds" }, { "label": "numeric runtime library in the payload", "value": 51379251, "unit": "bytes", "role": "metric", "n": 2, "statistic": "matches its exact pin in both builds" }, { "label": "runtime library licence text in the payload", "value": 1545, "unit": "bytes", "role": "metric", "n": 2, "statistic": "matches its exact pin in both builds" }, { "label": "exported installer tables inspected", "value": 14, "unit": "cases", "role": "metric", "n": 2, "statistic": "14 exports present for each build and all matched byte for byte" }, { "label": "payload files in the installer", "value": 3, "unit": "cases", "role": "metric", "n": 2, "statistic": "exactly three payload files" }, { "label": "unelevated current-user install and uninstall exit status", "value": 0, "unit": "cases", "role": "metric", "n": 1, "statistic": "0 denotes a successful exit code, recorded for the previous version only" }, { "label": "installer scenario overall pass flag", "value": 0, "unit": "cases", "role": "metric", "n": 1, "statistic": "0 denotes false, correctly preserving the failed interface qualification" } ], "comparisons": [], "chart": false, "presentation": { "title": "Packaging the desktop application and checking it installs", "question": "A desktop tool that cannot be installed is not usable, so I built the installer twice from the same source, inspected what it carries, and checked the install and uninstall behaviour of the previous version.", "comparison": "Two builds compared byte for byte, the embedded payload and exported tables inspected, and an unprivileged install-then-uninstall of the earlier version.", "finding": "Both builds produced 13,127,680 bytes with fourteen exported tables matching byte for byte and exactly three embedded payload files each matching their expected checksums, and the earlier version installed and uninstalled cleanly for a current user without touching files it does not own.", "lesson": "The package is real and its contents are exactly what I intended; the open point is that two builds from the same source differ in four bytes and I have not found out why.", "caveat": "The two builds are not byte-identical, exactly four bytes differ at offsets 8,300 to 8,303, and no cause is claimed; the install evidence belongs to the earlier version, nothing was installed or launched for this build, the installer is unsigned, and the toolchain archive is an observed snapshot rather than a reproducible environment.", "kind": "Functional check", "area": "Runtime", "labels": { "0": "Installer, first build", "1": "Installer, second build", "2": "Bytes differing between the builds", "3": "Embedded payload archive", "4": "Application executable in the payload", "5": "Numeric runtime library in the payload", "6": "Runtime library licence text", "7": "Exported tables inspected", "8": "Payload files in the installer", "9": "Unprivileged install and uninstall exit status", "10": "Installer scenario overall pass flag" }, "featuredRows": [ 0, 1, 2 ] }, "technical": { "original": { "title": "Native installer packaging, byte reproducibility and install coverage", "scope": "Two builds of the same installer from one packaging source, compared byte for byte, then the embedded payload and tables inspected with a write-capable toolkit, and the install and uninstall behaviour of the previous version checked on an existing machine.", "interpretation": "The installer produces a working package with an exactly pinned payload, and the previous version installs and uninstalls cleanly for an unprivileged user without touching files it does not own. The one unresolved point is reproducibility: two builds from the same packaging binary differ in four bytes, which is small but unexplained, and the receipt chooses to publish that rather than normalise it away." } }, "chartSeries": [] }, { "id": "rt-novice-gui-first-run", "title": "What a new user meets on the first run", "topic": "Runtime", "date": "2026-11-05", "evidence": "Measured", "scope": "Two installed first-run attempts, each checked for how far it got, what blocked it and whether it ever completed a computation.", "hardware": "A personal Windows machine with 8 GB of memory at an expected display scaling of 144. The CPU model and core count are not recorded in this receipt.", "software": "The installed desktop application built from a pinned source snapshot, with the native window shell, and a qualification harness that drives it through the operating system accessibility interface. The harness pins the installed executable, the installer and the request digests, and rejects reparse points on the selected local paths.", "input": "An installed application run driven by a harness that clicks the real controls, records the created personal configuration paths without opening them, and exercises the native file picker.", "samples": "Two installed runs. Both are recorded as failed or incomplete. A third blind retry was deliberately not performed.", "statistic": "Counts of runs, of successful stages and of blocking events. No timing distribution is published for the application path.", "warmCold": "Both runs are first-run launches of the installed application.", "network": "The remote profile gate was exercised and left disabled without a configured profile; no remote computation was attempted in either run.", "serialization": "Not applicable; no request or response frame was produced by the recorded runs.", "correctness": "Not the subject of these runs. The second run recorded successful included-library setup and the initial consent and remote-profile gating before it stopped.", "limitations": [ "Two runs, both failed or incomplete; no successful end-to-end first run is recorded.", "The application was never shown to complete a computation, produce a result or pass an oracle.", "The expected 144 display scaling is recorded as an environment expectation; an actual 144 scaling capture was not verified and the harness notes that a successful window capture does not prove pixel legibility.", "The harness explicitly states that observing a tab is not physical keyboard coverage.", "The harness records that teardown is not absolutely bounded, because local filesystem queries, scheduling and job assignment can all stall.", "No 150 or 200 percent scaling, accessibility-tool compatibility, remote execution or cancellation, 4 GB memory, numerical correctness or installation success is claimed.", "The run is a candidate qualification attempt, not an accepted result." ], "interpretation": "Neither run completed a computation; the second got through the bundled numeric library setup and the consent and remote-profile gating, then stopped at a capped timeout reading the native file picker's filename field, and the window layout is visibly clipped at the machine's expected display scaling.", "href": "/research/runtime/", "sourceIds": [ "rt-src-win-dev-gui", "rt-src-win-dev-progress" ], "rows": [ { "label": "installed first-run attempts", "value": 2, "unit": "cases", "role": "metric", "n": 2, "statistic": "two installed runs launched" }, { "label": "runs that completed a computation and an oracle check", "value": 0, "unit": "cases", "role": "metric", "n": 2, "statistic": "neither run reached a computation" }, { "label": "runs that completed included-library setup and consent gating", "value": 1, "unit": "cases", "role": "metric", "n": 2, "statistic": "recorded in the second run" }, { "label": "runs that ended in a bounded native-picker filename query timeout", "value": 1, "unit": "cases", "role": "metric", "n": 2, "statistic": "recorded in the second run" }, { "label": "expected environment display scaling", "value": 144, "unit": "dpi", "role": "metric", "n": 2, "statistic": "expected value recorded by the harness, not a verified capture" }, { "label": "global termination timer", "value": 135000, "unit": "ms", "role": "metric", "n": 1, "statistic": "terminates the owned application and helper jobs" }, { "label": "driver hard exit timer", "value": 148000, "unit": "ms", "role": "metric", "n": 1, "statistic": "terminates again and exits the driver" }, { "label": "normal operation budget", "value": 130000, "unit": "ms", "role": "metric", "n": 1, "statistic": "normal operation budget for a whole run" }, { "label": "single native text query timeout", "value": 300, "unit": "ms", "role": "metric", "n": 1, "statistic": "per query ceiling" }, { "label": "cleanup budget", "value": 3000, "unit": "ms", "role": "metric", "n": 1, "statistic": "cleanup ceiling" } ], "comparisons": [], "chart": false, "presentation": { "title": "What a new user meets on the first run", "question": "The hardest part to get right is often the first two minutes, so I drove the installed application through its first-run path twice as a non-technical user would.", "comparison": "Two installed first-run attempts, each checked for how far it got, what blocked it and whether it ever completed a computation.", "finding": "Neither run completed a computation; the second got through the bundled numeric library setup and the consent and remote-profile gating, then stopped at a capped timeout reading the native file picker's filename field, and the window layout is visibly clipped at the machine's expected display scaling.", "lesson": "Onboarding is the weakest part of the system so far, and the failures sit at the boundary of the operating system's file picker and the display rather than in the numerical work.", "caveat": "Two runs, both incomplete, so there is no successful end-to-end first run to describe; the expected 144 scaling was not verified in a capture, observing a control is not the same as physical keyboard coverage, teardown does not have an absolute limit, and no scaling, accessibility, remote execution, cancellation, memory or installation success is claimed.", "kind": "Incomplete experiment", "area": "Runtime", "labels": { "0": "First-run attempts", "1": "Runs that completed a computation", "2": "Runs that completed library setup and consent", "3": "Runs that ended in a file picker timeout", "4": "Expected display scaling" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "First-run experience of the installed desktop application for a non-technical user", "scope": "The installed application was launched twice on a personal machine and driven through its first-run path: included-library setup, consent, remote-profile gating, a native file picker and the request flow. Both runs are recorded as failed or incomplete, and the blocking points are published rather than smoothed over.", "interpretation": "The first-run path is the weakest part of the system so far. Onboarding reached the point of creating the user configuration and accepting consent, then stopped at a bounded timeout reading the native file picker filename field, and the window layout is visibly clipped at the machine display scaling. The harness is careful to separate an application defect from an environment or test-harness defect and does not claim either." } }, "chartSeries": [] }, { "topic": "GEMM", "date": "2026-10-19", "evidence": "Measured", "href": "/research/runtime/", "hardware": "Two worker processes on one admitted CPU host running Ubuntu 24.04 with kernel 6.8 on EPYC-Genoa, with the Rust toolchain at 1.99.0 and one declared thread. The receipt describes them as correlated processes sharing admitted hardware rather than a heterogeneous resource set.", "software": "A separate one-attempt preservation dataset of 1,200 correct measured calls, 450 warm-ups and 150 phases, with 240 calibrated profiles fresh for both bindings and 240 real regions executed on each of two forced workers.", "input": "A small-integer N32 two-dependent-GEMM region executed as eight measured calls per block, with every final output element checked on each call.", "samples": "1,200 correct measured calls, 450 warm-ups and 150 phases; 240 calibrated measured rows with fresh profiles on both bindings.", "statistic": "Nearest-rank block median and 95th percentile over 30 blocks in microseconds, compared against the optimised local boundary, with a paired mean-ratio bootstrap of 10,000 resamples.", "warmCold": "Each boundary is measured separately. Setup, preparation and calibration, warm-up, the first measured call with its external scalar oracle, the steady calls and cleanup are charged to distinct boundaries and the quantiles of nested phases cannot be added.", "network": "Loopback between the client and the two worker processes on the same host. The harness explicitly excludes process-cold worker launch and any wide-area or operator transport from these totals.", "serialization": "Per-phase counters remain fully enabled and charged, separating serial authenticated metadata, execute, fetch, release and statistics calls. Directional accounting excludes the enclosing transport overhead.", "correctness": "All 1,200 measured calls are recorded correct. The independent gate decision recomputed every comparison and the seeded bootstrap and accepted the source, process, key, listener, size and archive receipts.", "sourceIds": [ "rt-src-s6-r6-status", "rt-src-s6-gatekeeper-r2" ], "id": "rt-s6-first-use", "title": "Taking the first-use cost apart phase by phase", "scope": "Setup, preparation and calibration, cleanup and the whole first use, each against the equivalent local phase, over 30 blocks.", "limitations": [ "Quantiles of nested boundaries cannot be added; the setup boundary contains the artifact preparation.", "This boundary is not a native or wide-area start-up measurement and must not be read as one.", "The wide-area and cold observations in the same receipt are partial and are published separately.", "All measured dispatcher choices were local; the ratio measures the cost of preparing and calibrating the remote path.", "The first-use failure is preserved and is not replaced by the steady-state pass." ], "interpretation": "The whole first use cost 8.6 ms against 0.33 ms locally, 26 times more, and within that, preparation and calibration alone were 7.7 ms against 0.115 ms, while the steady calls themselves differ by a fraction of a millisecond.", "rows": [ { "label": "inclusive first use, optimised local, median", "value": 0.328, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank block median, 328 microseconds" }, { "label": "inclusive first use, optimised local, 95th percentile", "value": 0.456, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank block 95th percentile, 456 microseconds" }, { "label": "inclusive first use, calibrated dispatcher, median", "value": 8.638, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank block median, 8,638 microseconds" }, { "label": "inclusive first use, calibrated dispatcher, 95th percentile", "value": 12.16, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank block 95th percentile, 12,160 microseconds" }, { "label": "first-use ratio against the optimised local boundary", "value": 26.3354, "unit": "ratio", "role": "metric", "n": 30, "statistic": "median ratio on the inclusive first-use boundary" }, { "label": "first-use ratio, 95th percentile", "value": 26.6667, "unit": "ratio", "role": "metric", "n": 30, "statistic": "95th percentile ratio on the inclusive first-use boundary" }, { "label": "setup phase, optimised local, median", "value": 0.06, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank block median, 60 microseconds" }, { "label": "setup phase, calibrated dispatcher, median", "value": 0.761, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank block median, 761 microseconds" }, { "label": "preparation and calibration phase, optimised local, median", "value": 0.115, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank block median, 115 microseconds" }, { "label": "preparation and calibration phase, calibrated dispatcher, median", "value": 7.665, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank block median, 7,665 microseconds" }, { "label": "cleanup phase, optimised local, median", "value": 0.078, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank block median, 78 microseconds" }, { "label": "cleanup phase, calibrated dispatcher, median", "value": 0.387, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank block median, 387 microseconds" }, { "label": "measured calls", "value": 1200, "unit": "calls", "role": "metric", "n": 150, "statistic": "1,200 correct measured calls" } ], "comparisons": [ { "baseline": 0, "candidate": 2, "kind": "remote-vs-local" }, { "baseline": 1, "candidate": 3, "kind": "remote-vs-local" } ], "chart": false, "presentation": { "title": "Taking the first-use cost apart phase by phase", "question": "The first-use failure was large enough that I wanted to see where inside it the time went, so I measured the phases separately instead of only the total.", "comparison": "Setup, preparation and calibration, cleanup and the whole first use, each against the equivalent local phase, over 30 blocks.", "finding": "The whole first use cost 8.6 ms against 0.33 ms locally, 26 times more, and within that, preparation and calibration alone were 7.7 ms against 0.115 ms, while the steady calls themselves differ by a fraction of a millisecond.", "lesson": "The gap is start-up and calibration debt rather than steady-state execution; once the path is ready it behaves, and getting it ready is what fails.", "caveat": "Quantiles of nested boundaries cannot be added, this is not a native or wide-area start-up measurement, the wide-area and cold observations in the same run are partial, every measured dispatcher decision chose local, and the failure is kept rather than replaced by the steady-state pass.", "kind": "Performance", "area": "Runtime", "labels": { "0": "Local execution, whole first use, median", "1": "Local execution, whole first use, 95th percentile", "2": "Prepared path, whole first use, median", "3": "Prepared path, whole first use, 95th percentile", "6": "Local execution, setup, median", "7": "Prepared path, setup, median", "8": "Local execution, preparation and calibration, median", "9": "Prepared path, preparation and calibration, median", "10": "Local execution, cleanup, median", "11": "Prepared path, cleanup, median" }, "featuredRows": [ 0, 2 ] }, "technical": { "original": { "title": "Preservation first use including preparation and calibration, with the overhead boundaries itemised", "scope": "The first-use boundary of the preservation run, measured from setup through preparation, calibration, warm-up and the first measured call with its external scalar oracle. The overhead phases are published as their own rows so the cost structure is visible rather than hidden inside a single ratio.", "interpretation": "The remote path costs about 26 times the local boundary at the median on first use. The itemised phases show why: preparation and calibration alone cost roughly 7.7 ms at the median against a local preparation cost of 0.115 ms, while the steady call itself differs by only a fraction of a millisecond. The gap is start-up and calibration debt, not steady-state execution." } }, "chartSeries": [ { "title": "Inclusive first use / p50", "indices": [ 0, 2 ], "labels": [ "Local", "Calibrated dispatcher" ] } ] }, { "topic": "GEMM", "date": "2026-10-19", "evidence": "Measured", "href": "/research/runtime/", "hardware": "Two worker processes on one admitted CPU host running Ubuntu 24.04 with kernel 6.8 on EPYC-Genoa, with the Rust toolchain at 1.99.0 and one declared thread. The receipt describes them as correlated processes sharing admitted hardware rather than a heterogeneous resource set.", "software": "A separate one-attempt preservation dataset of 1,200 correct measured calls, 450 warm-ups and 150 phases, with 240 calibrated profiles fresh for both bindings and 240 real regions executed on each of two forced workers.", "input": "A small-integer N32 two-dependent-GEMM region executed as eight measured calls per block, with every final output element checked on each call.", "samples": "1,200 correct measured calls, 450 warm-ups and 150 phases; 240 calibrated measured rows with fresh profiles on both bindings.", "statistic": "Nearest-rank block median and 95th percentile over 30 blocks in microseconds, compared against the optimised local boundary, with a paired mean-ratio bootstrap of 10,000 resamples.", "warmCold": "Each boundary is measured separately. Setup, preparation and calibration, warm-up, the first measured call with its external scalar oracle, the steady calls and cleanup are charged to distinct boundaries and the quantiles of nested phases cannot be added.", "network": "Loopback between the client and the two worker processes on the same host. The harness explicitly excludes process-cold worker launch and any wide-area or operator transport from these totals.", "serialization": "Per-phase counters remain fully enabled and charged, separating serial authenticated metadata, execute, fetch, release and statistics calls. Directional accounting excludes the enclosing transport overhead.", "correctness": "All 1,200 measured calls are recorded correct. The independent gate decision recomputed every comparison and the seeded bootstrap and accepted the source, process, key, listener, size and archive receipts.", "sourceIds": [ "rt-src-s6-r6-status", "rt-src-s6-gatekeeper-r2" ], "id": "rt-s6-full-experiment", "title": "The whole experiment, including the wide-area observations", "scope": "Setup through cleanup against the optimised local boundary, alongside the single wide-area observations recorded in the same run.", "limitations": [ "Quantiles of nested boundaries cannot be added to the complete total.", "The wide-area rows are correlated single-block observations with a partial remote leg; the remote eighth-call receipt is not recorded at all.", "The 137.273 second figure is a failed cleanup-inclusive experiment duration and is not a result latency.", "The wide-area payload campaign failure was not explained; surviving control connections did not establish a cause.", "This boundary is not a native or wide-area start-up measurement.", "The complete-phase failure is preserved alongside the steady-state pass." ], "interpretation": "The complete experiment cost about 13.9 times the local boundary at the median and 10.6 times at the 95th percentile; over the wide-area link the first local parent record took 6.9 s against 35.9 s for a partial remote leg, and one remote boundary produced no result at all.", "rows": [ { "label": "inclusive full experiment, optimised local, median", "value": 0.677, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank block median, 677 microseconds" }, { "label": "inclusive full experiment, optimised local, 95th percentile", "value": 1.232, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank block 95th percentile, 1,232 microseconds" }, { "label": "inclusive full experiment, calibrated dispatcher, median", "value": 9.43, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank block median, 9,430 microseconds" }, { "label": "inclusive full experiment, calibrated dispatcher, 95th percentile", "value": 13.002, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank block 95th percentile, 13,002 microseconds" }, { "label": "full experiment ratio against the optimised local boundary", "value": 13.9291, "unit": "ratio", "role": "metric", "n": 30, "statistic": "median ratio on the inclusive full-experiment boundary" }, { "label": "full experiment ratio, 95th percentile", "value": 10.5536, "unit": "ratio", "role": "metric", "n": 30, "statistic": "95th percentile ratio on the inclusive full-experiment boundary" }, { "label": "wide-area local first parent receipt", "value": 6897, "unit": "ms", "role": "local", "n": 1, "statistic": "single recorded parent receipt" }, { "label": "wide-area partial remote first parent receipt", "value": 35905, "unit": "ms", "role": "remote", "n": 1, "statistic": "single recorded parent receipt, partial leg" }, { "label": "wide-area local eighth call receipt", "value": 7108, "unit": "ms", "role": "local", "n": 1, "statistic": "single recorded parent receipt" }, { "label": "wide-area remote eighth call receipt", "value": 0, "unit": "ms", "role": "remote", "n": null, "statistic": "not recorded; the remote leg produced no receipt" }, { "label": "wide-area descriptive API wait, local, median", "value": 0.025756, "unit": "ms", "role": "local", "n": 8, "statistic": "median of 8 correlated single-block samples" }, { "label": "wide-area descriptive API wait, local, 95th percentile", "value": 0.115579, "unit": "ms", "role": "local", "n": 8, "statistic": "95th percentile of 8 correlated single-block samples" }, { "label": "wide-area descriptive API wait, partial remote, median", "value": 8374.323146, "unit": "ms", "role": "remote", "n": 7, "statistic": "median of 7 correlated single-block samples" }, { "label": "wide-area descriptive API wait, partial remote, 95th percentile", "value": 11342.190034, "unit": "ms", "role": "remote", "n": 7, "statistic": "95th percentile of 7 correlated single-block samples" }, { "label": "failed cleanup-inclusive wide-area experiment duration", "value": 137273, "unit": "ms", "role": "metric", "n": 1, "statistic": "duration of a failed run including cleanup, not a result latency" }, { "label": "measured calls", "value": 1200, "unit": "calls", "role": "metric", "n": 150, "statistic": "1,200 correct measured calls" } ], "comparisons": [ { "baseline": 0, "candidate": 2, "kind": "remote-vs-local" }, { "baseline": 1, "candidate": 3, "kind": "remote-vs-local" }, { "baseline": 6, "candidate": 7, "kind": "remote-vs-local" } ], "chart": false, "presentation": { "title": "The whole experiment, including the wide-area observations", "question": "I wanted the complete boundary measured, and the same run happened to be the only place where a real external link was exercised, so I published both.", "comparison": "Setup through cleanup against the optimised local boundary, alongside the single wide-area observations recorded in the same run.", "finding": "The complete experiment cost about 13.9 times the local boundary at the median and 10.6 times at the 95th percentile; over the wide-area link the first local parent record took 6.9 s against 35.9 s for a partial remote leg, and one remote boundary produced no result at all.", "lesson": "The picture is consistent: roughly as fast as local in steady state and much slower everywhere else, with the external link the worst of it.", "caveat": "The wide-area figures are single correlated observations with an incomplete remote leg and one boundary that returned nothing, the 137-second figure is the duration of a failed run rather than a latency, the payload failure was never explained, and the complete-phase failure is kept alongside the steady-state pass.", "kind": "Performance", "area": "Runtime", "labels": { "0": "Local execution, median", "1": "Local execution, 95th percentile", "2": "Prepared path, median", "3": "Prepared path, 95th percentile" }, "featuredRows": [ 0, 2 ] }, "technical": { "original": { "title": "Preservation complete experiment boundary and the partial wide-area observations from the same run", "scope": "The complete experiment boundary of the preservation run, covering setup, preparation, calibration, warm-up, every measured call, the external oracles, instrumentation and cleanup. The same receipt contains partial wide-area and cold observations, which are published here as descriptive rows because they are the only connectivity figures in the dataset.", "interpretation": "The complete experiment costs about 13.9 times the optimised local boundary at the median and 10.6 times at the 95th percentile. The wide-area figures are far larger still and are partial: the local first parent receipt took 6.897 seconds against 35.905 seconds for the partial remote leg, and one remote boundary produced no result at all. Taken together the picture is consistent: the path is roughly as fast as local in steady state and much slower everywhere else." } }, "chartSeries": [ { "title": "Inclusive full experiment / p50", "indices": [ 0, 2 ], "labels": [ "Local", "Calibrated dispatcher" ] } ] }, { "topic": "GEMM", "date": "2026-10-19", "evidence": "Measured", "href": "/research/runtime/", "hardware": "Two worker processes on one admitted CPU host running Ubuntu 24.04 with kernel 6.8 on EPYC-Genoa, with the Rust toolchain at 1.99.0 and one declared thread. The receipt describes them as correlated processes sharing admitted hardware rather than a heterogeneous resource set.", "software": "A separate one-attempt preservation dataset of 1,200 correct measured calls, 450 warm-ups and 150 phases, with 240 calibrated profiles fresh for both bindings and 240 real regions executed on each of two forced workers.", "input": "A small-integer N32 two-dependent-GEMM region executed as eight measured calls per block, with every final output element checked on each call.", "samples": "1,200 correct measured calls, 450 warm-ups and 150 phases; 240 calibrated measured rows with fresh profiles on both bindings.", "statistic": "Nearest-rank block median and 95th percentile over 30 blocks in microseconds, compared against the optimised local boundary, with a paired mean-ratio bootstrap of 10,000 resamples.", "warmCold": "Each boundary is measured separately. Setup, preparation and calibration, warm-up, the first measured call with its external scalar oracle, the steady calls and cleanup are charged to distinct boundaries and the quantiles of nested phases cannot be added.", "network": "Loopback between the client and the two worker processes on the same host. The harness explicitly excludes process-cold worker launch and any wide-area or operator transport from these totals.", "serialization": "Per-phase counters remain fully enabled and charged, separating serial authenticated metadata, execute, fetch, release and statistics calls. Directional accounting excludes the enclosing transport overhead.", "correctness": "All 1,200 measured calls are recorded correct. The independent gate decision recomputed every comparison and the seeded bootstrap and accepted the source, process, key, listener, size and archive receipts.", "sourceIds": [ "rt-src-s6-r6-status", "rt-src-s6-gatekeeper-r2" ], "id": "rt-s6-steady-eight-call", "title": "The steady state measured against a strict local baseline", "scope": "Eight calls per block on an already prepared path against the optimised local boundary, over 30 blocks with 1,200 checked calls.", "limitations": [ "This is the steady leg only; the first-use and complete-experiment legs fail and are published separately.", "The paired mean-ratio interval upper endpoint exceeds the 1.10 median bound; the decision rule uses observed quantiles with uncertainty disclosed rather than confidence-bound containment.", "All measured dispatcher choices were local; the ratio measures the cost of the dispatcher path, not a placement win.", "Remote execution is proved separately by the forced worker arms and is not claimed here.", "This is a small-integer experiment and is not a universal numerical or tail guarantee." ], "interpretation": "The prepared path took 239 microseconds at the median and 297 at the 95th percentile against 219 and 275 locally, 9 percent and 8 percent more, inside the 10 and 15 percent limits I set in advance.", "rows": [ { "label": "complete eight-call steady total, optimised local, median", "value": 0.219, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank block median, 219 microseconds" }, { "label": "complete eight-call steady total, optimised local, 95th percentile", "value": 0.275, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank block 95th percentile, 275 microseconds" }, { "label": "complete eight-call steady total, calibrated dispatcher, median", "value": 0.239, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank block median, 239 microseconds" }, { "label": "complete eight-call steady total, calibrated dispatcher, 95th percentile", "value": 0.297, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank block 95th percentile, 297 microseconds" }, { "label": "steady ratio against the optimised local boundary", "value": 1.0913242, "unit": "ratio", "role": "metric", "n": 30, "statistic": "median ratio against the 1.10 bound" }, { "label": "steady ratio, 95th percentile", "value": 1.08, "unit": "ratio", "role": "metric", "n": 30, "statistic": "95th percentile ratio against the 1.15 bound" }, { "label": "paired mean-ratio interval, lower bound", "value": 1.0306468478114097, "unit": "ratio", "role": "metric", "n": 30, "statistic": "10,000 paired resamples at the fixed seed" }, { "label": "paired mean-ratio interval, upper bound", "value": 1.1164022244723213, "unit": "ratio", "role": "metric", "n": 30, "statistic": "10,000 paired resamples at the fixed seed" }, { "label": "uncalibrated steady ratio, median", "value": 1.0365296804, "unit": "ratio", "role": "metric", "n": 30, "statistic": "retained tail-bound check" }, { "label": "uncalibrated steady ratio, 95th percentile", "value": 1.1927272727, "unit": "ratio", "role": "metric", "n": 30, "statistic": "retained, above the 1.15 bound" }, { "label": "earlier candidate preservation ratio, median", "value": 1.2152466368, "unit": "ratio", "role": "metric", "n": 30, "statistic": "retained failure from the earlier immutable dataset" }, { "label": "earlier candidate preservation ratio, 95th percentile", "value": 1.1992481203, "unit": "ratio", "role": "metric", "n": 30, "statistic": "retained failure from the earlier immutable dataset" }, { "label": "measured calls", "value": 1200, "unit": "calls", "role": "metric", "n": 150, "statistic": "1,200 correct measured calls" }, { "label": "exact-source release task assertions passed", "value": 177, "unit": "cases", "role": "metric", "n": 1, "statistic": "177 passed and 0 failed with 3 explicit exclusions" }, { "label": "calibrated profiles confirmed fresh", "value": 240, "unit": "calls", "role": "metric", "n": 150, "statistic": "240 calibrated measured rows with fresh profiles on both bindings" }, { "label": "real regions executed on the forced workers", "value": 480, "unit": "calls", "role": "metric", "n": 150, "statistic": "the recorded 240 real regions on each of two forced workers, summed" } ], "comparisons": [ { "baseline": 0, "candidate": 2, "kind": "remote-vs-local" }, { "baseline": 1, "candidate": 3, "kind": "remote-vs-local" } ], "chart": false, "presentation": { "title": "The steady state measured against a strict local baseline", "question": "I wanted a second steady-state measurement that could be compared with the earlier campaign, so I ran the preservation setup against an optimised local boundary.", "comparison": "Eight calls per block on an already prepared path against the optimised local boundary, over 30 blocks with 1,200 checked calls.", "finding": "The prepared path took 239 microseconds at the median and 297 at the 95th percentile against 219 and 275 locally, 9 percent and 8 percent more, inside the 10 and 15 percent limits I set in advance.", "lesson": "The steady state is reproducible across campaigns, and it is an overhead result rather than a speed-up.", "caveat": "The paired interval's upper end sits above the median bound and the decision rule uses observed quantiles rather than interval containment, the first-use and complete-experiment legs fail and are published separately, remote execution is only proved by the forced worker arms, and every measured dispatcher decision chose local.", "kind": "Performance", "area": "Runtime", "labels": { "0": "Local execution, median", "1": "Local execution, 95th percentile", "2": "Prepared path, median", "3": "Prepared path, 95th percentile" }, "featuredRows": [ 0, 2 ] }, "technical": { "original": { "title": "Preservation steady-state eight-call boundary against the optimised local boundary", "scope": "The steady-state boundary of the preservation run: eight measured calls per block on an already prepared and calibrated path, compared against the optimised local boundary. This boundary passed the predeclared bounds; it is the only leg that did.", "interpretation": "With preparation and calibration already paid, the dispatcher path costs about 9 percent more than the optimised local boundary at the median and 8 percent more at the 95th percentile, inside the 10 and 15 percent bounds. The paired mean-ratio interval is disclosed with an upper endpoint above the median bound. The steady pass stands together with the first-use and complete-experiment failures and does not become an acceleration claim." } }, "chartSeries": [] }, { "topic": "GEMM", "evidence": "Measured", "href": "/research/runtime/", "hardware": "Two worker processes on one admitted CPU host, described in the receipt as correlated processes sharing the same hardware. The host is recorded as Ubuntu 24.04 with kernel 6.8 on EPYC-Genoa, with the Rust toolchain at 1.99.0 and one declared thread. The receipt states explicitly that this is not a heterogeneous resource set.", "software": "A private immutable prepared plan retaining owned input identity plus live session, backend, memory, capability, affinity and freshness checks; one authoritative placement decision per two-GEMM region; a common optimised runner with a visible fallback trace.", "input": "A small-integer N32 two-dependent-GEMM region executed as eight calls per block, with all 1,024 final output elements checked on every measured call.", "samples": "1,200 measured calls, 450 warm-ups and 150 phase records across five arms of 30 paired blocks each. 240 calibrated measured rows with valid profiles and ages between 120 and 438 microseconds.", "statistic": "Nearest-rank block median and 95th percentile over 30 blocks, expressed as a ratio against the fixed named best eligible prepared local baseline, with a paired mean-ratio bootstrap of 10,000 resamples at a fixed seed.", "warmCold": "The qualifying arm is the calibrated prepared steady state. Preparation and calibration costs are charged to a separate first-use boundary and are not folded into the steady figure.", "network": "Loopback between the client and the two worker processes on the same host. Directional stream accounting excludes the enclosing transport overhead and private allocator peaks.", "serialization": "Traffic records retain actual remote transfer and residency behaviour separately from dispatcher local behaviour. Per-call codec and transfer accounting is carried in the campaign receipts.", "correctness": "Every one of the 1,200 measured calls reports 1,024 final output elements checked; the source aborts on any mismatch and the launch exit is zero. Independent re-summing of all eight caller times in each of the 150 blocks found zero mismatches, and no failed traffic records appear in the completed phases.", "sourceIds": [ "rt-src-prepared-s5-gatekeeper", "rt-src-prepared-s5-verification", "rt-src-prepared-s5-campaign" ], "id": "rt-prepared-s5-first-use", "title": "What the first use of the prepared path costs", "date": "2026-10-18", "scope": "The inclusive first-use boundary against the same local baseline, including the external correctness check.", "limitations": [ "The boundary includes artifact preparation and calibration, which are charged once and amortised across later blocks; it is not comparable with the steady figure.", "Preparation and calibration are nested inside the inclusive first-use total, so the phase quantiles cannot be summed to the total.", "The external scalar oracle and warm-up are included in this boundary.", "All measured dispatcher choices were local; the ratio measures the cost of preparing and calibrating the remote path, not a placement win.", "The historical failure of the first-use boundary is preserved rather than replaced by the steady-state pass." ], "interpretation": "First use cost about 27 times the local baseline at the median and 31 times at the 95th percentile.", "rows": [ { "label": "median ratio of first use against the best eligible local baseline", "value": 26.9381107492, "unit": "ratio", "role": "metric", "n": 30, "statistic": "observed block median ratio on the inclusive first-use boundary" }, { "label": "95th percentile ratio of first use against the best eligible local baseline", "value": 30.832884097, "unit": "ratio", "role": "metric", "n": 30, "statistic": "observed block 95th percentile ratio on the inclusive first-use boundary" }, { "label": "measured calls", "value": 1200, "unit": "calls", "role": "metric", "n": 150, "statistic": "1,200 measured calls across 150 phase records" }, { "label": "phase records", "value": 150, "unit": "blocks", "role": "metric", "n": 150, "statistic": "phase records carrying eight measured calls each" } ], "comparisons": [], "chart": false, "presentation": { "title": "What the first use of the prepared path costs", "question": "A steady-state number means very little if the first use is ruinous, so I measured the same path from before preparation through to the first measured call.", "comparison": "The inclusive first-use boundary against the same local baseline, including the external correctness check.", "finding": "First use cost about 27 times the local baseline at the median and 31 times at the 95th percentile.", "lesson": "Getting the remote path ready is where nearly all the cost lives; paying it once and then running cheaply is a property of the workload shape, not evidence that the path is faster.", "caveat": "This boundary includes preparation and calibration, which are charged once and amortised, so it is not comparable with the steady figure, the correctness check and warm-up sit inside it, and every measured dispatcher decision still chose local.", "kind": "Performance", "area": "Runtime" }, "technical": { "original": { "title": "Prepared calibrated first use, including preparation and calibration cost", "scope": "The first-use boundary of the same prepared qualification, measured from before the prepared artifact and its attachment through calibration and the first measured call, including the external scalar oracle. This boundary failed the predeclared bounds by more than an order of magnitude.", "interpretation": "Preparing, calibrating and first-touching the remote path costs about 27 times the local baseline at the median. Amortising that cost is a property of the workload shape and the preparation design, not evidence that the path is faster; the steady-state pass and this first-use failure are the two ends of the same measurement and both are published." } }, "chartSeries": [] }, { "topic": "GEMM", "evidence": "Measured", "href": "/research/runtime/", "hardware": "Two worker processes on one admitted CPU host, described in the receipt as correlated processes sharing the same hardware. The host is recorded as Ubuntu 24.04 with kernel 6.8 on EPYC-Genoa, with the Rust toolchain at 1.99.0 and one declared thread. The receipt states explicitly that this is not a heterogeneous resource set.", "software": "A private immutable prepared plan retaining owned input identity plus live session, backend, memory, capability, affinity and freshness checks; one authoritative placement decision per two-GEMM region; a common optimised runner with a visible fallback trace.", "input": "A small-integer N32 two-dependent-GEMM region executed as eight calls per block, with all 1,024 final output elements checked on every measured call.", "samples": "1,200 measured calls, 450 warm-ups and 150 phase records across five arms of 30 paired blocks each. 240 calibrated measured rows with valid profiles and ages between 120 and 438 microseconds.", "statistic": "Nearest-rank block median and 95th percentile over 30 blocks, expressed as a ratio against the fixed named best eligible prepared local baseline, with a paired mean-ratio bootstrap of 10,000 resamples at a fixed seed.", "warmCold": "The qualifying arm is the calibrated prepared steady state. Preparation and calibration costs are charged to a separate first-use boundary and are not folded into the steady figure.", "network": "Loopback between the client and the two worker processes on the same host. Directional stream accounting excludes the enclosing transport overhead and private allocator peaks.", "serialization": "Traffic records retain actual remote transfer and residency behaviour separately from dispatcher local behaviour. Per-call codec and transfer accounting is carried in the campaign receipts.", "correctness": "Every one of the 1,200 measured calls reports 1,024 final output elements checked; the source aborts on any mismatch and the launch exit is zero. Independent re-summing of all eight caller times in each of the 150 blocks found zero mismatches, and no failed traffic records appear in the completed phases.", "sourceIds": [ "rt-src-prepared-s5-gatekeeper", "rt-src-prepared-s5-verification", "rt-src-prepared-s5-campaign" ], "id": "rt-prepared-s5-full-experiment", "title": "The complete cost of one whole experiment", "date": "2026-10-18", "scope": "Five arms over the same campaign: the calibrated prepared path, the local path, two forced worker arms and an uncalibrated arm.", "limitations": [ "Quantiles of nested phases cannot be added to the complete total; the absolute arm totals are the additive view.", "This is the prepared CPU scope only; a GPU arm was held.", "All measured dispatcher choices were local; the result measures the cost of the complete prepared path rather than a placement win.", "The complete-phase failure is preserved alongside the steady-state pass.", "Two worker processes shared one host, so the topology remains degenerate." ], "interpretation": "The complete experiment cost about 14.6 times the local baseline at the median and 16.3 times at the 95th percentile, with absolute totals of 281 ms for the calibrated arm against 19 ms for the local arm and about 494 ms and 496 ms for the two forced worker arms.", "rows": [ { "label": "median ratio of the complete experiment against the best eligible local baseline", "value": 14.5754098361, "unit": "ratio", "role": "metric", "n": 30, "statistic": "observed block median ratio on the complete experiment boundary" }, { "label": "95th percentile ratio of the complete experiment against the best eligible local baseline", "value": 16.25606469, "unit": "ratio", "role": "metric", "n": 30, "statistic": "observed block 95th percentile ratio on the complete experiment boundary" }, { "label": "complete experiment total, calibrated arm", "value": 280.571, "unit": "ms", "role": "remote", "n": 150, "statistic": "summed total across the calibrated arm, all phases" }, { "label": "complete experiment total, local arm", "value": 18.966, "unit": "ms", "role": "local", "n": 150, "statistic": "summed total across the local arm, all phases" }, { "label": "complete experiment total, first forced worker arm", "value": 493.861, "unit": "ms", "role": "remote", "n": 150, "statistic": "summed total across the first forced worker arm" }, { "label": "complete experiment total, second forced worker arm", "value": 496.184, "unit": "ms", "role": "remote", "n": 150, "statistic": "summed total across the second forced worker arm" }, { "label": "complete experiment total, uncalibrated arm", "value": 51.282, "unit": "ms", "role": "remote", "n": 150, "statistic": "summed total across the uncalibrated arm" }, { "label": "measured calls", "value": 1200, "unit": "calls", "role": "metric", "n": 150, "statistic": "1,200 measured calls across 150 phase records" } ], "comparisons": [ { "baseline": 2, "candidate": 3, "kind": "implementation" } ], "chart": false, "presentation": { "title": "The complete cost of one whole experiment", "question": "The honest total is everything, so I added up setup, preparation, calibration, warm-up, every measured call, the external checks and cleanup for each arm.", "comparison": "Five arms over the same campaign: the calibrated prepared path, the local path, two forced worker arms and an uncalibrated arm.", "finding": "The complete experiment cost about 14.6 times the local baseline at the median and 16.3 times at the 95th percentile, with absolute totals of 281 ms for the calibrated arm against 19 ms for the local arm and about 494 ms and 496 ms for the two forced worker arms.", "lesson": "The setup and preparation work dwarfs the steady cost by more than two orders of magnitude, and that is what decides whether the path is usable end to end.", "caveat": "Quantiles of nested phases cannot be added to the totals, so the absolute arm totals are the additive view, this covers the prepared CPU scope only with the accelerator arm held back, two workers shared one host, and every measured dispatcher decision chose local.", "kind": "Performance", "area": "Runtime", "labels": { "2": "Calibrated prepared path, complete total", "3": "Local execution, complete total", "4": "Forced worker arm, complete total", "5": "Second forced worker arm, complete total", "6": "Uncalibrated path, complete total" }, "featuredRows": [ 2, 3 ] }, "technical": { "original": { "title": "Prepared calibrated complete experiment phase, including every cost", "scope": "The complete experiment boundary: preparation, calibration, warm-ups, every measured call, the external oracles, instrumentation and cleanup. The receipt also publishes the absolute totals per arm. This boundary failed the predeclared bounds.", "interpretation": "Across the whole experiment the prepared path costs about 14.6 times the local baseline at the median and 16.3 times at the 95th percentile, while the local arm itself totals only about 19 ms and each forced worker arm about 0.5 s. The complete-phase cost is dominated by the non-steady boundaries: setup, preparation and calibration together exceed the steady cost by more than two orders of magnitude." } }, "chartSeries": [] }, { "topic": "GEMM", "evidence": "Measured", "href": "/research/runtime/", "hardware": "Two worker processes on one admitted CPU host, described in the receipt as correlated processes sharing the same hardware. The host is recorded as Ubuntu 24.04 with kernel 6.8 on EPYC-Genoa, with the Rust toolchain at 1.99.0 and one declared thread. The receipt states explicitly that this is not a heterogeneous resource set.", "software": "A private immutable prepared plan retaining owned input identity plus live session, backend, memory, capability, affinity and freshness checks; one authoritative placement decision per two-GEMM region; a common optimised runner with a visible fallback trace.", "input": "A small-integer N32 two-dependent-GEMM region executed as eight calls per block, with all 1,024 final output elements checked on every measured call.", "samples": "1,200 measured calls, 450 warm-ups and 150 phase records across five arms of 30 paired blocks each. 240 calibrated measured rows with valid profiles and ages between 120 and 438 microseconds.", "statistic": "Nearest-rank block median and 95th percentile over 30 blocks, expressed as a ratio against the fixed named best eligible prepared local baseline, with a paired mean-ratio bootstrap of 10,000 resamples at a fixed seed.", "warmCold": "The qualifying arm is the calibrated prepared steady state. Preparation and calibration costs are charged to a separate first-use boundary and are not folded into the steady figure.", "network": "Loopback between the client and the two worker processes on the same host. Directional stream accounting excludes the enclosing transport overhead and private allocator peaks.", "serialization": "Traffic records retain actual remote transfer and residency behaviour separately from dispatcher local behaviour. Per-call codec and transfer accounting is carried in the campaign receipts.", "correctness": "Every one of the 1,200 measured calls reports 1,024 final output elements checked; the source aborts on any mismatch and the launch exit is zero. Independent re-summing of all eight caller times in each of the 150 blocks found zero mismatches, and no failed traffic records appear in the completed phases.", "sourceIds": [ "rt-src-prepared-s5-gatekeeper", "rt-src-prepared-s5-verification", "rt-src-prepared-s5-campaign" ], "id": "rt-prepared-s5-steady-eight-call", "title": "The prepared path once it is warm and calibrated", "date": "2026-10-18", "scope": "Eight calls per block against the best eligible local baseline, over 30 paired blocks, with all 1,024 output elements checked on every call.", "limitations": [ "This is the steady leg only. Preparation, calibration, refresh and full-experiment cost are charged elsewhere and fail.", "All measured dispatcher choices were local; the result measures the cost of the remote path, not a placement win.", "Real remote execution is proved separately by forced worker baselines and is not claimed here.", "The paired mean-ratio interval upper endpoint exceeds the 1.10 median bound; the frozen decision rule uses observed quantiles with uncertainty disclosed rather than confidence-bound containment, so no robust population bound is claimed.", "The result is a thirty-block small-integer experiment and is not a universal numerical or tail guarantee.", "Retained payload and accounting are not an allocator, resident-set or enclosing transport trace." ], "interpretation": "The prepared path took 228 microseconds at the median and 259 at the 95th percentile against 211 and 228 locally, about 8 percent more at the median and 14 percent at the tail.", "rows": [ { "label": "prepared applied whole-workload wait, median", "value": 0.228, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank block median, 228 microseconds" }, { "label": "prepared applied whole-workload wait, 95th percentile", "value": 0.259, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank block 95th percentile, 259 microseconds" }, { "label": "best eligible local whole-workload wait, median", "value": 0.211, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank block median, 211 microseconds" }, { "label": "best eligible local whole-workload wait, 95th percentile", "value": 0.228, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank block 95th percentile, 228 microseconds" }, { "label": "median ratio against the best eligible local baseline", "value": 1.0805687204, "unit": "ratio", "role": "metric", "n": 30, "statistic": "observed block median ratio against the 1.10 bound" }, { "label": "95th percentile ratio against the best eligible local baseline", "value": 1.1359649123, "unit": "ratio", "role": "metric", "n": 30, "statistic": "observed block 95th percentile ratio against the 1.15 bound" }, { "label": "paired mean-ratio interval, lower bound", "value": 1.0469289615080855, "unit": "ratio", "role": "metric", "n": 30, "statistic": "10,000 paired resamples at the fixed seed" }, { "label": "paired mean-ratio interval, upper bound", "value": 1.1081226992587965, "unit": "ratio", "role": "metric", "n": 30, "statistic": "10,000 paired resamples at the fixed seed" }, { "label": "measured calls", "value": 1200, "unit": "calls", "role": "metric", "n": 150, "statistic": "1,200 measured calls across 150 phase records" }, { "label": "warm-up records", "value": 450, "unit": "calls", "role": "metric", "n": 150, "statistic": "untimed warm-up records in the campaign" }, { "label": "phase records", "value": 150, "unit": "blocks", "role": "metric", "n": 150, "statistic": "phase records carrying eight measured calls each" }, { "label": "calibrated measured rows with valid fresh profiles", "value": 240, "unit": "calls", "role": "metric", "n": 150, "statistic": "profile ages between 120 and 438 microseconds" }, { "label": "forced worker regions executed", "value": 480, "unit": "calls", "role": "metric", "n": 150, "statistic": "the recorded 240 real regions on each of two forced worker arms, summed" } ], "comparisons": [ { "baseline": 2, "candidate": 0, "kind": "remote-vs-local" }, { "baseline": 3, "candidate": 1, "kind": "remote-vs-local" } ], "chart": false, "presentation": { "title": "The prepared path once it is warm and calibrated", "question": "I wanted to know what the remote path costs when everything it needs is already in place, so I measured the steady state of a prepared and calibrated setup.", "comparison": "Eight calls per block against the best eligible local baseline, over 30 paired blocks, with all 1,024 output elements checked on every call.", "finding": "The prepared path took 228 microseconds at the median and 259 at the 95th percentile against 211 and 228 locally, about 8 percent more at the median and 14 percent at the tail.", "lesson": "Within the overhead I was willing to accept, the prepared path behaves like local; that is a statement about overhead, not an acceleration.", "caveat": "This is the steady leg only, since the first-use and complete-experiment legs fail and are published separately; every measured dispatcher decision chose local, the paired interval's upper end sits above the median bound, and a thirty-block small-integer experiment is not a general guarantee.", "kind": "Performance", "area": "Runtime", "labels": { "0": "Prepared path, median", "1": "Prepared path, 95th percentile", "2": "Local execution, median", "3": "Local execution, 95th percentile" }, "featuredRows": [ 0, 2 ] }, "technical": { "original": { "title": "Prepared calibrated steady-state eight-call workload, ratio against the best eligible local baseline", "scope": "The steady-state leg of a prepared multi-resource qualification: a pre-built artifact is attached and calibrated before measurement, so the boundary deliberately excludes preparation and calibration cost. The ratio against the best eligible single target passed the predeclared bounds.", "interpretation": "In the prepared steady state the dispatcher path costs about 8 percent more than the best eligible local baseline at the median and about 14 percent at the 95th percentile, inside the predeclared 10 and 15 percent bounds. The paired mean-ratio interval is disclosed with an upper endpoint above the median bound. Nothing here is an acceleration claim: every measured choice was local, and the remote path exists only in the forced correctness arms." } }, "chartSeries": [ { "title": "Prepared eight-call wait / p50", "indices": [ 2, 0 ], "labels": [ "Local", "Calibrated dispatcher" ] } ] }, { "topic": "GEMM", "evidence": "Measured", "href": "/research/runtime/", "hardware": "Two worker processes on one admitted CPU host, described in the receipt as correlated processes sharing the same hardware. The host is recorded as Ubuntu 24.04 with kernel 6.8 on EPYC-Genoa, with the Rust toolchain at 1.99.0 and one declared thread. The receipt states explicitly that this is not a heterogeneous resource set.", "software": "A private immutable prepared plan retaining owned input identity plus live session, backend, memory, capability, affinity and freshness checks; one authoritative placement decision per two-GEMM region; a common optimised runner with a visible fallback trace.", "input": "A small-integer N32 two-dependent-GEMM region executed as eight calls per block, with all 1,024 final output elements checked on every measured call.", "samples": "1,200 measured calls, 450 warm-ups and 150 phase records across five arms of 30 paired blocks each. 240 calibrated measured rows with valid profiles and ages between 120 and 438 microseconds.", "statistic": "Nearest-rank block median and 95th percentile over 30 blocks, expressed as a ratio against the fixed named best eligible prepared local baseline, with a paired mean-ratio bootstrap of 10,000 resamples at a fixed seed.", "warmCold": "The qualifying arm is the calibrated prepared steady state. Preparation and calibration costs are charged to a separate first-use boundary and are not folded into the steady figure.", "network": "Loopback between the client and the two worker processes on the same host. Directional stream accounting excludes the enclosing transport overhead and private allocator peaks.", "serialization": "Traffic records retain actual remote transfer and residency behaviour separately from dispatcher local behaviour. Per-call codec and transfer accounting is carried in the campaign receipts.", "correctness": "Every one of the 1,200 measured calls reports 1,024 final output elements checked; the source aborts on any mismatch and the launch exit is zero. Independent re-summing of all eight caller times in each of the 150 blocks found zero mismatches, and no failed traffic records appear in the completed phases.", "sourceIds": [ "rt-src-prepared-s5-gatekeeper", "rt-src-prepared-s5-verification", "rt-src-prepared-s5-campaign" ], "id": "rt-prepared-s5-unknown-steady", "title": "The same steady state without a valid calibration", "date": "2026-10-18", "scope": "The uncalibrated steady arm against the same local baseline, inside the same campaign as the calibrated arm.", "limitations": [ "This arm is not the qualifying arm; it is retained to show the tail behaviour when calibration is absent.", "Its tail failure is preserved and no criterion was narrowed to accommodate it.", "The historical uncalibrated tail failure recorded at the qualification itself, a 95th percentile ratio of 1.2587719298, is retained alongside this arm.", "All measured dispatcher choices were local." ], "interpretation": "Its median ratio was 1.047, close to the local baseline, but its 95th-percentile ratio was 1.259, above the 1.15 tail limit I had set, so the arm failed exactly where the calibrated arm passed.", "rows": [ { "label": "median ratio of the uncalibrated steady arm against the best eligible local baseline", "value": 1.0473933649, "unit": "ratio", "role": "metric", "n": 30, "statistic": "observed block median ratio" }, { "label": "95th percentile ratio of the uncalibrated steady arm against the best eligible local baseline", "value": 1.2587719298, "unit": "ratio", "role": "metric", "n": 30, "statistic": "observed block 95th percentile ratio, above the 1.15 bound" }, { "label": "complete experiment total, uncalibrated arm", "value": 51.282, "unit": "ms", "role": "remote", "n": 150, "statistic": "summed total across the uncalibrated arm, all phases" }, { "label": "measured calls", "value": 1200, "unit": "calls", "role": "metric", "n": 150, "statistic": "1,200 measured calls across 150 phase records" } ], "comparisons": [], "chart": false, "presentation": { "title": "The same steady state without a valid calibration", "question": "I wanted to know how much the calibration actually buys, so I kept the uncalibrated arm of the same campaign and read it on its own.", "comparison": "The uncalibrated steady arm against the same local baseline, inside the same campaign as the calibrated arm.", "finding": "Its median ratio was 1.047, close to the local baseline, but its 95th-percentile ratio was 1.259, above the 1.15 tail limit I had set, so the arm failed exactly where the calibrated arm passed.", "lesson": "Calibration is what keeps the tail inside its limit; without it the average looks fine and the worst case does not.", "caveat": "This arm is not the one that met the criteria and is kept visible precisely because it failed, no criterion was widened to accommodate it, and every measured dispatcher decision chose local.", "kind": "Performance", "area": "Runtime" }, "technical": { "original": { "title": "Uncalibrated steady-state eight-call workload, retained as a failing tail bound", "scope": "The same steady-state boundary measured without a valid calibration. The qualifying arm is the calibrated one, so this arm is retained rather than promoted: its 95th percentile ratio breaches the tail bound and that failure is preserved.", "interpretation": "Without calibration the median ratio is close to the local baseline but the 95th percentile ratio breaches the tail bound, so the uncalibrated arm fails where the calibrated arm passes. This is the reason the qualification names the calibrated arm explicitly and keeps the uncalibrated result visible rather than discarding it." } }, "chartSeries": [] }, { "id": "rt-s5-windows-linux-object-interop", "title": "A Windows client working against a Linux worker", "topic": "Interoperability", "date": "2026-10-18", "evidence": "Measured", "scope": "Uploading a 4 by 4 object set, referencing it three times, executing one multiplication, and then deliberately violating the protocol in three ways.", "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.", "statistic": "Counts of references, executions, checked elements and negatives, plus one recorded end-to-end duration and the directional stream counters. No distribution is published.", "warmCold": "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": "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.", "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." ], "interpretation": "All 16 output elements were checked and correct, the three violations, a stale epoch, a released handle and the wrong worker, were each refused, the worker released every resident byte at the end, and the session moved 2,053 bytes out and 1,141 back in 12.5 seconds.", "href": "/research/native-interception/", "sourceIds": [ "rt-src-prepared-s5-object-result", "rt-src-prepared-s5-windows-build", "rt-src-prepared-s5-verification" ], "rows": [ { "label": "final output elements checked", "value": 16, "unit": "cases", "role": "metric", "n": 1, "statistic": "all 16 elements of the 4 by 4 f32 output" }, { "label": "references issued", "value": 3, "unit": "calls", "role": "metric", "n": 1, "statistic": "references against the uploaded object set" }, { "label": "executions", "value": 1, "unit": "calls", "role": "metric", "n": 1, "statistic": "one multiplication executed by the worker" }, { "label": "negative paths exercised", "value": 3, "unit": "cases", "role": "metric", "n": 3, "statistic": "stale epoch, released handle and wrong worker" }, { "label": "outbound stream bytes", "value": 2053, "unit": "bytes", "role": "metric", "n": 1, "statistic": "directional stream counter for the session" }, { "label": "inbound stream bytes", "value": 1141, "unit": "bytes", "role": "metric", "n": 1, "statistic": "directional stream counter for the session" }, { "label": "end-to-end session duration", "value": 12463.547, "unit": "ms", "role": "metric", "n": 1, "statistic": "single recorded duration under an explicit absolute deadline" }, { "label": "resident bytes after release", "value": 0, "unit": "bytes", "role": "metric", "n": 1, "statistic": "the worker released to zero resident bytes" } ], "comparisons": [], "chart": false, "presentation": { "title": "A Windows client working against a Linux worker", "question": "The next question was whether the two sides can actually talk to each other across operating systems, so I ran a live exchange from Windows to a Linux worker.", "comparison": "Uploading a 4 by 4 object set, referencing it three times, executing one multiplication, and then deliberately violating the protocol in three ways.", "finding": "All 16 output elements were checked and correct, the three violations, a stale epoch, a released handle and the wrong worker, were each refused, the worker released every resident byte at the end, and the session moved 2,053 bytes out and 1,141 back in 12.5 seconds.", "lesson": "The object protocol works across operating systems for the demonstrated path, with clean cleanup and no leaked residency.", "caveat": "One session and one execution, the object shape is small so nothing is established about scale or throughput, only the client-to-worker direction was exercised, and the result is functional rather than a performance one.", "kind": "Functional check", "area": "Splice", "labels": { "0": "Output elements checked", "1": "References issued", "2": "Executions", "3": "Negative paths exercised", "4": "Outbound bytes", "5": "Inbound bytes", "6": "End-to-end duration", "7": "Resident bytes after release" }, "featuredRows": [ 0, 3 ] }, "technical": { "original": { "title": "Windows client exchanging objects with a Linux worker", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "rt-cn-002-gemm-thread-scaling", "title": "How the local multiplication scales with threads", "topic": "GEMM", "date": "2026-10-17", "evidence": "Measured", "scope": "Square f32 and f64 multiplications at 256, 512, 1024 and 2048 elements per side, at one, two, four and eight threads, and once with the machine squeezed onto a single busy core.", "hardware": "One node with 8 dedicated EPYC-Milan vCPUs, 30 GiB of memory, 4 GiB of swap and 225 GB of disk, running Ubuntu 26.04.1 with no accelerator present. The virtual size recorded alongside the eight-thread run is 1,286,156 kB.", "software": "Optimised OpenBLAS 0.3.32 through the system CBLAS interface; the runtime binary compiled with Rust 1.99.1.", "input": "Dense square f32 and f64 matrix multiplications of side 256, 512, 1024 and 2048, with alpha 1 and beta 0.", "samples": "20 repetitions for sides 256, 512 and 1024 and 10 repetitions for side 2048, per thread configuration.", "statistic": "Median and 95th percentile per shape and thread configuration; the recorded 95th percentiles are quoted for the largest shape.", "warmCold": "Every repetition runs in one warmed process. No cold-start cost is separated from the measured repetitions.", "network": "None. This is a local arithmetic benchmark with no transport involved.", "serialization": "None. The benchmark produces no request or response frame.", "correctness": "The benchmark is not the subject of correctness. Its outputs are used elsewhere as the local reference for the comparison campaigns.", "limitations": [ "The contended configuration is described as one contended core with eight threads, so it measures scheduling interference rather than a reduced thread count.", "The virtual size recorded next to the eight-thread run is far larger than the resident set and is not a resident-memory figure.", "Only the largest shape is quoted with its 95th percentile in the published rows; the smaller shapes are quoted at the median.", "This is a node baseline and not evidence for the frozen useful-workload gate." ], "interpretation": "The 2048 f32 case fell from 156 ms on one thread to 80, 44 and then 38 ms as threads increased, and squeezing the machine onto one busy core pushed the eight-thread figure back up to 66 ms; the f64 case went from 315 ms to 82 ms.", "href": "/research/runtime/", "sourceIds": [ "rt-src-cn-gemm-idle-t1", "rt-src-cn-gemm-idle-t2", "rt-src-cn-gemm-idle-t4", "rt-src-cn-gemm-idle-t8", "rt-src-cn-gemm-contended", "rt-src-cn-node-acceptance" ], "rows": [ { "label": "2048 f32 GEMM, 1 thread, median", "value": 156.4289, "unit": "ms", "role": "local", "n": 10, "statistic": "median of 10 repetitions" }, { "label": "2048 f32 GEMM, 2 threads, median", "value": 80.5002, "unit": "ms", "role": "local", "n": 10, "statistic": "median of 10 repetitions" }, { "label": "2048 f32 GEMM, 4 threads, median", "value": 43.5208, "unit": "ms", "role": "local", "n": 10, "statistic": "median of 10 repetitions" }, { "label": "2048 f32 GEMM, 8 threads, median", "value": 38.4522, "unit": "ms", "role": "local", "n": 10, "statistic": "median of 10 repetitions" }, { "label": "2048 f32 GEMM, 8 threads on one contended core, median", "value": 65.9984, "unit": "ms", "role": "local", "n": 10, "statistic": "median of 10 repetitions" }, { "label": "2048 f64 GEMM, 1 thread, median", "value": 315.1201, "unit": "ms", "role": "local", "n": 10, "statistic": "median of 10 repetitions" }, { "label": "2048 f64 GEMM, 2 threads, median", "value": 164.0491, "unit": "ms", "role": "local", "n": 10, "statistic": "median of 10 repetitions" }, { "label": "2048 f64 GEMM, 4 threads, median", "value": 83.1243, "unit": "ms", "role": "local", "n": 10, "statistic": "median of 10 repetitions" }, { "label": "2048 f64 GEMM, 8 threads, median", "value": 81.6981, "unit": "ms", "role": "local", "n": 10, "statistic": "median of 10 repetitions" }, { "label": "2048 f64 GEMM, 8 threads on one contended core, median", "value": 124.2526, "unit": "ms", "role": "local", "n": 10, "statistic": "median of 10 repetitions" }, { "label": "1024 f32 GEMM, 1 thread, median", "value": 19.5584, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "1024 f32 GEMM, 2 threads, median", "value": 9.9168, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "1024 f32 GEMM, 4 threads, median", "value": 5.2422, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "1024 f32 GEMM, 8 threads, median", "value": 5.2193, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "1024 f32 GEMM, 8 threads on one contended core, median", "value": 10.7429, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "512 f32 GEMM, 1 thread, median", "value": 2.4684, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "512 f32 GEMM, 2 threads, median", "value": 1.2564, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "512 f32 GEMM, 4 threads, median", "value": 0.6707, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "512 f32 GEMM, 8 threads, median", "value": 0.6931, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "512 f32 GEMM, 8 threads on one contended core, median", "value": 3.2269, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "256 f32 GEMM, 1 thread, median", "value": 0.3226, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "256 f32 GEMM, 2 threads, median", "value": 0.1727, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "256 f32 GEMM, 4 threads, median", "value": 0.0882, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "256 f32 GEMM, 8 threads, median", "value": 0.1079, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" }, { "label": "256 f32 GEMM, 8 threads on one contended core, median", "value": 2.9923, "unit": "ms", "role": "local", "n": 20, "statistic": "median of 20 repetitions" } ], "comparisons": [ { "baseline": 0, "candidate": 3, "kind": "implementation" }, { "baseline": 3, "candidate": 4, "kind": "implementation" } ], "chart": true, "presentation": { "title": "How the local multiplication scales with threads", "question": "Every remote comparison is read against a local number, so I measured how that local number changes with thread count and under contention.", "comparison": "Square f32 and f64 multiplications at 256, 512, 1024 and 2048 elements per side, at one, two, four and eight threads, and once with the machine squeezed onto a single busy core.", "finding": "The 2048 f32 case fell from 156 ms on one thread to 80, 44 and then 38 ms as threads increased, and squeezing the machine onto one busy core pushed the eight-thread figure back up to 66 ms; the f64 case went from 315 ms to 82 ms.", "lesson": "The local arithmetic flattens after four threads, and how loaded the machine is changes that baseline by roughly a factor of two, which changes every comparison built on top of it.", "caveat": "One node with eight dedicated cores and no accelerator, every repetition inside one warmed process so no start-up cost is separated, the contended case measures scheduling interference rather than fewer threads, and the large virtual size recorded beside the run is not a memory figure.", "kind": "Performance", "area": "Runtime", "labels": { "0": "2048 f32, 1 thread", "1": "2048 f32, 2 threads", "2": "2048 f32, 4 threads", "3": "2048 f32, 8 threads", "4": "2048 f32, 8 threads on one busy core", "5": "2048 f64, 1 thread", "6": "2048 f64, 2 threads", "7": "2048 f64, 4 threads", "8": "2048 f64, 8 threads", "9": "2048 f64, 8 threads on one busy core", "10": "1024 f32, 1 thread", "11": "1024 f32, 2 threads", "12": "1024 f32, 4 threads", "13": "1024 f32, 8 threads", "14": "1024 f32, 8 threads on one busy core", "15": "512 f32, 1 thread", "16": "512 f32, 2 threads", "17": "512 f32, 4 threads", "18": "512 f32, 8 threads", "19": "512 f32, 8 threads on one busy core", "20": "256 f32, 1 thread", "21": "256 f32, 2 threads", "22": "256 f32, 4 threads", "23": "256 f32, 8 threads", "24": "256 f32, 8 threads on one busy core" }, "featuredRows": [ 0, 1, 2, 3 ] }, "technical": { "original": { "title": "Node GEMM microbenchmark across thread counts and under CPU contention", "scope": "A standalone multiplication benchmark on one node, repeated at four thread counts on an otherwise idle machine and once with the machine contended to a single core. It characterises the local arithmetic cost that the remote arms are compared against.", "interpretation": "The local arithmetic cost falls steeply from one to four threads and then flattens, with the 2048 square f32 case moving from about 156 ms single-threaded to about 38 ms at eight threads. A one-core contention event roughly doubles the eight-thread result at the largest shape, so a shared host materially changes the local baseline against which any remote comparison is read." } }, "chartSeries": [] }, { "id": "rt-cn-codec-link-matrix", "title": "How the codec stack behaves on friendly and hostile payloads", "topic": "Representation", "date": "2026-10-17", "evidence": "Measured", "scope": "Raw, two zstd levels and lz4 over a structured payload and over a random payload of the same size, then the same four modes repeated over a tunnel.", "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.", "statistic": "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.", "warmCold": "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": "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.", "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." ], "interpretation": "On the structured payload the upload fell from 49,400 bytes raw to 311 bytes with zstd level 1 and 292 with level 3, and the transfer from 565 ms to about 90 ms; on the random payload zstd level 3 saved only about a tenth of the upload and lz4 saved nothing, while over the tunnel the first raw transfer cost 6.5 ms and the third 0.37 ms as the profile store warmed.", "href": "/research/resynth/", "sourceIds": [ "rt-src-cn-compression-link", "rt-src-cn-measured-link", "rt-src-cn-node-acceptance", "rt-src-cn-chunk-bench" ], "rows": [ { "label": "structured payload, raw: upload bytes", "value": 49400, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "structured payload, raw: download bytes", "value": 16485, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "structured payload, raw: elapsed", "value": 564.776, "unit": "ms", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "structured payload, zstd level 1: upload bytes", "value": 311, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "structured payload, zstd level 1: download bytes", "value": 771, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "structured payload, zstd level 1: elapsed", "value": 90.311, "unit": "ms", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "structured payload, zstd level 3: upload bytes", "value": 292, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "structured payload, zstd level 3: download bytes", "value": 835, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "structured payload, zstd level 3: elapsed", "value": 101.093, "unit": "ms", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "structured payload, lz4: upload bytes", "value": 487, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "structured payload, lz4: download bytes", "value": 1408, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "structured payload, lz4: elapsed", "value": 106.112, "unit": "ms", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "random payload, raw: upload bytes", "value": 49400, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "random payload, raw: download bytes", "value": 16485, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "random payload, raw: elapsed", "value": 564.055, "unit": "ms", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "random payload, zstd level 1: upload bytes", "value": 44475, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "random payload, zstd level 1: download bytes", "value": 15405, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "random payload, zstd level 1: elapsed", "value": 518.634, "unit": "ms", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "random payload, zstd level 3: upload bytes", "value": 44451, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "random payload, zstd level 3: download bytes", "value": 15403, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "random payload, zstd level 3: elapsed", "value": 529.126, "unit": "ms", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "random payload, lz4: upload bytes", "value": 49560, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "random payload, lz4: download bytes", "value": 16646, "unit": "bytes", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "random payload, lz4: elapsed", "value": 607.937, "unit": "ms", "role": "remote", "n": 1, "statistic": "single recorded loopback transfer" }, { "label": "repeated payload, local path: elapsed, first recorded transfer", "value": 0.054, "unit": "ms", "role": "local", "n": 1, "statistic": "first recorded transfer of the group" }, { "label": "repeated payload, local path: upload bytes", "value": 0, "unit": "bytes", "role": "local", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "repeated payload, local path: download bytes", "value": 0, "unit": "bytes", "role": "local", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "repeated payload, raw: elapsed, first recorded transfer", "value": 6.533, "unit": "ms", "role": "remote", "n": 1, "statistic": "first recorded transfer of the group" }, { "label": "repeated payload, raw: elapsed, last recorded transfer", "value": 0.367, "unit": "ms", "role": "remote", "n": 3, "statistic": "last recorded transfer of the group (sample 2), after the profile cache is warm" }, { "label": "repeated payload, raw: upload bytes", "value": 49397, "unit": "bytes", "role": "remote", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "repeated payload, raw: download bytes", "value": 16482, "unit": "bytes", "role": "remote", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "repeated payload, zstd level 1: elapsed, first recorded transfer", "value": 51.921, "unit": "ms", "role": "remote", "n": 1, "statistic": "first recorded transfer of the group" }, { "label": "repeated payload, zstd level 1: elapsed, last recorded transfer", "value": 40.641, "unit": "ms", "role": "remote", "n": 3, "statistic": "last recorded transfer of the group (sample 2), after the profile cache is warm" }, { "label": "repeated payload, zstd level 1: upload bytes", "value": 302, "unit": "bytes", "role": "remote", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "repeated payload, zstd level 1: download bytes", "value": 626, "unit": "bytes", "role": "remote", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "repeated payload, zstd level 1: worker profile cost, first recorded transfer", "value": 1.396, "unit": "ms", "role": "metric", "n": 1, "statistic": "worker-side profile cost on the first recorded transfer" }, { "label": "repeated payload, zstd level 1: worker profile cost, last recorded transfer", "value": 0.022, "unit": "ms", "role": "metric", "n": 1, "statistic": "worker-side profile cost once the profile cache is warm" }, { "label": "repeated payload, lz4: elapsed, first recorded transfer", "value": 43.188, "unit": "ms", "role": "remote", "n": 1, "statistic": "first recorded transfer of the group" }, { "label": "repeated payload, lz4: elapsed, last recorded transfer", "value": 40.864, "unit": "ms", "role": "remote", "n": 3, "statistic": "last recorded transfer of the group (sample 2), after the profile cache is warm" }, { "label": "repeated payload, lz4: upload bytes", "value": 487, "unit": "bytes", "role": "remote", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "repeated payload, lz4: download bytes", "value": 635, "unit": "bytes", "role": "remote", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "repeated payload, lz4: worker profile cost, first recorded transfer", "value": 0.027, "unit": "ms", "role": "metric", "n": 1, "statistic": "worker-side profile cost on the first recorded transfer" }, { "label": "repeated payload, lz4: worker profile cost, last recorded transfer", "value": 0.023, "unit": "ms", "role": "metric", "n": 1, "statistic": "worker-side profile cost once the profile cache is warm" }, { "label": "random payload, local path: elapsed, first recorded transfer", "value": 0.016, "unit": "ms", "role": "local", "n": 1, "statistic": "first recorded transfer of the group" }, { "label": "random payload, local path: upload bytes", "value": 0, "unit": "bytes", "role": "local", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "random payload, local path: download bytes", "value": 0, "unit": "bytes", "role": "local", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "random payload, raw: elapsed, first recorded transfer", "value": 0.375, "unit": "ms", "role": "remote", "n": 1, "statistic": "first recorded transfer of the group" }, { "label": "random payload, raw: elapsed, last recorded transfer", "value": 0.346, "unit": "ms", "role": "remote", "n": 3, "statistic": "last recorded transfer of the group (sample 2), after the profile cache is warm" }, { "label": "random payload, raw: upload bytes", "value": 49397, "unit": "bytes", "role": "remote", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "random payload, raw: download bytes", "value": 16482, "unit": "bytes", "role": "remote", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "random payload, zstd level 1: elapsed, first recorded transfer", "value": 41.442, "unit": "ms", "role": "remote", "n": 1, "statistic": "first recorded transfer of the group" }, { "label": "random payload, zstd level 1: elapsed, last recorded transfer", "value": 41.255, "unit": "ms", "role": "remote", "n": 3, "statistic": "last recorded transfer of the group (sample 2), after the profile cache is warm" }, { "label": "random payload, zstd level 1: upload bytes", "value": 29784, "unit": "bytes", "role": "remote", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "random payload, zstd level 1: download bytes", "value": 15583, "unit": "bytes", "role": "remote", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "random payload, zstd level 1: worker profile cost, first recorded transfer", "value": 0.726, "unit": "ms", "role": "metric", "n": 1, "statistic": "worker-side profile cost on the first recorded transfer" }, { "label": "random payload, zstd level 1: worker profile cost, last recorded transfer", "value": 0.024, "unit": "ms", "role": "metric", "n": 1, "statistic": "worker-side profile cost once the profile cache is warm" }, { "label": "random payload, lz4: elapsed, first recorded transfer", "value": 0.335, "unit": "ms", "role": "remote", "n": 1, "statistic": "first recorded transfer of the group" }, { "label": "random payload, lz4: elapsed, last recorded transfer", "value": 0.338, "unit": "ms", "role": "remote", "n": 3, "statistic": "last recorded transfer of the group (sample 2), after the profile cache is warm" }, { "label": "random payload, lz4: upload bytes", "value": 33273, "unit": "bytes", "role": "remote", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "random payload, lz4: download bytes", "value": 16775, "unit": "bytes", "role": "remote", "n": 1, "statistic": "recorded application-stream bytes" }, { "label": "random payload, lz4: worker profile cost, first recorded transfer", "value": 0.015, "unit": "ms", "role": "metric", "n": 1, "statistic": "worker-side profile cost on the first recorded transfer" }, { "label": "random payload, lz4: worker profile cost, last recorded transfer", "value": 0.016, "unit": "ms", "role": "metric", "n": 1, "statistic": "worker-side profile cost once the profile cache is warm" } ], "comparisons": [ { "baseline": 18, "candidate": 12, "kind": "compression" }, { "baseline": 6, "candidate": 0, "kind": "compression" }, { "baseline": 20, "candidate": 14, "kind": "compression" } ], "chart": false, "presentation": { "title": "How the codec stack behaves on friendly and hostile payloads", "question": "I wanted the compression behaviour and its warm-up cost measured together, so I ran a codec matrix over loopback and then the same stack through an authenticated tunnel with repeated transfers.", "comparison": "Raw, two zstd levels and lz4 over a structured payload and over a random payload of the same size, then the same four modes repeated over a tunnel.", "finding": "On the structured payload the upload fell from 49,400 bytes raw to 311 bytes with zstd level 1 and 292 with level 3, and the transfer from 565 ms to about 90 ms; on the random payload zstd level 3 saved only about a tenth of the upload and lz4 saved nothing, while over the tunnel the first raw transfer cost 6.5 ms and the third 0.37 ms as the profile store warmed.", "lesson": "The compression behaves honestly, near-total on structured data and almost nothing on random bytes, and the one-off profiling cost lands on the first transfer rather than being hidden.", "caveat": "One transfer per condition in the matrix, so the byte counts are repeatable but the timings are single observations, three transfers per group in the tunnel run with no distribution, a separate chunked-transfer test could not run on that operating system, and the two payload kinds are not interchangeable inputs.", "kind": "Performance", "area": "ReSynth", "featuredRows": [ 2, 5, 8, 11 ] }, "technical": { "original": { "title": "Codec matrix and authenticated tunnel timing, structured and random payloads, cold and warm profile", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "rt-cn-s5-002-node-four-mode", "title": "Running the workload through a worker over the loopback interface", "topic": "GEMM", "date": "2026-10-17", "evidence": "Measured", "scope": "In-process execution, a worker started fresh for each block, and a persistent worker, all over the loopback interface on a dedicated eight-core machine.", "hardware": "A dedicated compute node with 8 dedicated EPYC-Milan vCPUs, 30 GiB of memory, 4 GiB of swap and 225 GB of disk, running Ubuntu 26.04.1 with no accelerator present.", "software": "Optimised OpenBLAS 0.3.32 with 8 threads for the local arm; Rust toolchain 1.99.1; loopback transport; the admitted reference BLAS provider image could not be bound on this operating system, so the resident-object arm was not run.", "input": "A 2048 by 2048 by 2048 f32 row-major GEMM per call, alpha 1, beta 0, eight calls per workload, with pseudo-random operands in the range 0.5 to 1.5 and a per-output digest recorded.", "samples": "30 blocks of 8 calls per arm, with 3 untimed warm-ups per arm.", "statistic": "Nearest-rank 95th percentile and median over 30 blocks; paired median differences against the local arm with a 10,000-resample seeded bootstrap.", "warmCold": "The cold arm starts a fresh worker process for every block over loopback; the warm arm reuses a persistent worker. The local arm executes in process with 3 untimed warm-ups.", "network": "Loopback TCP only. No external link, no tunnel and no encryption overhead is involved.", "serialization": "Not recorded as a separate figure in this campaign report.", "correctness": "A f64 oracle on the 4 by 4 corner slice with the tolerance 1e-4 plus 1e-4 relative, plus a per-output SHA-256 digest. Every block in all three arms was oracle-true.", "limitations": [ "Three arms only; the resident-object arm was absent because the pinned admitted provider userland was not yet available on that node.", "Two worker processes shared one host, so the topology is degenerate and no heterogeneous resource is represented.", "Every measured dispatcher choice was local, so the result shows the cost of the worker path rather than a placement win.", "This is a node baseline and not evidence for the frozen useful-workload gate." ], "interpretation": "The local median was 766 ms while the fresh worker took 2.25 s and the persistent worker 2.22 s, so the worker path added roughly 1.45 seconds per workload.", "href": "/research/runtime/", "sourceIds": [ "rt-src-cn-s5-002", "rt-src-cn-node-acceptance", "rt-src-cn-s4-v4-protocol" ], "rows": [ { "label": "local whole-workload wait, median", "value": 765.85, "unit": "ms", "role": "local", "n": 30, "statistic": "arithmetic median of 30 blocks" }, { "label": "local whole-workload wait, 95th percentile", "value": 780.59, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank 95th percentile of 30 blocks" }, { "label": "cold worker whole-workload wait, median", "value": 2246.09, "unit": "ms", "role": "remote", "n": 30, "statistic": "arithmetic median of 30 blocks" }, { "label": "cold worker whole-workload wait, 95th percentile", "value": 2267.04, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank 95th percentile of 30 blocks" }, { "label": "warm worker whole-workload wait, median", "value": 2216.48, "unit": "ms", "role": "remote", "n": 30, "statistic": "arithmetic median of 30 blocks" }, { "label": "warm worker whole-workload wait, 95th percentile", "value": 2231.08, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank 95th percentile of 30 blocks" }, { "label": "paired difference of local over cold worker", "value": -1479.15, "unit": "ms", "role": "metric", "n": 30, "statistic": "paired median difference with a 10,000-resample seeded bootstrap" }, { "label": "paired difference interval, lower bound", "value": -1482.24, "unit": "ms", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval" }, { "label": "paired difference interval, upper bound", "value": -1476.24, "unit": "ms", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval" }, { "label": "paired difference of local over warm worker", "value": -1446.77, "unit": "ms", "role": "metric", "n": 30, "statistic": "paired median difference with a 10,000-resample seeded bootstrap" }, { "label": "paired difference interval, lower bound", "value": -1452.1, "unit": "ms", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval" }, { "label": "paired difference interval, upper bound", "value": -1441.39, "unit": "ms", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval" }, { "label": "measured calls per arm", "value": 240, "unit": "calls", "role": "metric", "n": 30, "statistic": "30 blocks of 8 calls per arm, giving 240 measured calls per arm" }, { "label": "measured blocks per arm", "value": 30, "unit": "blocks", "role": "metric", "n": 30, "statistic": "blocks per arm" } ], "comparisons": [ { "baseline": 0, "candidate": 2, "kind": "remote-vs-local" }, { "baseline": 1, "candidate": 3, "kind": "remote-vs-local" }, { "baseline": 2, "candidate": 4, "kind": "implementation" } ], "chart": false, "presentation": { "title": "Running the workload through a worker over the loopback interface", "question": "I wanted a clean baseline with no external link anywhere in it, so I compared three ways of running the same arithmetic on one quiet node.", "comparison": "In-process execution, a worker started fresh for each block, and a persistent worker, all over the loopback interface on a dedicated eight-core machine.", "finding": "The local median was 766 ms while the fresh worker took 2.25 s and the persistent worker 2.22 s, so the worker path added roughly 1.45 seconds per workload.", "lesson": "On a single machine the cheapest eligible target for this workload was simply local, and I measured that rather than assuming it.", "caveat": "Only three of the four planned modes ran because the fixed provider image could not be bound on that operating system, two workers shared the host so no heterogeneous pairing is represented, and every dispatcher decision in the campaign chose local.", "kind": "Performance", "area": "Runtime", "labels": { "0": "Local execution, median", "1": "Local execution, 95th percentile", "2": "Fresh worker, median", "3": "Fresh worker, 95th percentile", "4": "Persistent worker, median", "5": "Persistent worker, 95th percentile" }, "featuredRows": [ 0, 2, 4 ] }, "technical": { "original": { "title": "Node four-mode comparison with local, process-cold and warm worker arms", "scope": "A three-arm comparison on a single quiescent node over loopback: in-process local BLAS, a process-cold worker started per block, and a persistent worker. The resident-object arm was not part of this campaign because the pinned provider userland required for it was not yet in place on that node.", "interpretation": "The worker path adds roughly 1.45 to 1.48 seconds per workload of loopback transfer and protocol overhead against the in-process local arm, so the best eligible single target for this workload is local, measured rather than assumed. The comparison is between two implementations of the same arithmetic on one machine." } }, "chartSeries": [] }, { "id": "rt-cn-s5-003-node-resident-four-mode", "title": "Adding the resident-operand mode once the worker could be bound", "topic": "GEMM", "date": "2026-10-17", "evidence": "Measured", "scope": "Four arms, local, fresh worker, persistent worker and resident operand, across 30 blocks with 960 checked calls.", "hardware": "The qualifying userland runs on an 8 dedicated EPYC-Milan vCPUs, 30 GiB of memory node running Ubuntu 26.04.1, with the worker executed under the pinned dynamic loader and the five digest-verified provider images: the admitted reference BLAS at 677,880 bytes, plus the pinned C library, math library, compiler runtime and loader. Live-binding offsets are pinned to one CPU variant, so a different host needs a new admission profile. The accelerator model is not applicable to this campaign.", "software": "Rust toolchain 1.99.0 on the qualifying userland; the admitted reference BLAS provider; loopback transport. The worker starts and passes provider admission with a resident-set figure of 6 MB under a 256 MiB cap.", "input": "A 2048 by 2048 by 2048 f32 row-major GEMM per call, alpha 1, beta 0, eight calls per workload.", "samples": "120 measured trials across 30 blocks containing all four arms, plus 10 warm-up trials recorded in the same array. 960 measured calls, all correct.", "statistic": "Call median and workload median; paired median difference against the local arm with a 95 percent bootstrap interval.", "warmCold": "Three untimed rehearsals precede the measured blocks. The cold arm restarts the worker process for every block; the resident arm uploads the resident operand once per block and clears residency and staging at block boundaries.", "network": "Loopback only. A separate shaped-link campaign in the same receipt measures constrained rates and is recorded separately.", "serialization": "Per-call framed traffic and logical byte counts are recorded. The resident arm skips the repeated operand upload on every call after the first, and the receipt records the skip flag on 264 resident call records.", "correctness": "960 of 960 measured calls correct, against an independent single-thread direct-CBLAS reference plus an 8 by 8 f64 scalar slice per call. Object lifecycle was verified per trial with residency and staging counts returning to zero after release and exact execution, reference and byte counters.", "limitations": [ "The harness summary for the per-arm percentiles includes the 10 warm-up trials while the paired and gate analysis uses only blocks 0 to 29; both accounting methods are disclosed here.", "The live-binding offsets are pinned to one CPU variant, so the result is not transferable to a different host without a new admission profile.", "The frozen useful-workload gate was applied and failed; the receipt preserves that failure and makes no pass claim.", "The runner header hardcoded a shape value regardless of the actual shape; this was corrected in the runner and the shape attributions here rest on the per-call durations and the recorded invocation arguments.", "Two worker processes shared one host, so the topology remains degenerate." ], "interpretation": "The local workload median was 3.44 s and the three remote arms 30,347, 30,604 and 29.5 s, so the resident arm was about 7.6 times slower than local even though it avoided 117 MB of operand uploads per block, roughly 3.3 GB across the campaign.", "href": "/research/runtime/", "sourceIds": [ "rt-src-cn-s5-003", "rt-src-cn-s4-v4-protocol", "rt-src-s4-protocol" ], "rows": [ { "label": "local call wait, median", "value": 422.27, "unit": "ms", "role": "local", "n": 240, "statistic": "median of 240 measured calls" }, { "label": "local whole-workload wait, median", "value": 3438.94, "unit": "ms", "role": "local", "n": 30, "statistic": "median of 30 blocks" }, { "label": "cold worker call wait, median", "value": 3792.46, "unit": "ms", "role": "remote", "n": 240, "statistic": "median of 240 measured calls" }, { "label": "cold worker whole-workload wait, median", "value": 30347.13, "unit": "ms", "role": "remote", "n": 30, "statistic": "median of 30 blocks" }, { "label": "warm worker call wait, median", "value": 3800.73, "unit": "ms", "role": "remote", "n": 240, "statistic": "median of 240 measured calls" }, { "label": "warm worker whole-workload wait, median", "value": 30604.44, "unit": "ms", "role": "remote", "n": 30, "statistic": "median of 30 blocks" }, { "label": "resident object call wait, median", "value": 3656.95, "unit": "ms", "role": "remote", "n": 240, "statistic": "median of 240 measured calls" }, { "label": "resident object whole-workload wait, median", "value": 29515.14, "unit": "ms", "role": "remote", "n": 30, "statistic": "median of 30 blocks" }, { "label": "paired difference of cold worker over local", "value": 26940.32, "unit": "ms", "role": "metric", "n": 30, "statistic": "paired median difference with a 95 percent bootstrap interval" }, { "label": "paired difference interval, lower bound", "value": 26812.22, "unit": "ms", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval" }, { "label": "paired difference interval, upper bound", "value": 27072.34, "unit": "ms", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval" }, { "label": "paired difference of warm worker over local", "value": 27146.47, "unit": "ms", "role": "metric", "n": 30, "statistic": "paired median difference with a 95 percent bootstrap interval" }, { "label": "paired difference interval, lower bound", "value": 26902.61, "unit": "ms", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval" }, { "label": "paired difference interval, upper bound", "value": 27300.53, "unit": "ms", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval" }, { "label": "paired difference of resident object over local", "value": 26072.52, "unit": "ms", "role": "metric", "n": 30, "statistic": "paired median difference with a 95 percent bootstrap interval" }, { "label": "paired difference interval, lower bound", "value": 25854.63, "unit": "ms", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval" }, { "label": "paired difference interval, upper bound", "value": 26244.82, "unit": "ms", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval" }, { "label": "resident gate improvement recorded by the frozen criterion", "value": -7.58, "unit": "ratio", "role": "metric", "n": 30, "statistic": "recorded resident median improvement, negative, against the frozen gate" }, { "label": "resident gate interval, lower bound", "value": -7.63, "unit": "ratio", "role": "metric", "n": 30, "statistic": "recorded 95 percent interval lower bound" }, { "label": "resident gate interval, upper bound", "value": -7.49, "unit": "ratio", "role": "metric", "n": 30, "statistic": "recorded 95 percent interval upper bound" }, { "label": "operand upload avoided per block", "value": 117440512, "unit": "bytes", "role": "metric", "n": 30, "statistic": "seven 16 MiB uploads avoided against the cold arm" }, { "label": "operand upload avoided across the measured blocks", "value": 3523215360, "unit": "bytes", "role": "metric", "n": 30, "statistic": "net arm-versus-arm difference summed over 30 blocks" }, { "label": "resident call records with the operand upload skipped", "value": 264, "unit": "calls", "role": "metric", "n": 264, "statistic": "per-call skip flag across measured and warm-up resident trials" }, { "label": "measured calls", "value": 960, "unit": "calls", "role": "metric", "n": 30, "statistic": "8 calls per block over 30 blocks, all oracle-correct" } ], "comparisons": [ { "baseline": 1, "candidate": 3, "kind": "remote-vs-local" }, { "baseline": 3, "candidate": 7, "kind": "implementation" }, { "baseline": 5, "candidate": 7, "kind": "implementation" } ], "chart": false, "presentation": { "title": "Adding the resident-operand mode once the worker could be bound", "question": "The missing mode was the one where an operand stays on the far side, so once the fixed provider image could run I repeated the four-way comparison with that mode included.", "comparison": "Four arms, local, fresh worker, persistent worker and resident operand, across 30 blocks with 960 checked calls.", "finding": "The local workload median was 3.44 s and the three remote arms 30,347, 30,604 and 29.5 s, so the resident arm was about 7.6 times slower than local even though it avoided 117 MB of operand uploads per block, roughly 3.3 GB across the campaign.", "lesson": "Residency does what it is supposed to do on the bytes and still cannot overcome the per-call cost of materialising and returning a full result.", "caveat": "The live-binding offsets are tied to one processor variant so the result does not transfer to another host without a fresh admission profile, the worker header recorded a fixed shape regardless of the actual shape, two workers shared one host, and the acceptance criterion I set in advance was applied and failed.", "kind": "Performance", "area": "Runtime", "labels": { "0": "Local execution, median call", "1": "Local execution, median workload", "2": "Fresh worker, median call", "3": "Fresh worker, median workload", "4": "Persistent worker, median call", "5": "Persistent worker, median workload", "6": "Resident operand, median call", "7": "Resident operand, median workload" }, "featuredRows": [ 1, 3, 5, 7 ] }, "technical": { "original": { "title": "Node four-mode comparison with the resident-operand arm unblocked on the pinned provider userland", "scope": "A four-arm comparison on the qualifying pinned userland: local, process-cold worker, persistent worker and a resident-object arm that uploads one operand once per block and then issues eight references. The frozen useful-workload gate was applied to the result and failed.", "interpretation": "The resident-operand arm is the fastest of the three remote arms and avoids about 117,440,512 bytes of operand upload per block, roughly 3.3 GiB across the 30 measured blocks, yet it remains about 7.6 times slower than the local arm. Residency therefore works as designed and is not sufficient to overcome the per-call materialisation and round-trip cost of this workload." } }, "chartSeries": [] }, { "id": "rt-cn-s5-003-shaped-link", "title": "What happens to the worker path on a deliberately slow link", "topic": "Interoperability", "date": "2026-10-17", "evidence": "Measured", "scope": "At 10 KB/s and at 2 MB/s, using a 512-element shape that moves a manageable amount of data and a 2048-element shape that does not.", "hardware": "The same 8 dedicated EPYC-Milan vCPUs node running Ubuntu 26.04.1, with traffic shaping applied to the loopback interface. The qualifying pinned provider userland supplies the worker.", "software": "A rate-limited loopback interface, the pinned admitted provider userland, and the runtime service deadline structure of a 30 second serve bound and a 120 second transport bound.", "input": "Square f32 GEMM workloads of 128, 512 and 2048 elements per side, with the 2048 case moving approximately 64 MiB per call.", "samples": "Three local blocks at the 10 KB/s profile; a single recorded per-block and per-call pair at the 2 MB/s profile; a fail-closed case at the 2 MB/s profile with the 2048 shape. Sample counts beyond these are not recorded.", "statistic": "Single recorded block and per-call medians at the 2 MB/s profile; the 10 KB/s profile is recorded as a pass or fail-closed outcome rather than a timing distribution.", "warmCold": "Not recorded as a separate factor. The worker path at the 2 MB/s profile completes with a ready worker; the cold profile is not separately reported.", "network": "Two shaped loopback rates: 10 KB/s and 2 MB/s.", "serialization": "At the 2 MB/s profile the effective shaped rate moves approximately 4 MiB per call, which the receipt attributes to shaped-queue and transfer overhead rather than to arithmetic.", "correctness": "Not the subject of this measurement. The cold and warm outcomes at the lowest rate are recorded as correct fail-closed refusals: a transport timeout, no fabricated result, and a documented fallback.", "limitations": [ "The lowest-rate profile is recorded as a pass or fail-closed outcome, not as a latency distribution.", "The 2 MB/s profile figures come from a small number of recorded rows; the block count for the remote arm is not recorded.", "The receipt corrects an earlier transcription error: a stated 771.70 ms local figure was an unsupported transcription, and the receipt value of 33.06 ms per block is the one carried here.", "The deadline-derived transfer ceilings are arithmetic from the stated rate and the serve deadline, not independent measurements.", "Only the local arm completed at the lowest rate, so no remote comparison exists at that rate." ], "interpretation": "At 2 MB/s a local block took 33 ms against 16.8 s for the worker block, the per-call ceiling implied by the deadline was about 300 KB at 10 KB/s and about 60 MB at 2 MB/s, and the large shape needing 64 MB per call was refused rather than left hanging.", "href": "/research/runtime/", "sourceIds": [ "rt-src-cn-s5-003" ], "rows": [ { "label": "local whole-workload wait at 2 MB/s, 512 shape", "value": 33.06, "unit": "ms", "role": "local", "n": 3, "statistic": "recorded per-block value for the local arm at the 2 MB/s profile" }, { "label": "local per-call wait at 2 MB/s, 512 shape", "value": 4.1, "unit": "ms", "role": "local", "n": 3, "statistic": "recorded per-call value, approximately 4.1 ms in process" }, { "label": "warm worker per-call wait at 2 MB/s, 512 shape", "value": 2100, "unit": "ms", "role": "remote", "n": null, "statistic": "recorded per-call value, approximately 2,100 ms at the shaped rate" }, { "label": "warm worker whole-workload wait at 2 MB/s, 512 shape", "value": 16816.59, "unit": "ms", "role": "remote", "n": null, "statistic": "recorded per-block median" }, { "label": "per-call transfer ceiling at 10 KB/s within the serve deadline", "value": 300000, "unit": "bytes", "role": "metric", "n": 1, "statistic": "arithmetic from the stated rate and the 30 second serve deadline" }, { "label": "per-call transfer ceiling at 2 MB/s within the serve deadline", "value": 60000000, "unit": "bytes", "role": "metric", "n": 1, "statistic": "arithmetic from the stated rate and the 30 second serve deadline" }, { "label": "transfer per call at the 2048 shape", "value": 67108864, "unit": "bytes", "role": "metric", "n": 1, "statistic": "approximately 64 MiB per call at the 2048 shape" }, { "label": "serve deadline", "value": 30000, "unit": "ms", "role": "metric", "n": 1, "statistic": "runtime service deadline" }, { "label": "transport bound", "value": 120000, "unit": "ms", "role": "metric", "n": 1, "statistic": "runtime transport bound" } ], "comparisons": [ { "baseline": 0, "candidate": 3, "kind": "remote-vs-local" }, { "baseline": 1, "candidate": 2, "kind": "remote-vs-local" } ], "chart": false, "presentation": { "title": "What happens to the worker path on a deliberately slow link", "question": "I wanted to find where the service deadline and the transport limit actually bite, so I shaped the loopback traffic to two fixed rates and ran the worker arms against them.", "comparison": "At 10 KB/s and at 2 MB/s, using a 512-element shape that moves a manageable amount of data and a 2048-element shape that does not.", "finding": "At 2 MB/s a local block took 33 ms against 16.8 s for the worker block, the per-call ceiling implied by the deadline was about 300 KB at 10 KB/s and about 60 MB at 2 MB/s, and the large shape needing 64 MB per call was refused rather than left hanging.", "lesson": "On a slow link the remote path cannot be exercised at large sizes at all; it refuses cleanly instead of stalling, which is the right behaviour but means there is nothing to compare.", "caveat": "The slowest profile is recorded as a refusal outcome rather than a timing distribution, the faster profile comes from a small number of rows, the ceilings are arithmetic from the stated rate and deadline rather than separate measurements, and an earlier local figure in the record was an unsupported transcription that has since been corrected.", "kind": "Performance", "area": "Runtime", "labels": { "0": "Local execution, block wait at 2 MB/s", "1": "Local execution, call wait at 2 MB/s", "2": "Worker, call wait at 2 MB/s", "3": "Worker, block wait at 2 MB/s" }, "featuredRows": [ 0, 3 ] }, "technical": { "original": { "title": "Worker arms under deliberately shaped network rates", "scope": "The worker arms were exercised against loopback traffic shaped to two fixed rates to establish where the service deadline and the transport bound bite. Larger shapes at low rates are recorded as designed fail-closed behaviour rather than as wins.", "interpretation": "The service deadline structure bounds how much data a single call may move: about 300 KB at 10 KB/s and about 60 MB at 2 MB/s. A shape that needs more than that fails closed rather than hanging, which is the correct behaviour but means the remote arm cannot be exercised on a slow link at large sizes. The only usable remote point is the 2 MB/s profile, where the wait is dominated by shaped throughput." } }, "chartSeries": [] }, { "id": "rt-cn-s5-003-worker-kill-fallback", "title": "Killing the worker in the middle of a workload", "topic": "Runtime", "date": "2026-10-17", "evidence": "Measured", "scope": "One recorded workload with the worker killed after thirteen verified calls, followed by a local run of the same workload.", "hardware": "The same node with the pinned admitted provider userland; no accelerator is involved.", "software": "The runtime worker and its transport, with the shaped-link harness and the pinned userland.", "input": "A 2048 by 2048 by 2048 f32 row-major workload; the recorded shape is 2048 because a script argument-position error originally placed the shape into the worker executable slot.", "samples": "One recorded workload: 13 oracle-true calls before the worker was killed, then one local fallback workload.", "statistic": "Single recorded workload per leg; the fallback leg is recorded as a per-block median.", "warmCold": "The worker was killed during a warm-arm workload. The fallback leg is a local execution.", "network": "Loopback only. The failure mode is a worker loss, not a link change.", "serialization": "Not recorded as a separate figure.", "correctness": "The runtime returned a transport error with no fabricated result and the runner exited with code 101. The local fallback then executed the same workload and was oracle-correct.", "limitations": [ "A single recorded workload; no rate or distribution.", "The receipts header hardcoded a shape value regardless of the actual shape, so the shape attribution rests on the per-call durations and the recorded invocation arguments; the runner header was corrected afterwards.", "Only the fallback leg has a per-block median; the killed leg has a call count.", "This exercises one failure direction and not the full fault matrix." ], "interpretation": "The runtime surfaced a transport error rather than inventing a result and exited with code 101, and the local run that followed completed the same workload correctly in 764 ms.", "href": "/research/runtime/", "sourceIds": [ "rt-src-cn-s5-003" ], "rows": [ { "label": "calls completed before the worker was killed", "value": 13, "unit": "calls", "role": "remote", "n": 1, "statistic": "oracle-true calls recorded before the kill" }, { "label": "local fallback whole-workload wait", "value": 763.75, "unit": "ms", "role": "local", "n": 1, "statistic": "recorded per-block median of the fallback leg" }, { "label": "runner exit code after the transport error", "value": 101, "unit": "cases", "role": "metric", "n": 1, "statistic": "exit code recorded when the transport error was surfaced" } ], "comparisons": [], "chart": false, "presentation": { "title": "Killing the worker in the middle of a workload", "question": "A worker can die at any moment, so I killed one mid-workload and checked what the runtime reported and what the user ended up with.", "comparison": "One recorded workload with the worker killed after thirteen verified calls, followed by a local run of the same workload.", "finding": "The runtime surfaced a transport error rather than inventing a result and exited with code 101, and the local run that followed completed the same workload correctly in 764 ms.", "lesson": "The fallback held under a real fault: nothing was fabricated, and the work still got done.", "caveat": "A single recorded workload with no rate or distribution, only the fallback leg has a duration while the killed leg has a call count so no ratio can be drawn between them, and this exercises one failure direction only.", "kind": "Functional check", "area": "Runtime" }, "technical": { "original": { "title": "Worker loss during a workload and the resulting local fallback", "scope": "A worker was killed in the middle of a warm-arm workload to observe whether the runtime fabricates a result, reports the loss honestly and falls back to local execution with the same workload.", "interpretation": "A worker loss mid-workload is surfaced as a transport error rather than a fabricated result, and the runtime falls back to local execution, producing an oracle-correct workload. This is the fallback invariant holding under a real fault, not a performance result. The two recorded quantities are in different units, a call count and a block duration, so no arithmetic ratio is drawn between them." } }, "chartSeries": [] }, { "id": "rt-win-native-c-baseline", "title": "The native floor: what this multiplication costs on a personal machine", "topic": "GEMM", "date": "2026-10-15", "evidence": "Measured", "scope": "Direct native calls, the cost of copying the operands, the cost of fully validating the output, and the process setup, all inside one child process on my own Windows machine.", "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.", "statistic": "Single recorded values per interval from one two-call child; there is no repeated-sample distribution and no statistical qualification.", "warmCold": "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": "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.", "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." ], "interpretation": "The multiplication itself took 162 to 165 ms, adding operand copies and full output validation brought the call to 215 to 219 ms, and the whole program from entry to cleanup took 850 ms.", "href": "/research/native-interception/", "sourceIds": [ "rt-src-win-frozen-baseline", "rt-src-win-integration" ], "rows": [ { "label": "direct native multiplication, first call", "value": 165.1557, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval in one child process" }, { "label": "direct native multiplication, repeated call", "value": 161.9817, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval in one child process" }, { "label": "operand snapshot, first call", "value": 3.1676, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval in one child process" }, { "label": "operand snapshot, repeated call", "value": 1.8216, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval in one child process" }, { "label": "full output hash, finite scan and 64 scalar checks, first call", "value": 50.1971, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval in one child process" }, { "label": "full output hash, finite scan and 64 scalar checks, repeated call", "value": 51.0359, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval in one child process" }, { "label": "call total including validation, first call", "value": 218.5204, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval in one child process" }, { "label": "call total including validation, repeated call", "value": 214.8392, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval in one child process" }, { "label": "process setup", "value": 411.7636, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval, including nested provider load and admission" }, { "label": "nested provider load and admission inside setup", "value": 136.4707, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval" }, { "label": "cleanup", "value": 4.8053, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval" }, { "label": "whole application from entry through cleanup", "value": 849.929, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval" }, { "label": "maximum sampled absolute error against the reference", "value": 0.000529259600171, "unit": "ratio", "role": "metric", "n": 64, "statistic": "maximum over 64 deterministic scalar checks" }, { "label": "four-thread configuration allocation failure", "value": 0, "unit": "cases", "role": "metric", "n": 1, "statistic": "0 denotes the child exited with a provider allocation failure and emitted no timing" } ], "comparisons": [ { "baseline": 1, "candidate": 7, "kind": "implementation" } ], "chart": false, "presentation": { "title": "The native floor: what this multiplication costs on a personal machine", "question": "Before asking whether any external path helps, I measured the plain native cost of the fixed multiplication with an independently written program that does nothing but call a good library.", "comparison": "Direct native calls, the cost of copying the operands, the cost of fully validating the output, and the process setup, all inside one child process on my own Windows machine.", "finding": "The multiplication itself took 162 to 165 ms, adding operand copies and full output validation brought the call to 215 to 219 ms, and the whole program from entry to cleanup took 850 ms.", "lesson": "That 162 to 165 ms is the floor any external path has to beat, and the extra 50 ms of validation is what any trustworthy result has to pay.", "caveat": "One child and two calls with no distribution, a four-thread configuration failed to allocate under a memory cap so the threading picture is incomplete, the machine was not idle, and this is an arithmetic reference rather than an end-to-end latency.", "kind": "Performance", "area": "Splice", "labels": { "0": "Direct native call, first", "1": "Direct native call, repeated", "2": "Operand snapshot, first", "3": "Operand snapshot, repeated", "4": "Full output validation, first", "5": "Full output validation, repeated", "6": "Call total including validation, first", "7": "Call total including validation, repeated", "8": "Process setup", "9": "Library load inside setup", "10": "Cleanup", "11": "Whole application, entry to cleanup" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "Independent native C baseline for the frozen 2048-square workload on a personal Windows machine", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "rt-win-native-rust-runtime", "title": "The same workload through the interception path and the dispatcher", "topic": "Runtime", "date": "2026-10-15", "evidence": "Measured", "scope": "Direct calls into the numeric library against the same calls routed through the automatic local dispatcher, plus a paired run with diagnostics.", "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.", "statistic": "Single recorded values per interval; no repeated-sample distribution.", "warmCold": "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": "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.", "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." ], "interpretation": "The direct path took 208 to 219 ms and the dispatched path 201 to 220 ms, effectively the same, while the paired diagnostic run took 605 to 636 ms and the whole launcher about 2.64 s.", "href": "/research/runtime/", "sourceIds": [ "rt-src-win-integration", "rt-src-win-win002", "rt-src-win-traffic-budget", "rt-src-win-frozen-baseline" ], "rows": [ { "label": "release direct provider executor, first call", "value": 219.018, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval" }, { "label": "release direct provider executor, repeated call", "value": 207.832, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval" }, { "label": "release runtime automatic local dispatcher, first call", "value": 219.958, "unit": "ms", "role": "local", "n": 1, "statistic": "single recorded interval" }, { "label": "release runtime automatic local dispatcher, repeated call", "value": 201.334, "unit": "ms", "role": "local", "n": 1, "statistic": "single recorded interval" }, { "label": "release paired direct, runtime and diagnostic comparison, first call", "value": 635.56, "unit": "ms", "role": "metric", "n": 1, "statistic": "single recorded interval" }, { "label": "release paired direct, runtime and diagnostic comparison, repeated call", "value": 604.621, "unit": "ms", "role": "metric", "n": 1, "statistic": "single recorded interval" }, { "label": "provider admission and load", "value": 297.008, "unit": "ms", "role": "native", "n": 1, "statistic": "single recorded interval" }, { "label": "input generation and full input hashing", "value": 362.825, "unit": "ms", "role": "metric", "n": 1, "statistic": "single recorded interval" }, { "label": "diagnostic whole workload, two-call paired comparison", "value": 2382.333, "unit": "ms", "role": "metric", "n": 1, "statistic": "single recorded inner interval, excluding final publication and library drop" }, { "label": "launcher wall", "value": 2640, "unit": "ms", "role": "metric", "n": 1, "statistic": "approximate figure reported as about 2.640 seconds, including process, serialisation and unload overhead" }, { "label": "runtime offline test suite, passed", "value": 145, "unit": "cases", "role": "metric", "n": 1, "statistic": "145 passed with 0 failed and 0 ignored" }, { "label": "runtime offline test suite, failed", "value": 0, "unit": "cases", "role": "metric", "n": 1, "statistic": "0 failed" }, { "label": "interception native unit suite, passed", "value": 17, "unit": "cases", "role": "metric", "n": 1, "statistic": "17 passed with 0 failed" }, { "label": "interception native unit suite, ignored", "value": 1, "unit": "cases", "role": "metric", "n": 1, "statistic": "one ignored child helper, executed by the parent as a fail-stop child" }, { "label": "compiled C to interception to runtime to native library cases, passed", "value": 52, "unit": "cases", "role": "metric", "n": 1, "statistic": "48 intercepted plus 4 exactly-once original fallbacks" }, { "label": "object stream bytes observed over the two-operation session", "value": 0, "unit": "bytes", "role": "metric", "n": 1, "statistic": "zero outbound and zero inbound bytes" }, { "label": "active observation window for the traffic accounting", "value": 1722.169, "unit": "ms", "role": "metric", "n": 1, "statistic": "a full active hour was not observed" }, { "label": "traffic budget policy target", "value": 100000000, "unit": "bytes", "role": "metric", "n": 1, "statistic": "decimal bytes per active hour" }, { "label": "provider archive downloaded during setup, outside the operation counters", "value": 40860061, "unit": "bytes", "role": "metric", "n": 1, "statistic": "engineering setup download" } ], "comparisons": [ { "baseline": 3, "candidate": 5, "kind": "implementation" }, { "baseline": 2, "candidate": 3, "kind": "implementation" } ], "chart": false, "presentation": { "title": "The same workload through the interception path and the dispatcher", "question": "I wanted to know what the interception and dispatch machinery costs on top of the native call, so I ran the identical workload both ways on my own machine.", "comparison": "Direct calls into the numeric library against the same calls routed through the automatic local dispatcher, plus a paired run with diagnostics.", "finding": "The direct path took 208 to 219 ms and the dispatched path 201 to 220 ms, effectively the same, while the paired diagnostic run took 605 to 636 ms and the whole launcher about 2.64 s.", "lesson": "The dispatch machinery is close to free in absolute terms on this machine, and the session moved no network bytes at all because local execution opens no transport.", "caveat": "Two calls per configuration with no statistical significance, the traffic accounting covers eligible local calls only and a 40.9 MB setup download sits outside the counters, the provider archive is unsigned, and no remote worker or accelerator is represented anywhere in this measurement.", "kind": "Performance", "area": "Splice", "labels": { "0": "Direct native call, first", "1": "Direct native call, repeated", "2": "Dispatched call, first", "3": "Dispatched call, repeated", "4": "Paired comparison with diagnostics, first", "5": "Paired comparison with diagnostics, repeated", "6": "Library admission and load", "7": "Input generation and hashing", "8": "Diagnostic whole workload", "9": "Launcher wall time" }, "featuredRows": [ 0, 1, 2, 3 ] }, "technical": { "original": { "title": "Runtime path and interception path for the same native workload on a personal Windows machine", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "rt-s4-r4-gpu-diagnostic", "title": "A deliberately small accelerator probe, and why I stopped there", "topic": "GEMM", "date": "2026-10-13", "evidence": "Measured", "scope": "Local execution against a non-resident remote run and a resident-operand remote run, two blocks of eight calls each.", "hardware": "The remote host exposes 7.56 GiB of memory, four EPYC-Genoa vCPUs and no swap, with sampled CPU utilisation around 99.7 percent and CPU pressure around 46 percent. The local workstation has an i7-8665U, four cores and eight threads, and 7.75 GiB of memory. The accelerator has compute capability 8.6 and driver 570.195.03. Neither machine was uncontended.", "software": "Optimised OpenBLAS configured for four threads as the frozen local baseline, and a pinned serial reference BLAS as an alternative compute implementation. Compiler versions are not recorded in this receipt.", "input": "Frozen 2048 by 2048 tensors, eight calls per workload, unchanged operand digests, 16 MiB materialised outputs.", "samples": "Two diagnostic blocks of eight calls each, with a 48-call paired diagnostic containing 16 local calls. Ninety-six successful accelerator calls in total: 8 smoke, 56 warm-up and 32 measured.", "statistic": "Median of two measured blocks. There is no qualification confidence interval; the receipt states the two blocks are diagnostic observations only.", "warmCold": "The cold rehearsal took 47.2692 seconds including start-up and teardown and is a single untimed rehearsal, not a measured cold distribution. The prescribed warm-up sequence took 307.321 seconds.", "network": "Not recorded as a separate figure; host-side spans include transport and worker completion and are not disjoint pure network or pure kernel measurements.", "serialization": "Raw f32 decoding occurs for uploads and this worker path contains no compression or decompression codec. Device counters record resident uploads of 272 MiB against 384 MiB for non-resident, with 128 MiB returned and 128 MiB of output cloned per workload.", "correctness": "Every-element optimised BLAS checks and four f64 scalar reference positions were retained with absolute and relative tolerances of 1e-4. Stale-token rejection and owned process exits passed.", "limitations": [ "Two measured blocks only; no qualification confidence interval and no statistical claim.", "The full 30-block qualification was not attempted because the projected duration of 4,227,624 ms exceeded the remaining bounded time.", "Native phase instrumentation was not enabled because the remote bootstrap dropped its timing argument, so accelerator initialisation, host-to-device copy, kernel and device-to-host spans are not recorded for this run.", "A single larger-memory configuration of the local baseline failed to allocate and no valid timing was emitted from it; the exact requested workspace is not measured.", "The direct accelerator store path does not invoke the immutable-result cache or a compression path.", "Actual provider billing and provider timer enforcement are recorded as unknown." ], "interpretation": "The local median was 2.49 s, the non-resident remote 42.7 s and the resident remote 34.2 s, about 13.8 times the local time, while keeping one operand resident avoided 117 MB of uploads per workload and saved about a fifth of the traffic.", "href": "/research/runtime/", "sourceIds": [ "rt-src-s4-r4-decision", "rt-src-s4-protocol", "rt-src-s4-v3-audit" ], "rows": [ { "label": "local whole-workload wait, median", "value": 2487.6, "unit": "ms", "role": "local", "n": 2, "statistic": "median of 2 measured blocks" }, { "label": "warm remote whole-workload wait, median", "value": 42675.9, "unit": "ms", "role": "remote", "n": 2, "statistic": "median of 2 measured blocks" }, { "label": "resident whole-workload wait, median", "value": 34244, "unit": "ms", "role": "remote", "n": 2, "statistic": "median of 2 measured blocks" }, { "label": "resident improvement over local", "value": -1276.595, "unit": "percent", "role": "metric", "n": 2, "statistic": "percent change of the resident median against the local median" }, { "label": "resident saving against non-resident remote", "value": 19.758, "unit": "percent", "role": "metric", "n": 2, "statistic": "percent reduction of the resident median against the non-resident remote median" }, { "label": "cold rehearsal, untimed", "value": 47269.2, "unit": "ms", "role": "remote", "n": 1, "statistic": "single untimed rehearsal including start-up and teardown" }, { "label": "prescribed warm-up sequence", "value": 307321, "unit": "ms", "role": "remote", "n": 1, "statistic": "total elapsed time of the prescribed warm-up sequence" }, { "label": "resident upload phase per call, mean", "value": 2263.1, "unit": "ms", "role": "remote", "n": 229, "statistic": "mean host span across deduplicated diagnostic uploads" }, { "label": "resident execution round trip per call, mean", "value": 102.2, "unit": "ms", "role": "remote", "n": 32, "statistic": "mean host span across measured rows" }, { "label": "resident materialisation round trip per call, mean", "value": 1012.3, "unit": "ms", "role": "remote", "n": 88, "statistic": "mean host span across materialisations" }, { "label": "resident independent verification per call, mean", "value": 340.2, "unit": "ms", "role": "remote", "n": 32, "statistic": "mean host span across measured rows" }, { "label": "resident releases per call, mean", "value": 323.5, "unit": "ms", "role": "remote", "n": 32, "statistic": "mean host span across measured rows" }, { "label": "non-resident upload per call, mean", "value": 3389.7, "unit": "ms", "role": "remote", "n": 32, "statistic": "mean host span across measured rows" }, { "label": "initial resident operand setup, first workload", "value": 1801.8, "unit": "ms", "role": "remote", "n": 1, "statistic": "recorded host span" }, { "label": "initial resident operand setup, second workload", "value": 1716.7, "unit": "ms", "role": "remote", "n": 1, "statistic": "recorded host span" }, { "label": "successful accelerator calls", "value": 96, "unit": "calls", "role": "metric", "n": 96, "statistic": "8 smoke, 56 warm-up and 32 measured calls" }, { "label": "resident uploads per workload", "value": 285212672, "unit": "bytes", "role": "remote", "n": 2, "statistic": "device counter total, 272 MiB" }, { "label": "non-resident uploads per workload", "value": 402653184, "unit": "bytes", "role": "remote", "n": 2, "statistic": "device counter total, 384 MiB" }, { "label": "upload avoided per workload by residency", "value": 117440512, "unit": "bytes", "role": "metric", "n": 2, "statistic": "seven 16 MiB operand uploads avoided" }, { "label": "output returned per workload", "value": 134217728, "unit": "bytes", "role": "remote", "n": 2, "statistic": "128 MiB" }, { "label": "output cloned per workload", "value": 134217728, "unit": "bytes", "role": "remote", "n": 2, "statistic": "128 MiB" }, { "label": "device requested high-water", "value": 71303168, "unit": "bytes", "role": "metric", "n": 2, "statistic": "device counter high-water" }, { "label": "device requested ceiling", "value": 134217728, "unit": "bytes", "role": "metric", "n": 1, "statistic": "requested device allocation ceiling" }, { "label": "projected full qualification duration", "value": 4227624, "unit": "ms", "role": "metric", "n": 1, "statistic": "projection recorded before declining to launch the full run" } ], "comparisons": [ { "baseline": 0, "candidate": 2, "kind": "remote-vs-local" }, { "baseline": 1, "candidate": 2, "kind": "implementation" } ], "chart": false, "presentation": { "title": "A deliberately small accelerator probe, and why I stopped there", "question": "I wanted a first look at the accelerator without committing to the full campaign, so I ran two blocks and measured the host-side phases around the device.", "comparison": "Local execution against a non-resident remote run and a resident-operand remote run, two blocks of eight calls each.", "finding": "The local median was 2.49 s, the non-resident remote 42.7 s and the resident remote 34.2 s, about 13.8 times the local time, while keeping one operand resident avoided 117 MB of uploads per workload and saved about a fifth of the traffic.", "lesson": "Even in a probe the upload and materialisation spans dominated while the device round trip stayed small, so the cost structure was already clear; I did not start the full campaign because it projected to run for over 70 minutes.", "caveat": "Two measured blocks only with no confidence interval, device-side phases were not recorded because the remote start-up dropped its timing argument, a larger-memory local configuration failed to allocate and produced no timing at all, and actual provider billing is recorded as unknown.", "kind": "Incomplete experiment", "area": "Runtime", "labels": { "0": "Local execution, median", "1": "Non-resident remote execution, median", "2": "Resident remote execution, median" }, "featuredRows": [ 0, 2 ] }, "technical": { "original": { "title": "Accelerator-first diagnostic comparison, two measured blocks", "scope": "A deliberately bounded diagnostic on the frozen 2048-square eight-call workload, executed on an accelerator with the local baseline on a virtual private server. Full qualification was not launched. The disposition records a measured loss against the local baseline and a smaller saving against non-resident remote execution.", "interpretation": "On two blocks the resident mode was about 13.8 times slower than the local baseline while saving about a fifth of the traffic against non-resident remote execution. The per-call host spans show upload and materialisation dominating while the execute round trip is small, so the loss is again a data-movement cost rather than an arithmetic cost. The absence of native phase spans means the device-side portion of the wait cannot be separated from this evidence." } }, "chartSeries": [] }, { "id": "rt-transfer-calculations", "title": "Transferring operands that came out of calculations", "topic": "Representation", "date": "2026-10-13", "evidence": "Measured", "scope": "The same seven modes over the same four-call workload with the calculation-derived operand pattern.", "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.", "statistic": "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.", "warmCold": "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": "Every mode in this class is recorded as passing the correctness check.", "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." ], "interpretation": "The compressor cut the transfer to 263,749 bytes at 26.1 ms and difference encoding to 467,041 bytes at 23.1 ms, both far below the raw 1,058,842 bytes at 28.0 ms and local execution at 8.2 ms.", "href": "/research/resynth/", "sourceIds": [ "rt-src-transfer-report-csv", "rt-src-transfer-report-md" ], "rows": [ { "label": "local execution, no transport: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "local execution, no transport: total user wait", "value": 8.194, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "local execution, no transport: bytes avoided against the matched raw run", "value": 1058842, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "raw transport: total wire bytes", "value": 1058842, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "raw transport: total user wait", "value": 27.982, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "raw transport: bytes avoided against the matched raw run", "value": 0, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "resident-operand transport: total wire bytes", "value": 467149, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "resident-operand transport: total user wait", "value": 26.153, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "resident-operand transport: bytes avoided against the matched raw run", "value": 591693, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed transport: total wire bytes", "value": 263749, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed transport: total user wait", "value": 26.074, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed transport: bytes avoided against the matched raw run", "value": 795093, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "byte-delta transport: total wire bytes", "value": 467041, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "byte-delta transport: total user wait", "value": 23.115, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "byte-delta transport: bytes avoided against the matched raw run", "value": 591801, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed byte-delta transport: total wire bytes", "value": 263641, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: total user wait", "value": 26.33, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: bytes avoided against the matched raw run", "value": 795201, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive representation selection: total wire bytes", "value": 733389, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive representation selection: total user wait", "value": 29.689, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive representation selection: bytes avoided against the matched raw run", "value": 325453, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive selection, which chose the local path: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: total user wait", "value": 8.164, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: bytes avoided against the matched raw run", "value": 1058842, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" } ], "comparisons": [ { "baseline": 1, "candidate": 4, "kind": "remote-vs-local" }, { "baseline": 3, "candidate": 9, "kind": "compression" } ], "chart": false, "presentation": { "title": "Transferring operands that came out of calculations", "question": "I wanted to know whether data produced by arithmetic behaves differently from data that was merely structured, so I measured the same modes on calculation-derived operands.", "comparison": "The same seven modes over the same four-call workload with the calculation-derived operand pattern.", "finding": "The compressor cut the transfer to 263,749 bytes at 26.1 ms and difference encoding to 467,041 bytes at 23.1 ms, both far below the raw 1,058,842 bytes at 28.0 ms and local execution at 8.2 ms.", "lesson": "This regime behaves like the structured one rather than the random one, so where the data came from is not the same question as whether it compresses.", "caveat": "Every mode saw the same logical input once, with no repetitions; the byte counts leave out packet and tunnel overhead, the avoided-byte figure is measured against the raw run and can be negative, the timings overlap and must not be summed, and this is a Linux CPU transport measurement.", "kind": "Performance", "area": "ReSynth", "featuredRows": [ 1, 4, 7, 10 ] }, "technical": { "original": { "title": "Transfer byte and latency accounting, calculation-derived operands", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "rt-transfer-chain", "title": "Transferring operands that depend on each other", "topic": "Representation", "date": "2026-10-13", "evidence": "Measured", "scope": "The five modes that ran in this regime, with the modes that were absent recorded as absent rather than inferred.", "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.", "statistic": "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.", "warmCold": "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": "Every mode in this class is recorded as passing the correctness check.", "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." ], "interpretation": "Raw transport moved 2,116,934 bytes in 60.4 ms against 21.8 ms locally, keeping the operand resident moved only 472,253 bytes in 37.7 ms and LZ4 331,285 bytes in 41.3 ms, while the automatic mode chose local at 23.1 ms.", "href": "/research/resynth/", "sourceIds": [ "rt-src-transfer-report-csv", "rt-src-transfer-report-md" ], "rows": [ { "label": "local execution, no transport: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "local execution, no transport: total user wait", "value": 21.782, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "local execution, no transport: bytes avoided against the matched raw run", "value": 2116934, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "raw transport: total wire bytes", "value": 2116934, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "raw transport: total user wait", "value": 60.389, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "raw transport: bytes avoided against the matched raw run", "value": 0, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "resident-operand transport: total wire bytes", "value": 472253, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "resident-operand transport: total user wait", "value": 37.704, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "resident-operand transport: bytes avoided against the matched raw run", "value": 1644681, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed transport: total wire bytes", "value": 331285, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed transport: total user wait", "value": 41.311, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed transport: bytes avoided against the matched raw run", "value": 1785649, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive selection, which chose the local path: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: total user wait", "value": 23.091, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: bytes avoided against the matched raw run", "value": 2116934, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" } ], "comparisons": [ { "baseline": 1, "candidate": 4, "kind": "remote-vs-local" }, { "baseline": 3, "candidate": 9, "kind": "compression" } ], "chart": false, "presentation": { "title": "Transferring operands that depend on each other", "question": "When each operand depends on the previous result, nothing can be sent ahead of time, so I measured the same modes on a dependent chain.", "comparison": "The five modes that ran in this regime, with the modes that were absent recorded as absent rather than inferred.", "finding": "Raw transport moved 2,116,934 bytes in 60.4 ms against 21.8 ms locally, keeping the operand resident moved only 472,253 bytes in 37.7 ms and LZ4 331,285 bytes in 41.3 ms, while the automatic mode chose local at 23.1 ms.", "lesson": "In a dependent chain residency is worth the most, because it removed 1.6 MB of the 2.1 MB that raw had to carry.", "caveat": "Only five of the eight modes ran in this regime and the rest are recorded as missing rather than inferred; each mode was measured once, the byte counts omit packet and tunnel overhead, the timings overlap and must not be added, and this is a Linux CPU transport measurement.", "kind": "Performance", "area": "ReSynth", "featuredRows": [ 1, 4, 7, 10 ] }, "technical": { "original": { "title": "Transfer byte and latency accounting, dependent operand chain", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "rt-transfer-full-outputs", "title": "Asking for the entire output every time", "topic": "Representation", "date": "2026-10-13", "evidence": "Measured", "scope": "The same seven modes over the same four-call workload with the full-output pattern.", "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.", "statistic": "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.", "warmCold": "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": "Every mode in this class is recorded as passing the correctness check.", "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." ], "interpretation": "Raw transport moved 1,058,842 bytes in 29.2 ms against 9.4 ms locally, while the compressed modes moved around 600,000 bytes in 24 to 25 ms, and the automatic mode moved 996,838 bytes in 27.5 ms while its own local choice took 7.9 ms.", "href": "/research/resynth/", "sourceIds": [ "rt-src-transfer-report-csv", "rt-src-transfer-report-md" ], "rows": [ { "label": "local execution, no transport: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "local execution, no transport: total user wait", "value": 9.39, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "local execution, no transport: bytes avoided against the matched raw run", "value": 1058842, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "raw transport: total wire bytes", "value": 1058842, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "raw transport: total user wait", "value": 29.16, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "raw transport: bytes avoided against the matched raw run", "value": 0, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "resident-operand transport: total wire bytes", "value": 664012, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "resident-operand transport: total user wait", "value": 26.264, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "resident-operand transport: bytes avoided against the matched raw run", "value": 394830, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed transport: total wire bytes", "value": 600250, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed transport: total user wait", "value": 24.089, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed transport: bytes avoided against the matched raw run", "value": 458592, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "byte-delta transport: total wire bytes", "value": 666022, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "byte-delta transport: total user wait", "value": 24.294, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "byte-delta transport: bytes avoided against the matched raw run", "value": 392820, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed byte-delta transport: total wire bytes", "value": 601798, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: total user wait", "value": 24.189, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: bytes avoided against the matched raw run", "value": 457044, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive representation selection: total wire bytes", "value": 996838, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive representation selection: total user wait", "value": 27.464, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive representation selection: bytes avoided against the matched raw run", "value": 62004, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive selection, which chose the local path: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: total user wait", "value": 7.939, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: bytes avoided against the matched raw run", "value": 1058842, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" } ], "comparisons": [ { "baseline": 1, "candidate": 4, "kind": "remote-vs-local" }, { "baseline": 3, "candidate": 9, "kind": "compression" } ], "chart": false, "presentation": { "title": "Asking for the entire output every time", "question": "Requesting everything back each call is the least favourable case for any shortcut, so I measured the same modes with the full output always demanded.", "comparison": "The same seven modes over the same four-call workload with the full-output pattern.", "finding": "Raw transport moved 1,058,842 bytes in 29.2 ms against 9.4 ms locally, while the compressed modes moved around 600,000 bytes in 24 to 25 ms, and the automatic mode moved 996,838 bytes in 27.5 ms while its own local choice took 7.9 ms.", "lesson": "Demanding full outputs did not reorder the modes much; the automatic decision to stay local was still the fastest thing available.", "caveat": "One matched workload per mode with no repeats and no distribution; the byte counts omit packet and tunnel overhead, the avoided-byte figure is measured against the raw run and can be negative, the timings overlap and must not be summed, and this is a Linux CPU transport measurement.", "kind": "Performance", "area": "ReSynth", "featuredRows": [ 1, 4, 7, 10 ] }, "technical": { "original": { "title": "Transfer byte and latency accounting, full outputs requested", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "rt-transfer-incompressible", "title": "Transferring operands that resist compression", "topic": "Representation", "date": "2026-10-13", "evidence": "Measured", "scope": "The same seven modes over the same four-call workload with the incompressible operand pattern.", "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.", "statistic": "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.", "warmCold": "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": "Every mode in this class is recorded as passing the correctness check.", "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." ], "interpretation": "LZ4 still moved 600,250 bytes but took 28.7 ms against raw at 27.0 ms, difference encoding moved 666,022 bytes in 32.8 ms, and combining compression with differences was the slowest mode of all at 43.8 ms, while local execution took 8.2 ms.", "href": "/research/resynth/", "sourceIds": [ "rt-src-transfer-report-csv", "rt-src-transfer-report-md" ], "rows": [ { "label": "local execution, no transport: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "local execution, no transport: total user wait", "value": 8.235, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "local execution, no transport: bytes avoided against the matched raw run", "value": 1058842, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "raw transport: total wire bytes", "value": 1058842, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "raw transport: total user wait", "value": 26.958, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "raw transport: bytes avoided against the matched raw run", "value": 0, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "resident-operand transport: total wire bytes", "value": 664012, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "resident-operand transport: total user wait", "value": 26.651, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "resident-operand transport: bytes avoided against the matched raw run", "value": 394830, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed transport: total wire bytes", "value": 600250, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed transport: total user wait", "value": 28.666, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed transport: bytes avoided against the matched raw run", "value": 458592, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "byte-delta transport: total wire bytes", "value": 666022, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "byte-delta transport: total user wait", "value": 32.827, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "byte-delta transport: bytes avoided against the matched raw run", "value": 392820, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed byte-delta transport: total wire bytes", "value": 601798, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: total user wait", "value": 43.809, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: bytes avoided against the matched raw run", "value": 457044, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive representation selection: total wire bytes", "value": 996838, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive representation selection: total user wait", "value": 27.778, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive representation selection: bytes avoided against the matched raw run", "value": 62004, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive selection, which chose the local path: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: total user wait", "value": 8.147, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: bytes avoided against the matched raw run", "value": 1058842, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" } ], "comparisons": [ { "baseline": 1, "candidate": 4, "kind": "remote-vs-local" }, { "baseline": 3, "candidate": 9, "kind": "compression" } ], "chart": false, "presentation": { "title": "Transferring operands that resist compression", "question": "Compression should buy nothing here and might cost, so I measured the same modes on operands chosen to be hard to compress.", "comparison": "The same seven modes over the same four-call workload with the incompressible operand pattern.", "finding": "LZ4 still moved 600,250 bytes but took 28.7 ms against raw at 27.0 ms, difference encoding moved 666,022 bytes in 32.8 ms, and combining compression with differences was the slowest mode of all at 43.8 ms, while local execution took 8.2 ms.", "lesson": "On this data compression bought much less and one combination cost more than sending everything raw, so the representation has to follow the data rather than a fixed preference.", "caveat": "Each mode was run once on the same matched workload, so there is no distribution; the byte counts leave out packet and tunnel overhead, the avoided-byte figure is measured against the raw run and may be negative, the timings overlap and cannot be added, and this is a Linux CPU transport measurement.", "kind": "Performance", "area": "ReSynth", "featuredRows": [ 1, 4, 7, 10 ] }, "technical": { "original": { "title": "Transfer byte and latency accounting, incompressible operands", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "rt-transfer-mixed", "title": "A workload that mixes several kinds of operand", "topic": "Representation", "date": "2026-10-13", "evidence": "Measured", "scope": "The same seven modes over a single four-call workload mixing regimes.", "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.", "statistic": "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.", "warmCold": "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": "Every mode in this class is recorded as passing the correctness check.", "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." ], "interpretation": "Raw transport moved 529,796 bytes in 18.9 ms against 8.6 ms locally, LZ4 moved 197,973 bytes in 18.0 ms and the resident-operand mode 398,002 bytes in 15.8 ms, but the automatic mode moved 664,124 bytes, more than the raw run it was supposed to improve on, and took 20.8 ms.", "href": "/research/resynth/", "sourceIds": [ "rt-src-transfer-report-csv", "rt-src-transfer-report-md" ], "rows": [ { "label": "local execution, no transport: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "local execution, no transport: total user wait", "value": 8.638, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "local execution, no transport: bytes avoided against the matched raw run", "value": 529796, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "raw transport: total wire bytes", "value": 529796, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "raw transport: total user wait", "value": 18.885, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "raw transport: bytes avoided against the matched raw run", "value": 0, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "resident-operand transport: total wire bytes", "value": 398002, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "resident-operand transport: total user wait", "value": 15.838, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "resident-operand transport: bytes avoided against the matched raw run", "value": 131794, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed transport: total wire bytes", "value": 197973, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed transport: total user wait", "value": 18.005, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed transport: bytes avoided against the matched raw run", "value": 331823, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "byte-delta transport: total wire bytes", "value": 398654, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "byte-delta transport: total user wait", "value": 16.65, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "byte-delta transport: bytes avoided against the matched raw run", "value": 131142, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed byte-delta transport: total wire bytes", "value": 231503, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: total user wait", "value": 18.587, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: bytes avoided against the matched raw run", "value": 298293, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive representation selection: total wire bytes", "value": 664124, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive representation selection: total user wait", "value": 20.83, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive representation selection: bytes avoided against the matched raw run", "value": -134328, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive selection, which chose the local path: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: total user wait", "value": 9.66, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: bytes avoided against the matched raw run", "value": 529796, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" } ], "comparisons": [ { "baseline": 1, "candidate": 4, "kind": "remote-vs-local" }, { "baseline": 3, "candidate": 9, "kind": "compression" } ], "chart": false, "presentation": { "title": "A workload that mixes several kinds of operand", "question": "Real workloads mix data shapes, so I measured the same modes on a workload that combines several regimes in one run.", "comparison": "The same seven modes over a single four-call workload mixing regimes.", "finding": "Raw transport moved 529,796 bytes in 18.9 ms against 8.6 ms locally, LZ4 moved 197,973 bytes in 18.0 ms and the resident-operand mode 398,002 bytes in 15.8 ms, but the automatic mode moved 664,124 bytes, more than the raw run it was supposed to improve on, and took 20.8 ms.", "lesson": "The mixed regime is where automatic selection can look actively bad, which is why I keep that negative result visible instead of quietly dropping it.", "caveat": "One matched workload per mode with no repeats or distribution; the byte counts leave out packet and tunnel overhead, the avoided-byte figure is measured against the raw run and is negative here, the timings overlap and must not be added together, and this is a Linux CPU transport measurement.", "kind": "Performance", "area": "ReSynth", "featuredRows": [ 1, 4, 7, 10 ] }, "technical": { "original": { "title": "Transfer byte and latency accounting, mixed operand regime", "scope": "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.", "interpretation": "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." } }, "chartSeries": [ { "title": "Framed wire bytes / mixed inputs", "indices": [ 3, 6, 9, 12, 15, 18 ], "labels": [ "Raw", "Resident", "LZ4", "Delta", "LZ4 + delta", "Adaptive" ] } ] }, { "id": "rt-transfer-small-changes", "title": "Transferring operands that change slightly between calls", "topic": "Representation", "date": "2026-10-13", "evidence": "Measured", "scope": "The same seven modes over the same four-call workload with the small-change operand pattern.", "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.", "statistic": "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.", "warmCold": "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": "Every mode in this class is recorded as passing the correctness check.", "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." ], "interpretation": "Raw transport moved 1,058,842 bytes in 33.9 ms against 10.7 ms locally; the resident-operand mode moved 664,012 bytes in 24.4 ms, difference encoding 567,631 bytes in 31.5 ms and LZ4 361,908 bytes in 27.9 ms, while the automatic mode again chose local and took 14.7 ms.", "href": "/research/resynth/", "sourceIds": [ "rt-src-transfer-report-csv", "rt-src-transfer-report-md" ], "rows": [ { "label": "local execution, no transport: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "local execution, no transport: total user wait", "value": 10.724, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "local execution, no transport: bytes avoided against the matched raw run", "value": 1058842, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "raw transport: total wire bytes", "value": 1058842, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "raw transport: total user wait", "value": 33.879, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "raw transport: bytes avoided against the matched raw run", "value": 0, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "resident-operand transport: total wire bytes", "value": 664012, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "resident-operand transport: total user wait", "value": 24.36, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "resident-operand transport: bytes avoided against the matched raw run", "value": 394830, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed transport: total wire bytes", "value": 361908, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed transport: total user wait", "value": 27.897, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed transport: bytes avoided against the matched raw run", "value": 696934, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "byte-delta transport: total wire bytes", "value": 567631, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "byte-delta transport: total user wait", "value": 31.491, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "byte-delta transport: bytes avoided against the matched raw run", "value": 491211, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed byte-delta transport: total wire bytes", "value": 364116, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: total user wait", "value": 29.563, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: bytes avoided against the matched raw run", "value": 694726, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive representation selection: total wire bytes", "value": 865458, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive representation selection: total user wait", "value": 29.058, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive representation selection: bytes avoided against the matched raw run", "value": 193384, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive selection, which chose the local path: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: total user wait", "value": 14.697, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: bytes avoided against the matched raw run", "value": 1058842, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" } ], "comparisons": [ { "baseline": 1, "candidate": 4, "kind": "remote-vs-local" }, { "baseline": 3, "candidate": 9, "kind": "compression" } ], "chart": false, "presentation": { "title": "Transferring operands that change slightly between calls", "question": "Byte-level difference encoding exists precisely for this shape of data, so I measured the same set of modes on operands that shift a little between calls.", "comparison": "The same seven modes over the same four-call workload with the small-change operand pattern.", "finding": "Raw transport moved 1,058,842 bytes in 33.9 ms against 10.7 ms locally; the resident-operand mode moved 664,012 bytes in 24.4 ms, difference encoding 567,631 bytes in 31.5 ms and LZ4 361,908 bytes in 27.9 ms, while the automatic mode again chose local and took 14.7 ms.", "lesson": "Difference encoding did reduce the bytes against raw, but LZ4 did better still, and the automatic chooser once more decided the work was not worth sending.", "caveat": "Each mode was measured once on the same matched workload, so there is no distribution behind any of these numbers; the byte counts leave out packet and tunnel overhead, the avoided-byte figure is measured against the raw run and can come out negative, the timings overlap and must not be added together, and this is a Linux CPU transport measurement.", "kind": "Performance", "area": "ReSynth", "featuredRows": [ 1, 4, 7, 10 ] }, "technical": { "original": { "title": "Transfer byte and latency accounting, small operand changes", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "rt-transfer-structured", "title": "Transferring operands that are highly structured", "topic": "Representation", "date": "2026-10-13", "evidence": "Measured", "scope": "The same seven modes over the same four-call workload with the structured operand pattern.", "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.", "statistic": "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.", "warmCold": "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": "Every mode in this class is recorded as passing the correctness check.", "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." ], "interpretation": "LZ4 cut the transfer from 1,058,842 bytes raw to 45,312 bytes and brought the wait down to 21.6 ms, below both the resident-operand mode at 467,149 bytes and 23.4 ms and raw at 28.3 ms, against 9.9 ms for local execution.", "href": "/research/resynth/", "sourceIds": [ "rt-src-transfer-report-csv", "rt-src-transfer-report-md" ], "rows": [ { "label": "local execution, no transport: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "local execution, no transport: total user wait", "value": 9.905, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "local execution, no transport: bytes avoided against the matched raw run", "value": 1058842, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "raw transport: total wire bytes", "value": 1058842, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "raw transport: total user wait", "value": 28.296, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "raw transport: bytes avoided against the matched raw run", "value": 0, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "resident-operand transport: total wire bytes", "value": 467149, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "resident-operand transport: total user wait", "value": 23.37, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "resident-operand transport: bytes avoided against the matched raw run", "value": 591693, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed transport: total wire bytes", "value": 45312, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed transport: total user wait", "value": 21.622, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed transport: bytes avoided against the matched raw run", "value": 1013530, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "byte-delta transport: total wire bytes", "value": 467041, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "byte-delta transport: total user wait", "value": 23.22, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "byte-delta transport: bytes avoided against the matched raw run", "value": 591801, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed byte-delta transport: total wire bytes", "value": 45204, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: total user wait", "value": 22.523, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: bytes avoided against the matched raw run", "value": 1013638, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive representation selection: total wire bytes", "value": 701164, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive representation selection: total user wait", "value": 26.08, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive representation selection: bytes avoided against the matched raw run", "value": 357678, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive selection, which chose the local path: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: total user wait", "value": 8.011, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: bytes avoided against the matched raw run", "value": 1058842, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" } ], "comparisons": [ { "baseline": 1, "candidate": 4, "kind": "remote-vs-local" }, { "baseline": 3, "candidate": 9, "kind": "compression" } ], "chart": false, "presentation": { "title": "Transferring operands that are highly structured", "question": "This is the regime a general-purpose compressor should pay for best, so I measured the same modes on operands with strong internal structure.", "comparison": "The same seven modes over the same four-call workload with the structured operand pattern.", "finding": "LZ4 cut the transfer from 1,058,842 bytes raw to 45,312 bytes and brought the wait down to 21.6 ms, below both the resident-operand mode at 467,149 bytes and 23.4 ms and raw at 28.3 ms, against 9.9 ms for local execution.", "lesson": "Here the compressor was clearly the best of the sending modes, yet the automatic chooser still preferred to keep everything local at 8.0 ms.", "caveat": "Every mode was measured once against the same matched workload with no distribution; the byte counts omit packet and tunnel overhead, the avoided-byte figure is measured against the raw run and can be negative, the timings overlap and must not be summed, and this is a Linux CPU transport measurement.", "kind": "Performance", "area": "ReSynth", "labels": { "1": "Local execution", "4": "Uncompressed transfer", "7": "Reuse an existing input", "10": "Compressed transfer (LZ4)" }, "featuredRows": [ 1, 4, 7, 10 ] }, "technical": { "original": { "title": "Transfer byte and latency accounting, structured operands", "scope": "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.", "interpretation": "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." } }, "chartSeries": [ { "title": "Framed wire bytes / structured inputs", "indices": [ 3, 6, 9, 12, 15, 18 ], "labels": [ "Raw", "Resident", "LZ4", "Delta", "LZ4 + delta", "Adaptive" ] } ] }, { "id": "rt-transfer-unchanged", "title": "Transferring operands that never change", "topic": "Representation", "date": "2026-10-13", "evidence": "Measured", "scope": "Local execution with no transport against raw, resident-operand, LZ4-compressed, byte-delta, compressed-delta and automatic modes, each over the same four-call workload with the same logical input.", "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.", "statistic": "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.", "warmCold": "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": "Every mode in this class is recorded as passing the correctness check.", "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." ], "interpretation": "Raw transport moved 1,058,842 bytes and took 37.9 ms against 8.7 ms locally; keeping the operand resident cut that to 467,149 bytes and 22.2 ms, and LZ4 got it to 263,749 bytes and 24.5 ms, while the automatic mode chose to stay local and took 10.4 ms.", "href": "/research/resynth/", "sourceIds": [ "rt-src-transfer-report-csv", "rt-src-transfer-report-md" ], "rows": [ { "label": "local execution, no transport: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "local execution, no transport: total user wait", "value": 8.744, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "local execution, no transport: bytes avoided against the matched raw run", "value": 1058842, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "raw transport: total wire bytes", "value": 1058842, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "raw transport: total user wait", "value": 37.934, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "raw transport: bytes avoided against the matched raw run", "value": 0, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "resident-operand transport: total wire bytes", "value": 467149, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "resident-operand transport: total user wait", "value": 22.222, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "resident-operand transport: bytes avoided against the matched raw run", "value": 591693, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed transport: total wire bytes", "value": 263749, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed transport: total user wait", "value": 24.545, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed transport: bytes avoided against the matched raw run", "value": 795093, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "byte-delta transport: total wire bytes", "value": 467017, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "byte-delta transport: total user wait", "value": 25.53, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "byte-delta transport: bytes avoided against the matched raw run", "value": 591825, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "lz4-compressed byte-delta transport: total wire bytes", "value": 263617, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: total user wait", "value": 30.674, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "lz4-compressed byte-delta transport: bytes avoided against the matched raw run", "value": 795225, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive representation selection: total wire bytes", "value": 733389, "unit": "bytes", "role": "remote", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive representation selection: total user wait", "value": 27.245, "unit": "ms", "role": "remote", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive representation selection: bytes avoided against the matched raw run", "value": 325453, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" }, { "label": "adaptive selection, which chose the local path: total wire bytes", "value": 0, "unit": "bytes", "role": "local", "n": 4, "statistic": "measured application-stream bytes across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: total user wait", "value": 10.374, "unit": "ms", "role": "local", "n": 4, "statistic": "total user wait across a matched four-call workload" }, { "label": "adaptive selection, which chose the local path: bytes avoided against the matched raw run", "value": 1058842, "unit": "bytes", "role": "metric", "n": 4, "statistic": "measured stream-byte difference against the matched raw four-call workload" } ], "comparisons": [ { "baseline": 1, "candidate": 4, "kind": "remote-vs-local" }, { "baseline": 3, "candidate": 9, "kind": "compression" } ], "chart": false, "presentation": { "title": "Transferring operands that never change", "question": "This is the regime where keeping an operand on the far side should pay best, so I measured every transport mode against the same matched workload.", "comparison": "Local execution with no transport against raw, resident-operand, LZ4-compressed, byte-delta, compressed-delta and automatic modes, each over the same four-call workload with the same logical input.", "finding": "Raw transport moved 1,058,842 bytes and took 37.9 ms against 8.7 ms locally; keeping the operand resident cut that to 467,149 bytes and 22.2 ms, and LZ4 got it to 263,749 bytes and 24.5 ms, while the automatic mode chose to stay local and took 10.4 ms.", "lesson": "With an unchanged operand both residency and compression cut the bytes substantially, and the mode that decides automatically ended up ahead of all of them.", "caveat": "A single matched workload per mode with no repeats; the byte counts leave out packet and tunnel overhead, the avoided-byte figure is measured against the raw run and can come out negative, the timings overlap and must not be added together, and this is a Linux CPU transport measurement.", "kind": "Performance", "area": "ReSynth", "featuredRows": [ 1, 4, 7, 10 ] }, "technical": { "original": { "title": "Transfer byte and latency accounting, unchanged operands", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "rt-s4-r3-cpu-four-mode", "title": "The same four modes without a GPU in the picture", "topic": "GEMM", "date": "2026-10-12", "evidence": "Measured", "scope": "Local execution against a remote worker on the same shared virtual machine, over 30 blocks and 960 checked calls.", "hardware": "The comparison ran on a shared virtual private server; the core count, memory size and accelerator model are not recorded in this receipt. The receipt explicitly discloses that the shared qualification overlapped and that the result is not an isolated-host causal estimate.", "software": "Optimised local baseline and a pinned serial reference BLAS provider used as the admitted local path; compiler and operating system versions are not recorded in this receipt.", "input": "The frozen 2048-square f32 eight-call workload with full 16 MiB output materialisation, alpha 1, beta 0.", "samples": "120 trials and 960 correct measured calls over 30 blocks; warm-up and rehearsal counts are not recorded in this receipt.", "statistic": "Whole-workload median wait and a paired 95 percent bootstrap interval on the improvement ratio.", "warmCold": "Four modes were compared per block, including a process-cold mode. Warm-up counts and the reset procedure are not recorded in this receipt.", "network": "Not recorded in this receipt.", "serialization": "Not recorded in this receipt.", "correctness": "960 measured calls recorded as correct against the full-output and scalar oracle. The separate accelerator-resident attempt passed an exact-source eight-call smoke with full-output and scalar oracle, released ownership, stale-token rejection and an identity-bound worker exit, but its full campaign stopped during the first resident warm-up after seven completed warm-ups with zero measured blocks.", "limitations": [ "Shared-host overlap is disclosed in the receipt; the slowdown factor is not an isolated-host causal estimate.", "The separate accelerator attempt produced zero measured blocks, so its numerical smoke result must not be read as campaign evidence.", "The initiating cause of the early stop is recorded as unknown because the original native receipt was overwritten by an emergency monitor restart.", "Estimated spend of 0.06192123695 currency units is recorded; actual provider billing is recorded as unknown.", "No accelerator resource remained running at the end of the attempt." ], "interpretation": "The local median was 3.52 s and the resident remote median 30.2 s, 8.6 times slower, and the separate accelerator attempt in the same record passed its small smoke test and then produced no measured blocks at all.", "href": "/research/runtime/", "sourceIds": [ "rt-src-s4-r3-decision", "rt-src-s4-protocol" ], "rows": [ { "label": "local whole-workload wait, median", "value": 3514.577, "unit": "ms", "role": "local", "n": 30, "statistic": "arithmetic median of 30 blocks" }, { "label": "resident whole-workload wait, median", "value": 30220.935, "unit": "ms", "role": "remote", "n": 30, "statistic": "arithmetic median of 30 blocks" }, { "label": "resident wait relative to local", "value": 8.598739, "unit": "ratio", "role": "metric", "n": 30, "statistic": "ratio of the resident whole-workload median to the local median" }, { "label": "paired improvement interval, lower bound", "value": -7.653039196, "unit": "ratio", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval on the improvement ratio" }, { "label": "paired improvement interval, upper bound", "value": -7.560618264, "unit": "ratio", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval on the improvement ratio" }, { "label": "measured calls", "value": 960, "unit": "calls", "role": "metric", "n": 30, "statistic": "8 calls per block over 30 blocks" }, { "label": "trials", "value": 120, "unit": "blocks", "role": "metric", "n": 120, "statistic": "trials recorded in the campaign" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "remote-vs-local" } ], "chart": false, "presentation": { "title": "The same four modes without a GPU in the picture", "question": "Before blaming the accelerator I wanted a comparison where the far side was the same kind of machine, so I ran the four-mode campaign on CPU only.", "comparison": "Local execution against a remote worker on the same shared virtual machine, over 30 blocks and 960 checked calls.", "finding": "The local median was 3.52 s and the resident remote median 30.2 s, 8.6 times slower, and the separate accelerator attempt in the same record passed its small smoke test and then produced no measured blocks at all.", "lesson": "The remote path was slower than local even with no accelerator involved, so the gap belongs to the path rather than to the device.", "caveat": "The shared host's overlap is disclosed, so the slowdown is not an isolated-host causal estimate; the cause of the early stop was lost when an emergency restart overwrote the original record, the spend figure is an estimate with actual provider billing recorded as unknown, and nothing was left running at the end.", "kind": "Performance", "area": "Runtime", "labels": { "0": "Local execution, median", "1": "Resident remote execution, median" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "CPU-only four-mode comparison attempt, resident operand against local baseline", "scope": "A CPU-only execution of the frozen four-mode comparison. The disposition records a completed 30-block campaign of 120 trials and 960 correct measured calls, then a separate accelerator-resident attempt that passed its eight-call smoke but produced no measured blocks. The overall requirement remained unmet.", "interpretation": "The resident operand mode was about 8.6 times slower than the optimised local baseline on the same CPU host, which is a measured loss for this method and a larger loss than the later accelerator-backed attempts recorded elsewhere in this dataset. The receipt preserves a numerical smoke pass and a campaign failure in the same entry, and the failure is the part that counts." } }, "chartSeries": [] }, { "id": "aspr-baseline-forecast-accuracy", "title": "Can a forecaster predict which operations will be needed next?", "topic": "ASPR", "date": "2026-10-11", "evidence": "Measured", "scope": "A linear model and a recurrent network, each scored for precision, recall and for how often it reproduced a complete set of operations.", "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.", "statistic": "precision, recall, joint class accuracy and exact-bundle accuracy on the held-out test split", "warmCold": "not recorded", "network": "None; classification only. Workload placement cost is simulated in a separate file.", "serialization": "not recorded", "correctness": "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.", "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." ], "interpretation": "The linear model reached 0.78 precision and 0.84 recall and the recurrent model 0.78 and 0.79, but reproducing a whole complete set of operations succeeded essentially never, zero for the linear model and about 0.01 for the recurrent one.", "href": "/research/aspr/", "sourceIds": [ "alg-aspr-predictor" ], "rows": [ { "label": "Linear baseline precision", "value": 0.7804878048780488, "unit": "fraction", "role": "metric", "n": 820, "statistic": "tp / (tp + fp) on the held-out test split" }, { "label": "Linear baseline recall", "value": 0.835509138381201, "unit": "fraction", "role": "metric", "n": 766, "statistic": "tp / (tp + fn) on the held-out test split" }, { "label": "Linear baseline joint class accuracy", "value": 0.5028368794326241, "unit": "fraction", "role": "metric", "n": null, "statistic": "joint class accuracy on the held-out test split; denominator not recorded" }, { "label": "Linear baseline candidate exact-bundle accuracy", "value": 0, "unit": "fraction", "role": "metric", "n": null, "statistic": "exact-bundle accuracy on the held-out test split; denominator not recorded" }, { "label": "Linear baseline discoverable bundle fraction", "value": 0.8198433420365535, "unit": "fraction", "role": "metric", "n": null, "statistic": "share of bundles recorded as discoverable in the test split" }, { "label": "GRU baseline precision", "value": 0.7828348504551366, "unit": "fraction", "role": "metric", "n": 769, "statistic": "tp / (tp + fp) on the held-out test split" }, { "label": "GRU baseline recall", "value": 0.7859007832898173, "unit": "fraction", "role": "metric", "n": 766, "statistic": "tp / (tp + fn) on the held-out test split" }, { "label": "GRU baseline joint class accuracy", "value": 0.4645390070921986, "unit": "fraction", "role": "metric", "n": null, "statistic": "joint class accuracy on the held-out test split; denominator not recorded" }, { "label": "GRU baseline candidate exact-bundle accuracy", "value": 0.010443864229765013, "unit": "fraction", "role": "metric", "n": null, "statistic": "exact-bundle accuracy on the held-out test split; denominator not recorded" }, { "label": "GRU baseline discoverable bundle fraction", "value": 0.8198433420365535, "unit": "fraction", "role": "metric", "n": null, "statistic": "share of bundles recorded as discoverable in the test split" } ], "comparisons": [], "chart": false, "presentation": { "title": "Can a forecaster predict which operations will be needed next?", "question": "Before any placement decision can be made, something has to anticipate which operations are coming, so I trained two baseline forecasters on a synthetic trace and scored them on data they had not seen.", "comparison": "A linear model and a recurrent network, each scored for precision, recall and for how often it reproduced a complete set of operations.", "finding": "The linear model reached 0.78 precision and 0.84 recall and the recurrent model 0.78 and 0.79, but reproducing a whole complete set of operations succeeded essentially never, zero for the linear model and about 0.01 for the recurrent one.", "lesson": "Identifying plausible operations is a different thing from reproducing the complete set, so any modelled speed-up built on these forecasts has to be read with that gap in view.", "caveat": "These are synthetic traces rather than real drawing or production workloads, the thresholds were chosen on a separate validation slice, and the workload latency attached to these forecasts elsewhere is modelled rather than measured.", "kind": "Functional check", "area": "ASPR", "labels": { "0": "Linear precision", "1": "Linear recall", "2": "Linear class accuracy", "3": "Linear complete-set accuracy", "4": "Linear discoverable share", "5": "Recurrent precision", "6": "Recurrent recall", "7": "Recurrent class accuracy", "8": "Recurrent complete-set accuracy", "9": "Recurrent discoverable share" }, "featuredRows": [ 0, 1, 5, 6 ] }, "technical": { "original": { "title": "Baseline linear and GRU placement forecasters on the held-out synthetic test split", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "aspr-cache-placement-simulation", "title": "Modelling where each operation should run when a local cache is available", "topic": "ASPR", "date": "2026-10-11", "evidence": "Simulation", "scope": "Reactive placement, a hand-written heuristic, a learned linear placement and a learned recurrent placement, each over the same 134 operations with 33 cache hits.", "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.", "statistic": "modeled mean and 95th-percentile operation latency", "warmCold": "Warm cache throughout; cache population cost is outside the modeled trace.", "network": "Simulated only; no network was exercised.", "serialization": "not recorded", "correctness": "Recorded unknown-bundle rejections are zero in every mode below.", "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." ], "interpretation": "Modelled mean latency was 42.9 ms for reactive, 30.5 ms for the heuristic, 30.1 ms for the learned linear placement and 40.7 ms for the learned recurrent placement, and the 95th percentile was 120.6 ms for every one of them.", "href": "/research/aspr/", "sourceIds": [ "alg-aspr-cache-simulation" ], "rows": [ { "label": "Reactive placement, mean", "value": 42.92724552238806, "unit": "ms", "role": "local", "n": 134, "statistic": "modeled mean over the trace" }, { "label": "Heuristic placement, mean", "value": 30.4630051641791, "unit": "ms", "role": "local", "n": 134, "statistic": "modeled mean over the trace" }, { "label": "Learned linear placement, mean", "value": 30.072405238805974, "unit": "ms", "role": "local", "n": 134, "statistic": "modeled mean over the trace" }, { "label": "Learned GRU placement, mean", "value": 40.70129598507462, "unit": "ms", "role": "local", "n": 134, "statistic": "modeled mean over the trace" }, { "label": "Reactive placement, 95th percentile", "value": 120.6, "unit": "ms", "role": "metric", "n": 134, "statistic": "modeled 95th percentile" }, { "label": "Learned linear placement, 95th percentile", "value": 120.6, "unit": "ms", "role": "metric", "n": 134, "statistic": "modeled 95th percentile" } ], "comparisons": [ { "baseline": 0, "candidate": 2, "kind": "simulation" }, { "baseline": 1, "candidate": 2, "kind": "simulation" }, { "baseline": 2, "candidate": 3, "kind": "simulation" } ], "chart": true, "presentation": { "title": "Modelling where each operation should run when a local cache is available", "question": "I wanted to compare placement strategies before building any of them, so I modelled four of them over a synthetic trace with a 64 MiB local result cache.", "comparison": "Reactive placement, a hand-written heuristic, a learned linear placement and a learned recurrent placement, each over the same 134 operations with 33 cache hits.", "finding": "Modelled mean latency was 42.9 ms for reactive, 30.5 ms for the heuristic, 30.1 ms for the learned linear placement and 40.7 ms for the learned recurrent placement, and the 95th percentile was 120.6 ms for every one of them.", "lesson": "The simple heuristic matched the learned linear placement and beat the learned recurrent one, and none of them improved the tail at all.", "caveat": "This is arithmetic modelling with no network, no remote machine and no accelerator exercised, the remote cost model is not independently validated here, and the latency attached to these forecasts is simulated rather than measured.", "kind": "Simulation", "area": "ASPR", "labels": { "0": "Reactive placement, mean", "1": "Heuristic placement, mean", "2": "Learned linear placement, mean", "3": "Learned recurrent placement, mean", "4": "Reactive placement, 95th percentile", "5": "Learned linear placement, 95th percentile" }, "featuredRows": [ 0, 1, 2, 3 ] }, "technical": { "original": { "title": "Modeled placement with a 64 MiB local result cache: reactive, heuristic and learned", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "aspr-codec-random-1mib", "title": "The same six codecs on data that will not compress", "topic": "ASPR", "date": "2026-10-11", "evidence": "Measured", "scope": "The same six profiles over the same size of incompressible input.", "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.", "statistic": "exact coded bytes and median encode time of 10 samples", "warmCold": "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": "Round-trip correctness is not recorded as a pass or fail field in this file.", "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." ], "interpretation": "Both zlib levels made the file slightly larger than the original, 1,048,902 bytes against 1,048,576, while lzma preset 1 gave 674,572 bytes, lzma preset 6 gave 848,528 and the byte-plane transform 558,573.", "href": "/research/aspr/", "sourceIds": [ "alg-aspr-codec" ], "rows": [ { "label": "Raw bytes, no codec", "value": 1048576, "unit": "bytes", "role": "metric", "n": 10, "statistic": "exact coded size; encode median 0.0948 ms in the source" }, { "label": "zlib level 1", "value": 1048902, "unit": "bytes", "role": "metric", "n": 10, "statistic": "exact coded size; encode median 40.21175 ms in the source" }, { "label": "zlib level 9", "value": 1048902, "unit": "bytes", "role": "metric", "n": 10, "statistic": "exact coded size; encode median 41.77355 ms in the source" }, { "label": "lzma preset 1", "value": 674572, "unit": "bytes", "role": "metric", "n": 10, "statistic": "exact coded size; encode median 255.056 ms in the source" }, { "label": "lzma preset 6", "value": 848528, "unit": "bytes", "role": "metric", "n": 10, "statistic": "exact coded size; encode median 320.27750000000003 ms in the source" }, { "label": "XOR-plane transform plus zlib level 9", "value": 558573, "unit": "bytes", "role": "metric", "n": 10, "statistic": "exact coded size; encode median 29.2665 ms in the source" } ], "comparisons": [], "chart": false, "presentation": { "title": "The same six codecs on data that will not compress", "question": "A codec that looks good on friendly data can be useless on hostile data, so I ran the identical six profiles over a megabyte of random bytes.", "comparison": "The same six profiles over the same size of incompressible input.", "finding": "Both zlib levels made the file slightly larger than the original, 1,048,902 bytes against 1,048,576, while lzma preset 1 gave 674,572 bytes, lzma preset 6 gave 848,528 and the byte-plane transform 558,573.", "lesson": "On incompressible input the general-purpose codecs buy very little and the cheapest option can cost bytes, so one corpus is not enough to choose a codec.", "caveat": "Ten samples per profile on one host, byte buffers with no transport, random synthetic bytes are not a drawing payload, and round-trip correctness is not recorded here.", "kind": "Performance", "area": "ASPR", "labels": { "0": "Uncompressed", "1": "zlib level 1", "2": "zlib level 9", "3": "lzma preset 1", "4": "lzma preset 6", "5": "Byte-plane transform with zlib level 9" }, "featuredRows": [ 0, 1, 2, 3 ] }, "technical": { "original": { "title": "Lossless codec screening on a 1 MiB random-byte buffer", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "aspr-codec-smooth-1mib", "title": "Six ways to compress one megabyte of smooth data", "topic": "ASPR", "date": "2026-10-11", "evidence": "Measured", "scope": "Uncompressed, two zlib levels, two lzma presets and a byte-plane transform followed by zlib, each with ten encode and ten decode samples.", "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.", "statistic": "exact coded bytes and median encode time of 10 samples", "warmCold": "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": "Round-trip correctness is not recorded as a pass or fail field in this file.", "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." ], "interpretation": "The raw megabyte became 148,083 bytes with zlib level 1, 148,474 with level 9, 59,940 with lzma preset 1, 23,940 with lzma preset 6 and just 2,397 bytes with the byte-plane transform.", "href": "/research/aspr/", "sourceIds": [ "alg-aspr-codec" ], "rows": [ { "label": "Raw bytes, no codec", "value": 1048576, "unit": "bytes", "role": "metric", "n": 10, "statistic": "exact coded size; encode median 0.00555 ms in the source" }, { "label": "zlib level 1", "value": 148083, "unit": "bytes", "role": "metric", "n": 10, "statistic": "exact coded size; encode median 12.79725 ms in the source" }, { "label": "zlib level 9", "value": 148474, "unit": "bytes", "role": "metric", "n": 10, "statistic": "exact coded size; encode median 791.3118 ms in the source" }, { "label": "lzma preset 1", "value": 59940, "unit": "bytes", "role": "metric", "n": 10, "statistic": "exact coded size; encode median 48.127700000000004 ms in the source" }, { "label": "lzma preset 6", "value": 23940, "unit": "bytes", "role": "metric", "n": 10, "statistic": "exact coded size; encode median 496.76265 ms in the source" }, { "label": "XOR-plane transform plus zlib level 9", "value": 2397, "unit": "bytes", "role": "metric", "n": 10, "statistic": "exact coded size; encode median 12.7918 ms in the source" } ], "comparisons": [], "chart": false, "presentation": { "title": "Six ways to compress one megabyte of smooth data", "question": "I wanted to know which lossless codec to reach for before committing to one, so I measured six profiles on a megabyte of smooth, highly structured bytes.", "comparison": "Uncompressed, two zlib levels, two lzma presets and a byte-plane transform followed by zlib, each with ten encode and ten decode samples.", "finding": "The raw megabyte became 148,083 bytes with zlib level 1, 148,474 with level 9, 59,940 with lzma preset 1, 23,940 with lzma preset 6 and just 2,397 bytes with the byte-plane transform.", "lesson": "The transform followed by zlib was by far the smallest on this data, and the zlib level comparison is the warning: the higher level actually produced a slightly larger file.", "caveat": "Ten samples per profile on one host, byte buffers only with no transport or authenticated envelope, smooth synthetic bytes are not a drawing payload, and round-trip correctness is not recorded as a pass or a failure here.", "kind": "Performance", "area": "ASPR", "labels": { "0": "Uncompressed", "1": "zlib level 1", "2": "zlib level 9", "3": "lzma preset 1", "4": "lzma preset 6", "5": "Byte-plane transform with zlib level 9" }, "featuredRows": [ 0, 1, 2, 3 ] }, "technical": { "original": { "title": "Lossless codec screening on a 1 MiB smooth buffer", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "aspr-inference-budget", "title": "How much it costs to ask a forecaster for an opinion", "topic": "ASPR", "date": "2026-10-11", "evidence": "Measured", "scope": "Five thousand timed calls per model in a fresh process, covering feature construction and one model call, with adaptation timed separately.", "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.", "statistic": "median, 95th percentile and CPU milliseconds per call", "warmCold": "Warm process; the first call is included in the recorded samples.", "network": "None; local CPU only.", "serialization": "not recorded", "correctness": "Not the subject of this measurement.", "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." ], "interpretation": "The linear model answered in a median of 0.045 ms and the recurrent model in 0.074 ms, with CPU time per call of 0.053 and 0.084 ms.", "href": "/research/aspr/", "sourceIds": [ "alg-aspr-inference-budget" ], "rows": [ { "label": "Linear, median call", "value": 0.0446, "unit": "ms", "role": "metric", "n": 5000, "statistic": "median of 5000 calls" }, { "label": "Linear, 95th-percentile call", "value": 0.07280500000000002, "unit": "ms", "role": "metric", "n": 5000, "statistic": "95th percentile of 5000 calls" }, { "label": "Linear, CPU milliseconds per call", "value": 0.053125, "unit": "ms", "role": "metric", "n": 5000, "statistic": "CPU time per call" }, { "label": "GRU, median call", "value": 0.0741, "unit": "ms", "role": "metric", "n": 5000, "statistic": "median of 5000 calls" }, { "label": "GRU, 95th-percentile call", "value": 0.126505, "unit": "ms", "role": "metric", "n": 5000, "statistic": "95th percentile of 5000 calls" }, { "label": "GRU, CPU milliseconds per call", "value": 0.084375, "unit": "ms", "role": "metric", "n": 5000, "statistic": "CPU time per call" } ], "comparisons": [], "chart": true, "presentation": { "title": "How much it costs to ask a forecaster for an opinion", "question": "A forecaster that costs more than it saves is pointless, so I measured the price of a single prediction for both models.", "comparison": "Five thousand timed calls per model in a fresh process, covering feature construction and one model call, with adaptation timed separately.", "finding": "The linear model answered in a median of 0.045 ms and the recurrent model in 0.074 ms, with CPU time per call of 0.053 and 0.084 ms.", "lesson": "Asking for a forecast is three orders of magnitude cheaper than the operations it is meant to place, so the forecaster is never the reason a placement went wrong.", "caveat": "CPU inference only with no power telemetry and no accelerator path, five thousand calls on one machine whose processor was never recorded, and the model and feature memory counters read as zero in this data.", "kind": "Performance", "area": "ASPR", "labels": { "0": "Linear model, median call", "1": "Linear model, 95th percentile", "2": "Linear model, CPU time per call", "3": "Recurrent model, median call", "4": "Recurrent model, 95th percentile", "5": "Recurrent model, CPU time per call" }, "featuredRows": [ 0, 3 ] }, "technical": { "original": { "title": "Measured CPU inference and adaptation cost for both forecasters", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "aspr-interference-short-bursts", "title": "Whether background work slows the foreground", "topic": "ASPR", "date": "2026-10-11", "evidence": "Measured", "scope": "Thirty bursts each with no background work, with unrestricted background work, and with background work limited to a ten-percent budget.", "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.", "statistic": "median and 95th percentile of 30 bursts", "warmCold": "Warm; bursts run back to back after the condition is established.", "network": "None; local CPU only.", "serialization": "not recorded", "correctness": "Not the subject of this measurement.", "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." ], "interpretation": "The median burst was 9.66 ms with no background work, 11.54 ms with unrestricted background work and 11.56 ms under the budget, with the 95th percentile rising from 12.0 ms to 13.5 ms and 13.3 ms.", "href": "/research/aspr/", "sourceIds": [ "alg-aspr-interference" ], "rows": [ { "label": "No background work, median", "value": 9.663250000000001, "unit": "ms", "role": "local", "n": 30, "statistic": "median of 30 bursts" }, { "label": "No background work, 95th percentile", "value": 11.99265, "unit": "ms", "role": "metric", "n": 30, "statistic": "95th percentile of 30 bursts" }, { "label": "Unlimited background work, median", "value": 11.544599999999999, "unit": "ms", "role": "local", "n": 30, "statistic": "median of 30 bursts" }, { "label": "Unlimited background work, 95th percentile", "value": 13.505559999999997, "unit": "ms", "role": "metric", "n": 30, "statistic": "95th percentile of 30 bursts" }, { "label": "Ten-percent background budget, median", "value": 11.56305, "unit": "ms", "role": "local", "n": 30, "statistic": "median of 30 bursts" }, { "label": "Ten-percent background budget, 95th percentile", "value": 13.307719999999998, "unit": "ms", "role": "metric", "n": 30, "statistic": "95th percentile of 30 bursts" } ], "comparisons": [], "chart": true, "presentation": { "title": "Whether background work slows the foreground", "question": "If the system does speculative work in the background, I needed to know what that does to someone waiting for an answer, so I ran a fixed operation under three background conditions.", "comparison": "Thirty bursts each with no background work, with unrestricted background work, and with background work limited to a ten-percent budget.", "finding": "The median burst was 9.66 ms with no background work, 11.54 ms with unrestricted background work and 11.56 ms under the budget, with the 95th percentile rising from 12.0 ms to 13.5 ms and 13.3 ms.", "lesson": "Limiting the background budget did not protect the foreground here; both background conditions cost about the same, roughly two milliseconds of extra wait per burst.", "caveat": "Short bursts rather than a sustained energy test, one host with eight threads and no multi-tenant or remote interference, and the source of the background work is not described.", "kind": "Performance", "area": "ASPR", "labels": { "0": "No background work, median", "1": "No background work, 95th percentile", "2": "Unlimited background work, median", "3": "Unlimited background work, 95th percentile", "4": "Budgeted background work, median", "5": "Budgeted background work, 95th percentile" }, "featuredRows": [ 0, 2, 4 ] }, "technical": { "original": { "title": "Short-burst response under no background work, unlimited background work and a ten-percent budget", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "aspr-local-precompute-simulation", "title": "Modelling background precomputation and splitting work between two places", "topic": "ASPR", "date": "2026-10-11", "evidence": "Simulation", "scope": "A cache baseline, learned local precomputation and a dual placement mode, each modelled at one times and at four times the assumed background CPU cost.", "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.", "statistic": "modeled mean and 95th-percentile operation latency with background CPU work", "warmCold": "Warm cache in every combination.", "network": "Simulated only; no network was exercised.", "serialization": "not recorded", "correctness": "Pending work after the trace is zero and unknown-bundle rejections are not raised in the rows below.", "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." ], "interpretation": "At the cheaper background cost the baseline modelled 42.9 ms, precomputation 30.5 ms and the split mode 26.2 ms; at four times the background cost precomputation slipped to 38.2 ms and the split mode to 28.5 ms, and every combination still showed a 120.6 ms 95th percentile.", "href": "/research/aspr/", "sourceIds": [ "alg-aspr-precompute-simulation" ], "rows": [ { "label": "Cache baseline, one-times CPU work, mean", "value": 42.92724552238806, "unit": "ms", "role": "local", "n": 134, "statistic": "modeled mean over the trace" }, { "label": "Learned local predictive, one-times CPU work, mean", "value": 30.49750298507462, "unit": "ms", "role": "local", "n": 134, "statistic": "modeled mean over the trace" }, { "label": "Dual placement, one-times CPU work, mean", "value": 26.245946686567162, "unit": "ms", "role": "local", "n": 134, "statistic": "modeled mean over the trace" }, { "label": "Learned local predictive, four-times CPU work, mean", "value": 38.22850298507463, "unit": "ms", "role": "local", "n": 134, "statistic": "modeled mean over the trace" }, { "label": "Dual placement, four-times CPU work, mean", "value": 28.453419223880598, "unit": "ms", "role": "local", "n": 134, "statistic": "modeled mean over the trace" }, { "label": "All modes and work factors, 95th percentile", "value": 120.6, "unit": "ms", "role": "metric", "n": 134, "statistic": "modeled 95th percentile, identical in all six combinations" } ], "comparisons": [ { "baseline": 0, "candidate": 2, "kind": "simulation" }, { "baseline": 0, "candidate": 4, "kind": "simulation" }, { "baseline": 1, "candidate": 2, "kind": "simulation" } ], "chart": true, "presentation": { "title": "Modelling background precomputation and splitting work between two places", "question": "If a forecast is often right, some of the work could be started in advance, so I modelled a learned precomputation mode and a mode that splits work between local and remote, at two different background cost levels.", "comparison": "A cache baseline, learned local precomputation and a dual placement mode, each modelled at one times and at four times the assumed background CPU cost.", "finding": "At the cheaper background cost the baseline modelled 42.9 ms, precomputation 30.5 ms and the split mode 26.2 ms; at four times the background cost precomputation slipped to 38.2 ms and the split mode to 28.5 ms, and every combination still showed a 120.6 ms 95th percentile.", "lesson": "Speculative work buys a lower average only while the background budget stays cheap, and it does nothing for the tail.", "caveat": "A ten-percent CPU budget assumption rather than a measured scheduler, an identical tail in all six combinations, and background work that is charged but never validated against real behaviour.", "kind": "Simulation", "area": "ASPR", "labels": { "0": "Cache baseline, mean", "1": "Learned precomputation, mean", "2": "Dual placement, mean", "3": "Learned precomputation at four times background work, mean", "4": "Dual placement at four times background work, mean", "5": "All modes, 95th percentile" }, "featuredRows": [ 0, 1, 2 ] }, "technical": { "original": { "title": "Modeled learned local precomputation and dual placement at one-times and four-times CPU work", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "aspr-memory-corrected", "title": "What the two forecasters actually cost in memory", "topic": "ASPR", "date": "2026-10-11", "evidence": "Measured", "scope": "Working set, peak and recorded parameter storage for the linear model and for the recurrent one, each in its own fresh process.", "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.", "statistic": "working bytes, peak bytes and recorded parameter bytes", "warmCold": "Fresh process.", "network": "None; local process only.", "serialization": "not recorded", "correctness": "Not the subject of this measurement.", "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." ], "interpretation": "The linear model occupied 26,984,448 bytes working and the recurrent model 27,070,464 bytes, while their parameter storage was 4,192 and 12,928 bytes, so a difference of a few thousand bytes of weights produced a difference of about 86 KB of process.", "href": "/research/aspr/", "sourceIds": [ "alg-aspr-memory-corrected" ], "rows": [ { "label": "Linear working bytes", "value": 26984448, "unit": "bytes", "role": "metric", "n": null, "statistic": "fresh-process working set" }, { "label": "Linear peak bytes", "value": 26984448, "unit": "bytes", "role": "metric", "n": null, "statistic": "fresh-process peak" }, { "label": "Linear parameter bytes", "value": 4192, "unit": "bytes", "role": "metric", "n": null, "statistic": "recorded parameter storage" }, { "label": "GRU working bytes", "value": 27070464, "unit": "bytes", "role": "metric", "n": null, "statistic": "fresh-process working set" }, { "label": "GRU peak bytes", "value": 27070464, "unit": "bytes", "role": "metric", "n": null, "statistic": "fresh-process peak" }, { "label": "GRU parameter bytes", "value": 12928, "unit": "bytes", "role": "metric", "n": null, "statistic": "recorded parameter storage" } ], "comparisons": [], "chart": false, "presentation": { "title": "What the two forecasters actually cost in memory", "question": "Parameter counts alone would mislead me about deployment size, so I measured a fresh process with the numeric runtime and the weights loaded.", "comparison": "Working set, peak and recorded parameter storage for the linear model and for the recurrent one, each in its own fresh process.", "finding": "The linear model occupied 26,984,448 bytes working and the recurrent model 27,070,464 bytes, while their parameter storage was 4,192 and 12,928 bytes, so a difference of a few thousand bytes of weights produced a difference of about 86 KB of process.", "lesson": "The shared runtime dominates the footprint, so parameter count tells you almost nothing about what deploying a model will cost.", "caveat": "The footprint includes the runtime rather than the weights alone, the two models were loaded one after another so a combined deployment is unmeasured, and there is no power telemetry.", "kind": "Performance", "area": "ASPR", "labels": { "0": "Linear model, working bytes", "1": "Linear model, peak bytes", "2": "Linear model, parameter bytes", "3": "Recurrent model, working bytes", "4": "Recurrent model, peak bytes", "5": "Recurrent model, parameter bytes" }, "featuredRows": [ 0, 3 ] }, "technical": { "original": { "title": "Fresh-process runtime and loaded-weight memory for both forecasters", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "aspr-refined-forecast-fresh-trace", "title": "The same forecasters on a fresh synthetic trace", "topic": "ASPR", "date": "2026-10-11", "evidence": "Measured", "scope": "I kept the prediction threshold unchanged and tested the linear and recurrent models on a fresh generated trace, counting correct predictions, misses and false alarms.", "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.", "statistic": "precision, recall, joint class accuracy and exact-bundle accuracy at a frozen threshold", "warmCold": "not recorded", "network": "None; classification only.", "serialization": "not recorded", "correctness": "The frozen threshold, fresh counts and each fraction are recorded in the same file, so every fraction can be recomputed from its counts.", "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." ], "interpretation": "The linear model scored 0.79 precision and 0.82 recall and the recurrent model 0.80 and 0.81, so the refinement stabilised the ordinary metrics, while complete-set accuracy stayed at zero for the linear model and about 0.009 for the recurrent one.", "href": "/research/aspr/", "sourceIds": [ "alg-aspr-refinement" ], "rows": [ { "label": "Linear refined precision", "value": 0.7940038684719536, "unit": "fraction", "role": "metric", "n": 4136, "statistic": "tp / (tp + fp) on the fresh synthetic trace at a frozen threshold" }, { "label": "Linear refined recall", "value": 0.8230576441102757, "unit": "fraction", "role": "metric", "n": 3990, "statistic": "tp / (tp + fn) on the fresh synthetic trace at a frozen threshold" }, { "label": "Linear refined joint class accuracy", "value": 0.499163179916318, "unit": "fraction", "role": "metric", "n": null, "statistic": "joint class accuracy on the fresh synthetic trace; denominator not recorded" }, { "label": "Linear refined exact-bundle accuracy", "value": 0, "unit": "fraction", "role": "metric", "n": null, "statistic": "exact-bundle accuracy on the fresh synthetic trace; denominator not recorded" }, { "label": "Linear refined discoverable bundle fraction", "value": 0.7518796992481203, "unit": "fraction", "role": "metric", "n": null, "statistic": "share of bundles recorded as discoverable on the fresh trace" }, { "label": "GRU refined precision", "value": 0.8020469296055917, "unit": "fraction", "role": "metric", "n": 4006, "statistic": "tp / (tp + fp) on the fresh synthetic trace at a frozen threshold" }, { "label": "GRU refined recall", "value": 0.8052631578947368, "unit": "fraction", "role": "metric", "n": 3990, "statistic": "tp / (tp + fn) on the fresh synthetic trace at a frozen threshold" }, { "label": "GRU refined joint class accuracy", "value": 0.45244072524407253, "unit": "fraction", "role": "metric", "n": null, "statistic": "joint class accuracy on the fresh synthetic trace; denominator not recorded" }, { "label": "GRU refined exact-bundle accuracy", "value": 0.008771929824561403, "unit": "fraction", "role": "metric", "n": null, "statistic": "exact-bundle accuracy on the fresh synthetic trace; denominator not recorded" }, { "label": "GRU refined discoverable bundle fraction", "value": 0.7518796992481203, "unit": "fraction", "role": "metric", "n": null, "statistic": "share of bundles recorded as discoverable on the fresh trace" } ], "comparisons": [], "chart": false, "presentation": { "title": "The same forecasters on a fresh synthetic trace", "question": "I wanted to know whether the forecasts held up on data that had not influenced the thresholds, so I froze the thresholds from the earlier split and re-scored on a new trace.", "comparison": "I kept the prediction threshold unchanged and tested the linear and recurrent models on a fresh generated trace, counting correct predictions, misses and false alarms.", "finding": "The linear model scored 0.79 precision and 0.82 recall and the recurrent model 0.80 and 0.81, so the refinement stabilised the ordinary metrics, while complete-set accuracy stayed at zero for the linear model and about 0.009 for the recurrent one.", "lesson": "Better classification did not turn forecasting into reproducing a whole set of operations, and that remains the unresolved part of the idea.", "caveat": "This is another generated trace, not real drawing data. I kept the thresholds unchanged rather than tuning them to the new test.", "kind": "Functional check", "area": "ASPR", "labels": { "0": "Linear precision", "1": "Linear recall", "2": "Linear class accuracy", "3": "Linear complete-set accuracy", "4": "Linear discoverable share", "5": "Recurrent precision", "6": "Recurrent recall", "7": "Recurrent class accuracy", "8": "Recurrent complete-set accuracy", "9": "Recurrent discoverable share" }, "featuredRows": [ 0, 1, 5, 6 ] }, "technical": { "original": { "title": "Frozen-threshold forecaster refinement on a fresh synthetic trace", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "obp-cpu-reassociation-n1024", "title": "The same evaluation comparison at four times the size", "topic": "OBP v2", "date": "2026-10-11", "evidence": "Measured", "scope": "Eight calculation paths with 1,024-by-1,024 matrices, thirty test blocks per path, with correctness checks outside the timer.", "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.", "statistic": "median of 30 held-out blocks per operation", "warmCold": "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": "Each case records the reference sum, reference vector sum, vector digest and oracle time alongside the timed rows; the oracle runs outside the timer.", "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." ], "interpretation": "The right-associated path took 1.18 ms against 30.9 ms for left-to-right, 26 times faster, and the directly demanded slice took 0.165 ms against 30.2 ms for the full slice, 183 times faster, while multi_dot came in at 1.255 ms.", "href": "/research/obp-v2/", "sourceIds": [ "alg-obp-cpu-benchmark" ], "rows": [ { "label": "Native dense f32 matrix-vector product", "value": 14.4665, "unit": "ms", "role": "native", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Left-to-right f64 reassociation", "value": 30.8735, "unit": "ms", "role": "native", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Certified right-associated f64 boundary path", "value": 1.18045, "unit": "ms", "role": "local", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "NumPy multi_dot f64 library path", "value": 1.2551999999999999, "unit": "ms", "role": "native", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Scanned right-associated f64 path", "value": 20.4194, "unit": "ms", "role": "local", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Full demanded f64 slice", "value": 30.1521, "unit": "ms", "role": "native", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Direct demanded f64 slice", "value": 0.16515000000000002, "unit": "ms", "role": "local", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Warm memoised f32 result", "value": 1.0077500000000001, "unit": "ms", "role": "local", "n": 30, "statistic": "median of held-out timing blocks" } ], "comparisons": [ { "baseline": 1, "candidate": 2, "kind": "implementation" }, { "baseline": 3, "candidate": 2, "kind": "implementation" }, { "baseline": 5, "candidate": 6, "kind": "implementation" } ], "chart": true, "presentation": { "title": "The same evaluation comparison at four times the size", "question": "I increased the matrix dimension to 1,024 to see whether a better calculation order remained useful as the intermediate result grew.", "comparison": "Eight calculation paths with 1,024-by-1,024 matrices, thirty test blocks per path, with correctness checks outside the timer.", "finding": "The right-associated path took 1.18 ms against 30.9 ms for left-to-right, 26 times faster, and the directly demanded slice took 0.165 ms against 30.2 ms for the full slice, 183 times faster, while multi_dot came in at 1.255 ms.", "lesson": "The gap widens sharply with size, which says the waste was proportional to the array rather than a fixed overhead.", "caveat": "One shared laptop, a structured integer-valued input rather than an arbitrary matrix, 30 held-out blocks per operation, and the comparison interval against the library path includes zero so no separation from it is claimed at this size.", "kind": "Performance", "area": "OBP", "labels": { "0": "Native f32 product", "1": "Original calculation order", "2": "Reordered calculation", "3": "Library calculation", "4": "Scanned reorder", "5": "Full slice", "6": "Demanded slice", "7": "Reused f32 result" }, "featuredRows": [ 1, 2 ] }, "technical": { "original": { "title": "Certified reassociation, slices and memo against native paths at n=1024", "scope": "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.", "interpretation": "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]." } }, "chartSeries": [] }, { "id": "obp-cpu-reassociation-n2048", "title": "Avoiding a large intermediate matrix", "topic": "OBP v2", "date": "2026-10-11", "evidence": "Measured", "scope": "Eight calculation paths with 2,048-by-2,048 matrices, thirty test blocks per path, with correctness checks outside the timer.", "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.", "statistic": "median of 30 held-out blocks per operation", "warmCold": "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": "Each case records the reference sum, reference vector sum, vector digest and oracle time alongside the timed rows; the oracle runs outside the timer.", "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." ], "interpretation": "The right-associated path took 4.60 ms against 209.9 ms for left-to-right, 45.7 times faster, and the directly demanded slice took 0.33 ms against 255.0 ms for the full slice, 768 times faster, while the library path came in at 4.57 ms.", "href": "/research/obp-v2/", "sourceIds": [ "alg-obp-cpu-benchmark" ], "rows": [ { "label": "Native dense f32 matrix-vector product", "value": 81.4829, "unit": "ms", "role": "native", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Left-to-right f64 reassociation", "value": 209.94735, "unit": "ms", "role": "native", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Certified right-associated f64 boundary path", "value": 4.59705, "unit": "ms", "role": "local", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "NumPy multi_dot f64 library path", "value": 4.57235, "unit": "ms", "role": "native", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Scanned right-associated f64 path", "value": 90.61619999999999, "unit": "ms", "role": "local", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Full demanded f64 slice", "value": 254.98865, "unit": "ms", "role": "native", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Direct demanded f64 slice", "value": 0.3321, "unit": "ms", "role": "local", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Warm memoised f32 result", "value": 4.52055, "unit": "ms", "role": "local", "n": 30, "statistic": "median of held-out timing blocks" } ], "comparisons": [ { "baseline": 1, "candidate": 2, "kind": "implementation" }, { "baseline": 3, "candidate": 2, "kind": "implementation" }, { "baseline": 5, "candidate": 6, "kind": "implementation" } ], "chart": true, "presentation": { "title": "Avoiding a large intermediate matrix", "question": "When the matrices are 2,048 by 2,048, does calculating the final vector require building a matrix with more than four million entries first?", "comparison": "Eight calculation paths with 2,048-by-2,048 matrices, thirty test blocks per path, with correctness checks outside the timer.", "finding": "The right-associated path took 4.60 ms against 209.9 ms for left-to-right, 45.7 times faster, and the directly demanded slice took 0.33 ms against 255.0 ms for the full slice, 768 times faster, while the library path came in at 4.57 ms.", "lesson": "The big number here is the avoided materialisation, not an advantage over the library; the two fastest paths were within a fraction of a millisecond of each other.", "caveat": "One shared laptop, a structured integer-valued input rather than an arbitrary matrix, 30 held-out blocks per operation, and the paired interval against the library path includes zero, so no advantage over it is claimed at this size.", "kind": "Performance", "area": "OBP", "labels": { "0": "Native f32 product", "1": "Original calculation order", "2": "Reordered calculation", "3": "Library calculation", "4": "Scanned reorder", "5": "Full slice", "6": "Demanded slice", "7": "Reused f32 result" }, "featuredRows": [ 1, 2, 3 ] }, "technical": { "original": { "title": "Certified reassociation, slices and memo against native paths at n=2048", "scope": "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.", "interpretation": "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]." } }, "chartSeries": [] }, { "id": "obp-cpu-reassociation-n256", "title": "Reassociating a sum and asking only for the part that is needed", "topic": "OBP v2", "date": "2026-10-11", "evidence": "Measured", "scope": "On one laptop I timed a left-to-right f64 evaluation, a certified right-associated evaluation, the NumPy multi_dot library path, a scanned variant, and the full slice against the directly demanded slice, over 30 held-out blocks each.", "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.", "statistic": "median of 30 held-out blocks per operation", "warmCold": "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": "Each case records the reference sum, reference vector sum, vector digest and oracle time alongside the timed rows; the oracle runs outside the timer.", "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." ], "interpretation": "The right-associated path took 0.125 ms against 0.654 ms for left-to-right, 5.2 times faster, and asking for the demanded slice directly took 0.054 ms against 0.561 ms for the full slice, while multi_dot matched the certified path at 0.134 ms.", "href": "/research/obp-v2/", "sourceIds": [ "alg-obp-cpu-benchmark" ], "rows": [ { "label": "Native dense f32 matrix-vector product", "value": 0.35729999999999995, "unit": "ms", "role": "native", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Left-to-right f64 reassociation", "value": 0.65445, "unit": "ms", "role": "native", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Certified right-associated f64 boundary path", "value": 0.12495, "unit": "ms", "role": "local", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "NumPy multi_dot f64 library path", "value": 0.13415, "unit": "ms", "role": "native", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Scanned right-associated f64 path", "value": 0.5332, "unit": "ms", "role": "local", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Full demanded f64 slice", "value": 0.5613, "unit": "ms", "role": "native", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Direct demanded f64 slice", "value": 0.054150000000000004, "unit": "ms", "role": "local", "n": 30, "statistic": "median of held-out timing blocks" }, { "label": "Warm memoised f32 result", "value": 0.039, "unit": "ms", "role": "local", "n": 30, "statistic": "median of held-out timing blocks" } ], "comparisons": [ { "baseline": 1, "candidate": 2, "kind": "implementation" }, { "baseline": 3, "candidate": 2, "kind": "implementation" }, { "baseline": 5, "candidate": 6, "kind": "implementation" } ], "chart": true, "presentation": { "title": "Reassociating a sum and asking only for the part that is needed", "question": "I wanted to know how much time goes into building values the application never uses, so I compared calculation orders using 256-by-256 matrices and a vector.", "comparison": "On one laptop I timed a left-to-right f64 evaluation, a certified right-associated evaluation, the NumPy multi_dot library path, a scanned variant, and the full slice against the directly demanded slice, over 30 held-out blocks each.", "finding": "The right-associated path took 0.125 ms against 0.654 ms for left-to-right, 5.2 times faster, and asking for the demanded slice directly took 0.054 ms against 0.561 ms for the full slice, while multi_dot matched the certified path at 0.134 ms.", "lesson": "Most of the avoidable work sits in the evaluation order and in materialising the whole array, but at this size my path was not separated from the library and I do not claim that it was.", "caveat": "One shared laptop with uncontrolled power and thermal state, a structured integer-valued input rather than an arbitrary floating-point matrix, 30 held-out blocks per operation, and the correctness checks ran outside the timer.", "kind": "Performance", "area": "OBP", "labels": { "0": "Native f32 product", "1": "Original calculation order", "2": "Reordered calculation", "3": "Library calculation", "4": "Scanned reorder", "5": "Full slice", "6": "Demanded slice", "7": "Reused f32 result" }, "featuredRows": [ 1, 2 ] }, "technical": { "original": { "title": "Certified reassociation, slices and memo against native paths at n=256", "scope": "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.", "interpretation": "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]." } }, "chartSeries": [] }, { "id": "obp-gen1-verification-assertions", "title": "The verification count for the earlier generation of the algorithm", "topic": "OBP v2", "date": "2026-10-11", "evidence": "Fixture", "scope": "The recorded verification batch for the first generation, covering deterministic algorithm checks, reanalysis of recorded traces and model simulation.", "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.", "statistic": "exact recorded assertion count", "warmCold": "not recorded", "network": "None; recorded traces and deterministic checks.", "serialization": "not recorded", "correctness": "The recorded batch status is PASS with 2,919 checks.", "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." ], "interpretation": "That batch records a pass status with 2,919 checks in total, but it is a single recorded total with no per-suite breakdown.", "href": "/research/obp-v2/", "sourceIds": [ "alg-obp-gen1-verification" ], "rows": [ { "label": "Gen-1 verification assertions", "value": 2919, "unit": "assertions", "role": "metric", "n": null, "statistic": "recorded assertion count under status PASS" } ], "comparisons": [], "chart": false, "presentation": { "title": "The verification count for the earlier generation of the algorithm", "question": "I also wanted a number for the earlier generation of the work, because it is easy to blend two different verification batches into a single headline.", "comparison": "The recorded verification batch for the first generation, covering deterministic algorithm checks, reanalysis of recorded traces and model simulation.", "finding": "That batch records a pass status with 2,919 checks in total, but it is a single recorded total with no per-suite breakdown.", "lesson": "It is an aggregate for its own generation and must not be added to the 1,381 checks from the later design.", "caveat": "Deterministic checks and reanalysis of recorded traces rather than a new external measurement, and no new accelerator work was involved.", "kind": "Functional check", "area": "OBP" }, "technical": { "original": { "title": "Gen-1 verification batch: deterministic algorithm, trace reanalysis and model simulation", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "obp-registered-vs-untracked-n1024", "title": "Two ways of keeping a result and not copying it", "topic": "OBP v2", "date": "2026-10-11", "evidence": "Measured", "scope": "Recomputing, reusing a registered immutable result, and scanning before reuse, with 1,024-by-1,024 matrix inputs. The untracked path pays for its input checks and 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.", "statistic": "median of 30 blocks per method", "warmCold": "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": "Both recorded checks pass: all warm results are byte and value exact with fresh ownership, and a changed input rejected the cached result.", "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." ], "interpretation": "The known-result reuse took 1.24 ms against 12.9 ms for recomputation, 10.4 times faster, and against 8.19 ms for the search-then-reuse path, 6.6 times faster.", "href": "/research/obp-v2/", "sourceIds": [ "alg-aspr-local-new" ], "rows": [ { "label": "Optimised BLAS recomputation", "value": 12.912299999999998, "unit": "ms", "role": "native", "n": 30, "statistic": "median of 30 blocks" }, { "label": "Registered immutable cache hit", "value": 1.24495, "unit": "ms", "role": "local", "n": 30, "statistic": "median of 30 blocks" }, { "label": "Untracked exact-scan cache hit with full copy", "value": 8.19195, "unit": "ms", "role": "local", "n": 30, "statistic": "median of 30 blocks" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "cache" }, { "baseline": 2, "candidate": 1, "kind": "cache" } ], "chart": true, "presentation": { "title": "Two ways of keeping a result and not copying it", "question": "I wanted to know whether the bookkeeping around a kept result matters as much as the reuse itself, so I compared a version that knows which result it is looking at against one that searches for it.", "comparison": "Recomputing, reusing a registered immutable result, and scanning before reuse, with 1,024-by-1,024 matrix inputs. The untracked path pays for its input checks and output copy.", "finding": "The known-result reuse took 1.24 ms against 12.9 ms for recomputation, 10.4 times faster, and against 8.19 ms for the search-then-reuse path, 6.6 times faster.", "lesson": "Knowing which result you want is worth more than the reuse itself, because it removes the copy from the critical path.", "caveat": "A synthetic repeated input rather than a production workload, only one size measured, the search-then-reuse path is charged a full output copy while the known-result path is not re-copied, and the memory counters read as zero in this data.", "kind": "Performance", "area": "OBP", "labels": { "0": "Recomputation", "1": "Known-result reuse", "2": "Search-then-reuse with a copy" }, "featuredRows": [ 0, 1, 2 ] }, "technical": { "original": { "title": "Registered immutable cache against untracked exact-scan cache at n=1024", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "obp-v2-fixture-assertions", "title": "The finite checks behind the placement design", "topic": "OBP v2", "date": "2026-10-11", "evidence": "Fixture", "scope": "Reference correctness and discrete simulation checks, exact algebraic and cost checks, block and patch byte-conformance vectors, and a small rematerialisation simulation.", "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.", "statistic": "exact assertion count per artifact", "warmCold": "not recorded", "network": "None; finite fixtures.", "serialization": "Block header and patch byte vectors only; an authenticated envelope is assumed and not implemented.", "correctness": "The four artifacts record reference checks and exact checks; counts are assertion totals, not a pass rate.", "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." ], "interpretation": "The four artefacts contribute 1,020, 225, 126 and 10 assertions, 1,381 in total, and each summand is recorded in its own artefact so the total can be recomputed without repeating anything.", "href": "/research/obp-v2/", "sourceIds": [ "alg-obp-reference-results", "alg-obp-extended-results", "alg-obp-block-format", "alg-obp-rematerialization" ], "rows": [ { "label": "Reference correctness and discrete simulation assertions", "value": 1020, "unit": "assertions", "role": "metric", "n": null, "statistic": "exact assertion count in the artifact" }, { "label": "Exact checks, worked example and algebraic cost estimates", "value": 225, "unit": "assertions", "role": "metric", "n": null, "statistic": "exact assertion count in the artifact" }, { "label": "Block header and patch byte-conformance vectors", "value": 126, "unit": "assertions", "role": "metric", "n": null, "statistic": "exact assertion count in the artifact" }, { "label": "Discrete rematerialisation simulation assertions", "value": 10, "unit": "assertions", "role": "metric", "n": null, "statistic": "exact assertion count in the artifact" } ], "comparisons": [], "chart": false, "presentation": { "title": "The finite checks behind the placement design", "question": "Before trusting a design I wanted a count of the deterministic checks behind it, so I tallied the assertions in the four recorded artefacts.", "comparison": "Reference correctness and discrete simulation checks, exact algebraic and cost checks, block and patch byte-conformance vectors, and a small rematerialisation simulation.", "finding": "The four artefacts contribute 1,020, 225, 126 and 10 assertions, 1,381 in total, and each summand is recorded in its own artefact so the total can be recomputed without repeating anything.", "lesson": "The design rests on a large number of small deterministic checks rather than on one big measurement, and I keep them separate from throughput numbers.", "caveat": "Assertion totals are not external validation and not a throughput measurement, the data are structured integers and bit-exact cases rather than arbitrary floating-point matrices, the simulations carry no device timing, and the storage and authenticated-envelope behaviour is assumed rather than implemented.", "kind": "Functional check", "area": "OBP", "labels": { "0": "Reference and simulation assertions", "1": "Exact algebraic assertions", "2": "Byte-conformance vectors", "3": "Rematerialisation simulation assertions" }, "featuredRows": [ 0, 1, 2, 3 ] }, "technical": { "original": { "title": "OBP v2 fixture assertions across four evidence artifacts", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "obp-warm-cache-n1024", "title": "Reusing results with a matrix dimension of 1,024", "topic": "OBP v2", "date": "2026-10-11", "evidence": "Measured", "scope": "The same three compute-versus-reuse pairs with matrix dimension 1,024, over thirty warm blocks per method.", "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.", "statistic": "median of 30 warm blocks per method", "warmCold": "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": "Not recorded as a pass or fail field in this file.", "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." ], "interpretation": "The vector pair went from 0.966 ms to 0.0052 ms, 186 times faster, the slice pair from 0.114 ms to 0.0052 ms and the dense pair from 8.83 ms to 1.03 ms.", "href": "/research/obp-v2/", "sourceIds": [ "alg-obp-cache-baseline" ], "rows": [ { "label": "Vector result computed, no cache", "value": 0.9656, "unit": "ms", "role": "native", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Vector result via library path, no cache", "value": 0.7583, "unit": "ms", "role": "native", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Vector result reused from warm cache", "value": 0.0052, "unit": "ms", "role": "local", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Demanded slice computed, no cache", "value": 0.11445, "unit": "ms", "role": "native", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Demanded slice reused from warm cache", "value": 0.0052, "unit": "ms", "role": "local", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Dense product computed, no cache", "value": 8.831949999999999, "unit": "ms", "role": "native", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Dense product reused from warm cache", "value": 1.0318999999999998, "unit": "ms", "role": "local", "n": 30, "statistic": "median of warm timing blocks" } ], "comparisons": [ { "baseline": 0, "candidate": 2, "kind": "cache" }, { "baseline": 3, "candidate": 4, "kind": "cache" }, { "baseline": 5, "candidate": 6, "kind": "cache" } ], "chart": true, "presentation": { "title": "Reusing results with a matrix dimension of 1,024", "question": "I wanted to know whether reuse keeps its advantage as the result gets larger, so I repeated the matched comparison at the middle size.", "comparison": "The same three compute-versus-reuse pairs with matrix dimension 1,024, over thirty warm blocks per method.", "finding": "The vector pair went from 0.966 ms to 0.0052 ms, 186 times faster, the slice pair from 0.114 ms to 0.0052 ms and the dense pair from 8.83 ms to 1.03 ms.", "lesson": "Reuse scales with the size of the result, which is what makes it more attractive as the workload grows rather than less.", "caveat": "What is priced here is a hit, so nothing is charged for filling the store, and the store size and eviction policy are not recorded; one input family on one machine.", "kind": "Performance", "area": "OBP", "labels": { "0": "Original vector computation", "1": "Library vector computation", "2": "Reused vector result", "3": "Original slice computation", "4": "Reused slice result", "5": "Original dense product", "6": "Reused dense product" }, "featuredRows": [ 0, 2, 5, 6 ] }, "technical": { "original": { "title": "Warm result cache against uncached compute at n=1024", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "obp-warm-cache-n2048", "title": "Reusing results at the largest matrix size", "topic": "OBP v2", "date": "2026-10-11", "evidence": "Measured", "scope": "The same three compute-versus-reuse pairs with matrix dimension 2,048, over thirty warm blocks per method.", "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.", "statistic": "median of 30 warm blocks per method", "warmCold": "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": "Not recorded as a pass or fail field in this file.", "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." ], "interpretation": "The vector pair went from 4.89 ms to 0.010 ms, 489 times faster, the slice pair from 0.322 ms to 0.0096 ms and the dense pair from 75.4 ms to 5.80 ms.", "href": "/research/obp-v2/", "sourceIds": [ "alg-obp-cache-baseline" ], "rows": [ { "label": "Vector result computed, no cache", "value": 4.88685, "unit": "ms", "role": "native", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Vector result via library path, no cache", "value": 3.60025, "unit": "ms", "role": "native", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Vector result reused from warm cache", "value": 0.01, "unit": "ms", "role": "local", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Demanded slice computed, no cache", "value": 0.322, "unit": "ms", "role": "native", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Demanded slice reused from warm cache", "value": 0.00955, "unit": "ms", "role": "local", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Dense product computed, no cache", "value": 75.38825, "unit": "ms", "role": "native", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Dense product reused from warm cache", "value": 5.80325, "unit": "ms", "role": "local", "n": 30, "statistic": "median of warm timing blocks" } ], "comparisons": [ { "baseline": 0, "candidate": 2, "kind": "cache" }, { "baseline": 3, "candidate": 4, "kind": "cache" }, { "baseline": 5, "candidate": 6, "kind": "cache" } ], "chart": true, "presentation": { "title": "Reusing results at the largest matrix size", "question": "I repeated the reuse comparison at the largest size to see how far the gap could open.", "comparison": "The same three compute-versus-reuse pairs with matrix dimension 2,048, over thirty warm blocks per method.", "finding": "The vector pair went from 4.89 ms to 0.010 ms, 489 times faster, the slice pair from 0.322 ms to 0.0096 ms and the dense pair from 75.4 ms to 5.80 ms.", "lesson": "At this size, deciding what to compute and whether to compute it again matters more than any implementation detail underneath.", "caveat": "Only the reuse is priced, so the cost of producing and storing the result first time is absent, as are the store size and its eviction policy; one input family on one machine.", "kind": "Performance", "area": "OBP", "labels": { "0": "Original vector computation", "1": "Library vector computation", "2": "Reused vector result", "3": "Original slice computation", "4": "Reused slice result", "5": "Original dense product", "6": "Reused dense product" }, "featuredRows": [ 0, 2, 5, 6 ] }, "technical": { "original": { "title": "Warm result cache against uncached compute at n=2048", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "obp-warm-cache-n256", "title": "Reusing a result instead of computing it again", "topic": "OBP v2", "date": "2026-10-11", "evidence": "Measured", "scope": "Three compute-versus-reuse pairs with matrix dimension 256, over thirty warm blocks per method.", "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.", "statistic": "median of 30 warm blocks per method", "warmCold": "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": "Not recorded as a pass or fail field in this file.", "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." ], "interpretation": "Reusing a vector result took 0.0036 ms against 0.070 ms for recomputation, about twenty times faster, while the demanded slice went from 0.0295 ms to 0.0043 ms and the dense product from 0.317 ms to 0.019 ms.", "href": "/research/obp-v2/", "sourceIds": [ "alg-obp-cache-baseline" ], "rows": [ { "label": "Vector result computed, no cache", "value": 0.07005, "unit": "ms", "role": "native", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Vector result via library path, no cache", "value": 0.0698, "unit": "ms", "role": "native", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Vector result reused from warm cache", "value": 0.00355, "unit": "ms", "role": "local", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Demanded slice computed, no cache", "value": 0.0295, "unit": "ms", "role": "native", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Demanded slice reused from warm cache", "value": 0.0043, "unit": "ms", "role": "local", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Dense product computed, no cache", "value": 0.31710000000000005, "unit": "ms", "role": "native", "n": 30, "statistic": "median of warm timing blocks" }, { "label": "Dense product reused from warm cache", "value": 0.019, "unit": "ms", "role": "local", "n": 30, "statistic": "median of warm timing blocks" } ], "comparisons": [ { "baseline": 0, "candidate": 2, "kind": "cache" }, { "baseline": 3, "candidate": 4, "kind": "cache" }, { "baseline": 5, "candidate": 6, "kind": "cache" } ], "chart": true, "presentation": { "title": "Reusing a result instead of computing it again", "question": "If the same input keeps coming back, recomputing is wasted work, so I compared recomputation against reusing a result that was already in hand.", "comparison": "Three compute-versus-reuse pairs with matrix dimension 256, over thirty warm blocks per method.", "finding": "Reusing a vector result took 0.0036 ms against 0.070 ms for recomputation, about twenty times faster, while the demanded slice went from 0.0295 ms to 0.0043 ms and the dense product from 0.317 ms to 0.019 ms.", "lesson": "Reuse is where most of the available speed sits at small sizes, and it is a local property that says nothing about sending work elsewhere.", "caveat": "These rows price a hit rather than a miss, so the cost of populating the store is excluded, the store size and eviction policy are not recorded here, and this is one input family on one machine.", "kind": "Performance", "area": "OBP", "labels": { "0": "Original vector computation", "1": "Library vector computation", "2": "Reused vector result", "3": "Original slice computation", "4": "Reused slice result", "5": "Original dense product", "6": "Reused dense product" }, "featuredRows": [ 0, 2, 5, 6 ] }, "technical": { "original": { "title": "Warm result cache against uncached compute at n=256", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "rt-a40-resident-conformance", "title": "Checking the resident-object interface against a real accelerator", "topic": "Runtime", "date": "2026-10-11", "evidence": "Validation", "scope": "128 configurations covering precisions, layouts, transpose combinations, scalar pairs and padded tails, plus 22 cases designed to be refused at admission.", "hardware": "One NVIDIA A40 with 46,068 MiB of memory, compute capability 8.6 and driver 570.195.03, on a kernel 6.8.0-60-generic host running Ubuntu 24.04 with glibc 2.39. The CUDA runtime library actually loaded by the conformance process was version 12.8.90, with the driver library, the BLAS library and the BLAS-lt library recorded by size. No compiler toolkit was present in the image, which the runtime design does not require.", "software": "A runtime build compiled with the experimental resident feature explicitly enabled and default features off, using a pinned toolchain and 33 vendored dependency archives, with the lockfile byte-identical before and after the build.", "input": "128 configuration vectors spanning f32 and f64, row-major and column-major layouts, no-transpose and transpose combinations on both operands, four alpha and beta pairs, and padded and unpadded tails. A separate set of 22 admission-rejection cases exercised the negative admission path.", "samples": "128 conformance vectors and 22 admission rejections in one qualifying run. The earlier failed orchestration attempts are retained separately and are not counted.", "statistic": "Counts of passed vectors, passed rejections and device counter totals. No timing distribution is published.", "warmCold": "Each vector was executed at three object versions, giving 384 executions and 1,152 references. No cold-start or steady-state split is published.", "network": "Not recorded as a separate figure in this qualification.", "serialization": "Not recorded as a separate figure in this qualification.", "correctness": "The run reported all 128 vectors passing with indices exactly 1 to 128 and all 22 admission rejections passing, with the harness result and the admission result both reported. Requested-owned allocation returned to zero at clean close.", "limitations": [ "The resident feature is default-off and no worker advertises it.", "This is a single experimental trusted in-process conformance, not a full acceptance of the accelerator gate.", "There is no real device fault injection, lease or quota enforcement, pinned eviction test, physical copy tracing or private and global memory enforcement.", "Requested-owned counters are interface counters and are not device memory enforcement.", "The cost figure is an estimate from a price readback and is not a billing receipt; provider timer enforcement was not proved.", "No general accelerator readiness is claimed." ], "interpretation": "All 128 configurations passed with indices exactly 1 to 128 and all 22 refusals passed, allocation returned to zero at close, and the requested-owned high-water was about 4 MB against 46 GB of device memory.", "href": "/research/runtime/", "sourceIds": [ "rt-src-nw1-cuda" ], "rows": [ { "label": "conformance vectors passed", "value": 128, "unit": "cases", "role": "metric", "n": 128, "statistic": "indices exactly 1 to 128 across dtypes, layouts, transposes, scalar pairs and padding" }, { "label": "admission rejections passed", "value": 22, "unit": "cases", "role": "metric", "n": 22, "statistic": "negative admission cases" }, { "label": "requested-owned allocation high-water", "value": 4195024, "unit": "bytes", "role": "metric", "n": 128, "statistic": "requested-owned device allocation high-water" }, { "label": "requested-owned allocation at clean close", "value": 0, "unit": "bytes", "role": "metric", "n": 1, "statistic": "requested-owned bytes at close" }, { "label": "upload bytes credited", "value": 32640, "unit": "bytes", "role": "metric", "n": 128, "statistic": "store-owned host-to-device counter after successful validated operations" }, { "label": "device-to-device clone bytes credited", "value": 24192, "unit": "bytes", "role": "metric", "n": 128, "statistic": "store-owned device-to-device counter" }, { "label": "materialisation bytes credited", "value": 56832, "unit": "bytes", "role": "metric", "n": 128, "statistic": "store-owned device-to-host counter" }, { "label": "executions", "value": 384, "unit": "calls", "role": "metric", "n": 128, "statistic": "128 vectors at three object versions" }, { "label": "references", "value": 1152, "unit": "calls", "role": "metric", "n": 128, "statistic": "references across the run" }, { "label": "evictions", "value": 0, "unit": "calls", "role": "metric", "n": 128, "statistic": "evictions recorded during the run" }, { "label": "device total memory", "value": 48305799168, "unit": "bytes", "role": "metric", "n": 1, "statistic": "46,068 MiB reported by the device, expressed in bytes" }, { "label": "envelope cost estimate", "value": 0.091, "unit": "usd", "role": "metric", "n": 1, "statistic": "estimate from a price readback, not a billing receipt" }, { "label": "envelope hard cap", "value": 1, "unit": "usd", "role": "metric", "n": 1, "statistic": "the declared hard cap for the qualification envelope" }, { "label": "elapsed across the short-lived instances", "value": 1134000, "unit": "ms", "role": "metric", "n": 6, "statistic": "18.9 minutes total across 6 instances against a 90 minute allowance" } ], "comparisons": [ { "baseline": 11, "candidate": 12, "kind": "overhead" } ], "chart": false, "presentation": { "title": "Checking the resident-object interface against a real accelerator", "question": "Before trusting the resident-object design on real hardware I wanted to see whether it behaves as specified, so I ran a conformance pass on an actual accelerator.", "comparison": "128 configurations covering precisions, layouts, transpose combinations, scalar pairs and padded tails, plus 22 cases designed to be refused at admission.", "finding": "All 128 configurations passed with indices exactly 1 to 128 and all 22 refusals passed, allocation returned to zero at close, and the requested-owned high-water was about 4 MB against 46 GB of device memory.", "lesson": "The interface behaves as designed on real hardware, which qualifies its shape and nothing beyond that.", "caveat": "No device fault injection, lease or quota enforcement, eviction test or memory enforcement was exercised, the counters are interface counters rather than device memory enforcement, the cost figure is an estimate from a price readback rather than a billing record, and no general accelerator readiness is claimed.", "kind": "Functional check", "area": "Runtime", "labels": { "0": "Configurations passed", "1": "Refusals passed", "2": "Requested-owned high-water", "3": "Requested-owned allocation at close", "7": "Executions", "8": "References", "9": "Evictions" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "Resident-object conformance on a real CUDA accelerator", "scope": "A conformance run of the experimental resident-object interface against a real accelerator: 128 configuration vectors and 22 admission rejections, with device counters and a cost envelope. The run qualifies the interface shape on that hardware and nothing beyond it.", "interpretation": "The resident-object interface behaves as specified on real hardware across 128 configurations and 22 negative admissions, with allocation returning to zero on close and a requested-owned high-water of about 4 MB. The interface is qualified in shape. It is not qualified in fault behaviour, memory enforcement, performance or product readiness, and the source constant that records non-validation is carried unchanged." } }, "chartSeries": [] }, { "id": "rt-component-qualification-counts", "title": "Checking each component on its own, then all four together", "topic": "Runtime", "date": "2026-10-11", "evidence": "Validation", "scope": "Contracts, codec, interception and runtime, each built twice from locked sources, and then the composed integration built twice.", "hardware": "An isolated Linux CPU container image with a pinned digest, 1 CPU, 1,536 MB of memory and memory swap, a process limit of 128, a 768 MB target temporary store and a 64 MB temporary store. Compiler toolchain differed by component: 1.90.0 for the codec component and 1.99.0 for the interception and runtime components.", "software": "Rust 2024 edition crates with exact dependency pins, vendored offline sources, locked builds, and an internal dependency resolved by exact lock checksum to the qualified artifact of the dependency.", "input": "Not applicable. These are source and test qualification counts, not workload measurements.", "samples": "Two independent clean locked builds per component, plus two builds of the composed integration.", "statistic": "Counts of passed and failed test cases, build outcomes and reproducibility flags.", "warmCold": "Not applicable.", "network": "No network use at build or test time; the container ran with no network and the dependency registry index was never consulted.", "serialization": "Not applicable.", "correctness": "Each component ran its retained test vectors unchanged from the frozen source, and the composed integration re-ran all four component suites plus a consumer probe and the ported interception scripts.", "limitations": [ "Scope is isolated Linux CPU only; no Windows, accelerator, desktop or publication qualification is inferred.", "The runtime component records compiled reproducibility as not claimed, because its two host-side builds produced different library digests; both digests are retained.", "The codec component records its crate bytes as non-reproducible, with the single admission archive bound by checksum in the run that produced it.", "A first attempt at the codec component failed on offline resolution of the internal dependency and that failure is retained.", "The contracts component had already been published, so its later additions are additive overlay files only.", "Independent review of the composed integration accepted the result but disclosed that one check reused a pre-composition receipt and that a large-message assertion was made on the compression path within the frame bound." ], "interpretation": "The components passed their individual checks, and the combined build passed 145 tests per build. The standalone runtime builds had different test counts and were not claimed to be byte-identical; I kept those limits separate from the combined-build result.", "href": "/research/runtime/", "sourceIds": [ "rt-src-ua2-resynth-summary", "rt-src-ua2-splice-summary", "rt-src-ua2-runtime-summary", "rt-src-ua2-conformance", "rt-src-ua2-release-readiness", "rt-src-ua2-resynth-manifest" ], "rows": [ { "label": "contracts unit tests passed", "value": 13, "unit": "cases", "role": "metric", "n": 1, "statistic": "13 passed and 0 failed, with a compiler-resolved API comparison" }, { "label": "codec component tests passed per build", "value": 18, "unit": "cases", "role": "metric", "n": 2, "statistic": "18 passed and 0 failed on each of two builds" }, { "label": "interception component tests passed per build", "value": 39, "unit": "cases", "role": "metric", "n": 2, "statistic": "39 passed and 0 failed on each of two builds" }, { "label": "frozen interception validation scripts passed", "value": 7, "unit": "cases", "role": "metric", "n": 1, "statistic": "7 passed and 0 failed, including malformed and truncated failure modes" }, { "label": "runtime component tests passed, first build", "value": 70, "unit": "cases", "role": "metric", "n": 1, "statistic": "70 passed and 0 failed" }, { "label": "runtime component tests passed, second build", "value": 61, "unit": "cases", "role": "metric", "n": 1, "statistic": "61 passed and 0 failed" }, { "label": "composed integration tests passed per build", "value": 145, "unit": "cases", "role": "metric", "n": 2, "statistic": "13 contracts, 18 codec, 70 runtime, 39 interception and 5 consumer probe" }, { "label": "composed integration interception scripts passed", "value": 6, "unit": "cases", "role": "metric", "n": 1, "statistic": "6 passed and 0 failed" }, { "label": "packages in the composed lock", "value": 27, "unit": "cases", "role": "metric", "n": 1, "statistic": "27 of 27 verified acyclic by topological sort" }, { "label": "release files staged and hash recorded", "value": 22, "unit": "cases", "role": "metric", "n": 1, "statistic": "22 staged files recorded with digests before promotion" }, { "label": "codec component compiled reproducibility", "value": 1, "unit": "cases", "role": "metric", "n": 2, "statistic": "1 denotes byte-identical library artefacts across both builds" }, { "label": "interception component compiled reproducibility", "value": 1, "unit": "cases", "role": "metric", "n": 2, "statistic": "1 denotes byte-identical library and shared-library artefacts across both builds" }, { "label": "runtime component compiled reproducibility", "value": 0, "unit": "cases", "role": "metric", "n": 2, "statistic": "0 denotes not claimed for this component; both differing digests are retained" }, { "label": "codec component crate byte reproducibility", "value": 0, "unit": "cases", "role": "metric", "n": 1, "statistic": "0 denotes crate bytes are not byte-deterministic across runs; the admission archive is bound by checksum" } ], "comparisons": [ { "baseline": 1, "candidate": 6, "kind": "historical" }, { "baseline": 4, "candidate": 6, "kind": "implementation" } ], "chart": true, "presentation": { "title": "Checking each component on its own, then all four together", "question": "I wanted the component boundaries tested in isolation as well as in composition, so I built and tested each one separately and then the whole graph.", "comparison": "Contracts, codec, interception and runtime, each built twice from locked sources, and then the composed integration built twice.", "finding": "The components passed their individual checks, and the combined build passed 145 tests per build. The standalone runtime builds had different test counts and were not claimed to be byte-identical; I kept those limits separate from the combined-build result.", "lesson": "The boundaries hold on their own and the composition reproduces them; the one soft spot is the runtime component, whose two builds produced different library bytes, so I record its compiled reproducibility as unclaimed rather than asserted.", "caveat": "Linux CPU only, with no Windows, accelerator or desktop conclusion implied; the codec package bytes are also not byte-deterministic and are bound by checksum instead, a first attempt at the codec component failed on offline dependency resolution and is kept, and one check in the independent review reused a result from before the composition.", "kind": "Functional check", "area": "Runtime", "labels": { "0": "Contracts tests passed", "1": "Codec tests passed, per build", "2": "Interception tests passed, per build", "3": "Interception validation scripts passed", "4": "Runtime tests passed, first build", "5": "Runtime tests passed, second build", "6": "Composed integration tests passed, per build", "7": "Composed integration scripts passed", "8": "Packages in the composed lock", "9": "Release files hashed before promotion", "10": "Codec library reproducible build", "11": "Interception library reproducible build", "12": "Runtime library reproducible build", "13": "Codec package byte-reproducible" }, "featuredRows": [ 0, 6 ] }, "technical": { "original": { "title": "Independent qualification counts for the four extracted components and their composed integration", "scope": "The build, test and reproducibility counts recorded for each component when it was extracted and qualified in isolation, and for the composed integration of all four. The published counts are the qualification evidence for the component boundaries, not performance results.", "interpretation": "Each component was qualified in isolation and then qualified again inside the composed graph, which is the shape of the claim: the boundaries hold and the composition reproduces them. The published counts also show exactly where the evidence is thinner, which is the runtime component, whose compiled reproducibility is recorded as unclaimed rather than asserted." } }, "chartSeries": [] }, { "id": "rt-nw1-windows-object-roundtrip", "title": "Moving objects to a Windows worker, and the three ways it refuses", "topic": "Interoperability", "date": "2026-10-11", "evidence": "Validation", "scope": "A 4 KB object uploaded and fetched back, against a wrong key, a connection from outside the loopback interface, and an upload above the managed maximum.", "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.", "statistic": "Counts of passed and failed cases. No timing distribution is published.", "warmCold": "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": "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.", "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." ], "interpretation": "The fetched bytes were identical to the upload and matched its digest, all three violations were refused with the expected error, and the wider Windows suite reported 43 cases passed and none failed.", "href": "/research/native-interception/", "sourceIds": [ "rt-src-nw1-interop" ], "rows": [ { "label": "live round-trip cases passed", "value": 4, "unit": "cases", "role": "metric", "n": 4, "statistic": "4 passed and 0 failed" }, { "label": "live round-trip cases failed", "value": 0, "unit": "cases", "role": "metric", "n": 4, "statistic": "0 failed" }, { "label": "uploaded object size", "value": 4096, "unit": "bytes", "role": "metric", "n": 1, "statistic": "512 f64 values" }, { "label": "fetched object size", "value": 4096, "unit": "bytes", "role": "metric", "n": 1, "statistic": "512 f64 values, byte-identical to the upload" }, { "label": "full Windows suite passed", "value": 43, "unit": "cases", "role": "metric", "n": 43, "statistic": "37 library, 3 probe and 3 command-line tool cases" }, { "label": "full Windows suite failed", "value": 0, "unit": "cases", "role": "metric", "n": 43, "statistic": "0 failed" }, { "label": "negative admission cases exercised", "value": 3, "unit": "cases", "role": "metric", "n": 3, "statistic": "wrong key, non-loopback connection and oversized upload" } ], "comparisons": [], "chart": false, "presentation": { "title": "Moving objects to a Windows worker, and the three ways it refuses", "question": "I needed to know whether the object protocol actually works on Windows and whether it refuses the things it should, so I ran a live round trip and three deliberate violations.", "comparison": "A 4 KB object uploaded and fetched back, against a wrong key, a connection from outside the loopback interface, and an upload above the managed maximum.", "finding": "The fetched bytes were identical to the upload and matched its digest, all three violations were refused with the expected error, and the wider Windows suite reported 43 cases passed and none failed.", "lesson": "The protocol round-trips correctly on Windows and fails closed in the three ways that matter for admission; it also uncovered a real portability bug, a hard-coded Unix random source that broke every Windows handshake until the operating system's cryptography path was used instead.", "caveat": "The live session used a 4 KB object and the larger-message path was proven elsewhere, reparse refusal was not exercised live because it needs administrative rights, adversarial access-control refusal was reviewed in code rather than tested black-box, and the Linux leg was not re-run live.", "kind": "Functional check", "area": "Splice", "labels": { "0": "Live round-trip cases passed", "1": "Live round-trip cases failed", "2": "Uploaded object size", "3": "Fetched object size", "4": "Full Windows suite passed", "5": "Full Windows suite failed", "6": "Negative admission cases exercised" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "Windows object-worker interoperability round trip and its negatives", "scope": "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.", "interpretation": "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." } }, "chartSeries": [] }, { "id": "rt-s4-r13-gpu-four-mode", "title": "Sending a fixed matrix multiplication to a GPU and waiting for it", "topic": "GEMM", "date": "2026-10-10", "evidence": "Measured", "scope": "Local execution against a remote accelerator in three states, a fresh remote session, a warm remote session, and a remote session with one operand kept resident, with each block running all four modes in a rotated order.", "hardware": "Local baseline: an optimised system BLAS identified in the raw record as OpenBLAS 0.3.26 with a dynamic architecture build, no affinity, a Cooperlake target string and a MAX_THREADS=64 library capacity string; the host CPU model and core count are not recorded in this receipt. Remote backend: one CUDA accelerator with compute capability 8.6 and 46,068 MiB of memory, driver 570.195.03, kernel 6.8.0-60-generic. The accelerator model name and the local host memory size are not recorded.", "software": "Runtime and worker binaries built from one pinned source commit; a compiled native BLAS provider. Compiler and operating system of the remote host are not recorded in this receipt.", "input": "One row-major f32 GEMM of 2048 by 2048 by 2048 per call, alpha 1, beta 0, eight sequential calls per workload, each requesting the full 16 MiB output. Operand and output digests are recorded for every call. The generator seed and the operand source bytes are recorded in the raw document but are not restated here.", "samples": "30 measured blocks, each containing all four modes once in a rotated order, plus 10 untimed warm-up or rehearsal trials; 960 measured calls in total.", "statistic": "Nearest-rank 95th percentile and arithmetic median over 30 blocks. Paired differences against the local mode use a 10,000-resample percentile bootstrap with a recorded deterministic seed.", "warmCold": "Three untimed warm-up workloads per non-cold mode are excluded from the results. The cold mode is process-cold: one untimed process-cold rehearsal, then a process reset before every measured cold trial. Mode-specific state is released at block boundaries and the process, worker, session and epoch identifiers are recorded so independence can be audited.", "network": "Not recorded as a separate figure. Framed application-stream bytes are recorded per call and per block; physical link, encryption and retransmission overhead are not recorded.", "serialization": "Per-call framed traffic is recorded in the raw document as approximately 33,555,529 bytes transmitted and 16,777,715 bytes received for a remote call. Logical payload sizes are recorded separately from framed sizes, and the two are not interchangeable.", "correctness": "Every measured call was checked against a high-precision scalar oracle on a deterministic input slice and against an independently optimised local result for the full output, with the tolerance 1e-4 absolute plus 1e-4 relative and no non-finite values accepted. All 960 call-level checks and all 30 block-level proofs passed, and no call or block proof failed.", "limitations": [ "The recorded local baseline runs on a shared host whose contention was not measured for this attempt, so the ratio is not an isolated-host causal estimate.", "The remote wait includes a serial complete local reference computation inside each remote call; that structural cost explains the direction of the result but was not subtracted from the recorded measurement.", "The parent collection process did not exit normally and required a bounded read-only recovery; the recovered bytes were hash-verified, so this is evidence retrieval rather than a workload replay, and no normal collection-reliability result is claimed.", "Cleanup was verified point in time only; provider timer enforcement and billing finality are not recorded.", "Two blocks are the whole of the diagnostic evidence in a later related attempt; this attempt is the full 30-block campaign." ], "interpretation": "The local median was 1.76 s and the resident remote median 13 s, about 7.4 times slower, and the improvement I had required in advance was nowhere near being met.", "href": "/research/runtime/", "sourceIds": [ "rt-src-s4-r13-campaign", "rt-src-s4-r13-recomputed", "rt-src-s4-r13-decision", "rt-src-s4-protocol" ], "rows": [ { "label": "local whole-workload wait, median", "value": 1762.5130985, "unit": "ms", "role": "local", "n": 30, "statistic": "arithmetic median of 30 blocks" }, { "label": "local whole-workload wait, 95th percentile", "value": 1915.174941, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank 95th percentile of 30 blocks" }, { "label": "resident whole-workload wait, median", "value": 13033.702884, "unit": "ms", "role": "remote", "n": 30, "statistic": "arithmetic median of 30 blocks" }, { "label": "resident whole-workload wait, 95th percentile", "value": 13584.58596, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank 95th percentile of 30 blocks" }, { "label": "paired improvement of local over resident", "value": -6.3949537708925, "unit": "ratio", "role": "metric", "n": 30, "statistic": "paired median difference divided by the local median, with a 10,000-resample bootstrap at the recorded seed" }, { "label": "paired improvement interval, lower bound", "value": -6.656731866751922, "unit": "ratio", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval, 10,000 resamples" }, { "label": "paired improvement interval, upper bound", "value": -6.202670974245489, "unit": "ratio", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval, 10,000 resamples" }, { "label": "resident wait relative to local", "value": 7.395, "unit": "ratio", "role": "metric", "n": 30, "statistic": "ratio of the resident whole-workload median to the local median" }, { "label": "measured calls", "value": 960, "unit": "calls", "role": "metric", "n": 30, "statistic": "8 calls per block over 30 blocks" }, { "label": "measured blocks", "value": 30, "unit": "blocks", "role": "metric", "n": 30, "statistic": "blocks retained in the raw document" }, { "label": "untimed warm-up and rehearsal trials", "value": 10, "unit": "blocks", "role": "metric", "n": 10, "statistic": "trials recorded but excluded from the result" } ], "comparisons": [ { "baseline": 0, "candidate": 2, "kind": "remote-vs-local" }, { "baseline": 1, "candidate": 3, "kind": "remote-vs-local" } ], "chart": false, "presentation": { "title": "Sending a fixed matrix multiplication to a GPU and waiting for it", "question": "The first thing I wanted to know was whether moving this fixed workload to an accelerator could beat a good local library, so I ran a four-mode comparison over 30 blocks.", "comparison": "Local execution against a remote accelerator in three states, a fresh remote session, a warm remote session, and a remote session with one operand kept resident, with each block running all four modes in a rotated order.", "finding": "The local median was 1.76 s and the resident remote median 13 s, about 7.4 times slower, and the improvement I had required in advance was nowhere near being met.", "lesson": "For this workload and this method, moving the work to an accelerator lost badly, and that is a statement about the method and the envelope rather than about the hardware.", "caveat": "The local baseline ran on a shared host whose contention I did not measure, the remote wait included a serial reference computation that I did not subtract, the collection process needed a limited recovery afterwards, and cleanup was verified at one instant only.", "kind": "Performance", "area": "Runtime", "labels": { "0": "Local execution, median", "1": "Local execution, 95th percentile", "2": "Resident remote execution, median", "3": "Resident remote execution, 95th percentile" }, "featuredRows": [ 0, 2 ] }, "technical": { "original": { "title": "Four-mode whole-workload comparison against an accelerator backend, attempt R13", "scope": "One resident-operand accelerator backend compared with an optimised local baseline on the frozen 2048-square eight-call workload, with four execution modes per block: local, process-cold remote, warm remote and warm remote with one resident operand. The independent gate decision recorded a performance failure and left the useful-workload requirement unmet.", "interpretation": "The resident-operand mode was about 7.4 times slower than the local baseline on this workload and method. The frozen gate required the resident mode to improve the whole-workload median by at least 20 percent with a bootstrap lower bound above zero and a 95th percentile within 10 percent of the local 95th percentile; all three criteria failed. The result is a measured loss for this method and envelope, not a claim about accelerator hardware." } }, "chartSeries": [] }, { "id": "rt-s4-r14-gpu-four-mode", "title": "Repeating the accelerator comparison and taking it apart phase by phase", "topic": "GEMM", "date": "2026-10-10", "evidence": "Measured", "scope": "The same fixed workload across four modes over 30 blocks, now with per-call and per-block phase timings for the remote modes.", "hardware": "Local baseline: an optimised system BLAS identified in the raw record as OpenBLAS 0.3.26 with a dynamic architecture build, no affinity, a Cooperlake target string and a MAX_THREADS=64 library capacity string; host CPU model and core count are not recorded. Remote backend: one CUDA accelerator with compute capability 8.6, 46,068 MiB of memory, driver 570.195.03. The accelerator model name is not recorded in this receipt.", "software": "Runtime and worker binaries built from one pinned source commit with a compiled native BLAS provider; the compiler and operating system of the local host are not recorded.", "input": "One row-major f32 GEMM of 2048 by 2048 by 2048 per call, alpha 1, beta 0, eight sequential calls per workload, each requesting the full 16 MiB output, with operand and output digests recorded for every call.", "samples": "30 measured blocks, each containing all four modes once in a rotated order, plus 10 untimed warm-up or rehearsal trials; 960 measured calls in total.", "statistic": "Nearest-rank 95th percentile and arithmetic median over 30 blocks. Paired differences against the local mode use a 10,000-resample percentile bootstrap at the recorded deterministic seed 1395928370.", "warmCold": "Three untimed warm-up workloads per non-cold mode are excluded. The cold mode is process-cold with one untimed rehearsal and a reset before every measured cold trial. Resident state is released at block boundaries.", "network": "Not recorded as a separate figure. Framed application-stream bytes are recorded per call and per block; physical link, encryption and retransmission overhead are not recorded.", "serialization": "Remote call traffic is recorded per call as approximately 33,555,529 bytes transmitted and 16,777,715 bytes received, with logical payload, packed and framed byte counts kept separate. Per-block transmitted traffic reaches approximately 2.43 GB.", "correctness": "Every measured call was checked against a high-precision scalar oracle on a deterministic input slice and against an independently optimised local result for the full output, with the tolerance 1e-4 absolute plus 1e-4 relative and no non-finite values accepted. All 960 call-level flags and all 30 block-level lifecycle flags were independently confirmed.", "limitations": [ "The parent collection process failed and required a bounded read-only recovery with hash verification of twelve result documents; this is evidence retrieval rather than a workload replay and no normal collection-reliability result is claimed.", "Cleanup was verified point in time only; provider timer enforcement and billing finality are not recorded.", "The recorded local baseline ran on a shared host whose contention was not measured for this attempt.", "The remote wait includes a serial complete local reference computation inside each remote call; that structural cost was not subtracted from the recorded measurement.", "A recorded negative local choice and an unfavourable natural link case are present in the raw evidence as diagnostic cases rather than timed wins." ], "interpretation": "The local median was 1.75 s, the cold remote 18.3 s, the warm remote 16.3 s and the resident remote 12.9 s, 7.4 times the local time, and per call the upload took about 905 ms and materialisation about 347 ms while the arithmetic itself took roughly 30 ms.", "href": "/research/runtime/", "sourceIds": [ "rt-src-s4-r14-campaign", "rt-src-s4-r14-decision", "rt-src-s4-protocol", "rt-src-s4-bottleneck" ], "rows": [ { "label": "local whole-workload wait, median", "value": 1751.910585, "unit": "ms", "role": "local", "n": 30, "statistic": "arithmetic median of 30 blocks" }, { "label": "local whole-workload wait, 95th percentile", "value": 1920.826496, "unit": "ms", "role": "local", "n": 30, "statistic": "nearest-rank 95th percentile of 30 blocks" }, { "label": "cold remote whole-workload wait, median", "value": 18264.801124999998, "unit": "ms", "role": "remote", "n": 30, "statistic": "arithmetic median of 30 blocks" }, { "label": "cold remote whole-workload wait, 95th percentile", "value": 19582.365772, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank 95th percentile of 30 blocks" }, { "label": "warm remote whole-workload wait, median", "value": 16250.157567, "unit": "ms", "role": "remote", "n": 30, "statistic": "arithmetic median of 30 blocks" }, { "label": "warm remote whole-workload wait, 95th percentile", "value": 20768.513675, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank 95th percentile of 30 blocks" }, { "label": "resident remote whole-workload wait, median", "value": 12887.3775365, "unit": "ms", "role": "remote", "n": 30, "statistic": "arithmetic median of 30 blocks" }, { "label": "resident remote whole-workload wait, 95th percentile", "value": 13229.34361, "unit": "ms", "role": "remote", "n": 30, "statistic": "nearest-rank 95th percentile of 30 blocks" }, { "label": "paired improvement of local over resident", "value": -6.356184526106965, "unit": "ratio", "role": "metric", "n": 30, "statistic": "paired median difference divided by the local median" }, { "label": "paired improvement interval, lower bound", "value": -6.5688903955180145, "unit": "ratio", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval, 10,000 resamples, seed 1395928370" }, { "label": "paired improvement interval, upper bound", "value": -6.196642972433452, "unit": "ratio", "role": "metric", "n": 30, "statistic": "95 percent bootstrap interval, 10,000 resamples, seed 1395928370" }, { "label": "resident wait relative to local", "value": 7.356, "unit": "ratio", "role": "metric", "n": 30, "statistic": "ratio of the resident whole-workload median to the local median" }, { "label": "paired cold remote difference against local", "value": 16544.221208000003, "unit": "ms", "role": "metric", "n": 30, "statistic": "paired median difference with a 10,000-resample bootstrap" }, { "label": "paired warm remote difference against local", "value": 14515.945169999999, "unit": "ms", "role": "metric", "n": 30, "statistic": "paired median difference with a 10,000-resample bootstrap" }, { "label": "paired resident difference against local", "value": 11200.7173465, "unit": "ms", "role": "metric", "n": 30, "statistic": "paired median difference with a 10,000-resample bootstrap" }, { "label": "resident upload phase per call", "value": 905, "unit": "ms", "role": "remote", "n": 960, "statistic": "range 905 to 982 ms across calls in the recorded phase decomposition" }, { "label": "resident materialisation phase per call", "value": 347, "unit": "ms", "role": "remote", "n": 960, "statistic": "range 347 to 531 ms across calls in the recorded phase decomposition" }, { "label": "resident execute phase per call", "value": 30, "unit": "ms", "role": "remote", "n": 960, "statistic": "approximately 30 ms, recorded as the dominant share of the wait being outside compute" }, { "label": "measured calls", "value": 960, "unit": "calls", "role": "metric", "n": 30, "statistic": "8 calls per block over 30 blocks" }, { "label": "measured blocks", "value": 30, "unit": "blocks", "role": "metric", "n": 30, "statistic": "blocks retained in the raw document" } ], "comparisons": [ { "baseline": 0, "candidate": 6, "kind": "remote-vs-local" }, { "baseline": 1, "candidate": 7, "kind": "remote-vs-local" }, { "baseline": 2, "candidate": 4, "kind": "implementation" } ], "chart": false, "presentation": { "title": "Repeating the accelerator comparison and taking it apart phase by phase", "question": "The first comparison left me unsure where the time actually went, so I repeated it with a full breakdown of each remote call into upload, materialisation, execution and release.", "comparison": "The same fixed workload across four modes over 30 blocks, now with per-call and per-block phase timings for the remote modes.", "finding": "The local median was 1.75 s, the cold remote 18.3 s, the warm remote 16.3 s and the resident remote 12.9 s, 7.4 times the local time, and per call the upload took about 905 ms and materialisation about 347 ms while the arithmetic itself took roughly 30 ms.", "lesson": "The loss was almost entirely data movement and the cost of keeping state alive between calls; the arithmetic was the smallest part of the wait.", "caveat": "The collection process failed and needed a hash-verified recovery, the shared local host's contention was not measured, the serial reference computation inside each remote call was not subtracted, and provider timer enforcement and billing finality are not recorded.", "kind": "Performance", "area": "Runtime", "labels": { "0": "Local execution, median", "1": "Local execution, 95th percentile", "2": "Cold remote execution, median", "3": "Cold remote execution, 95th percentile", "4": "Warm remote execution, median", "5": "Warm remote execution, 95th percentile", "6": "Resident remote execution, median", "7": "Resident remote execution, 95th percentile" }, "featuredRows": [ 0, 2, 4, 6 ] }, "technical": { "original": { "title": "Four-mode whole-workload comparison against an accelerator backend, attempt R14", "scope": "A repeat of the frozen four-mode comparison with the same 2048-square eight-call workload, adding a full per-call and per-block phase decomposition of the remote modes. The independent gate decision recorded a performance failure and left the useful-workload requirement unmet. The raw result document is an error wrapper; the complete losing measurements are retained inside its partial field.", "interpretation": "The resident-operand mode was about 7.36 times slower than the local baseline, and the cold and warm remote modes were slower still. The phase decomposition shows that the remote execute step is roughly 30 ms per call while upload, materialisation, verification and release together account for the overwhelming majority of the wait, so the loss is a transport and residency-persistence problem rather than an arithmetic problem. The frozen gate failed on all three criteria: median improvement, bootstrap lower bound and the 95th percentile ceiling of 2,112.9091456 ms." } }, "chartSeries": [ { "title": "Whole-workload wait / p50", "indices": [ 0, 2, 4, 6 ], "labels": [ "Local", "Cold remote", "Warm remote", "Resident remote" ] }, { "title": "Whole-workload wait / p95", "indices": [ 1, 3, 5, 7 ], "labels": [ "Local", "Cold remote", "Warm remote", "Resident remote" ] } ] }, { "id": "alpha-study-b-termination", "title": "A study that never started", "topic": "Fusion history", "date": "2026-09-21", "evidence": "Validation", "scope": "Nothing to compare, because the machine disappeared before the first measurement.", "hardware": "RTX 5090 observed during preflight.", "software": "CUDA 12.8; PyTorch 2.7.1+cu128.", "input": "not recorded", "samples": "0 measured conditions.", "statistic": "Single recorded run unless stated otherwise.", "warmCold": "not recorded", "network": "not recorded", "serialization": "not recorded", "correctness": "No workload correctness measurement occurred.", "limitations": [ "Folder chronology and failed preflight are not benchmark completion.", "No replacement allocation or synthetic result substituted." ], "interpretation": "Zero conditions were measured against 24 planned; the 42 MB bundle transferred successfully and the device preflight passed, then the instance vanished.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-study-b-live" ], "rows": [ { "label": "Measured conditions", "value": 0, "unit": "conditions", "role": "metric", "n": null, "statistic": "recorded value" }, { "label": "Planned conditions", "value": 24, "unit": "conditions", "role": "metric", "n": null, "statistic": "recorded value" }, { "label": "Transferred bundle", "value": 42256285, "unit": "bytes", "role": "metric", "n": null, "statistic": "recorded value" } ], "comparisons": [], "chart": false, "presentation": { "title": "A study that never started", "question": "I planned a larger policy study with 24 conditions, and I want the record to show that it did not happen rather than quietly leaving it out.", "comparison": "Nothing to compare, because the machine disappeared before the first measurement.", "finding": "Zero conditions were measured against 24 planned; the 42 MB bundle transferred successfully and the device preflight passed, then the instance vanished.", "lesson": "There is no result here at all, and recording it as an empty study keeps the later numbers honest.", "caveat": "The folder chronology and the failed preflight are not a completed benchmark, and no replacement machine or synthetic result was substituted for the missing data.", "kind": "Incomplete experiment", "area": "Fusion Alpha", "labels": { "0": "Conditions measured", "1": "Conditions planned", "2": "Bundle transferred" } }, "technical": { "original": { "title": "Study B v1: no conditions measured", "scope": "Infrastructure failure before experiment bootstrap.", "interpretation": "The bundle transfer and CUDA preflight succeeded, but the instance disappeared before measurements. This supplies no policy or performance result." } }, "chartSeries": [] }, { "id": "alpha-heldout-policies", "title": "Testing placement policies on data they had not seen", "topic": "Fusion history", "date": "2026-09-09", "evidence": "Measured", "scope": "Always local, the combined policy, always the fastest available resource and always remote, three counterbalanced repetitions each.", "hardware": "not recorded", "software": "not recorded", "input": "not recorded", "samples": "3 counterbalanced repetitions per strategy.", "statistic": "Recorded policy medians.", "warmCold": "not recorded", "network": "Loopback.", "serialization": "not recorded", "correctness": "All outputs correct.", "limitations": [ "Original engineering report retained; raw held-out-v3 file is absent from this checkout.", "No broad planner generalisation from three repetitions." ], "interpretation": "Always-local had a median of 19.0 ms, the combined policy 19.8 ms, the fastest-resource policy 22.4 ms and always-remote 122.0 ms.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-falsification" ], "rows": [ { "label": "All-local", "value": 18.991, "unit": "ms", "role": "local", "n": 3, "statistic": "median" }, { "label": "Fusion", "value": 19.833, "unit": "ms", "role": "metric", "n": 3, "statistic": "median" }, { "label": "Fastest-resource policy", "value": 22.433, "unit": "ms", "role": "metric", "n": 3, "statistic": "median" }, { "label": "Remote-only", "value": 122.027, "unit": "ms", "role": "remote", "n": 3, "statistic": "median" } ], "comparisons": [], "chart": true, "presentation": { "title": "Testing placement policies on data they had not seen", "question": "Before trusting the placement logic I wanted to see how it behaved on held-out decisions, so I ran four policies over a counterbalanced set.", "comparison": "Always local, the combined policy, always the fastest available resource and always remote, three counterbalanced repetitions each.", "finding": "Always-local had a median of 19.0 ms, the combined policy 19.8 ms, the fastest-resource policy 22.4 ms and always-remote 122.0 ms.", "lesson": "On the held-out median the placement logic did not beat simply staying local, which is the honest negative result I kept.", "caveat": "Three repetitions, the raw held-out data were not kept so this comes from the original report, and this is decision-quality evidence rather than evidence about external hardware.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Always local", "1": "Combined policy", "2": "Fastest resource", "3": "Always remote" }, "featuredRows": [ 0, 1, 2, 3 ] }, "technical": { "original": { "title": "Counterbalanced held-out loopback policies", "scope": "Held-out v3 policy study on the loopback decision corpus.", "interpretation": "The planner did not beat all-local on the held-out median. This is decision-quality evidence, not external GPU evidence." } }, "chartSeries": [] }, { "id": "alpha-persistent-large", "title": "The dedicated resident machine at a much larger size", "topic": "Fusion history", "date": "2026-09-09", "evidence": "Measured", "scope": "One local run against one remote run on the dedicated machine with the input already loaded, wall time and device compute recorded separately.", "hardware": "Persistent NVIDIA RTX 5090, 32,607 MiB VRAM; driver 580.178.04.", "software": "CUDA 12.8; PyTorch 2.11.0+cu128 (campaign report).", "input": "262,144 resident values; intensity 4096 (campaign context).", "samples": "1 local and 1 remote wall observation.", "statistic": "Single recorded run unless stated otherwise.", "warmCold": "Input already resident in GPU memory; 0 host-to-device uploads.", "network": "Remote wall includes request/return. Fresh ingress excluded; separate campaign report records approximately 39 s for 5.3 MB.", "serialization": "not recorded", "correctness": "Campaign reports correct outputs and retained resident object identity.", "limitations": [ "Not a 20-block held-out campaign.", "Warm compute and wall time must not be interchanged.", "Input size comes from the accompanying original campaign report; the raw comparison pins input identity but does not repeat its size." ], "interpretation": "The local run took 2.99 s and the resident remote 931 ms, a win of about three times, while the device's own compute was 70 ms.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-persistent-large" ], "rows": [ { "label": "Local wall", "value": 2993.3796, "unit": "ms", "role": "local", "n": 1, "statistic": "recorded value" }, { "label": "Resident remote wall", "value": 931.2212, "unit": "ms", "role": "remote", "n": 1, "statistic": "recorded value" }, { "label": "Local compute", "value": 2992.952000000001, "unit": "ms", "role": "metric", "n": 1, "statistic": "recorded value" }, { "label": "GPU compute", "value": 70.17317399731837, "unit": "ms", "role": "metric", "n": 1, "statistic": "recorded value" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "historical" } ], "chart": false, "presentation": { "title": "The dedicated resident machine at a much larger size", "question": "I repeated the same resident comparison with far more data to find where the remote side finally overtakes the local machine.", "comparison": "One local run against one remote run on the dedicated machine with the input already loaded, wall time and device compute recorded separately.", "finding": "The local run took 2.99 s and the resident remote 931 ms, a win of about three times, while the device's own compute was 70 ms.", "lesson": "Together with the smaller case this is the whole story: residency plus size is where the remote path earns its place, and neither factor is sufficient alone.", "caveat": "One observation per side, the input size comes from the accompanying report rather than being repeated in the raw comparison, and wall time and compute time must not be interchanged; neither figure includes moving fresh input across the network.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Local wall time", "1": "Resident remote wall time", "2": "Local compute", "3": "Device compute" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "Persistent GPU resident comparison: 262144 values", "scope": "Resident-input wall-time comparison, with compute-only sub-intervals recorded separately.", "interpretation": "Residency is a condition of this test. The smaller resident case loses; the larger one wins at this boundary. Neither includes fresh-input WAN staging." } }, "chartSeries": [] }, { "id": "alpha-persistent-small", "title": "A dedicated machine with its input already resident, at a small size", "topic": "Fusion history", "date": "2026-09-09", "evidence": "Measured", "scope": "One local run against one remote run on the dedicated machine, measuring the whole-request wall time with the device compute recorded separately.", "hardware": "Persistent NVIDIA RTX 5090, 32,607 MiB VRAM; driver 580.178.04.", "software": "CUDA 12.8; PyTorch 2.11.0+cu128 (campaign report).", "input": "4,096 resident values; intensity 4096 (campaign context).", "samples": "1 local and 1 remote wall observation.", "statistic": "Single recorded run unless stated otherwise.", "warmCold": "Input already resident in GPU memory; 0 host-to-device uploads.", "network": "Remote wall includes request/return. Fresh ingress excluded; separate campaign report records approximately 39 s for 5.3 MB.", "serialization": "not recorded", "correctness": "Campaign reports correct outputs and retained resident object identity.", "limitations": [ "Not a 20-block held-out campaign.", "Warm compute and wall time must not be interchanged.", "Input size comes from the accompanying original campaign report; the raw comparison pins input identity but does not repeat its size." ], "interpretation": "The local run took 666 ms and the remote 805 ms, so the resident remote case still lost even though the device's own compute was 54 ms.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-persistent-small" ], "rows": [ { "label": "Local wall", "value": 666.2844, "unit": "ms", "role": "local", "n": 1, "statistic": "recorded value" }, { "label": "Resident remote wall", "value": 805.4838000000001, "unit": "ms", "role": "remote", "n": 1, "statistic": "recorded value" }, { "label": "Local compute", "value": 666.2271, "unit": "ms", "role": "metric", "n": 1, "statistic": "recorded value" }, { "label": "GPU compute", "value": 53.95455099642277, "unit": "ms", "role": "metric", "n": 1, "statistic": "recorded value" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "historical" } ], "chart": false, "presentation": { "title": "A dedicated machine with its input already resident, at a small size", "question": "I kept a GPU running with its input already loaded to take acquisition out of the comparison entirely, and started with a small case.", "comparison": "One local run against one remote run on the dedicated machine, measuring the whole-request wall time with the device compute recorded separately.", "finding": "The local run took 666 ms and the remote 805 ms, so the resident remote case still lost even though the device's own compute was 54 ms.", "lesson": "Residency helps but is not sufficient: at this size the request and the return still cost more than the local computation.", "caveat": "A single observation on each side, with the input size taken from the accompanying report rather than repeated in the raw comparison; wall time and compute time are different things and must not be swapped, and neither figure includes moving fresh input across the network.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Local wall time", "1": "Resident remote wall time", "2": "Local compute", "3": "Device compute" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "Persistent GPU resident comparison: 4096 values", "scope": "Resident-input wall-time comparison, with compute-only sub-intervals recorded separately.", "interpretation": "Residency is a condition of this test. The smaller resident case loses; the larger one wins at this boundary. Neither includes fresh-input WAN staging." } }, "chartSeries": [] }, { "id": "alpha-policy-wins", "title": "Which strategy actually won most often", "topic": "Fusion history", "date": "2026-09-09", "evidence": "Measured", "scope": "The same four strategies over 24 observations, counting how many each one won.", "hardware": "not recorded", "software": "not recorded", "input": "not recorded", "samples": "24 observations.", "statistic": "Count of winning strategies.", "warmCold": "not recorded", "network": "Loopback.", "serialization": "not recorded", "correctness": "All strategies were required to produce correct output.", "limitations": [ "A win count is not a speedup distribution.", "Original report retained; raw repeated-matrix dataset not recovered in this checkout." ], "interpretation": "Always-local won 19 of 24, the fastest-resource policy 4, always-remote 1 and the combined policy none at all.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-falsification" ], "rows": [ { "label": "All-local wins", "value": 19, "unit": "wins", "role": "metric", "n": null, "statistic": "recorded value" }, { "label": "Fastest-resource wins", "value": 4, "unit": "wins", "role": "metric", "n": null, "statistic": "recorded value" }, { "label": "Remote-only wins", "value": 1, "unit": "wins", "role": "metric", "n": null, "statistic": "recorded value" }, { "label": "Fusion wins", "value": 0, "unit": "wins", "role": "metric", "n": null, "statistic": "recorded value" } ], "comparisons": [], "chart": false, "presentation": { "title": "Which strategy actually won most often", "question": "Medians hide how often a policy was right, so I counted the wins directly over a larger repeated decision set.", "comparison": "The same four strategies over 24 observations, counting how many each one won.", "finding": "Always-local won 19 of 24, the fastest-resource policy 4, always-remote 1 and the combined policy none at all.", "lesson": "The win count tells the same story as the medians and more starkly: the combined policy never produced the best answer in this corpus.", "caveat": "A win count is not a speed-up distribution, the raw repeated data were not recovered, and every strategy had to produce correct output to be counted at all.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Always local wins", "1": "Fastest resource wins", "2": "Always remote wins", "3": "Combined policy wins" }, "featuredRows": [ 0, 1, 2, 3 ] }, "technical": { "original": { "title": "Repeated loopback decision corpus", "scope": "Six-cell repeated loopback decision corpus, 24 observations.", "interpretation": "Preserves the negative planner result alongside the execution mechanisms." } }, "chartSeries": [] }, { "id": "alpha-region-heavy", "title": "Two dependent stages inside one rented GPU job", "topic": "Fusion history", "date": "2026-09-09", "evidence": "Measured", "scope": "The managed job's total set against its internal stage time and its acquisition time, on the larger of the two workloads.", "hardware": "Remote RTX 5090.", "software": "not recorded", "input": "250,000 values; intensity 64.", "samples": "not recorded", "statistic": "Single recorded run unless stated otherwise.", "warmCold": "Cold acquisition.", "network": "not recorded", "serialization": "not recorded", "correctness": "Report records correct output for both regions.", "limitations": [ "Original raw region file is not retained in the checkout; values are transcribed from the original engineering report.", "One run; no confidence interval." ], "interpretation": "The provider reported 295 seconds in total, of which 283 seconds was waiting for the machine and only 321 ms was the actual two-stage compute.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-final-report" ], "rows": [ { "label": "Provider total", "value": 295309, "unit": "ms", "role": "remote", "n": 1, "statistic": "recorded value" }, { "label": "Queue / acquisition", "value": 283000, "unit": "ms", "role": "metric", "n": 1, "statistic": "recorded value" }, { "label": "A+B compute", "value": 321.3, "unit": "ms", "role": "metric", "n": 1, "statistic": "recorded value" } ], "comparisons": [], "chart": false, "presentation": { "title": "Two dependent stages inside one rented GPU job", "question": "I wanted to know whether keeping both stages on the same device would beat sending them apart, so I ran a connected two-stage region in one managed job.", "comparison": "The managed job's total set against its internal stage time and its acquisition time, on the larger of the two workloads.", "finding": "The provider reported 295 seconds in total, of which 283 seconds was waiting for the machine and only 321 ms was the actual two-stage compute.", "lesson": "Keeping the stages together on one device worked, and the whole result was decided by how long it took to get the machine at all.", "caveat": "A single run with no confidence interval, and the region data behind it were not kept, so these figures are transcribed from the original engineering report.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Managed job total", "1": "Queue and acquisition", "2": "Two-stage compute" } }, "technical": { "original": { "title": "Cold connected region: heavy", "scope": "Connected A→B stages in one managed GPU job; stage time and lifecycle time are different intervals.", "interpretation": "Internal residency works, but cold acquisition dominates this historical observation." } }, "chartSeries": [] }, { "id": "alpha-region-small", "title": "The same connected region at a smaller size", "topic": "Fusion history", "date": "2026-09-09", "evidence": "Measured", "scope": "The managed job's total set against its acquisition time and its internal stage time, on the smaller workload.", "hardware": "Remote RTX 5090.", "software": "not recorded", "input": "10,000 values; intensity 4.", "samples": "not recorded", "statistic": "Single recorded run unless stated otherwise.", "warmCold": "Cold acquisition.", "network": "not recorded", "serialization": "not recorded", "correctness": "Report records correct output for both regions.", "limitations": [ "Original raw region file is not retained in the checkout; values are transcribed from the original engineering report.", "One run; no confidence interval." ], "interpretation": "The provider reported 328 seconds in total, of which 315 seconds was acquisition and only 65.7 ms was the compute.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-final-report" ], "rows": [ { "label": "Provider total", "value": 327701, "unit": "ms", "role": "remote", "n": 1, "statistic": "recorded value" }, { "label": "Queue / acquisition", "value": 315000, "unit": "ms", "role": "metric", "n": 1, "statistic": "recorded value" }, { "label": "A+B compute", "value": 65.7, "unit": "ms", "role": "metric", "n": 1, "statistic": "recorded value" } ], "comparisons": [], "chart": false, "presentation": { "title": "The same connected region at a smaller size", "question": "I repeated the connected two-stage region with far less data to see whether the overheads would shrink with the work.", "comparison": "The managed job's total set against its acquisition time and its internal stage time, on the smaller workload.", "finding": "The provider reported 328 seconds in total, of which 315 seconds was acquisition and only 65.7 ms was the compute.", "lesson": "At ten times less work the acquisition cost was essentially unchanged, which says the overhead was the machine rather than the work.", "caveat": "One run with no confidence interval, and the underlying region files were not kept, so these figures come from the original engineering report.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Managed job total", "1": "Queue and acquisition", "2": "Two-stage compute" } }, "technical": { "original": { "title": "Cold connected region: small", "scope": "Connected A→B stages in one managed GPU job; stage time and lifecycle time are different intervals.", "interpretation": "Internal residency works, but cold acquisition dominates this historical observation." } }, "chartSeries": [] }, { "id": "alpha-same-container", "title": "Two dependent stages sharing one GPU container", "topic": "Fusion history", "date": "2026-09-09", "evidence": "Measured", "scope": "The two stages computed locally against the same two stages on the GPU, with the managed job's elapsed time recorded beside them.", "hardware": "RTX 5090.", "software": "not recorded", "input": "not recorded", "samples": "One documented control run.", "statistic": "Single recorded run unless stated otherwise.", "warmCold": "Cold managed job, same-container A→B residency.", "network": "not recorded", "serialization": "not recorded", "correctness": "Report records two correct dependent stages.", "limitations": [ "Compute-only comparison does not describe the managed elapsed boundary.", "Recorded elapsed is rounded in the original report." ], "interpretation": "The local two-stage compute took 429 ms and the GPU version 30 ms, while the managed job still took 55.9 seconds end to end.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-falsification" ], "rows": [ { "label": "Local A+B compute", "value": 428.713, "unit": "ms", "role": "local", "n": 1, "statistic": "recorded value" }, { "label": "GPU A+B compute", "value": 30.102, "unit": "ms", "role": "remote", "n": 1, "statistic": "recorded value" }, { "label": "Managed job elapsed", "value": 55900, "unit": "ms", "role": "metric", "n": 1, "statistic": "recorded value" } ], "comparisons": [], "chart": false, "presentation": { "title": "Two dependent stages sharing one GPU container", "question": "I wanted to see how much of the win comes simply from not shipping the intermediate result between two stages, so I kept both stages in one process.", "comparison": "The two stages computed locally against the same two stages on the GPU, with the managed job's elapsed time recorded beside them.", "finding": "The local two-stage compute took 429 ms and the GPU version 30 ms, while the managed job still took 55.9 seconds end to end.", "lesson": "Keeping the intermediate in place makes the compute fourteen times faster, but about fifty seconds of start-up still dominates the job.", "caveat": "One documented control run, the recorded elapsed figure is rounded in the original report, and the compute-only comparison does not describe what a user waits for.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Local two-stage compute", "1": "GPU two-stage compute", "2": "Managed job elapsed" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "Two dependent stages in one GPU container", "scope": "Dependent-stage compute and separately recorded managed elapsed time.", "interpretation": "Keeping intermediate state in one process accelerates the compute interval, while roughly 50 s of startup still dominates the managed job." } }, "chartSeries": [] }, { "id": "alpha-same-job-warm-heavy", "title": "Reusing a job that is already running", "topic": "Fusion history", "date": "2026-09-09", "evidence": "Measured", "scope": "Five iterations after the initial warm-up of the larger workload inside a single job.", "hardware": "RTX 5090.", "software": "not recorded", "input": "250,000 values; intensity 64.", "samples": "5 post-warmup iterations.", "statistic": "Median; initial warmup excluded.", "warmCold": "Warm inside the same job.", "network": "not recorded", "serialization": "not recorded", "correctness": "Report records validated outputs.", "limitations": [ "Raw same-job files are not retained in this checkout; original report is the source.", "Do not pool with persistent-Pod samples." ], "interpretation": "The median iteration was 173 ms.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-final-report" ], "rows": [ { "label": "Warm runtime median", "value": 173.4, "unit": "ms", "role": "remote", "n": 5, "statistic": "median" } ], "comparisons": [], "chart": false, "presentation": { "title": "Reusing a job that is already running", "question": "If the machine is already there, the second and later iterations should be far cheaper, so I timed iterations inside one live managed job.", "comparison": "Five iterations after the initial warm-up of the larger workload inside a single job.", "finding": "The median iteration was 173 ms.", "lesson": "A running job makes each iteration cheap, but that says nothing about whether a job can be kept alive as a reusable service.", "caveat": "Five iterations drawn from a single job on a single day, with the underlying data not kept, so this is transcribed from the original report; these samples must not be pooled with the dedicated-machine samples.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Warm iteration, median" } }, "technical": { "original": { "title": "Same-job warm runtime: heavy", "scope": "Post-warmup iterations inside one existing provider job, not cross-job persistent allocation.", "interpretation": "Readiness changes the compute budget; these samples do not establish a deployable reusable provider session." } }, "chartSeries": [] }, { "id": "alpha-same-job-warm-small", "title": "The same running job at a smaller size", "topic": "Fusion history", "date": "2026-09-09", "evidence": "Measured", "scope": "Five iterations after the initial warm-up of the smaller workload inside a single job.", "hardware": "RTX 5090.", "software": "not recorded", "input": "10,000 values; intensity 4.", "samples": "5 post-warmup iterations.", "statistic": "Median; initial warmup excluded.", "warmCold": "Warm inside the same job.", "network": "not recorded", "serialization": "not recorded", "correctness": "Report records validated outputs.", "limitations": [ "Raw same-job files are not retained in this checkout; original report is the source.", "Do not pool with persistent-Pod samples." ], "interpretation": "The median iteration was 12.7 ms.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-final-report" ], "rows": [ { "label": "Warm runtime median", "value": 12.7, "unit": "ms", "role": "remote", "n": 5, "statistic": "median" } ], "comparisons": [], "chart": false, "presentation": { "title": "The same running job at a smaller size", "question": "I checked whether the cheap-iteration effect survived at a smaller size, since the first result came from a large workload.", "comparison": "Five iterations after the initial warm-up of the smaller workload inside a single job.", "finding": "The median iteration was 12.7 ms.", "lesson": "The pattern holds: cheap once the machine exists, with no implication that the machine can be held between jobs.", "caveat": "Five iterations from one job on one day, the underlying files were not kept so this comes from the original report, and these samples must not be pooled with the dedicated-machine samples.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Warm iteration, median" } }, "technical": { "original": { "title": "Same-job warm runtime: small", "scope": "Post-warmup iterations inside one existing provider job, not cross-job persistent allocation.", "interpretation": "Readiness changes the compute budget; these samples do not establish a deployable reusable provider session." } }, "chartSeries": [] }, { "id": "alpha-warm-requests", "title": "Six warm requests against a machine that keeps its input", "topic": "Fusion history", "date": "2026-09-09", "evidence": "Measured", "scope": "Six requests, each recording the whole-request wall time and the device compute time separately.", "hardware": "Persistent RTX 5090 (campaign context).", "software": "not recorded", "input": "not recorded", "samples": "6 recorded requests.", "statistic": "Single recorded run unless stated otherwise.", "warmCold": "Warm; every sample records a GPU input-cache hit and no host-to-device upload.", "network": "not recorded", "serialization": "not recorded", "correctness": "Resident identities retained; no new full-output correctness check in this sample file.", "limitations": [ "No matched local arm in this file.", "Do not interpret GPU kernel time as application latency." ], "interpretation": "The median request took 449 ms end to end while the device compute was 2.0 ms.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-persistent-warm" ], "rows": [ { "label": "Request wall median", "value": 448.96185000000037, "unit": "ms", "role": "remote", "n": 6, "statistic": "median calculated from raw samples" }, { "label": "GPU compute median", "value": 1.9648269953904673, "unit": "ms", "role": "metric", "n": 6, "statistic": "median calculated from raw samples" } ], "comparisons": [], "chart": false, "presentation": { "title": "Six warm requests against a machine that keeps its input", "question": "I wanted the per-request overhead of a dedicated machine on its own, so I measured six warm requests with the input already held on the device.", "comparison": "Six requests, each recording the whole-request wall time and the device compute time separately.", "finding": "The median request took 449 ms end to end while the device compute was 2.0 ms.", "lesson": "A kernel that runs in two milliseconds still costs a third of a second to ask for, and that gap decides the outcome.", "caveat": "Six requests with no local comparison in the same data, and the device kernel time must not be read as application latency.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Request wall time, median", "1": "Device compute, median" } }, "technical": { "original": { "title": "Persistent GPU: six warm requests", "scope": "Warm resident requests; wall and compute have different timing boundaries.", "interpretation": "Sub-millisecond-to-millisecond kernels do not remove request/response latency." } }, "chartSeries": [] }, { "id": "alpha-full-fusion", "title": "The first end-to-end run that moved work between a CPU and a GPU", "topic": "Fusion history", "date": "2026-09-07", "evidence": "Measured", "scope": "One local-only run against one full cross-device run, with the object transfer and the remote stage timed inside the second.", "hardware": "Remote NVIDIA GeForce RTX 5090. Local CPU model not recorded in the receipt.", "software": "not recorded", "input": "250,000 input values, intensity 64; Stage-A object 5,032,313 bytes.", "samples": "1 recorded run per path.", "statistic": "Single recorded run unless stated otherwise.", "warmCold": "Cold provider lifecycle and object staging.", "network": "17,249.517 ms recorded object-transfer interval; transport internals not recorded.", "serialization": "not recorded", "correctness": "correct=true; documented floating-point tolerance 0.01.", "limitations": [ "Do not add remote sub-intervals to infer the reported total.", "Later report identifies roughly 155 s of correctness-reference work inside the total.", "Single historical run; not a production latency claim." ], "interpretation": "The full run completed correctly within the documented numerical tolerance, but its recorded total of 288 seconds was about twice the local-only 145 seconds, and inside that total roughly 155 seconds was local reference work I had run alongside it.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-full-fusion", "alpha-local-full" ], "rows": [ { "label": "Local-only total", "value": 145179.13710000002, "unit": "ms", "role": "local", "n": 1, "statistic": "recorded value" }, { "label": "Fusion recorded total", "value": 288321.2843, "unit": "ms", "role": "remote", "n": 1, "statistic": "recorded value" }, { "label": "Remote Stage B", "value": 115571, "unit": "ms", "role": "metric", "n": 1, "statistic": "recorded value" }, { "label": "Object transfer", "value": 17249.517, "unit": "ms", "role": "metric", "n": 1, "statistic": "recorded value" } ], "comparisons": [], "chart": false, "presentation": { "title": "The first end-to-end run that moved work between a CPU and a GPU", "question": "I wanted to see whether a whole application run, local preparation then GPU work then local results, could complete correctly, so I ran the full chain once.", "comparison": "One local-only run against one full cross-device run, with the object transfer and the remote stage timed inside the second.", "finding": "The full run completed correctly within the documented numerical tolerance, but its recorded total of 288 seconds was about twice the local-only 145 seconds, and inside that total roughly 155 seconds was local reference work I had run alongside it.", "lesson": "The cross-device chain worked; the timing cannot be read as a production latency because my own reference computation sat inside it.", "caveat": "A single historical run, the remote sub-intervals cannot be added to the reported total, and the recorded total contains the reference work, so it is not an uncontaminated comparison.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Local-only total", "1": "Recorded cross-device total", "2": "Remote stage", "3": "Object transfer" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "First correct heterogeneous Fusion: recorded full-run envelope", "scope": "Recorded full-run totals. The Fusion envelope also contains separately executed local correctness-reference work.", "interpretation": "Functional local → GPU → local execution succeeded. The recorded Fusion total is slower, but its correctness-reference tail prevents treating this as an uncontaminated production latency comparison." } }, "chartSeries": [] }, { "id": "alpha-isolated-positive", "title": "The same idea at a much larger size, where the GPU did win", "topic": "Fusion history", "date": "2026-09-07", "evidence": "Measured", "scope": "One local run against one managed GPU run, 250,000 input values at a compute intensity of 64.", "hardware": "Receipt identifies an NVIDIA L4 route. A later report labels the route RTX 5090; the original profile identity is retained here.", "software": "not recorded", "input": "250,000 input values, compute intensity 64.", "samples": "1 local and 1 remote observation.", "statistic": "Single recorded run unless stated otherwise.", "warmCold": "Managed provider execution.", "network": "not recorded", "serialization": "not recorded", "correctness": "CUDA verified and checksum artifact correct.", "limitations": [ "One observation per path.", "Provider compute sub-timing unavailable.", "Hardware labels differ between the original profile and later summary; no cross-GPU inference." ], "interpretation": "The local path took 146.7 seconds and the managed GPU 134.0 seconds, so the device was ahead by about 9 percent.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-stage-positive" ], "rows": [ { "label": "Local CPU", "value": 146673.3167, "unit": "ms", "role": "local", "n": 1, "statistic": "recorded value" }, { "label": "Managed GPU elapsed", "value": 134013, "unit": "ms", "role": "remote", "n": 1, "statistic": "recorded value" } ], "comparisons": [ { "baseline": 0, "candidate": 1, "kind": "historical" } ], "chart": true, "presentation": { "title": "The same idea at a much larger size, where the GPU did win", "question": "I scaled the same kind of job up by two hundred and fifty times to see whether the managed route could ever pay, and at that size it did.", "comparison": "One local run against one managed GPU run, 250,000 input values at a compute intensity of 64.", "finding": "The local path took 146.7 seconds and the managed GPU 134.0 seconds, so the device was ahead by about 9 percent.", "lesson": "This is the narrow positive result in the history: at sufficient size and intensity the remote device was faster, which is a reason to keep looking rather than a general claim.", "caveat": "One observation per path, the device's own compute time was not available, and the original record names one accelerator while a later summary names a different one, so I draw no conclusion across different hardware.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Local execution", "1": "Managed GPU elapsed" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "Cold managed GPU: isolated heavy Stage-B anchor", "scope": "Isolated Stage B, not a complete local → GPU → local application workload.", "interpretation": "A narrow positive isolated-stage observation, not evidence of a general scheduler or application speedup." } }, "chartSeries": [] }, { "id": "alpha-isolated-small", "title": "A small heavy computation sent to a rented GPU", "topic": "Fusion history", "date": "2026-09-07", "evidence": "Measured", "scope": "One local profile over five repetitions against a single cold managed GPU submission of 1,024 input values.", "hardware": "Remote NVIDIA L4; local CPU model not recorded in this receipt.", "software": "not recorded", "input": "1,024 input values, compute intensity 4.", "samples": "Local: 5 repetitions. Remote: 1.", "statistic": "Single recorded run unless stated otherwise.", "warmCold": "Cold managed submission.", "network": "not recorded", "serialization": "not recorded", "correctness": "GPU artifact verified CUDA and the expected output.", "limitations": [ "GPU compute sub-timing was not exposed.", "Different local and provider timing envelopes; not a pure kernel comparison." ], "interpretation": "The local kernel took 42 ms and the managed GPU reported 118 seconds from submission.", "href": "/research/fusion-history/", "sourceIds": [ "alpha-stage-small" ], "rows": [ { "label": "Local CPU", "value": 42.0089, "unit": "ms", "role": "local", "n": 5, "statistic": "median" }, { "label": "Managed GPU elapsed", "value": 118274, "unit": "ms", "role": "remote", "n": 1, "statistic": "recorded value" } ], "comparisons": [], "chart": false, "presentation": { "title": "A small heavy computation sent to a rented GPU", "question": "At the very start of this work I wanted to know whether a rented GPU could beat my own machine on a small but compute-heavy kernel, so I submitted one job and compared it with the local profile.", "comparison": "One local profile over five repetitions against a single cold managed GPU submission of 1,024 input values.", "finding": "The local kernel took 42 ms and the managed GPU reported 118 seconds from submission.", "lesson": "At this size the managed route loses outright, because acquisition and start-up dominate anything the device could save.", "caveat": "One managed run against five local ones, the device's own compute time was never exposed, and the two figures are measured on different timing envelopes so this is not a pure kernel comparison.", "kind": "Historical performance", "area": "Fusion Alpha", "labels": { "0": "Local execution", "1": "Managed GPU elapsed" }, "featuredRows": [ 0, 1 ] }, "technical": { "original": { "title": "Cold managed GPU: small Stage-B control", "scope": "Equivalent isolated heavy-compute kernel family; provider elapsed versus local kernel profile.", "interpretation": "The managed GPU route loses once acquisition and startup are included." } }, "chartSeries": [] }, { "id": "rt-product-connectivity-auth-session", "title": "The whole product path: provisioning, authentication, a real remote job", "topic": "Interoperability", "date": "2026-09-06", "evidence": "Measured", "scope": "One successful remote job of a 2048-square multiplication, one test with the carrier removed mid-job, and one forced host-process termination.", "hardware": "A personal Windows machine with an integrated GPU and no accelerator tooling available on it. The external computation ran on a separate rented accelerator with 32 GB of memory, reported as an RTX 5090.", "software": "The desktop client, the service backend that holds the provider credential, and the external compute provider. The provider required its own server-side key before it would start a job.", "input": "A single 2048 by 2048 matrix multiplication submitted through the client, with the checksum of the returned result recorded.", "samples": "One successful external job, one mid-job carrier removal, and one forced host-process termination test.", "statistic": "Single recorded values for the successful job. The lease path is recorded as a bounded interval rather than a distribution.", "warmCold": "The recorded job is a single cold external submission. No warm reuse is recorded.", "network": "The client contacts the service endpoint, which holds the provider credential and submits the external job. The receipt does not record transport byte counts.", "serialization": "Not recorded as a separate figure. The returned result carried a checksum and an execution time.", "correctness": "The external job returned the expected matrix size and a recorded checksum with a container exit code of zero and a completed provider status. On carrier removal the client reported the removal, revoked compute, denied capability and exited non-zero, the service recorded the compute session as released and revoked, and the provider reported the job cancelled with the reason that the credential lease had ended.", "limitations": [ "One successful job and one removal event; no distribution.", "The checksum is recorded, but the receipt does not publish an independent numerical oracle for the returned result.", "A second physical machine was not available, so second-machine hardware execution remains pending.", "The forced-termination test used a mock allocation, so it validates the lease path rather than a real provider teardown.", "The provider billing record is not published.", "This is a product validation record from 2026-09-06 and predates the component qualification work elsewhere in this dataset." ], "interpretation": "The remote job returned in 100 ms with the expected result and a zero exit code; removing the carrier mid-job made the client revoke the compute, deny capability and exit non-zero while the provider reported the job cancelled, and killing the host released the lease within eight seconds.", "href": "/research/runtime/", "sourceIds": [ "rt-src-desktop-validation" ], "rows": [ { "label": "external computation execution time", "value": 100.43, "unit": "ms", "role": "remote", "n": 1, "statistic": "single recorded value returned with the job result" }, { "label": "matrix side length", "value": 2048, "unit": "cases", "role": "metric", "n": 1, "statistic": "2048 by 2048 matrix multiplication" }, { "label": "successful external jobs", "value": 1, "unit": "calls", "role": "remote", "n": 1, "statistic": "one job completed with a zero container exit code" }, { "label": "successful local fallback on carrier removal", "value": 1, "unit": "cases", "role": "metric", "n": 1, "statistic": "client revoked compute, denied capability and exited non-zero" }, { "label": "forced host-termination lease bound", "value": 8000, "unit": "ms", "role": "metric", "n": 1, "statistic": "the recorded eight-second backend lease path, expressed in milliseconds" }, { "label": "backend release test cases passed", "value": 7, "unit": "cases", "role": "metric", "n": 1, "statistic": "7 tests covering marker parsing, discovery, URL restrictions, path escaping and secret redaction" } ], "comparisons": [], "chart": false, "presentation": { "title": "The whole product path: provisioning, authentication, a real remote job", "question": "I wanted to see whether the product works end to end for a user rather than in pieces, so I provisioned the credential carrier, ran a real remote computation and then broke the session in two ways.", "comparison": "One successful remote job of a 2048-square multiplication, one test with the carrier removed mid-job, and one forced host-process termination.", "finding": "The remote job returned in 100 ms with the expected result and a zero exit code; removing the carrier mid-job made the client revoke the compute, deny capability and exit non-zero while the provider reported the job cancelled, and killing the host released the lease within eight seconds.", "lesson": "The interesting result is the failure behaviour: the credential can be pulled out from under a running job and the job is cancelled rather than left running, and a killed host leaves nothing active behind it.", "caveat": "One successful job and one removal event with no distribution, the result's checksum is recorded but no independent numerical reference is published for it, a second physical machine was not available, and the forced-termination test used a stand-in allocation so it proves the lease path rather than a real provider teardown.", "kind": "Functional check", "area": "Runtime" }, "technical": { "original": { "title": "Product connectivity, authentication and session lifecycle on removable-media provisioning", "scope": "The product path end to end on a personal machine: a removable credential carrier is discovered and provisioned, the client authenticates with the service, a real external computation runs, and the session is released. The receipt also records what happens when the carrier is removed mid-job and when the host process is forcibly terminated.", "interpretation": "The product path works end to end at the functional level: provisioning, authentication, an external computation that completed, and a release. The interesting result is the failure path, where removing the credential carrier mid-job revoked the compute session and cancelled the external job rather than leaving it running, and where forcibly terminating the host released the lease within eight seconds with no session left active." } }, "chartSeries": [] } ], "sources": [ { "id": "cad-bridge-benchmark-uncompressed-r1", "title": "Captured-array intersection bridge benchmark, uncompressed run r1 (run: cad-usefulness-20261108-r1)", "date": "2026-11-08", "artifact": "intersection-benchmark.json", "sha256": "5901CCC71E566EF1C29ECEC75BA7C524AD6F6E2AFB909ABB32732798EA2C10DB", "locator": "/summary" }, { "id": "cad-bridge-benchmark-compressed-r2", "title": "Captured-array intersection bridge benchmark, lossless-compressed run r2 (run: cad-usefulness-20261108-r1)", "date": "2026-11-08", "artifact": "intersection-benchmark-compressed-r2.json", "sha256": "D75BCABD84B064105A0E617BE92ECE67AC7BFCAD840A67EA692D62AF42FD6D16", "locator": "/summary" }, { "id": "cad-bridge-progress-compressed-r2", "title": "Captured-array intersection bridge per-request progress log, compressed run r2 (run: cad-usefulness-20261108-r1)", "date": "2026-11-08", "artifact": "intersection-progress-compressed-r2.jsonl", "sha256": "29717B100591D8F129A6158ADA4F1CBF596014E814CCF87D6D4839F1EBB36B48", "locator": "/lines/0..12" }, { "id": "cad-usefulness-result-20261108", "title": "AutoCAD expensive-workload campaign result summary (run: cad-usefulness-20261108-r1)", "date": "2026-11-08", "artifact": "result.json", "sha256": "7294C0686A4AEBA207A540490B1CD0D1BF8FBAD3B31FDE53AFE2F760E2EE8065", "locator": "/profile" }, { "id": "cad-native-profile-20261108", "title": "Native AutoCAD synthetic operation profile log (run: cad-usefulness-20261108-r1)", "date": "2026-11-08", "artifact": "native-profile.txt", "sha256": "93BA251614C46B6F6B7E2070DAB917EEF68984051173154EA4A736077118046D", "locator": "/lines/1..31" }, { "id": "cad-intersection-faults-compressed-r2", "title": "Bridge fault-injection case matrix, compressed run r2 (run: cad-usefulness-20261108-r1)", "date": "2026-11-08", "artifact": "intersection-faults-compressed-r2.json", "sha256": "3EBB44863763B55BCED072381B48588842082F902DB865A20420D18733D7EC83", "locator": "/cases" }, { "id": "cad-intersection-disconnect-compressed-r2", "title": "Stopped remote worker fail-closed receipt, compressed run r2 (run: cad-usefulness-20261108-r1)", "date": "2026-11-08", "artifact": "intersection-disconnect-compressed-r2.json", "sha256": "0C7C7F7690F05B8BE4E902F868587B23B7B2B3922AD69461A4E4D19EB9412013", "locator": "/" }, { "id": "cad-intersection-admitted-input-128", "title": "Admitted AutoCAD curve capture used as intersection input, 128-route fixture (run: cad-usefulness-20261108-r1)", "date": "2026-11-08", "artifact": "intersection-admitted-input-128.json", "sha256": "97299FAFB36F2F44CA5943387DC484F8B55BD03B243CDA59B1E95303F4A15BD3", "locator": "/curves" }, { "id": "cad-length-restricted-r3", "title": "Restricted analytic straight-spline remote replacement acceptance receipt (run: cad-remote-straight-20261107-r3)", "date": "2026-11-08", "artifact": "acceptance.json", "sha256": "3498DEB4EE65049A380F0853BAB7ABD652F4ADB94C19E90E526F626E409C3902", "locator": "/" }, { "id": "cad-geometry-multisegment-live", "title": "Multi-segment AutoCAD remote length consumption receipt (run: cad-geometry-20261108-r2)", "date": "2026-11-08", "artifact": "live-acceptance.json", "sha256": "DFBD2FCF4905B3D21D1B31FA23324EECBBA582AE7189A19192B08E76AAC511E4", "locator": "/cases" }, { "id": "cad-crossdrawing-live-20261108", "title": "Cross-drawing AutoCAD remote length consumption receipt, campaigns r1 and r2 (run: cad-cross-live-20261108-r1)", "date": "2026-11-08", "artifact": "live-acceptance.json", "sha256": "61D25A65DCE7C75A0CCC9D1DA349C3D32432B3060462CC9A6C8870616DFFE1FC", "locator": "/live_results" }, { "id": "cad-intersection-native-baseline-128", "title": "Native AutoCAD intersection baseline capture, 128-route session (run: cad-intersection-live-20261109-r1)", "date": "2026-11-10", "artifact": "native-128-return.json", "sha256": "D2F43A1A70725D3C8A935B6BFD7790D6B5D48C9C21D0A574FFBDE1EA2F3AF3A3", "locator": "/" }, { "id": "cad-intersection-native-baseline-256", "title": "Native AutoCAD intersection baseline capture, 256-route session (run: cad-intersection-live-20261109-r1)", "date": "2026-11-10", "artifact": "native-256-return.json", "sha256": "CD2F8EDDB3E1463E43E5A1B70C424B79029317251DA7F4404E48D20E9E7F6450", "locator": "/" }, { "id": "cad-intersection-live-nov10", "title": "Live AutoCAD intersection consumption and fallback receipt (run: cad-intersection-live-20261109-r2, executed 2026-11-10)", "date": "2026-11-10", "artifact": "live-acceptance.json", "sha256": "E27E0AA9CFD14CAE08CEACBE7D1137FE0DE85997B3788B055A13E91652A44353", "locator": "/records" }, { "id": "cad-intersection-live-seal-nov10", "title": "Live AutoCAD intersection campaign seal manifest (run: cad-intersection-live-20261109-r2)", "date": "2026-11-10", "artifact": "live-seal.json", "sha256": "6F2CDB48FF5BA97356CE48B51F982BF9A023CB492CE3765A076E4538B47D03FC", "locator": "/" }, { "id": "cad-intersection-host-build-r5", "title": "Intersection host adapter build receipt r5 (run: cad-intersection-host-build-20261108-r5)", "date": "2026-11-08", "artifact": "build.json", "sha256": "C6EB6D1DEEF6B0C0F91474D141654CE33CC7710A20CB2EA7E5946142FF75BF85", "locator": "/" }, { "id": "cad-campus-result-20261110", "title": "AutoCAD campus pilot matched comparison result (run: cad-campus-20261110-r1)", "date": "2026-11-10", "artifact": "result.json", "sha256": "434AA3C83EC2B7DEBD5CF6F4449CF71B25EA437C19D15ED94A824C1CBFA108ED", "locator": "/comparison" }, { "id": "cad-campus-local-cold128-20261110", "title": "Local-mode AutoCAD 16,384-crossing cold operation receipt (run: cad-campus-local-live-20261110-r1)", "date": "2026-11-10", "artifact": "cold128.json", "sha256": "976B7B50E94501ADD154C8349447B1B6DE790896DDB7AA0F0D8BA346DC7F6F25", "locator": "/" }, { "id": "cad-campus-local-warm128c-20261110", "title": "Local-mode AutoCAD 16,384-crossing warm operation receipt (run: cad-campus-local-live-20261110-r1)", "date": "2026-11-10", "artifact": "local128c.json", "sha256": "E4A7FF18F246428F2663A94B3B0A7A1465BC559FED08426E53D112BD09B89CE8", "locator": "/" }, { "id": "cad-campus-remote-transport-20261110", "title": "Remote-mode transport stage timing log (run: cad-campus-remote-live-20261110-r1)", "date": "2026-11-10", "artifact": "transport-stages.jsonl", "sha256": "B70648DBE3430A12A57B62FCBFAEFF772228BB1454506AFEB2F7AE2B755030DF", "locator": "/lines/0..7" }, { "id": "cad-campus-prod-cold128-20261111", "title": "Non-QA candidate AutoCAD 16,384-crossing cold operation receipt (run: cad-campus-production-live-20261111-r2)", "date": "2026-11-11", "artifact": "cold128.json", "sha256": "F7E25F1ECB7566DF2B853D50F3D95BED764B81E95EEF6A7A3ED357CA961B2556", "locator": "/" }, { "id": "cad-campus-prod-warm128-20261111", "title": "Non-QA candidate AutoCAD 16,384-crossing warm operation receipt (run: cad-campus-production-live-20261111-r2)", "date": "2026-11-11", "artifact": "warm128.json", "sha256": "113259780FB19E7C90EF4444011218F9EEC455C27169F19B563044DA86EC0702", "locator": "/" }, { "id": "cad-sdk-qa-result", "title": "Direct AutoCAD SDK differential qualification result (run: cad-sdk-qa-20261110-r1)", "date": "2026-11-11", "artifact": "result.json", "sha256": "98363F64560AF604A211AF069A5AB2BAC1F3301F118067D1E6057BDA8B1F19CF", "locator": "/sdk_cases" }, { "id": "cad-sdk-qa-independent-review", "title": "Independent read-only SDK qualification follow-up review (run: cad-sdk-qa-20261110-r1)", "date": "2026-11-11", "artifact": "independent-review.md", "sha256": "4EF88D3DF5531FB6E628528D58D00FEC3150E0566DFA15EF45508FABB162F9C3", "locator": "/" }, { "id": "cad-install-auth-recon", "title": "Installed workflow reconnaissance: installer, account and second-machine status (run: cad-campus-20261110-r1)", "date": "2026-11-10", "artifact": "install-auth-recon.md", "sha256": "AB92CFEAA58DD4655A670A262ECDC7FA98FD46D55ED8FE7580B6F618D83DDD84", "locator": "/" }, { "id": "cad-campus-independent-review", "title": "Independent read-only review of the local-first candidate (run: cad-campus-20261110-r1)", "date": "2026-11-10", "artifact": "independent-review.md", "sha256": "F5CF721E54B68902FA03F3EA5987836787D773BB15ED1A4BE1606F81FA723160", "locator": "/" }, { "id": "cad-remote-cpu-readiness", "title": "Remote CPU node readiness receipt (host label withheld)", "date": "2026-11-07", "artifact": "cpu-readiness.json", "sha256": "1DDBD22F764D5B78002B7695E89D5AA79774D0D2DDBADB22201E9343DF1B7CE8", "locator": "/" }, { "id": "cad-pilot-install-013", "title": "Pilot desktop install receipt, version 0.1.3", "date": "2026-11-07", "artifact": "pilot-0.1.3-install.json", "sha256": "5B2EF9C2E9AF1BCB4CB78C43F593073E9EB7DC24A66513177ACD89F4E75C2AA0", "locator": "/" }, { "id": "cad-pilot-reconnect-013", "title": "Pilot desktop reconnect receipt, version 0.1.3", "date": "2026-11-07", "artifact": "pilot-0.1.3-reconnect.json", "sha256": "4EBA76700D9DF12808191962D54654020EE0B49D8EDC86B5C1901896368670EE", "locator": "/" }, { "id": "alg-obp-cpu-benchmark", "title": "Local CPU reassociation, slice and memo benchmark at n=256, 1024 and 2048", "date": "2026-10-11", "artifact": "cpu-benchmark.json", "sha256": "2B8A06326B30E2B2314B1430C4DE96F56FEC498DBEE2ED85181864026C4269DC", "locator": "/cases" }, { "id": "alg-obp-cache-baseline", "title": "Warm result cache against uncached compute at n=256, 1024 and 2048", "date": "2026-10-11", "artifact": "cache-baseline.json", "sha256": "71586C7B96385594CC62D237A4A88CDBD4F2A13E207C721E497F2B6F610EEC02", "locator": "/cases" }, { "id": "alg-aspr-local-new", "title": "Registered immutable cache against an untracked exact-scan cache at n=1024", "date": "2026-10-11", "artifact": "local-new-results.json", "sha256": "868B57BAEE3C3421F221817A0A71AAA5D9D1AC01E6D77CC8C244194ECF636E1D", "locator": "/summary_ms" }, { "id": "alg-aspr-predictor", "title": "Baseline linear and GRU placement forecasters, held-out classification and modeled workload cost", "date": "2026-10-11", "artifact": "predictor-results.json", "sha256": "A3D59A0238060486D30D4EDE5C4D1342EADD6A9691A92EA83B8F903EC9028BF4", "locator": "/models" }, { "id": "alg-aspr-refinement", "title": "Frozen-threshold refinement of the linear and GRU forecasters on a fresh synthetic trace", "date": "2026-10-11", "artifact": "refinement-results.json", "sha256": "57381C27089893188A1FBD58107A81E3D45AAC7C655D89D1FA127F3D9473AFAD", "locator": "/models" }, { "id": "alg-aspr-cache-simulation", "title": "Modeled local baseline with a 64 MiB result cache for reactive, heuristic and learned placement", "date": "2026-10-11", "artifact": "local-cache-simulation.json", "sha256": "65AE1146494230E4AF9AAB4C6DD202611EC09E7F7A209D6343D70BC48963C9F7", "locator": "/models" }, { "id": "alg-aspr-precompute-simulation", "title": "Modeled learned local precomputation and dual placement at one-times and four-times CPU work", "date": "2026-10-11", "artifact": "local-precompute-simulation.json", "sha256": "BD8BBA0DA4351497C2C24792179427C2D622D76BFB174ABFC140E9F86C298772", "locator": "/rows" }, { "id": "alg-aspr-inference-budget", "title": "Measured CPU inference and adaptation budget for both forecaster models", "date": "2026-10-11", "artifact": "inference-budget.json", "sha256": "F37BD137A3A67BC6BF44CDB1E59773BFF96BBB0E4F163CC30E6A72D174417CC0", "locator": "/models" }, { "id": "alg-aspr-memory-corrected", "title": "Fresh-process runtime and loaded-weight memory for both models", "date": "2026-10-11", "artifact": "memory-corrected.json", "sha256": "A38797A7283ACE600CA6F39C47F0DAD2E21131BB6001D1197F3E927B902591D8", "locator": "/models" }, { "id": "alg-aspr-interference", "title": "Short-burst interference response with none, unlimited and ten-percent background work", "date": "2026-10-11", "artifact": "interference-results.json", "sha256": "985BD4F63BCDBBF37AF350C34C24C74B487B976EDDB79BDA93DEC8DBDE4F3393", "locator": "/results" }, { "id": "alg-aspr-codec", "title": "Lossless codec screening over five corpora at two buffer sizes", "date": "2026-10-11", "artifact": "codec-results.json", "sha256": "9D3E274FA4C96CF1BF20C12B35B6C1EDF51AC57998A1F55F94FE66D48CB7CB8B", "locator": "/cases" }, { "id": "alg-obp-reference-results", "title": "Reference correctness and discrete simulation assertions for the boundary placement format", "date": "2026-10-11", "artifact": "reference-results.json", "sha256": "ABACE28BDE3EE8DE2CBA83AD8D9DAD08E30923CA552D34AC40C4CA19F1B52B19", "locator": "/assertions" }, { "id": "alg-obp-extended-results", "title": "Exact checks, worked example and algebraic cost estimates", "date": "2026-10-11", "artifact": "extended-results.json", "sha256": "80AFAADE76AA44E1B972009CA1A3C8B8AD73FAD74BB9446F3F836011CF1CD9D4", "locator": "/assertions" }, { "id": "alg-obp-block-format", "title": "Block header and patch byte-conformance vectors", "date": "2026-10-11", "artifact": "block-format-vectors.json", "sha256": "E6E43A36253DB7A97883181A22E9F84D889A42E4ED9D4AE974A69B5FFFF285B7", "locator": "/assertions" }, { "id": "alg-obp-rematerialization", "title": "Discrete rematerialisation simulation assertions", "date": "2026-10-11", "artifact": "rematerialization-results.json", "sha256": "2EA1483488F64DDCED124534E7B7FB1EEC368EAAD59765BE3F0AA8C93F6E7BD0", "locator": "/assertions" }, { "id": "alg-obp-gen1-verification", "title": "Gen-1 deterministic algorithm, trace-reanalysis and model-simulation verification batch", "date": "2026-10-11", "artifact": "verification-results.json", "sha256": "BAAF9928BE8D03ABF1C847F49EC0D25A627FBC81BCA0053DDC22D0453BC916A9", "locator": "/checks" }, { "id": "rt-src-s4-protocol", "title": "Frozen useful-workload comparison protocol, version 1", "date": "2026-10-03", "artifact": "protocol.md", "sha256": "bd95c9f4401a3ae6faca33a3e87495c3acae9cb886947ed3f30ec02c0ed580a5", "locator": "sections: Cases and scope; Fixed comparison procedure" }, { "id": "rt-src-s4-r13-campaign", "title": "Four-mode comparison campaign, attempt R13, raw result document", "date": "2026-10-10", "artifact": "campaign-result.json", "sha256": "ceeccc8b1ea2a48f6b8bac3c4f401ca372e37788496b485efb410f312c745c5a", "locator": "/partial/analysis" }, { "id": "rt-src-s4-r13-recomputed", "title": "Frozen-method recomputation of the R13 comparison", "date": "2026-10-10", "artifact": "recomputed-analysis.json", "sha256": "3577c10205d4383141bda86a73deeed0e26194f8036c8d24f94265657ca27e09", "locator": "/" }, { "id": "rt-src-s4-r13-decision", "title": "Independent gate decision on the R13 attempt", "date": "2026-10-10", "artifact": "gatekeeper-r13-performance-decision.md", "sha256": "6d7f94792a2eff11de872adee7fbbfb3d7b88cc7065dfd34372fc9272ff27f26", "locator": "table: Requirements and evidence" }, { "id": "rt-src-s4-r14-campaign", "title": "Four-mode comparison campaign, attempt R14, raw result document", "date": "2026-10-10", "artifact": "campaign-result.json", "sha256": "74690b389f849109a522197a01335a5002f2dc2a3e60b759065b439f800df36c", "locator": "/partial/analysis" }, { "id": "rt-src-s4-r14-decision", "title": "Independent gate decision on the R14 attempt", "date": "2026-10-10", "artifact": "gatekeeper-r14-performance-decision.md", "sha256": "ad9057ccffdde9b3dcb63373e9b3b95f4fc2ade97d7189e3e370b3b0e74d3aa5", "locator": "table: criterion versus actual evidence" }, { "id": "rt-src-s4-r3-decision", "title": "Disposition of the CPU-only comparison attempt", "date": "2026-10-12", "artifact": "result-decision.md", "sha256": "8f2f9d6449714d094e147034abd34b0dbc70a4eee52d638d942ad5db544f03a0", "locator": "opening paragraphs" }, { "id": "rt-src-s4-r4-decision", "title": "Disposition of the accelerator-first diagnostic attempt", "date": "2026-10-13", "artifact": "result-decision.md", "sha256": "dbb83861ee6b46ce84c09f1b12d9f5c09c2d130aef872d5fead718d3274c5fd9", "locator": "sections: Correctness and measured performance; Phases and residency effectiveness" }, { "id": "rt-src-s4-v3-audit", "title": "Status and recovery audit of the cross-machine attempt", "date": "2026-10-15", "artifact": "AUDIT-20261015.md", "sha256": "a3fde7baaa987bfa33ef74c071c38533ea610101fc2e959b3bc3850db1f8cea7", "locator": "sections: What is established; Findings" }, { "id": "rt-src-s4-bottleneck", "title": "Measured bottleneck analysis of the losing four-mode run", "date": "2026-10-16", "artifact": "performance-bottleneck-analysis.md", "sha256": "9f75a8422f4e5c66bde6386bb14515ec89db703955f5a14bff0ad6d3a5da712a", "locator": "sections: 2; 3" }, { "id": "rt-src-cn-s5-002", "title": "Node four-mode campaign report", "date": "2026-10-17", "artifact": "S5-002-campaign-evidence.md", "sha256": "f8ed9108305113e8b20aaa7788a1a036215ed11f9ecd92538b0e67b571c71753", "locator": "sections: Campaign table; Honest reading" }, { "id": "rt-src-cn-s5-003", "title": "Node resident four-mode campaign, shaped-link and fallback report", "date": "2026-10-17", "artifact": "S5-003-resident-unblock-campaign.md", "sha256": "2a351fa3df519ff6bc008dde086c88c34492affb143fff17654d65089115d108", "locator": "sections: 2; 3; 4" }, { "id": "rt-src-cn-node-acceptance", "title": "Compute-node acceptance report", "date": "2026-10-17", "artifact": "CN-001-node-acceptance-report.md", "sha256": "dfb4a9ab7261d0efe0d2c64ea514c9e8ba6a4e4090cb3398000b558011f874f6", "locator": "sections: Source provenance; Test results; Exploratory loopback benchmarks" }, { "id": "rt-src-cn-s4-v4-protocol", "title": "Frozen CPU-only protocol revision 2 and feasibility closure", "date": "2026-10-17", "artifact": "s4-v4-protocol-cpu.md", "sha256": "3f930854d5ded28364f9cfada87efa7ce3988f9be132fc2317a4d02b98f58f88", "locator": "sections: 1; 2 item F2" }, { "id": "rt-src-cn-compression-link", "title": "Codec matrix loopback log", "date": "2026-10-17", "artifact": "compression_link.log", "sha256": "c6de47ff26281080343ff56a42017ae893aa7b55ad4f408fe8ca09566cd41b1c", "locator": "lines 41 to 48" }, { "id": "rt-src-cn-measured-link", "title": "Authenticated tunnel codec and timing log", "date": "2026-10-17", "artifact": "measured_link.log", "sha256": "d799de00be0423fe65b2b4853533183dedbcec713df9879ba2d3d5c63cc959c4", "locator": "lines 38 to 58" }, { "id": "rt-src-cn-chunk-bench", "title": "Chunked-transfer benchmark log", "date": "2026-10-17", "artifact": "chunk-bench-4gcap.log", "sha256": "dfebbc544da67a35358e9a1dc30619259aa33dddedb8d048bc80599c9083a843", "locator": "final error lines" }, { "id": "rt-src-cn-gemm-idle-t1", "title": "Node GEMM microbenchmark, single thread", "date": "2026-10-17", "artifact": "gemm-idle-t1.json", "sha256": "d7eeb0fc6410fce8ab0ece23fe9cb577e9b9bb1b068ab23770d21e9a34fdf67b", "locator": "/results" }, { "id": "rt-src-cn-gemm-idle-t2", "title": "Node GEMM microbenchmark, two threads", "date": "2026-10-17", "artifact": "gemm-idle-t2.json", "sha256": "926127e7ff44d13438b752217537052a3f1eb136f7d720beee3ffe96a436f809", "locator": "/results" }, { "id": "rt-src-cn-gemm-idle-t4", "title": "Node GEMM microbenchmark, four threads", "date": "2026-10-17", "artifact": "gemm-idle-t4.json", "sha256": "1b3c275d851752dd08847b32b48884935946e79047c2e8420856003a00ad74d4", "locator": "/results" }, { "id": "rt-src-cn-gemm-idle-t8", "title": "Node GEMM microbenchmark, eight threads", "date": "2026-10-17", "artifact": "gemm-idle-t8.json", "sha256": "c3290633cbf1a696f51d92f658a2b6b45c2b7d2276ae9f5aaa5e3dbe160105ae", "locator": "/results" }, { "id": "rt-src-cn-gemm-contended", "title": "Node GEMM microbenchmark under CPU contention", "date": "2026-10-17", "artifact": "gemm-contended-t8.json", "sha256": "e0ab688770978708a519896fd3b80c9d86fcac5e7539ca37fd08f6ad5b48889c", "locator": "/results" }, { "id": "rt-src-prepared-s5-gatekeeper", "title": "Independent gate decision on the prepared-CPU qualification", "date": "2026-10-18", "artifact": "s5-final-gatekeeper-review.md", "sha256": "a3c21761dfa640c6e661c6e55593538c9003a7ce4155820b9ccb172f5f741ec0", "locator": "section: Independent performance and correctness checks" }, { "id": "rt-src-prepared-s5-verification", "title": "Independent verification of the prepared campaign", "date": "2026-10-18", "artifact": "verification-campaign-r8.md", "sha256": "1c4ed2633f10f8df9bd89a1ed909faa3d4efec7aff5d5780f92d52b9da79fe12", "locator": "sections: Independent recomputation; Validity, execution and residency" }, { "id": "rt-src-prepared-s5-campaign", "title": "Prepared campaign record, one entry per line", "date": "2026-10-18", "artifact": "campaign.jsonl", "sha256": "901d4c8b71f050681a537361f14699f124b774ad4dfc4e9b2261b6826eff28fc", "locator": "whole file" }, { "id": "rt-src-prepared-s5-object-result", "title": "Windows-client to Linux-worker object exchange receipt", "date": "2026-10-18", "artifact": "object-interop-result.json", "sha256": "722812cb63d7d423d9b7676a8a22f5eacae56ec79beea36e0b517e69928989fa", "locator": "/receipt" }, { "id": "rt-src-prepared-s5-windows-build", "title": "Windows client build receipt", "date": "2026-10-18", "artifact": "windows-build-r8-native.json", "sha256": "4a99dabb26dfae011eb7153b7d7816880b4b4c1e2c15a8f8771ec24766323226", "locator": "/" }, { "id": "rt-src-s6-r6-status", "title": "Measured startup and full-cost status, revision 6", "date": "2026-10-19", "artifact": "startup-full-cost-measured-status-r6.md", "sha256": "19acd6aa2b6824b1b037e8c5dee58803c16deb9e46a9455648747cdcbbd1a37c", "locator": "boundary table and following paragraph" }, { "id": "rt-src-s6-gatekeeper-r2", "title": "Independent gate decision on the preservation candidate", "date": "2026-10-19", "artifact": "preservation-actual-gatekeeper-r2.md", "sha256": "456c55439a2aa15c9ab7cf0023135d73a2f3ce52f2943d7eb89e9e24fbdcd8b4", "locator": "verdict paragraph" }, { "id": "rt-src-nw1-cuda", "title": "Accelerator device, dependency and backend qualification report", "date": "2026-10-11", "artifact": "final-report.md", "sha256": "66eca4fabf8d41274414b6d007c7441ce3cbb42553b40199684ff4384fb7edf9", "locator": "sections: Qualification verdict; Envelope compliance" }, { "id": "rt-src-nw1-interop", "title": "Windows object-worker interoperability report", "date": "2026-10-11", "artifact": "interop-report.md", "sha256": "7216389af807a5e8dc294f4b912744db268ee248bdab346b03551e561f808cf8", "locator": "sections: Windows live round-trip; Full Windows suite" }, { "id": "rt-src-win-integration", "title": "Personal-Windows native runtime checkpoint report", "date": "2026-10-15", "artifact": "integration-report.md", "sha256": "e26be2900b476eaedee7dc1499130083aa6487cbb90f2a0d71ea2a0f73e1b182", "locator": "sections: Fresh validation; Measured performance, with boundaries; Transfer report and traffic budget" }, { "id": "rt-src-win-frozen-baseline", "title": "Independent native frozen-baseline report", "date": "2026-10-15", "artifact": "frozen-baseline-results.md", "sha256": "414f2b17b041848f1d47cdbadec761e433b9c7165ce4678ec5ca316364856b89", "locator": "sections: Measured one-thread result; Four-thread failure and stop" }, { "id": "rt-src-win-win002", "title": "Explicit native Windows interception report", "date": "2026-10-15", "artifact": "win002-final-report.md", "sha256": "549697ce8fa9b93b8feb7447215cc0a06a1ffb6e982dc7a542a0237527f2c86e", "locator": "section: Final fresh-target results" }, { "id": "rt-src-win-traffic-budget", "title": "Windows traffic-budget assessment", "date": "2026-10-15", "artifact": "traffic-budget-assessment.json", "sha256": "c15fc76d572b527555ff6442f85be5203d051438da61b425693e75e785c3b88c", "locator": "/" }, { "id": "rt-src-transfer-report-md", "title": "Measured transfer report", "date": "2026-10-13", "artifact": "transfer-report.md", "sha256": "251490f3d4addc8ac5cdfcf09286515f7aeac12ea68184eeb2ecaf281d5d8d15", "locator": "section: preamble and measured table" }, { "id": "rt-src-transfer-report-csv", "title": "Measured transfer table, machine-readable", "date": "2026-10-13", "artifact": "transfer-report.csv", "sha256": "782bf61b2c333ffe3c703d47dda8404dc434eb05011bba62384e8d4d5e637d23", "locator": "whole file" }, { "id": "rt-src-ua2-resynth-summary", "title": "Codec component isolated qualification summary", "date": "2026-10-10", "artifact": "summary.json", "sha256": "73864f0a72e5dc54eacc260ad87f9c6c1e4ca6aa5b417d1d0b8c7c264482825c", "locator": "/builds" }, { "id": "rt-src-ua2-splice-summary", "title": "Interception component isolated qualification summary", "date": "2026-10-11", "artifact": "summary.json", "sha256": "da1ae5c301602c0a6bbb4937b7333045cdc9eaab70aac54507ca91d290320afb", "locator": "/builds and /validate" }, { "id": "rt-src-ua2-runtime-summary", "title": "Runtime component isolated qualification summary", "date": "2026-10-11", "artifact": "summary.json", "sha256": "3770e5b6ff38cb029ed77e4c2b6865cf0048ceab53d0d463bdf0fae070e1fe71", "locator": "/builds" }, { "id": "rt-src-ua2-conformance", "title": "Composed integration conformance summary", "date": "2026-10-11", "artifact": "conformance-summary.json", "sha256": "fd377c8302e03f2dc9fcbdbbdb85d2b1261ce973c7d2d89532bb45f52b685355", "locator": "/x_checks and /test_totals" }, { "id": "rt-src-ua2-release-readiness", "title": "Independent release readiness report", "date": "2026-10-11", "artifact": "release-readiness-report.md", "sha256": "2007e4e44ce727d80ff9d69680264b4d244ebf6215cff9915bd6ae0b89e39e61", "locator": "sections: 2 and 3" }, { "id": "rt-src-ua2-resynth-manifest", "title": "Released component manifest", "date": "2026-10-11", "artifact": "release-manifest.json", "sha256": "8d64d24fc0657241b7b579562a591ff5fcad6d2b21f113da6074ce6f0f2ecc6f", "locator": "/artifact_sha256 and /platform_profile" }, { "id": "rt-src-win-dev-progress", "title": "Desktop and packaging continuation record", "date": "2026-11-05", "artifact": "progress-20261105.md", "sha256": "3e7491bac37e79e7d4411ff602dd88804769141383ebfa2b362e648320628c37", "locator": "sections: Verified; Preferred installer candidate; GUI observations and blockers" }, { "id": "rt-src-win-dev-gui", "title": "Native GUI qualification harness record", "date": "2026-11-05", "artifact": "README.md", "sha256": "97d481cfc06ab16d46a5ae65258304b83dc3ec77d76c7476ef49f7eb46f12ad9", "locator": "sections: Actions and evidence; Bounds and limitations" }, { "id": "rt-src-msi-build-evidence", "title": "Native installer packaging evidence", "date": "2026-11-05", "artifact": "BUILD-EVIDENCE-0.1.1.md", "sha256": "8a46eeaf7852ba712284682db33bf72b41f170b74e8f6709c73ff115bfcbe7fc", "locator": "sections: Parent candidate; Two-build byte comparison; Independent embedded payload and table checks" }, { "id": "rt-src-desktop-validation", "title": "Product validation record", "date": "2026-09-06", "artifact": "validation.md", "sha256": "b16be876642f46795e361557ab8b913dca9a6ad97624b055543b036b5350a64c", "locator": "sections: Real execution; Removal and cleanup; Automated verification" }, { "id": "alpha-stage-small", "title": "Alpha isolated Stage-B control, 1,024 / intensity 4", "date": "2026-09-07", "artifact": "stage-b-profile-comparison-1024-4.json", "sha256": "07b31e3b3e397c3fc78e768c0af509829edff12f8975c5abec395d385f533708", "locator": "/local; /remote_gpu" }, { "id": "alpha-stage-positive", "title": "Alpha isolated Stage-B positive anchor, 250,000 / intensity 64", "date": "2026-09-07", "artifact": "stage-b-positive-anchor-250000-64.json", "sha256": "0ed206f318bd3290dfeb0a3ffe8d525e397892bbcce2409f5c6585c25443af2c", "locator": "/local; /remote_gpu" }, { "id": "alpha-full-fusion", "title": "First correct heterogeneous Fusion run", "date": "2026-09-07", "artifact": "fusion-heterogeneous-first-success-fusion-first-1788793479345-8e48cb83.json", "sha256": "d4be82bf5a941ce2795a9a62003a71e419e341c4c25bbecb6f46c7b9115d7bf9", "locator": "/timings; /correctness" }, { "id": "alpha-local-full", "title": "Matching Alpha local-only workload", "date": "2026-09-07", "artifact": "local-only-positive-250000-64.json", "sha256": "35c35478f8a545dd7159486f6363ccc16ad4a0583088dc4843bfc1a9a1b0ecf2", "locator": "/timings" }, { "id": "alpha-final-report", "title": "Alpha research report, 9 September 2026", "date": "2026-09-09", "artifact": "FUSION_ALPHA_FINAL_REPORT.md", "sha256": "acfa6004e04a78f4dd412fd1a205ecfa30474e4f6206766a3eae0b0936af86f5", "locator": "Main measured results; planner prediction boundary" }, { "id": "alpha-falsification", "title": "Alpha continuation: final research and falsification report", "date": "2026-09-09", "artifact": "FUSION_FINAL_RESEARCH_REPORT.md", "sha256": "b397e3cf3266c0577c1bf4b3cb641d228ca9559f80d3f038c31e7812eaabea11", "locator": "Measured evidence; decision quality" }, { "id": "alpha-persistent-small", "title": "Persistent RTX 5090 resident comparison: small", "date": "2026-09-09", "artifact": "heavy-crossover-live.json", "sha256": "1edbf421e81adf75b08a15416e75a0c4c32c19b65d3ca0412c6f044db2841d0a", "locator": "/local_wall_ms; /remote_wall_ms; /residency" }, { "id": "alpha-persistent-large", "title": "Persistent RTX 5090 resident comparison: large", "date": "2026-09-09", "artifact": "heavy-heldout-live.json", "sha256": "074e2caa6693e268ce94619945d86cf40ecbf31325012243f657cea83c4525bb", "locator": "/local_wall_ms; /remote_wall_ms; /residency" }, { "id": "alpha-persistent-warm", "title": "Persistent GPU repeated warm requests", "date": "2026-09-09", "artifact": "warm-persistent-live.json", "sha256": "4246acf6cce568140add57c503bcdb25c258675e46307b1635f0435e1479cc17", "locator": "/samples" }, { "id": "alpha-study-b-live", "title": "Study B v1: pre-measurement termination", "date": "2026-09-21", "artifact": "STUDY_B_V1_LIVE_RESULTS.md", "sha256": "2b921f6dc5239165fde63d99bf66193ea12f2f0d99c3439f0f84dc48ce437936", "locator": "Live counts and failure disposition" }, { "id": "doc-obp-v2", "title": "Observation-Boundary Placement v2 specification", "date": "2026-10-11", "artifact": "SPECIFICATION.md", "sha256": "440cbf6a2a1f25bac26eb46e639b3d2c59cdde6599ef5212e5bedfc1be73b22f", "locator": "§1, §2, §5–11, §14–16" }, { "id": "doc-aspr", "title": "ASPR + OBP v2: Dual Compute Intelligence", "date": "2026-10-11", "artifact": "ASPR_SPECIFICATION.md", "sha256": "b072c6e258cff3d70377dc9bfa86141918a88ba141162aa6bab6ff988c3b3a17", "locator": "§1–3; algorithm and evidence boundaries" }, { "id": "doc-resynth", "title": "ReSynth component responsibilities", "date": "2026-10-11", "artifact": "README.md", "sha256": "47eeaa7ff1e214151963920869930fd82491e3d2dd64f143bb3dde6ce37cb757", "locator": "Responsibilities and boundaries; NCP1 framing" }, { "id": "doc-splice", "title": "Splice component identity and interception scope", "date": "2026-10-11", "artifact": "README.md", "sha256": "34493cb3ab8c9fa3110981ad56ed236d2717496c5b2255610c8be3546ec54c09", "locator": "Package and library names; Linux LP64 CBLAS scope" }, { "id": "doc-gates", "title": "Engineering gate ledger inspected 12 November 2026", "date": "2026-11-12", "artifact": "gates.json", "sha256": "235503b207b67584ac896bae31004606b4da3d73e68f105d1f7f8f9e8dee169c", "locator": "S3, S4, S5, S6, NW1, NW2; scoped requirements and decisions" }, { "id": "doc-s5-review", "title": "Prepared CPU campaign r8: numerical and interoperability review", "date": "2026-10-18", "artifact": "verification-campaign-r8.md", "sha256": "1c4ed2633f10f8df9bd89a1ed909faa3d4efec7aff5d5780f92d52b9da79fe12", "locator": "Independent recomputation; validity and execution; Windows/Linux functional bridge" }, { "id": "doc-cad-campus", "title": "AutoCAD campus-readiness engineering record", "date": "2026-11-10", "artifact": "AUTOCAD-CAMPUS-20261114.md", "sha256": "fee03d4c195cb555d24809f43d186315a7fe1ab131b18a1ee6aa6142e6b4a5b1", "locator": "Local-first measurement and remaining student-pilot gates" }, { "id": "doc-cad-sdk", "title": "Direct SDK AutoCAD qualification record", "date": "2026-11-11", "artifact": "AUTOCAD-SDK-QUALIFICATION-20261111.md", "sha256": "49610ea4bc13d0d866d9f9c8becdcf4c969676e814c62717615612154dc2c2e3", "locator": "Bounded eight-case qualification; campus NO-GO" }, { "id": "doc-cad-live", "title": "Live intersection consumption and fallback engineering record", "date": "2026-11-10", "artifact": "AUTOCAD-INTERSECTION-LIVE-20261110.md", "sha256": "b57c66adf58c4a0d4978e4d48b363ef3ac384aad494a96cbc0ae343e1e21312f", "locator": "API scope, run chronology and retained failed exchanges" } ] }