Jonhoo 10 小时直播视频：Rust 完成十亿行挑战

是时候用 Rust 完成 十亿行挑战 了。这是一个深入研究 Rust 代码优化，并在过程中学习汇编、SIMD、性能分析以及 CPU 相关知识的绝佳途径，所以让我们开始吧！

目前已经有几个 Rust 实现和 这篇 优秀的文章，甚至还有一个现有的视频，但我希望现场演示迭代优化过程仍然是一个很好的教学练习。

观看：https://youtu.be/tCY7p6dVAGE

仓库：https://github.com/jonhoo/brrr

讨论：https://www.reddit.com/r/rust/comments/1paee4x/impl_rust_one_billion_row_challenge/

Xutex：一个实验性的、快速的、异步优化的互斥锁，并提供替代的同步 API

它仅使用原子指针（在 x64 架构上为 8 字节），并为无竞争锁提供快速路径。在竞争锁的情况下，它会回退到链表队列来存储等待者。为了减少堆内存分配，它使用了一个预分配队列结构的共享池，通过循环利用这些已竞争的队列来提升性能。向队列推送数据无需分配内存：等待者只需链接到自己的栈空间，而无需创建新节点。这正是 Xutex 速度快的关键原因。

总体而言，无论在竞争还是非竞争场景下，它都比 Tokio 的 Mutex 更快。它在 Monoio 等单线程运行时环境中表现尤为出色，但在 Tokio 等多线程运行时环境中也依然具有很高的性能。

与 Tokio 的异步互斥锁实现相比：

• 与 Tokio 的方法不同，它只为每个对象分配 8 个字节，直到发生争用时才会分配，而 Tokio 的方法总是无论如何都会分配一个完整的信号量。
• 对于无竞争锁，其速度与 std::Mutex 和 ParkingLot（单个原子操作）相匹配。
• 它包含一个替代的同步 API，因此您可以轻松地将其放入同步和异步上下文中。

我们对 Tokio 的维护者们充满敬意，之所以将这个库与他们的库进行比较，唯一的原因是 Tokio 是 Rust 社区的事实标准，而这个库最终仍然处于实验阶段。

需要注意的是：它依赖于对等待链表队列的推送/弹出操作使用微锁，这可能会引起一些争议。在第一个版本中，我尝试使用带有活跃用户引用计数的内部标准互斥锁，但最终放弃了这个想法，因为它并没有比微锁提供任何真正的优势。

虽然可以通过与 Tokio 相同的方式进行分配来完全消除微锁，但这会失去 8 字节的小开销和无竞争场景下的快速路径的优势。

仓库：https://github.com/fereidani/xutex

讨论：https://www.reddit.com/user/SonarSource/comments/1p0f19h/tldr_ai_creates_code_in_seconds_verifying_it/?p=1&impressionid=5421350714272165919

讨论：你选择 name.rs 还是 name/mod.rs 组织模块？

A
├── name/
└── name.rs

B
└── name/
    └── mod.rs

在 Rust 中，有两种方法可以声明嵌套模块。Rust 文档推荐第一种方案。但很多知名项目使用第二种。

见 https://www.reddit.com/r/rust/comments/1p9mfwc/namers_vs_namemodrs_is_there_a_reason_why/

--

From 日报小组 苦瓜小仔

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区