EQUALP下的数字哈希：ECL性能优化背后的兔子洞与天堂之乐

问题引入：当数值等价性遇上哈希一致性

一段时间前，我把ECL的快速泛函分发工作从抽屉里拿出来掸了掸灰。合并之前，我决定先优化基于表的调度，好度量一下改进幅度。这一动手，就挖出一整窝兔子洞，包括重新实现哈希表和哈希函数 原文。

这窝兔子洞里最丑的一块，是EQUALP谓词下数字哈希的一致性。Common Lisp标准规定，符合规范的实现必须支持EQ、EQL、EQUAL、EQUALP四种哈希表测试。EQUALP有个奇怪的地方：不同表示的数字，只要数学上相等，就被视为相等。比如 (equalp 1 1.0) 返回真，(equalp 1/2 0.5) 也返回真 原文。既然1和1.0被EQUALP认为是同一个东西，它们的哈希值就必须相同。ECL此前没有保证这一点，这是本次优化要修的核心。

为了度量改进，我用polyclot——一个McCLIM的工作绘图工具——生成了几张条形图，覆盖SLOT-ACCESS/READER、HTABLE-MIXBAG、HTABLE-SETREM、HTABLE-SMALL-STRING四个场景。图的方向是less is better，所以柱子越短越好 原文。这次折腾有两个好结果。哈希表和泛函分发会快很多；我也有灵感再写一篇关于Common Lisp的博客，就是这篇。

实现细节：二进制浮点下的 EQUALP 哈希难题

我在文章里明确假设二进制浮点，也就是浮点基数为2。ECL用的就是这个表示。这个假设让问题聚焦在浮点表示与数学等价之间的缝隙 原文。

EQUALP要求数学等价的数字有相同的哈希值。1、1.0、1/3、0.5这些表示不同的数字，在数学上可能相等，哈希值必须一致。ECL此前没有做到这一点。这不是一个可以绕过去的边缘情况，它直接决定了哈希表能否在EQUALP下正确工作 原文。

整个哈希表与哈希函数在ECL中被重新实现。这不是打补丁，是整体换新。作者把过程形容为挖出一整窝兔子洞，问题的复杂度远超预期 原文。表面是性能调优，底下是数值等价模型的重审。

基准对比与作者判断：多源观点交叉验证

基准对比分两层。一层是ECL自己的新旧实现比，一层是ECL与其他Common Lisp实现比。度量统一用less is better 原文。

HN用户a-french-anon评论说，这是非常彻底的基准测试与改进，并提到此前一个帖子（HN id=50245592）没获得足够关注，现在重新发布。他还说，ECL的其他领域也可能从这些优化中受益 HN。这个判断与作者自述的两个好结果形成了交叉印证。

综合多方来源，性能提升不只来自算法改进，也来自对EQUALP语义一致性的正确修复。这是原文与HN评论共同指向的结论 原文HN。这次优化把ECL的数字哈希从语义泥潭里拽了出来。哈希表快了，分发快了，顺带暴露了数值塔底下的一层地基问题。下一层地基是什么，我不确定。但方向是对的。

原文：

Heavenly delights of hashing numbers under EQUALP · 来源：Hacker News

参考来源：

• HN 评论区讨论 (item 50270878)

作者：itfan123 值班编辑 · 发布于 2026年10月28日