十亿行挑战
一个以 Java 为中心的“十亿行挑战”，要求从一个 12 GB、10 亿行的文本文件中计算温度的最小值/平均值/最大值，已经成为极限性能调优和系统知识的展示场。参与者争论这个任务究竟是 I/O 密集还是 CPU 密集，在内存映射、自定义数字解析、SIMD、多线程以及利用操作系统 page cache 行为等技术之间权衡，同时也争论公平的基准测试方法和禁止针对特定数据集作弊的规则。许多人将手工优化的 Java 与 C、Rust、SQL 数据库、awk 和 pandas 进行对比，借此探讨现代硬件、运行时和数据处理工具在高负载但概念简单的工作负载下是如何表现的。
挑战范围与语言
- 尽管它被包装成一个 Java 挑战，许多参与者仍在讨论并分享 C/C++、Rust、Go、.NET、Python、Perl、Awk、R、SQL、ClickHouse、DuckDB、Pinot 等实现。
- 有些人希望其他 JVM 语言也能被正式允许，而另一些人指出，“no external dependencies” 会排除 Hadoop 或 Pandas 之类的东西。
IO、缓存与文件访问策略
- 一个核心主题是：这个任务到底是 IO 密集型还是 CPU 密集型。
- 由于 12 GB 文件会在一台 32 GB 机器上运行 5 次，而且缓存不会被清空，后续运行实际上是在 page cache 中完成，从而使解析和聚合成为主要瓶颈。
- 争论的做法包括：读入 RAM vs
mmap、缓冲 IO vsO_DIRECT、io_uring、小型固定缓冲区，以及如何处理跨越 chunk 边界的行。 - 有人认为依赖操作系统缓存策略会让基准测试不那么“纯粹”，也有人认为这更符合真实部署。
正确性约束与过拟合担忧
- 站点名称必须是任意 UTF‑8（不能包含
;），最长 100 个字符；温度范围是 −99.9 到 99.9，且必须恰好有一位小数。 - 这使得可以使用整数运算（乘以 10）以及比完整浮点更简单的解析。
- 一些很快的方案被发现误用了哈希函数，或者依赖特定数据集，因此被移除；关于什么算不公平的“过拟合”，讨论也很多。
- 还有人提出对数据集随机化或使用隐藏种子，以防止针对单个文件进行调优。
基准方法论争论
- 组织者会丢弃 5 次运行中最快和最慢的结果，并对中间 3 次取平均。
- 一方认为最小时间最能反映算法在无噪声条件下的潜力。
- 另一方则反驳说，截尾均值更能近似真实世界中系统噪声、虚拟机争用和 GC 影响下的性能。
算法与实现策略
- 常见建议包括：按站点流式处理聚合、使用整数温度、手写数字解析、用 SIMD 做分隔符搜索和解析、尽量减少分配，以及谨慎设计哈希表。
- 也有人探索一些更特殊的想法，比如自定义状态机、完美哈希，或专门的 SIMD 有状态解析器，不过其可行性仍有争议。
数据库与分析引擎的使用
- 不少参与者演示了 SQL 引擎（PostgreSQL、ClickHouse、DuckDB、Pinot、kdb+/q）可以非常简洁地完成查询，但通常更慢，尤其是把导入时间也算进去时。
- 讨论内容还包括存储膨胀、索引策略、数组技巧、并行查询计划，以及用于批量加载时的 COPY vs INSERT。
Java、构建工具与语言比较
- 大家对 Java 的看法不一：有人称赞它的性能和工具链，也有人抱怨它的冗长和样板代码。
- 很长的分支讨论比较了 Maven、Gradle、Cargo/Go 工具、增量编译行为，以及构建缓慢的感受。
- 还有人指出，虽然底层语言可能最快，但由于更安全的默认行为和 JIT 优化，朴素的 Java 往往会胜过朴素的 C/C++。