When software hits the limit, we move the limit.

Optimization through the computing stack A sequence moves through grouped performance intervention domains: product architecture, data and execution, runtime and toolchain, operating systems, machine architecture and custom hardware. 1 s 100 ms 10 ms 1 ms 100 µs 10 µs PRODUCT AND ARCHITECTURE DATA AND EXECUTION RUNTIME AND TOOLCHAIN OPERATING SYSTEM AND SERVICES MACHINE ARCHITECTURE CUSTOM HARDWARE Workflow / productdelete redundant workflow steps System / distributioncollapse synchronous service hops Algorithmhoist invariants out of hot loops Data model / query planpush predicates into storage scans Data structure / access patternreplace scans with indexed lookups Allocation / garbage collectionreuse arena storage in hot paths Data layout / localitypack hot fields into contiguous arrays Concurrency / synchronizationshard locks; remove contention Language runtime / virtual machinespecialize hot-path dispatch Compiler / code generationfuse and vectorize hot kernels Storage / filesystem / I/Obatch I/O; eliminate seeks and copies Network / interprocess callscoalesce RPCs; compress wire payloads Operating system / schedulerbatch syscalls; keep state in kernel Instruction set / vector executionpack data into SIMD lanes Microarchitecture / cache / memorytile working sets to fit cache Graphics processor / acceleratormap independent work across GPU lanes Reconfigurable logic / FPGApipeline a dedicated datapath Application-specific silicon / ASIChardwire the critical datapath
From product architecture down to custom silicon, if we have to.

01 / The premise

Most people have learned to wait.

Wheels spin, loading bars creep, we all agree that computers are slow.

But usually, software creates the delay. Hardware that can perform billions of operations a second sits idle through a disk seek, network round trip, unnecessary copy or expensive abstraction. We measure the complete operation, find exactly where the time goes and remove the cause. That's how seconds become micro- or nanoseconds.

02 / Work across the stack

The limiting layer changes from project to project.

01 / rstat

From 800 milliseconds to 160 microseconds.

rstat is a Linux monitor that supplies CPU, memory and per-process data to a desktop status bar. It replaced a shell module that took roughly 800 milliseconds to produce one update.

A long-running Rust collector retained state between updates. Replacing the blocking power-profile service call with a direct Linux sysfs read and collapsing three Linux process-filesystem (procfs) walks into one brought each update down to 15 milliseconds. An extended Berkeley Packet Filter (eBPF) program then moved recurring process accounting into the kernel, leaving 0.16 milliseconds of userspace work on average.

Read the case study
Shell + service call ~800 ms
Direct sysfs + procfs ~15 ms
eBPF userspace refresh 0.16 ms avg
0.1 ms1 ms10 ms100 ms1 s
The refresh fell from roughly 800 to 0.16 milliseconds: a 5,000-fold reduction.

02 / Archivist

222,242 entries, live in 420 milliseconds.

Archivist is a desktop frontend for curating, verifying and launching a large video-game archive. Its interface needed 222,242 filesystem entries ready before browsing began.

Archivist's Rust backend builds one compact snapshot for the browser-based interface. Parent indices replace repeated path strings, and aligned columnar arrays replace one object per entry. The backend compresses the snapshot for transmission. The browser reconstructs paths and reads numeric columns in place.

Read the performance article
Uncompressed snapshot layout12.296 MiB benchmark snapshot
Header metadatasmall irregular MessagePack record Parent indicesreplaces repeated paths Aligned field columnsone structure-of-arrays column per field Basename blobNUL-separated UTF-8
The Rust backend compresses the complete snapshot with gzip for HTTP transport
4.70 MB live response51 ms browser fetch
1DecompressionStreambrowser-native streaming gzip
2Typed-array viewsnumeric columns are viewed in place
3One UTF-8 decodebasenames are reconstructed through parent indices
The browser applies all 222,242 entries 420 milliseconds after requesting the snapshot. In parallel, the backend decodes its own resident copy in 174 milliseconds.

03 / OpenZT2

During gameplay, OpenZT2 doesn't load assets slowly or quickly—it just doesn't load them at all.

OpenZT2 is a clean-room, native reconstruction of Zoo Tycoon 2. Its engine needs an entire game's converted assets without copying them through a conventional runtime cache.

A launcher converts source assets into an immutable, versioned content pack laid out in the same binary form the Rust engine reads. The game maps the pack into its virtual address space, validates typed references into those mapped bytes and asks Linux to preload selected page groups within an available-memory budget.

Visit OpenZT2
Native content packversioned records in the engine's Rust layout, with aligned payload ranges
read-only memory map
Process address rangethe virtual addresses exist before any payload page is read
1 / Choose pages to preload

The preload routine walks the requested asset groups and stops at the available-memory budget.

2 / Fault selected pages

Touching selected payload pages asks Linux to populate those 4-KiB pages in the kernel page cache.

3 / Read typed records in place

Validating the mapped archive returns typed Rust references into the memory mapping. Payload bytes aren't copied into a separate heap cache.

After the selected pages are resident, asset hydration performs no file-open or read system calls. Untouched pages remain available through Linux's normal demand paging.

04 / Rake In flight

SIMD the compiler must prove.

Rake is an experimental, vector-first language for structure-of-arrays kernels. A rack is one target-sized vector of values, and a pack supplies the complete column storage and runtime count. The same source is intended to traverse four-lane NEON or SSE2, eight-lane AVX2, or sixteen-lane AVX-512 racks without spelling out width-specific intrinsics.

Rake asks whether machine shape can be a checked requirement. C, Rust and ISPC can emit excellent SIMD; Rake's narrower experiment makes selected physical properties conditions of compilation. Its current AVX2 and NEON slices reject supported kernels that would split or scalarize a rack, call a helper, or spill a live rack. Fused names are transparent dataflow aliases, so an ordinary multiply-add graph inside a fused region currently becomes one verified FMA where the target provides it. Native pack traversal, broader algebraic rewrites, more CPU profiles and SPIR-V remain in flight.

Visit Rake
Fused dataflow in source crunch advance(positions: f32s, velocities: f32s) -> f32s:
  | scaled: f32s <| velocities * <0.5>
  | result: f32s <| positions + scaled
  return result
Language contractProfiles fix rack width. Angle brackets expose scalar broadcasts; fused names add readability without imposing storage or rounding boundaries.
Verified loweringTyped vector SSA preserves rack identity, explicit broadcasts, masked safety and fused regions while the selected profile is legalized.
Target machineToday, instruction selection and no-spill allocation produce the promised CPU register shape—or compilation fails. GPU subgroup lowering remains proposed.
Native backends todayx86-64 AVX2 · AArch64 NEON
Rake owns CPU instruction selection, register allocation and textual assembly, then verifies the encoded object. SSE2, AVX-512 and Vulkan subgroup profiles are planned extensions of the same fail-closed machine contract.

03 / Extreme engineering range

Whatever layer the problem requires.

Software

Business applications, native products, algorithms and data layout.

Systems

Storage, databases, networking, compilers and operating-system kernels.

Compute

Vector instructions, instruction-set architecture, programmable logic and application-specific silicon.

Silicon

Semiconductor and physical constraints when software is no longer the boundary.

Have a performance problem that has survived the usual fixes?

Let’s find the real limit. Sydney, Australia · Working worldwide