A 10 nanosecond actor hop on a 7 microsecond CME path

A thread wakeup, rather than actor messaging itself, carries most of the cost in Maciejewski's measurements. A ping/pong round trip between actors on separate cores has a median of about 3370 ns. Put both actors on one thread and it falls to 90 ns. Replace the mailbox push/pop with an inline synchronous call and the amortized figure reaches roughly 30 ns. Grouping eliminates the thread hop; the inline call also removes the queue.

The paper calls this synchronous delivery operation fast_send. The sender acquires the receiver's exclusive-access lock, executes its handler inline on the sender's stack, and receives the reply as a value. Receiver transparency separates the mechanism from an ordinary locked method call. Both delivery modes use the same handler, which routes its reply through the same operation. Even on the synchronous path, the reply value is heap-allocated, preventing allocation behavior from revealing the mode. The handler cannot learn which thread is executing it or whether the sender is blocked.

Cycles create the immediate danger. If A calls B and B calls A, a non-reentrant lock deadlocks, while a reentrant lock eventually exhausts the stack. Each thread therefore records a thread-local call chain. Before acquiring any lock, a synchronous send checks whether the receiver is already a member. Algorithm 1 gives the complete check. Three other pieces surround fast_send: actor groups whose members share one mailbox and thread, four selectable MPSC mailbox implementations, and a fixed-size memory pool.

The applied study follows a live CME MDP 3.0 multicast path from socket to book. It covers ES, NQ and ZN book and trade streams: 8.29 million messages during 53 minutes of one afternoon on 2026-09-16, all on one machine. Every message receives two software timestamps, one at socket read and one at book publish. At queue length zero, the fitted model is a floor plus a slope for in-packet position. Across six streams, the floors range from 6.81 to 7.23 microseconds and remain within 0.42 microseconds of one another. The per-message slope stretches from 312 ns/msg for NQ book to 966 ns/msg for ZN book. Against a roughly 7 microsecond floor, a fast_send hop is about 10 ns and a bare devirtualized call about 1 ns.

We could not test any of this. We have no exchange-colocated CME feed handler and no packet-capture timestamps. A bar-level backtest would exercise neither fast_send nor tick-to-book latency.

What the microbenchmarks establish

The benchmark host is an AMD EPYC 9374F running RHEL 9, pinned with taskset to two cores. Results are the median of three runs, with one message in flight, so each observation measures latency instead of throughput. The author says explicitly that only the ratios between rows are reproducible. Hardware, allocator, placement and turbo state all affect the absolute values. In the queue comparison's single-cross-thread-message regime, placement by itself changes cost by 2.2x. That swing exceeds the spread among the four queue types in the same regime.

Acquiring the mailbox lock once and draining the full queued burst lifted asynchronous throughput from 5.5 to 8.96 million round trips per second. Adding the pool took it to 13.6 million, or about 74 ns per message. Sender-side batching reached 11.3 million because producer and consumer became serialized.

Batching belongs on the drain side.

The pool matters more in the tail. Its amortized cost declined from about 128 ns to 92 ns. In a separate run, the maximum round trip dropped from 5.5 ms to 33 microseconds.

The missing fast_send percentile

Section 6 treats the tail as the figure of merit for an HFT path. Yet the fast_send measurements are amortized totals because the host's steady_clock has a resolution of about 10 ns. At a 30 ns round trip, any per-sample percentile is bound by that resolution, as the author directly acknowledges. The paper consequently reports no per-sample percentile for fast_send, despite setting the tail as its own criterion.

Reported tails cover the entire decode-and-book stage. ES book records p50 7.1, p99 18.5, p99.9 41.2 and a maximum of 1148.4 microseconds across 2,861,519 messages. NQ book reaches a maximum of 5567 microseconds. For ZN trade, p99 is 14.2x the median; for NQ book, the multiple is 1.9x.

The paper attributes those tails to the feed. Latency rises linearly with in-packet position. In a 45-message packet, the last message carries 44 times 0.57, roughly 25 microseconds, above the floor. Another message precedes 99.3 to 99.6% of trade-stream messages within the same packet. Queue backlog has a convex effect, though it appears rarely. ES book rises from 6.9 microseconds with an empty ring to 16.6 with six packets waiting. A qlen at or above three occurs for 0.08% of ES book messages (2,311 of 2,861,519).

The under-1% figure comes from arithmetic, not a measured difference. It takes a per-hop cost in nanoseconds, multiplies it by an asserted hop count of a few, and divides the result by the whole-stage floor in microseconds. We did not find an ablation that substitutes direct calls for fast_send within the same decode-and-book path and reports the resulting difference. That measurement would settle the point. We also did not find a head-to-head comparison with CAF, a hand-written lock-free pipeline or a kernel-bypass stack on this hardware and workload.

Judgment calls remain

The paper offers five delivery operations with different sender behavior under contention: plain asynchronous send; sleep-blocking fast_send; spinning fast_send_spin; non-blocking fast_send_x, which raises an ActorBusy exception; and best-effort fast_send_void, which falls back to async delivery. An adaptive variant, described separately, spins for a bounded count before blocking. Prose guidance leaves the choice at each call site to the programmer.

Cycle detection introduces a second policy choice with semantic consequences. Permissive (actor, message-class) keying allows genuine callbacks. The paper openly says this relaxes single-threaded state mutation and returns responsibility for reentrancy safety to the programmer. A third choice concerns ordering. Because fast_send executes ahead of work already queued in the receiver's mailbox, callers requiring FIFO relative to other senders must take the asynchronous path.

The queue heuristic is the easiest of the four because the measurements distinguish the options. Under fan-in, ShardedBQueue posts p99 of 6.6 microseconds against 69.9 for BQueue. In the bursty single-producer regime, BQueueBatched records 584.9 ns/msg against 605.8. LockFreeMPSC delivers the best grouped median at 70 ns. Its grouped maximum, however, ranges from 14 to 16 microseconds, compared with BQueue's 2.4 to 9. The author therefore does not make it the default.

The author labels two claims as unproven, and they deserve that status. The suggestion that actors suit LLM code generation remains a design hypothesis without an evaluation. Production/simulation duality is argued from the single shared group queue. We did not find a replay-equivalence experiment demonstrating it.

The strongest live result

The floor's indifference to load is the hardest part of the study to dismiss. During an FOMC release, packet rate jumped 4.6 to 9.8x within a second. The floor moved by at most +0.4 microseconds and declined on two of three instruments. This is how a servicing stage should behave, and the paper measures the behavior on live traffic rather than merely asserting it.

A hot-actor contention run would change my view of the broader HFT suitability claim. fast_send keeps the receiver's lock throughout the handler and blocks the sender for that duration. The author identifies the missing evidence himself: acyclic blocking and lock contention remain the developer's burden, while saturated, multi-axis evaluation is ongoing work. Even so, his conclusion reaches the suitability verdict ahead of that evidence, using a live path where the ring is empty 87 to 99.7% of the time.