9Rust for Low Latency

The Rust twin of this book’s feed decoder decodes a message in about eleven nanoseconds on this laptop, within a fifth of the C++ original from one run to the next. Both check every length before reading, neither allocates per message, and the Rust version was written without a single unsafe block. What Rust changes is not speed but where mistakes are caught: a data race or a dangling reference is a compile error, an out-of-bounds index a controlled panic instead of a silent read of someone else’s memory. This chapter looks at Rust on the hot path the way chapters 6 to 8 looked at C++: which abstractions really cost nothing, where the checks are and when the compiler removes them, how to write unsafe code that stays sound, how to control allocation and threads, and where Rust’s async machinery belongs in a trading system and where it does not.

9.1 Zero-cost abstractions, checked

Iterators, closures, generics and Option are designed to be zero-cost in Rust: they are monomorphised like C++ templates and inlined. The claim is checked the same way as in chapter 7, in the assembly. Safe Rust adds one thing C++ does not: every slice index is checked against the slice’s length.

Listing 9.1 is the assembly of a loop for i in 0..v.len() { s += v[i] } compiled by rustc -O: no comparison against the length and no call to the panic handler remain, and LLVM has vectorised the loop four elements at a time. Listing 9.2 reads one element at an index the compiler knows nothing about: a comparison, a predicted branch, and the panic path out of line. When the check cannot be removed it costs little, as long as it is predicted and the load it guards is the slow part: in Figure 9.1 a gather of 65 536 elements through a table of scattered indices costs the same, within noise, with and without the check, in both languages.

	test	rsi, rsi
	je	.LBB16_1
	cmp	rsi, 4
	jae	.LBB16_5
	xor	eax, eax
	xor	ecx, ecx
	jmp	.LBB16_4
.LBB16_1:
	xor	eax, eax
	ret
.LBB16_5:
	mov	rcx, rsi
	and	rcx, -4
	pxor	xmm1, xmm1
	xor	eax, eax
	pxor	xmm2, xmm2
	pxor	xmm0, xmm0
.LBB16_6:
	movq	xmm3, qword ptr [rdi + 4*rax]
	movq	xmm4, qword ptr [rdi + 4*rax + 8]
	punpckldq	xmm3, xmm1
	paddq	xmm2, xmm3
	punpckldq	xmm4, xmm1
	paddq	xmm0, xmm4
	add	rax, 4
	cmp	rcx, rax
	jne	.LBB16_6
	paddq	xmm0, xmm2
	pshufd	xmm1, xmm0, 238
	paddq	xmm1, xmm0
	movq	rax, xmm1
	jmp	.LBB16_8
.LBB16_4:
	mov	edx, dword ptr [rdi + 4*rcx]
	inc	rcx
	add	rax, rdx
.LBB16_8:
	cmp	rsi, rcx
	jne	.LBB16_4
	ret

	push	rax
	cmp	rdx, rsi
	jae	.LBB15_1
	mov	eax, dword ptr [rdi + 4*rdx]
	pop	rcx
	ret
.LBB15_1:
	lea	rax, [rip + .Lanon.3be006c39583d7e749c2975be3997e3f.5]
	mov	rdi, rdx
	mov	rdx, rax
	call	qword ptr [rip + _RNvNtCs4NRVxsYgnAr_4core9panicking18panic_bounds_check@GOTPCREL]
	ud2

9.2 Unsafe code and its boundaries

Rust’s guarantees hold for safe code; unsafe blocks are where the programmer takes over the compiler’s proof obligations: dereferencing raw pointers, calling C functions, skipping bounds checks, implementing lock-free structures (chapter 11).

The discipline is to keep the unsafe region small and to write down, next to each block, why it is sound. The gather of Listing 9.3 skips the per-element check only after the indices have been validated once, and refuses a slice whose length is not the one they were validated against: however it is called, it cannot read out of bounds. A function whose safety depends on its caller is itself marked unsafe, with a # Safety section stating the contract; clippy rejects a public function that dereferences a raw pointer argument without it. The same questions apply to C++ code, where every line is unsafe; Rust makes them local.

