为亚微秒级延迟而设计 (link)

Source: Dev.to

Lessons from Building a Minimal Execution Engine

大多数框架都在优化吞吐量、开发者速度或水平可扩展性。当你关注尾部延迟、确定性以及亚微秒级关键路径时，这些抽象往往会成为负担。我构建了 SubMicro Execution Engine 来探索当延迟——而不是功能——成为主要设计约束时会发生什么。下面是塑造该系统的几个实用经验教训。

Latency Lives in the Edges, Not the Core Logic

系统实际执行的“工作”很少是瓶颈。延迟隐藏在：

• 内存分配
• 缓存行争用
• 分支错误预测
• 调度器切换
• 同步原语

关键实践

• 保持热点路径无分配
• 倾向使用平坦、缓存友好的数据布局
• 避免隐式同步
• 设计能够装入 L1/L2 缓存的执行流

如果你无法从内存中描绘出热点路径，就说明你并未掌控延迟。

Determinism Beats Raw Throughput

一个每秒执行 1 M 操作的系统，有时不如一个始终保持每秒 200 k 操作的系统有用。

设计选择的指导原则

• 稳定的执行顺序
• 可预测的调度
• 热点路径中的最小动态行为

这会以峰值吞吐量为代价，换取紧凑的延迟分布——在实时系统和交易系统中，这一点更为关键。

Abstractions Have a Cost — Measure Them Ruthlessly

抽象本身并不坏，但未被测量的抽象是危险的。

在低延迟系统中：

• 虚函数调用的开销可能超过实际逻辑本身
• 通用容器会隐藏内存访问模式
• “干净”的接口常常会把执行路径碎片化

相反，应追求

• 对执行的显式控制
• 可见的数据移动
• 简单、可检查的组件

通过 移除 层而不是添加层来保持代码的可读性。

Scheduling Is a Latency Feature

调度器决定 何时 执行工作——这与 做什么 同样重要。

设计考虑因素包括

• 最小化上下文切换
• 可选的忙轮询策略
• 避免在热点路径中受操作系统干扰的执行模型

目标是让执行尽可能贴近 CPU，而不是在队列和线程之间来回跳转。

Measure the Tail, Not the Average

平均延迟是误导性的。

该引擎的设计假设是：

• p99 与 p99.9 的重要性高于均值
• 偶发的峰值会破坏实时系统
• 监控必须轻量到足以在生产环境中使用

如果不测量尾部延迟，你的优化就是盲目的。

Closing Thoughts

本项目刻意保持极简。它 不是 一个框架；而是一次探索——在每一个设计决策都要回答同一个问题的前提下，你能将延迟控制推向多远：

这会降低还是增加不可预测性？

Repository: submicro-execution-engine
Demo site: https://submicro.krishnabajpai.me/