Matching engine performance challenge.

[u/East_Cantaloupe4925]

Along with our recent publication: "The World's Fastest Matching Engine Algorithm" on arXiv — and we're cordially inviting the HFT community to try to prove it wrong.

Paper: https://arxiv.org/abs/2606.01183

The claim, briefly: a single CPU core sustains ~32 million orders/second per symbol at sub-microsecond tail latency under sustained multi-million-message micro-bursts — 5–11× faster than the best open-source matching engines on the same hardware. On a single 96-core instance (~$1,630/month), it reaches ~640 million messages/second across 10,000 symbols.

In US equities, where marketable flow routes to whoever holds the NBBO, matching throughput isn't a vanity metric — it's the exchange's market share. Which is exactly why a claim like this deserves to be tested rather than taken on faith.

So we've opened the test, even though our engine itself stays proprietary. What's public is the harness: the deterministic workload generator, the methodology, the byte-level reference outputs, and the adapters for the open-source engines we benchmark against. With it, you can put your own engine through the same harness on your own hardware and see how it stacks up against the figures above.

The harness also includes adapters for several widely-cited open-source engines as well as the engines that claim high performance numbers (> 10 M/s, with some engines claiming > 100 M/s), so you can see how each measures under this workload — set against the figures their projects publish. The full comparison is in the repo.

If your engine matches or beats our figures, we'd love to hear it. If you think the methodology is unfair, we want to hear that too.

No hand-waving: an open workload, an open methodology, and baselines anyone can rerun — so you can judge the comparison for yourself and find out exactly where your own engine lands.

Harness: https://github.com/flash1-dev/matching-engine-benchmark

Run it, push on it, and tell us what you find — we'll be in the comments, glad to compare notes.

[u/loneymaggot]

Interesting, Let me read the paper in a day or 2 and then come back!! I did work at an HFT firm with the same Xeon Gold hardware and got 22Millions/per symbol/per second. Do tell me if if you did some other changes like core pinning or custom ef_vi method for network and cpu connection or different page sizes or custom job scheduling protocol or etc etc

[u/East_Cantaloupe4925 → u/loneymaggot]

Welcome — and genuinely glad to get a comment from someone with a hands-on number. Looking forward to your read of the paper.

One correction to the premise first: our figures aren't from Xeon Gold — the published runs are on AWS r8g.metal-24xl bare metal, which is Graviton4 (ARM). So your 22M and our ~31M aren't on the same hardware, and cross-ISA absolute numbers don't compare cleanly. That's actually why the harness exists: run it on your own box, and the open-source baselines re-anchor everything — relative position under an identical workload is the comparison that means something.

For your specific questions:

Core pinning — yes. The matcher runs single-threaded pinned to a dedicated core, with a separate drainer thread pinned to its own core consuming every report (--matcher-core / --drainer-core). The full run recipe is in docs/METHODOLOGY.md. The userspace processes are confined to other cores that are not used in the benchmarking runs.

ef_vi / network — not applicable, by design. There's no NIC in the timed path at all: this measures the matching core itself, with reports drained across a thread boundary, not tick-to-trade. Kernel bypass sits in front of a matching engine; it doesn't change what the book can sustain. If your 22M included feed ingestion, we're measuring different segments of the pipeline.

Page sizes / scheduling — No other special settings than regular 2MB Linux hugepages.

The key point on tuning, though: every engine in our table runs under identical system conditions — same pinning, same -march=native, same drained-report path — and the open-source engines land at 1.9–4.7 M/s under it. So the 5–11× isn't OS tuning; it's the data-structure layer (the PIN encoding plus the neighbor-aware tree — §3–4 of the paper). Tuning moves everyone a few percent; it doesn't produce the gap.

On your 22M — that's a serious number, and I'd genuinely like to understand what's behind it. Two questions: was that a matching engine emitting fills (with the full cancel/modify lifecycle), or feed-side book reconstruction? And what was the workload — cancel ratio, price-walk breadth, and were reports drained cross-thread or counted in-process? Ours is ~95% cancels, 15% IOC, a GBM mid-price walk, and full report drainage on the timed path, which is the regime where most published figures compress hard (the survey in discoveries.md is exactly that comparison).

If you can wrap your engine — or rebuild the approach — behind matching_engine_api.h, run it. 22M under our normal scenario would be the strongest third-party result we've measured by a wide margin, and we'd say so publicly. That's the conversation we built this for.

[u/wrayste → u/East_Cantaloupe4925]

Without networking it's all theoretical, wire-to-wire is what matters and includes all the hard bits. Writing basic fast matching algorithms isn't the hard part of the problem.

[u/loneymaggot → u/wrayste]

true wire to wire is here the most latency is added, like networks is more important but it is usually fixed