BenedictNOTEBOOK / ENGINEERING JOURNAL
The work behind the work.
What I tried, what happened, and how it changed the next experiment—from early GPU work to calculations inside a live application.
Checking the cases that could break the geometry path
I compared complete returned arrays with AutoCAD’s original calculation in eight cases, rather than relying on matching digests.
I wanted to know whether the replacement preserved the caller’s behaviour, not just its coordinates. I tested an initial pair, a warm repeat, an existing output prefix, a duplicate prefix, endpoint contacts, reversed inputs and a document create-and-close.
The warm local results matched the original ordering within the test’s error budget without another native call. The prefix cases stayed native. The endpoint case was rejected by the local kernel and correctly returned to the original calculation. Changing documents forced another comparison, so I was not accidentally reusing an old approval.
All eight observed original statuses were successful. Errors, cancellation and more complicated drawing edits still need work. There is also no complete CAD installer or second-machine test. The result makes the supported calculation clearer; it does not make the application ready for students.
Technical details and evidence
The local path was the useful improvement
Inside real AutoCAD, warm local execution took about 123 ms and 297 ms at the two crossing counts. The remote path took about 1.04 s and 845 ms.
The question had moved beyond sending an array to a worker. I compared the original operation, my in-process Rust path and the remote path using one complete-operation timer: lookup, calculation, returning the array, conversion and binary output.
The local replacement was much faster than the original implementation, and faster than the same work sent remotely. This is an implementation result, not a benefit of distribution. The samples are small and sequential: one original measurement, three local samples and two or three remote samples. One local sample took 1.21 seconds; I did not discard it.
The first unfamiliar large geometry pair still took about 58 seconds for the local path to compare against the original. That minute matters more to the first user than a good warm median. I need to solve that cost before treating the work as a usable CAD product.
Technical details and evidence
Remote answers reached the live drawing session
Five warm intersection returns were consumed without repeating the native calculation. Stopping the worker returned the operation to AutoCAD’s original path.
The earlier bridge tests stopped before AutoCAD could use the answer. This time I used its geometry interface to return arrays from a remote worker into the live application. I wanted both the successful return and a useful failure path.
The returned arrays matched the native enumeration within the test’s error budget. A deliberately stopped worker produced the correct native array instead, and remote execution resumed after recovery. That answered a real integration question.
Some client-side exchanges still failed even when the worker calculated and sent a response. I have not isolated their cause. The first comparison for a large new drawing was also slow, and exporting points added time beyond the geometry call. This is a tested API path on generated drawings, not an ordinary interactive command ready for students.
Technical details and evidence
Would the curve result survive changing drawings?
Eight remote returns across three drawings succeeded without another native length call. The latency made this an integration result, not an acceleration.
A result that only works inside one prepared session is not enough. I generated separate drawings and compared their geometry with the original calculation before asking an ordinary LIST command to consume the remote answer.
The supported lengths returned correctly. Curved and weighted cases that disagreed stayed native. Stopping the worker also returned the calculation to the original path. One case labelled as a reconnection was actually another fallback; a new worker was needed before remote consumption resumed.
The successful hook time had a median near 570 ms, far beyond the tiny native calculations. A copy outside the approved drawing set also disabled interception for that process. These tests taught me more about state and recovery than about getting a useful speed improvement.
Technical details and evidence
Compression helped, but local was still far ahead
I measured the same captured intersection inputs locally and remotely before trying to return the answer into AutoCAD.
The uncompressed remote path was slow. I added lossless compression to the reply and repeated the tests as a separate run. At 16,384 crossings, the compressed bridge took about 9.4 ms locally and 857 ms remotely. At 65,536 crossings it took about 34.7 ms and 1.24 seconds.
The worker was doing the same calculation. Moving fewer bytes shortened the remote path, but did not make it competitive with running locally. These timers excluded capturing the application inputs and installing the result, so I did not divide the native API timing by the bridge timing and call it an application speedup.
I also tested bad and incomplete responses. Eight injected failure cases left the output untouched; a stopped worker failed without publishing a remote answer. Getting those behaviours right came before the live host experiment.
Technical details and evidence
- Captured-array intersection bridge benchmark, lossless-compressed run r2 (run: cad-usefulness-20261108-r1)
- Captured-array intersection bridge per-request progress log, compressed run r2 (run: cad-usefulness-20261108-r1)
- Captured-array intersection bridge benchmark, uncompressed run r1 (run: cad-usefulness-20261108-r1)
The dispatch machinery got close to direct local execution
With preparation already done, the small eight-call sequence added about 8% at the median and 14% at the 95th percentile.
I wanted to separate the cost of preparing a plan from the cost of repeatedly using it. I built and calibrated the plan before the steady measurement, then charged those earlier steps to a separate first-use measurement.
The prepared path took about 228 microseconds at the median against 211 directly. That stayed inside the overhead allowance I had chosen. It was still slower than direct local execution, and every automatic choice in the measured run was local. The two forced worker processes shared one host; they were not different kinds of hardware.
First use and the complete experiment were much more expensive. The uncertainty interval also prevented a universal overhead guarantee. I had made one small steady path acceptably close to local—not made setup free or demonstrated a remote-placement win.
Technical details and evidence
Removing work mattered more than moving it
The large local gains came from avoiding unnecessary intermediate results. The stronger library baseline changed what I could conclude.
At n=2048, reordering a matrix–matrix–vector calculation reduced about 210 ms to 4.6 ms on my laptop. But NumPy multi_dot took about 4.57 ms. I had shown the cost of materializing an unnecessary intermediate, not beaten the best existing contraction path.
Calculating only the requested slice was another large saving, but only when the other entries genuinely went unobserved. Reusing an immutable result was useful too; scanning untracked inputs made the same idea more expensive.
The prediction work raised a different problem. Individual precision and recall did not mean a complete input set was ready. The local overhead tests and synthetic-trace simulations stayed separate from real remote execution. This pushed me toward comparing the best legal local calculation before asking another machine to run anything.
Technical details and evidence
Already having the input changed the result at one size
The persistent GPU lost on the smaller resident input and won on the larger one. Fresh input transfer was outside both comparisons.
I kept the input in GPU memory and reused the same running process. At 4,096 values, local wall time was about 666 ms against 805 ms remotely. At 262,144 values, local was about 2.99 seconds and remote about 931 ms.
The larger case is a real resident-stage win. The smaller one stops me turning it into a general claim. Each is one observation, not a completed repeated campaign.
A separate fresh transfer of roughly 5.3 MB took about 39 seconds. The remote calculation only looks attractive when I say what is already present and what the user still has to wait for.
Technical details and evidence
The first correct local-to-GPU-to-local run
The chain returned the expected answer. Its recorded total did not establish a useful speedup.
I ran the first stage locally, staged its input for an external GPU and brought the result back for the final local stage. The answer passed the numerical comparison. That established a working path through the three stages.
The recorded total was about 288 seconds against 145 locally. A later reading identified roughly 155 seconds of local reference work inside the Fusion timer, used to check correctness. The total therefore is not a clean production-latency comparison.
I could make the heterogeneous calculation work without making the case for using it. That distinction stayed important in the later native execution and AutoCAD work.