BenedictENGINEERING / CASE STUDY
Naught Labs
I’m investigating whether existing applications can use compute beyond their own machine—and when doing so is actually worth it.
Why should a device end at its own hardware?
When an application outgrows a laptop, the usual answer is another computer, a remote desktop or a version of the application built for the cloud. I’m interested in a different possibility: keep the application, and let selected computations reach resources elsewhere.
That question led me from workload orchestration into native execution: the point where an application asks a library or its host for a particular calculation. It also exposed a difficult distinction. Making a remote calculation work is not the same as making the application faster.
The layers I’ve explored
My early Fusion experiments described work explicitly as a graph: one calculation produces data that another consumes. That made it possible to measure where work ran, what moved between machines and how long a GPU took to become available.
Splice moves closer to existing programs by intercepting selected numerical calls. The AutoCAD experiments take a separate route through the application’s geometry interfaces. Alongside those, OBP investigates doing less work, ASPR investigates anticipating data demand, and ReSynth investigates moving fewer bytes.
The local machine is the competitor
Some of the largest improvements came before any network was involved. Avoiding an unnecessary intermediate calculation can save more than offloading it. In AutoCAD, a local Rust implementation was faster than the remote version of the same operation.
I still have a narrow positive result for a GPU whose input was already present. But fresh input, startup and checking can reverse that result. I now treat the best local implementation as the baseline, rather than assuming that a faster remote processor must be useful.
What works, and what is unfinished
I have working numerical components, selected native-call interception, CPU and experimental GPU execution, Windows-to-Linux exchanges, and geometry results returned into a live AutoCAD session. Each has a specific supported boundary; they are not evidence that arbitrary applications can already offload safely.
The AutoCAD work is not ready for student use. The first unfamiliar drawing can still require a slow comparison against the original calculation, and the installer does not yet deliver the geometry integration as a complete product.
The larger ambition
I want compute to become something a device can access, rather than only something fixed inside its case. Privacy and accessibility belong to that ambition too: reaching another machine should not require blindly trusting it or buying into an entirely different application.
The research is how I test that ambition. A local result, a remote result and a failed experiment each tell me something different about which part of the idea is worth pursuing next.
Technical details and evidence
The implementation work spans Rust, C/C++ interoperability, OpenBLAS/CBLAS, TCP object exchange, LZ4/Zstandard and experimental CUDA/cuBLAS execution. Linux native interception, Windows native execution and AutoCAD host integration have different supported interfaces.
The linked experiments distinguish startup, steady execution, host result consumption and complete-operation cost. They do not establish production readiness, universal application compatibility or confidentiality against a malicious execution host.
The full intersection operation measured three ways at 16,384 crossings
Technical details and evidence
- Experiment identifier
- cad-campus-nov10-128-complete
- Original title
- Matched complete-operation comparison, 16384 crossings
- Measurement boundary
- Identical integer route geometry and control points, the same geometry operation through the application automation interface, an empty output prefix and full numerical arrays in the original native order. The complete timer covers entity lookup, the geometry call and any interception, qualification, execution and transfer where applicable, automation marshalling, byte conversion and binary file output. It excludes process startup, installation and account sign-in.
- Hardware
- Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.
- Software
- AutoCAD 2021 R24.0.47.0.0; local candidate adapter build with an in-process Rust primitive; frozen remote adapter build.
- Input
- Owned integer route pair, 128 routes, 16384 crossings.
- Samples
- Native complete operation: 1 sample. Local warm: 3 samples (82.7683, 1209.915 and 123.1285 ms complete). Remote warm: 2 samples (1067.1995 and 1012.2782 ms complete).
- Statistical method
- median of warm samples; native is a single sample
- Cold / warm state
- Warm for the local and remote medians. The cold first-use cost is recorded as a separate experiment and is not folded into these rows.
- Network
- Local mode ran with no worker and no tunnel. Remote mode used an encrypted tunnel to the CPU node with a bounded local forwarding proxy that adds a small hop.
- Serialization
- The remote response used the compressed frame; the local path produced the result in process.
- Correctness checks
- Full arrays, unique complete integer-grid sets and output digests were asserted. The warm original-order difference stayed at or below 1.25e-11, with the largest observed value 7.275957614183426e-12 in the larger case. Warm local returns and alternating pairs made zero native calls.
| Original metric | Exact value | Samples | Statistic |
|---|---|---|---|
| native complete operation | 3970.8752 ms | 1 | single sample |
| local warm complete operation, median | 123.1285 ms | 3 | median of 3 samples |
| remote warm complete operation, median | 1039.73885 ms | 2 | median of 2 samples |
CALCULATED FROM THE MEASUREMENTSnative complete operation ÷ local warm complete operation, median = 32.249846×96.899210% lower time for local warm complete operation, median.
CALCULATED FROM THE MEASUREMENTSlocal warm complete operation, median ÷ remote warm complete operation, median = 0.11842253×744.43395% higher time for remote warm complete operation, median.
Experimental limitations
- Native is a single sample while the local and remote medians rest on three and two samples, so the comparison is indicative rather than statistically qualified.
- Sessions were sequential, not randomised.
- Synthetic fixed geometry precludes any general or student-performance statement.
- The retained local outlier of 1209.915 ms complete is one of the three recorded local samples and is not hidden.
- The remote adapter still used the older single-entry cache, and both warm medians compare already-qualified empty-prefix operations.
- The campus verdict for this work is NO-GO for a student campus demonstration; nothing here is a student-readiness statement.
The local candidate is the fastest path measured for this workload by a wide margin and the remote path is second. The gain comes from the implementation, not from placement.
The prepared path once it is warm and calibrated
Technical details and evidence
- Experiment identifier
- rt-prepared-s5-steady-eight-call
- Original title
- Prepared calibrated steady-state eight-call workload, ratio against the best eligible local baseline
- Measurement boundary
- 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.
- 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.
- Statistical method
- 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.
- Cold / warm state
- 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 checks
- 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.
| Original metric | Exact value | Samples | Statistic |
|---|---|---|---|
| prepared applied whole-workload wait, median | 0.228 ms | 30 | nearest-rank block median, 228 microseconds |
| prepared applied whole-workload wait, 95th percentile | 0.259 ms | 30 | nearest-rank block 95th percentile, 259 microseconds |
| best eligible local whole-workload wait, median | 0.211 ms | 30 | nearest-rank block median, 211 microseconds |
| best eligible local whole-workload wait, 95th percentile | 0.228 ms | 30 | nearest-rank block 95th percentile, 228 microseconds |
| median ratio against the best eligible local baseline | 1.0805687204 ratio | 30 | observed block median ratio against the 1.10 bound |
| 95th percentile ratio against the best eligible local baseline | 1.1359649123 ratio | 30 | observed block 95th percentile ratio against the 1.15 bound |
| paired mean-ratio interval, lower bound | 1.0469289615080855 ratio | 30 | 10,000 paired resamples at the fixed seed |
| paired mean-ratio interval, upper bound | 1.1081226992587965 ratio | 30 | 10,000 paired resamples at the fixed seed |
| measured calls | 1200 calls | 150 | 1,200 measured calls across 150 phase records |
| warm-up records | 450 calls | 150 | untimed warm-up records in the campaign |
| phase records | 150 blocks | 150 | phase records carrying eight measured calls each |
| calibrated measured rows with valid fresh profiles | 240 calls | 150 | profile ages between 120 and 438 microseconds |
| forced worker regions executed | 480 calls | 150 | the recorded 240 real regions on each of two forced worker arms, summed |
CALCULATED FROM THE MEASUREMENTSbest eligible local whole-workload wait, median ÷ prepared applied whole-workload wait, median = 0.92543860×8.0568720% higher time for prepared applied whole-workload wait, median.
CALCULATED FROM THE MEASUREMENTSbest eligible local whole-workload wait, 95th percentile ÷ prepared applied whole-workload wait, 95th percentile = 0.88030888×13.596491% higher time for prepared applied whole-workload wait, 95th percentile.
Experimental 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.
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.
Technical details and evidence
- Splice component identity and interception scope
- ReSynth component responsibilities
- Observation-Boundary Placement v2 specification
- ASPR + OBP v2: Dual Compute Intelligence
- Live intersection consumption and fallback engineering record
- AutoCAD campus-readiness engineering record
- Engineering gate ledger inspected 12 November 2026
CONCEPTUAL ARCHITECTURE
Two possible execution paths.
APPLICATION → INTERCEPTION → QUALIFICATION → PLACEMENT
Local execution / fallback → host application
Representation → transfer → worker → validation → host application
1 / Application execution
An existing native application continues to own its state. Supporting arbitrary applications is a goal, not a demonstrated capability.
2 / Selected interception
Capture an eligible native computation at an explicit boundary. Compatibility, memory layout and side effects must be understood first.
3 / Qualification
Check correctness constraints, supported inputs and whether capture, transfer and validation can plausibly pay for themselves.
4 / Placement
Compare local and remote paths. An optimized local implementation is an essential baseline, not an inconvenient result to omit.
5 / Representation & transfer
Represent inputs, account for serialization and transfer costs, and validate data versions. Residency and reconstruction are research directions.
6 / Remote worker
Execute the selected computation externally. A faster worker alone does not prove a faster end-to-end application.
7 / Validation & return
Validate results against the computation’s contract before the application consumes them. Recovery must not silently change semantics.
8 / Local execution & fallback
Keep work local when unsupported, unprofitable or disconnected. A fallback path must preserve correctness and application state.