Nexus

Low-latency primitives and runtime for building high-performance systems.

Philosophy

These crates are born from years of building trading infrastructure, where certain patterns become clear: most systems don't need unbounded queues, dynamic allocation, or multi-producer flexibility. They need predictable, bounded, specialized primitives that do one thing well and never surprise you at runtime.

The core philosophy is predictability over generality:

• SPSC over MPMC — When you have one producer and one consumer, don't pay for synchronization you don't need
• Pre-allocation over dynamic growth — Allocate at startup, never on the hot path
• Bounded over unbounded — Know your capacity, reject rather than allocate
• Specialization over abstraction — A conflation slot isn't a queue of size 1, it's a different thing entirely

The goal isn't "fastest in microbenchmarks." It's consistent, low-latency behavior under real workloads — minimizing tail latency, avoiding syscalls, eliminating allocation jitter.

Each crate is small, focused, and honest about its constraints. No kitchen sinks.

Architecture

┌─────────────────────────────────────────────────────────┐
│                        *Runtime*                        │
│             rt · async-rt* · timer · + tokio            │
├─────────────────────────────────────────────────────────┤
│                       *Analytics*                       │
│                   stats-* · inference                   │
├─────────────────────────────────────────────────────────┤
│                       *Networking*                      │
│                     net · async-net                     │
├─────────────────────────────────────────────────────────┤
│                      *Concurrency*                      │
│         queue · channel · slot · notify · logbuf        │
├─────────────────────────────────────────────────────────┤
│                 *Collections & Flow Control*            │
│                    collections · rate                   │
├─────────────────────────────────────────────────────────┤
│                        *Storage*                        │
│                  slab · pool · smartptr                 │
├─────────────────────────────────────────────────────────┤
│                         *Types*                         │
│               bits · ascii · id · decimal               │
└─────────────────────────────────────────────────────────┘

* async-rt is experimental — use tokio for production async workloads

Crates

Types & Encoding

Storage & Allocation

Collections

Flow Control

Concurrency & Communication

Networking

Runtime

Streaming Statistics

Fixed-memory, zero-allocation streaming analytics. All types are O(1) per update, designed for hot-path integration. The nexus-stats umbrella crate re-exports everything; the subcrates allow fine-grained dependency control.

Inference

Real-time CPU inference for small, pre-trained models. Train in Python (PyTorch, LightGBM), load once via from_parts or SafeTensors, predict millions of times. Sub-microsecond latency, zero allocation after construction, SIMD-accelerated (SSE2/AVX2/AVX-512).

Design Principles

No allocation on the hot path

Every crate that manages memory supports pre-allocation. You pay the cost at startup, not when processing the millionth message.

Honest constraints

SPSC means SPSC. Don't sneak in an extra producer and expect it to work. The constraints enable the performance.

Benchmark what matters

Synthetic throughput is easy to game. We optimize for realistic workloads: ping-pong latency, p99/p999 tail latency, jitter under load. See individual crate BENCHMARKS.md files for methodology and results.

Minimal dependencies

These are foundational crates. Dependency trees are kept small and intentional.

Benchmark Conditions

Performance numbers are measured on an Intel Core Ultra 7 165U (12C/14T, 12MB L3) running Arch Linux with rustc 1.94.0. Comparative numbers (speedup ratios) are measured with turbo boost disabled and cores pinned via taskset; finalized cycle counts are with turbo boost enabled. Results vary by hardware — each crate's BENCHMARKS.md records the specific machine, toolchain, comparison-crate versions, and reproduction steps.

Platform Support

• Linux — Primary target, fully supported
• macOS — Supported
• Windows — Experimental where noted, typically behind feature flags

Contributing

Please read CONTRIBUTING.md before submitting changes.

The short version: we build specialized primitives, not general-purpose ones. Different constraints mean different problems, and different problems deserve different solutions. If you're proposing a feature, be ready to justify why it belongs in a tuned, minimal implementation.

We also have specific benchmarking standards — cycles not time, turbo boost disabled, cores pinned, jitter eliminated. Details in the contributing guide.

License

Licensed under either of Apache License, Version 2.0 or MIT license at your option.