over|yonder Get in touch ↗
Menu

We make tech faster

Performance engineering across software and hardware, from application code to silicon.

Optimization through the computing stack An illustrative optimisation path through the computing stack. Each fix, from product architecture down to custom hardware, cuts the time per operation further, from about one second towards ten microseconds on a logarithmic scale. A dashed line separates the fixes made in software from those that build new hardware. Software ↑ Hardware ↓ 1 s 100 ms 10 ms 1 ms 100 µs 10 µs Time per operation after each fix 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
Each step down the stack cuts the time per operation. We stop at the level where the problem is solved.

Selected engineering work

rstat

eBPF Linux system monitor for sub-millisecond CPU, memory and process telemetry.

Read the case study ↗
Shell + service callStarted command-line tools and waited on the power-profile service for every update.
~800 ms
Rust procfs collectorKept state in memory, read power directly and combined three process scans into one.
~15 ms
eBPF collectoreBPF accounts during scheduler events, and userspace reads the accumulated counters in one batch.
0.16 ms avg
0.1 ms1 ms10 ms100 ms1 s

Time per update, log scale

Rake

Rake is our vector programming language for calculations that apply the same operation to many values at once. Its compiler selects the vector instructions and checks the generated machine code.

If a calculation can’t stay vectorised under the selected profile, compilation fails. Explicit slow { … } blocks mark scalar work, so the programmer can see where those checks stop applying. The source stays focused on the calculation, and the compiler guarantees the vector code.

Read the Rake walkthrough ↗
Scalar CGCC’s automatic vectoriser disabled.
4.003 ms
Automatically vectorised CGCC chooses vector instructions for the loop.
0.147 ms
C with AVX2 intrinsicsHand-written vector operations and tail handling.
0.146 ms
RakeCompiler-generated AVX2 loop with verified vector instructions.
0.147 ms
012345 ms

Time per million values, linear scale

Square roots of non-negative inputs, zero otherwise. Ryzen 7 5800X3D, AVX2, GCC 14.3, 5 October 2026, with other work keeping all 16 threads busy. Medians of 31 samples, each averaging four passes, with execution order rotated. Measurement details and benchmark sources.

If a performance problem has survived the usual fixes, send it our way.

Let’s speed things up. ↗ Sydney, Australia · Working worldwide