/// A sound abstraction over the unchecked gather: it validates the indices once, then gathers without checks.
pub struct CheckedIndex<'a> {
    idx: &'a [usize],
}

impl<'a> CheckedIndex<'a> {
    pub fn new(idx: &'a [usize], len: usize) -> Option<CheckedIndex<'a>> {
        idx.iter().all(|&i| i < len).then_some(CheckedIndex { idx })
    }
    pub fn sum(&self, v: &[u32], len: usize) -> Option<u64> {
        // The indices were checked against `len`; refuse a slice of another length rather than trust it.
        // SAFETY: every index < len == v.len().
        (v.len() == len).then(|| unsafe { sum_gather_unchecked(v, self.idx) })
    }
}

9.3 Controlling allocation

Rust’s standard types allocate in slightly different places from C++’s, and the differences matter on a hot path. A String has no inline buffer, so even a four-letter symbol allocates; a Vec reserves room for four small elements at its first push, so three fills cost one allocation instead of three; HashMap::entry moves the key into the map instead of copying it. Counted with firm_arena::CountingAlloc, the Rust version of chapter 6’s first-draft handler (Listing 9.4) allocates five times per message where the C++ one allocated nine, and the fixed version none. The remedy is the same as in C++: fixed arrays, pools of indices, byte arrays for identifiers, no boxed closures on the hot path, and a test that asserts the count.

impl NaiveHandler {
    pub fn handle(&mut self, symbol: &str, client_id: &str, fills: &[Fill]) -> usize {
        let sym = symbol.to_string(); // a String always allocates (no inline buffer)
        let cid = client_id.to_string();
        let mut fs = Vec::new(); // the first push reserves room for four fills
        for f in fills {
            fs.push(*f);
        }
        *self.state.entry(cid).or_insert(0) += fills.len() as u32;
        let copy = fs.clone();
        self.on_done = Some(Box::new(move |_| copy.len() + sym.len()));
        self.on_done.as_ref().map_or(0, |f| f(&fs))
    }
}

9.4 Threads, pinning and what the type system guarantees

The chapter’s crate carries a documentation test marked compile_fail: a thread that increments an element of a vector while its owner also writes it. The test passes only if the compiler rejects the program, which it does, because the spawned thread borrows the vector mutably while it is still in use. What the type system does not provide is placement: the standard library cannot pin a thread to a CPU. firm.affinity declares the two C functions it needs, calls them inside unsafe blocks with the reason stated, and verifies the result with sched_getcpu (Listing 9.5); its C++ twin does the same with pthread_setaffinity_np. Both read the role-to-CPU plan that firm.coreplan writes (chapter 4).

pub fn pin_current(cpu: usize) -> Result<(), String> {
    if cpu >= SET_WORDS * 64 {
        return Err(format!("cpu {cpu} out of range"));
    }
    let mut set = CpuSet { bits: [0; SET_WORDS] };
    set.bits[cpu / 64] |= 1u64 << (cpu % 64);
    // SAFETY: `set` is a live, properly sized cpu_set_t; pid 0 means the calling thread.
    let rc = unsafe { sched_setaffinity(0, std::mem::size_of::<CpuSet>(), &set) };
    if rc == 0 { Ok(()) } else { Err(format!("sched_setaffinity({cpu}) failed")) }
}

9.5 Where async does and does not belong

Async code is how Rust serves many slow connections cheaply, and a trading firm has many: venue REST interfaces, websocket market data from dozens of crypto venues (chapter 17), drop-copy sessions, internal services. The hot path is the opposite case: one busy thread per role, pinned, spinning on its input, never yielding. A scheduler that may move a task between threads, or delay it behind another, adds exactly the jitter the hot path exists to avoid. The authors of the most widely used runtime say so themselves: it is designed for applications whose tasks spend most of their time waiting for input and output, not for speeding up computation. The usual split is a synchronous, pinned hot path, fed and drained by lock-free rings (chapter 12), with async services around it for everything that can wait.

9.6 Tutorial: the Rust twin, measured

9.7 Build: thread placement by role

9.8 Exercises

9.9 Problem: The Port

9.10 Interview questions