系统与数据库2018usenix.org
用高级语言编写 POSIX 内核的收益与成本
The benefits and costs of writing a POSIX kernel in a high-level language
进阶 · 约 60 分钟读完前置知识：操作系统基础、C 语言、垃圾回收机制
导读
这篇 OSDI'18 论文介绍了 Biscuit——一个用 Go 编写的 POSIX 内核，实现了虚拟内存、mmap、TCP/IP socket、日志文件系统等，足以运行真实应用。通过对比几乎相同的系统调用、缺页和上下文切换代码路径，Go 版本比 C 慢 5%–15%，且未做深度优化。
HN 关注点：HN 读者长期争论用高级语言写内核的性能代价，这篇论文用实测数据反驳了'性能损失 2 倍以上'的说法，引发关于安全性与性能权衡的讨论。
HN 评论精选
这几条评论里：支持 1 补充 2 亲历 1
支持愿意用约 10% 性能换取内存安全，并呼吁带边界检查的 C 方言
一个使用 GC（而非引用计数或 Rust 式生命周期）的未优化研究内核，在所测项目上竟能做到与传统内核相差 5-15% 以内，令人印象深刻。当然肯定有很多前提条件，但这支持了一个论点：用高级安全语言写内核和设备驱动不会带来批评者声称的 2 倍或更差的性能损失。我愿意用 10% 的性能换取整类安全漏洞的消除。（出于同样原因，我希望标准委员会推出一个带边界检查的 C 方言，让我可以选择付出一些性能代价来获得真正的动态和边界检查数组）
xenadu02查看英文原文
An unoptimized research kernel using GC (instead of ref-counting or Rust-style lifetimes) manages to get within 5-15% of a traditional kernel for the things they measured. That is impressive. Lots of asterisks and caveats apply I'm sure, but it bolsters the argument that writing kernels and device drivers in a high-level safe language wouldn't impose the 2x or worse perf penalty detractors like to claim. I know I'd trade 10% perf for the elimination of whole classes of security vulnerabilities. (For the same reason, I want the standards committee to produce a bounds-checked dialect of C where I can choose to pay some perf cost to get real dynamic and bounds-checked arrays)
补充期待生产级 Rust 内核，并想看三种语言的编译时间对比
我很希望看到业界采用生产级的 Rust 内核。我在家和工作中只用 Go 和 Rust，两者效率相当。Go 作为 GC 语言缺少很多'高级'特性，所以 GC 优势并不大。Rust 安全、快速且写起来很愉快。我对这些数字并不意外，但想看看 Rust、Go 和 C 写同等规模内核的编译时间对比。
ilovecaching查看英文原文
I would love to see a production ready kernel written in Rust adopted by the industry. I am exclusively using Go and Rust at home and at work, and I find myself equally productive in both. Go lacks a lot of 'high level' features for a GC language, so I don't find the GC to be that advantageous. Rust is safe, fast, and a joy to write. I'm not surprised by these numbers, I would be interested to see a breakdown of compile times for similarly sized kernels in Rust, Go, and C.
补充概述论文核心内容与关键性能数据
论文的贡献是 Biscuit，一个用 Go 编写的内核，实现了足够的 POSIX（虚拟内存、mmap、TCP/IP socket、日志文件系统、poll 等）来运行重要应用。在对比几乎相同的系统调用、缺页和上下文切换代码路径的实验中，Go 版本比 C 慢 5% 到 15%。
thrill查看英文原文
The paper contributes Biscuit, a kernel written in Go that implements enough of POSIX (virtual memory, mmap, TCP/IP sockets, a logging file system, poll, etc.) to execute significant applications. In experiments comparing nearly identical system call, page fault, and context switch code paths written in Go and C, the Go version was 5% to 15% slower.
亲历论文作者现身答疑
动作真快！我是这篇论文的作者之一，很乐意回答问题。
DblPlusUngood查看英文原文
Well that was fast! I'm an author of this paper and would be happy to answer questions.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2018Hacker News 讨论帖202 分 · 96 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选