These public projects explore performance, capacity, deployment, resource allocation, cache reuse, remote-change recovery and uplink failover. I start with a constraint, build something to examine it, and measure what happens. Follow a question to the evidence, the full article or the code.
The models and measurement methods have different scopes. Their numbers are not a ranking across projects.
Faster code. How do we know it still does the work?
What I built
I built a small C inference engine with a system-BLAS path, then added a same-model comparison across six backends and independent numerical checks.
Experimental evidence
Across five batch sizes, all six backends agreed on every class for 450 held-out examples, scoring 438/450 (97.33%). Probability outputs also passed checks against an independent float64 reference.
Measurement scope
Apple M5 Pro; a 64→32→10 Digits model. Timings cover warm, probability-producing Python-facing APIs.
How to read the result
Amortized time per example is not individual-request latency, and process RSS is not model-only RAM. The fastest backend changes with batch size; handwritten C has no universal win.
02 / Memory & capacity
tiny-arena-lab
Can tensor reuse make a workload fit?
What I built
I built a C11 memory planner and graph executor that reuse storage according to tensor lifetimes, with checks on intermediate values, actual addresses and deliberately injected faults.
Experimental evidence
At batch 16, the tensor arena fell from 8,832 to 6,144 bytes—about 30.4%—and inference completed within a configured 7 KiB arena budget. Both layouts agreed on every class and scored 438/450 (97.33%).
Measurement scope
A host experiment on Apple M5 Pro, comparing separate storage with lifetime-based reuse using the same Digits weights, schedule and kernels.
How to read the result
Arena storage is not total program RAM. The 7 KiB budget is an experiment setting, not a measured MCU limit. Observed timing ranges overlap: this demonstrates capacity feasibility, not a reliable speedup.
03 / Deployment & measurement
inference-doctor
CoreML was enabled. Did inference actually get faster?
What I built
I built an ONNX deployment diagnostic tool that checks outputs, times synchronous inference calls, measures worker RSS and reports the available execution-provider evidence and its gaps.
Experimental evidence
CPU EP had shorter warm inference times at all four tested maximum batch sizes. Both EPs agreed on every class and scored 436/450 (96.89%); logits and probabilities also passed reference checks.
Measurement scope
Apple M5 Pro; one small Digits ONNX model and 450 held-out examples. Maximum batches were 1, 16, 64 and 128, with short final batches fully executed and checked.
How to read the result
This compares deployment paths, not the theoretical power of CPUs and GPUs/NPUs. Enabling a provider does not prove Neural Engine use. Worker RSS excludes CoreML helper processes and device memory.
04 / Resource allocation & fairness
tiny-fair-proxy
Should more connections mean more bandwidth?
What I built
I built an experimental Rust TCP relay with bounded payload buffers, backpressure and tenant-weighted byte scheduling to compare per-connection and per-tenant allocation.
Experimental evidence
Three randomized paired blocks, 24 trials. With equal weights, one connection for A and four for B, A’s median share in the common receiver window was about 20% with connection scheduling and 50% with tenant scheduling. Overall throughput, including tails, was broadly similar.
Measurement scope
Native macOS ARM64 loopback; 512 KiB per connection and a shared 512 KiB/s cap in each direction. Receiver shares cover 0.4–1.4 seconds after the common start; listeners classify tenants in a trusted local environment.
How to read the result
Window shares are not total-payload shares, instantaneous ratios or request-latency guarantees. Listener classification is not authentication. Bounded payload buffers do not bound whole-system memory; sampled proxy RSS excludes peers and kernel socket buffers.
05 / Caching, routing and expiry
tiny-dns-router
When can a cached DNS answer be reused?
What I built
I built a local DNS forwarding service in Python with suffix routing, positive and negative caching, capacity limits and timeout failover.
Experimental evidence
In the repeated-query UDP workload, caching disabled and enabled each had three trials. The median of trial p50 latencies fell from 7.33 to 0.69 ms; median upstream queries fell from 120 to 4.
Measurement scope
Native macOS loopback with a controlled 6 ms upstream delay. Each trial began with an empty cache and scheduled 120 queries, one every 3 ms, reusing four query keys. Latency runs from actual client invocation through response validation, excluding pre-send scheduling wait.
How to read the result
Unique queries showed limited benefit. TTL limits reuse time; it does not guarantee freshness or correctness. Colima Linux results are reported separately. This does not establish Internet performance or maximum throughput; there is no DNSSEC validation, and cache limits are not a hard process-RAM limit.
06 / Remote changes & recovery
rulemoor
After a firewall change, can the operator reconnect?
What I built
I built an experimental remote Linux firewall service with management-port preflight, fresh TLS confirmation and recovery. Opt-in Boot Guard checks the journal and both policies before enabling a designated interface.
Experimental evidence
The same source passed 132 portable tests on each of macOS and Linux, plus 12 actual-systemd/Linux VM phases including setup and cleanup. With a real EISDIR receipt-write error, tested cleanup and stop paths still attempted close and read back DOWN.
Measurement scope
Explicitly enabled isolated namespace, static veth and exclusive interface-activation ownership. Two orderly VM restarts covered pending-baseline and committed-policy recovery. The old executor retired before successor admission; readbacks and probes are finite samples.
How to read the result
Interface operations can fail; a stale OPEN receipt is not readiness. Pre-UP checks do not cover every fault. Real disk exhaustion, sudden power loss, physical NICs, WAN, general network managers and whole-host early-boot zero-gap protection remain untested. Keep independent recovery access.
07 / Uplink failover & health evidence
uplinkstead
Failover switched. Which new requests recovered?
What I built
I built an opt-in dual-DHCP Linux IPv4 service with independent leases and path-bound TLS probes. A privileged writer validates proposed changes, with hysteresis and a persistent switching budget.
Experimental evidence
Retained same-source records: 295 portable tests on each of macOS and Linux, six installed-service upstream blackhole/recovery cycles, and 268 resource samples over about nine minutes with unchanged writer, worker and both DHCP-client identities.
Measurement scope
Isolated Linux VM, controlled DHCP/TLS servers and namespaces sharing one kernel. Fresh LAN TLS succeeded on the expected alternate path; stop/start was tested separately after sampling. The final same-client series used slower renewals to stay below the 64-transaction session cap.
How to read the result
Configured-target reachability does not establish Internet-wide or business-service health. Existing flows may break; budget exhaustion can block another switch. Long-term session rollover, physical ISPs, general DHCP interoperability, sudden power loss and boot-zero-gap remain unqualified. Short sampling does not prove leak freedom.
INTERACTIVE EXPERIMENTS
Interactive experiments
Illustrative teaching model
What changes a shot of espresso?
Change the grind, temperature or pressure, then watch the modeled flow and yield respond.