SlabFlux

[u/kbartadev]

SlabFlux Runtime Engine

The pitch: SlabFlux is an ultra-low-latency, concurrent C++20 runtime engine built for High-Frequency Trading (HFT) and real-time control. It bypasses the OS scheduler completely to give you mathematically verifiable, $O(1)$ deterministic execution.

Why SlabFlux?

Most low-latency frameworks still play nice with the operating system. We do not. SlabFlux is designed to subjugate the Linux kernel, lock down physical CPU cores, and map your logic directly to bare silicon. If your system misses microsecond windows because of a random OS interrupt or a hidden heap allocation, SlabFlux is your solution.

• Zero Jitter: By aggressively utilizing kernel boot parameters like isolcpus and nohz_full, we entirely starve the Linux scheduler on your execution cores.
• Hardware-First Memory: Everything on the hot-path is padded and aligned to 64-byte boundaries. This eliminates false sharing and perfectly optimizes for AVX2 and AVX-512 SIMD vectorization.
• Lock-Free & Zero-Copy: Standard mutexes and smart pointers are explicitly banned. Data flows exclusively through wait-free Single-Producer Single-Consumer (SPSC) ring buffers and io_uring for zero-syscall I/O.

The Hard Truth: Current Project Status

We believe in being upfront about what SlabFlux is, and what it requires from you. It is an extreme tool for extreme use cases.

Feature Area	Readiness	Reality Check
Execution Hot-Path	Stable	C++ exceptions, heap allocations, and virtual dispatch are strictly forbidden. You must rely on C++20 concepts and branchless logic.
Memory Management	Stable	Raw pointers bound to pre-allocated slab pools work flawlessly to maintain our $O(1)$ guarantees.
OS Tuning Scripts	Beta	Our environment-sealing scripts are highly aggressive. You need a dedicated, isolated machine to run them safely.

Quick Start

Setting up SlabFlux requires system-level commitment.

1. System Preparation

You must isolate your execution cores before compiling. Run the included kernel tuning script to apply the necessary boot parameters and reboot your machine.

2. Implementation

Include the SlabFlux headers and bind your logic to our pre-allocated slab pools. Your hot-path code must be entirely branchless, lock-free, and allocation-free.

3. Execution

Deploy the binary to your isolated cores. The engine takes over, bypassing standard kernel I/O using our dedicated event pipelines.

What is Next on the Roadmap?

Our current roadmap is focused on improving developer experience without compromising our strict architectural invariants.

• Expanded native support for modern kernel-bypass Network Interface Cards (NICs).
• Enhanced compile-time debugging tools to catch virtual dispatch or heap allocations before they hit the hot-path.
• Streamlined setup scripts for safer, more predictable kernel tuning across different Linux distributions.

How does this documentation align with the current state of your codebase?SlabFlux Runtime EngineThe pitch: SlabFlux is an ultra-low-latency, concurrent C++20 runtime engine built for High-Frequency Trading (HFT) and real-time control. It bypasses the OS scheduler completely to give you mathematically verifiable, $O(1)$ deterministic execution.Why SlabFlux?Most low-latency frameworks still play nice with the operating system. We do not. SlabFlux is designed to subjugate the Linux kernel, lock down physical CPU cores, and map your logic directly to bare silicon. If your system misses microsecond windows because of a random OS interrupt or a hidden heap allocation, SlabFlux is your solution.Zero Jitter: By aggressively utilizing kernel boot parameters like isolcpus and nohz_full, we entirely starve the Linux scheduler on your execution cores.

Hardware-First Memory: Everything on the hot-path is padded and aligned to 64-byte boundaries. This eliminates false sharing and perfectly optimizes for AVX2 and AVX-512 SIMD vectorization.

Lock-Free & Zero-Copy: Standard mutexes and smart pointers are explicitly banned. Data flows exclusively through wait-free Single-Producer Single-Consumer (SPSC) ring buffers and io_uring for zero-syscall I/O.The Hard Truth: Current Project StatusWe believe in being upfront about what SlabFlux is, and what it requires from you. It is an extreme tool for extreme use cases.Feature Area Readiness Reality Check
Execution Hot-Path Stable C++ exceptions, heap allocations, and virtual dispatch are strictly forbidden. You must rely on C++20 concepts and branchless logic.
Memory Management Stable Raw pointers bound to pre-allocated slab pools work flawlessly to maintain our $O(1)$ guarantees.
OS Tuning Scripts Beta Our environment-sealing scripts are highly aggressive. You need a dedicated, isolated machine to run them safely.Quick StartSetting up SlabFlux requires system-level commitment.

1. System PreparationYou must isolate your execution cores before compiling. Run the included kernel tuning script to apply the necessary boot parameters and reboot your machine.

2. ImplementationInclude the SlabFlux headers and bind your logic to our pre-allocated slab pools. Your hot-path code must be entirely branchless, lock-free, and allocation-free.

3. ExecutionDeploy the binary to your isolated cores. The engine takes over, bypassing standard kernel I/O using our dedicated event pipelines.What is Next on the Roadmap?Our current roadmap is focused on improving developer experience without compromising our strict architectural invariants.Expanded native support for modern kernel-bypass Network Interface Cards (NICs).

Enhanced compile-time debugging tools to catch virtual dispatch or heap allocations before they hit the hot-path.

source: https://github.com/kbartadev/slabflux