编程语言与软件工程2024arxiv.org
面向低延迟应用的 C++ 模式：包括高频交易
C++ patterns for low-latency applications including high-frequency trading
进阶 · 约 25 分钟读完前置知识：C++ 基础、计算机体系结构、性能优化基础
导读
这篇论文梳理了面向低延迟应用（包括高频交易）的 C++ 编程模式，讨论如何借助编译期分发、内联、减少运行时开销等手法压低延迟。整体偏向模式总结与综述性质。
HN 关注点：HN 读者一边讨论这些 C++ 优化技巧是否实用、是否漏掉 false sharing、LTO/PGO 等关键手段，一边争论高频交易本身对社会有没有价值。
HN 评论精选
这几条评论里：质疑 2 补充 1 亲历 1
质疑专业读者指出文章偏浅、漏掉 false sharing 与 LTO/PGO 等关键优化，并强调低延迟编程最难教的是对性能杀手近乎偏执的敏感。
这是一篇相当浅显的入门介绍。按我教本科生的经验，他们大多已经掌握这些内容——体系结构课讲过分支预测、缓存一致性、指令缓存的基础，也就是性能的入门要素。我有点意外文章完全没涉及 false sharing（伪共享）这个经典性能杀手，不过它似乎主要关注单线程延迟。同样意外的是，它没提到那些“免费”优化手段，比如 fat LTO、PGO，甚至标准化的 [[likely]]/[[unlikely]] 提示属性来优化 icache 布局。无论这篇文章还是我的学生，都没触及更细枝末节的部分——这些多涉及具体 IO API、同步原语、IPC 机制和更冷门的编译器内建。除此之外，初学低延迟编程的人几乎总是缺乏、也最难培养的，是一种“偏执”：对不必要的分配、拷贝和其他性能杀手怀有真正的恐惧、厌恶和愤怒；一种挥之不去的感觉，驱使他们强迫性地用 callgrind 跑 benchmark，寻找热循环里那些未命中对象缓存、转而调用分配器的地方。我记得一个很有启发性的时刻，是在写低延迟服务器时意识到，构造一个 vector I/O 操作整体上比……（原文截断）
nickelpro查看英文原文
Fairly trivial base introduction to the subject. In my experience teaching undergrads they mostly get this stuff already. Their CompArch class has taught them the basics of branch prediction, cache coherence, and instruction caches; the trivial elements of performance. I'm somewhat surprised the piece doesn't deal at all with a classic performance killer, false sharing, although it seems mostly concerned with single-threaded latency. The total lack of "free" optimization tricks like fat LTO, PGO, or even the standardized hinting attributes ([[likely]], [[unlikely]]) for optimizing icache layout was also surprising. Neither this piece, nor my undergraduates, deal with the more nitty-gritty elements of performance. These mostly get into the usage specifics of particular IO APIs, synchronization primitives, IPC mechanisms, and some of the more esoteric compiler builtins. Besides all that, what the nascent low-latency programmer almost always lacks, and the hardest thing to instill in them, is a certain paranoia. A genuine fear, hate, and anger, towards unnecessary allocations, copies, and other performance killers. A creeping feeling that causes them to compulsively run the benchmarks through callgrind looking for calls into the object cache that miss and go to an allocator in the middle of the hot loop. I think a formative moment for me was when I was writing a low-latency server and I realized that constructing a vector I/O operation ended up being overall slower than just copying the small objects I was dealing with into a contiguous buffer and performing a single write. There's no such thing as a free copy, and that includes fat pointers.
补充补充说明编译期分发除省去运行时决策外，还能让编译器内联并触发更多优化。
关于编译期分发的效率优势，文中说是因为函数调用的决策在编译阶段就完成了，绕过了运行时分发时的决策开销，从而执行更快、提升性能。编译期分发的另一个好处是：当编译器能静态确定调用的是哪个函数时，它可能直接把被调函数代码内联到调用点。这消除了全部函数调用开销，还可能促成进一步优化（死代码消除、常量传播等）。
munificent查看英文原文
> The noted efficiency in compile-time dispatch is due to decisions about function calls being made during the compilation phase. By bypassing the decision-making overhead present in runtime dispatch, programs can execute more swiftly, thus boosting performance. The other benefit with compile-time dispatch is that when the compiler can statically determine which function is being called, it may be able to inline the called function's code directly at the callsite. That eliminates all of the function call overhead and may also enable further optimizations (dead code elimination, constant propagation, etc.).
亲历分享了自己的 C++ 交易所与 LMAX Disruptor 实现，并表示考虑改用 Rust，因为内存与依赖管理更省心。
我用 C++ 基于 LMAX Disruptor 模式实现了一个证券交易所：https://github.com/sneilan/stock-exchange，还有把 LMAX Disruptor 写成几个 C++ 文件的基础实现：https://github.com/sneilan/lmax-disruptor-tutorial。不过我一直在考虑用 Rust 重写——我已经自己实现了 WebSocket 协议、认证系统、SSL 等。后来我意识到，尤其对单人软件项目而言，Rust 的内存管理和依赖管理要容易得多。
sneilan1查看英文原文
I've got an implementation of a stock exchange that uses the LMAX disruptor pattern in C++ https://github.com/sneilan/stock-exchange And a basic implementation of the LMAX disruptor as a couple C++ files https://github.com/sneilan/lmax-disruptor-tutorial I've been looking to rebuild this in rust however. I reached the point where I implemented my own websocket protocol, authentication system, SSL etc. Then I realized that memory management and dependencies are a lot easier in rust. Especially for a one man software project.
质疑质疑高频交易本身是否对社会有价值，认为其负面外部性未受足够审视。
高频交易有任何存在的正当理由吗？人们常常抱怨比特币浪费能源，但奇怪的是这事却被放行，尽管在我看来它对社会肯定是净负面。
globular-toast查看英文原文
Is there any good reason for high-frequency trading to exist? People often complain about bitcoin wasting energy, but oddly this gets a free pass despite this being a definite net negative to society as far as I can tell.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2024Hacker News 讨论帖389 分 · 231 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选