尧图网站建设  提升至 O(1))
写作缘由作者虽讨厌写博客文章但为思考问题、整合知识仍强迫自己写且文章发布后常冒新点子。这篇文章源于上一篇关于缩小 Ruby 哈希表文章发布后的新想法。AR 表并非哈希表当条目数不超 8 个时Ruby 的 Hash 类实际是键值对数组。介绍了其数据结构ar_table 为节省内存只存哈希码低字节增加哈希冲突可能但可接受。其查找例程是线性搜索性能为 O(n)可通过实验验证查找第 8 个键比第 1 个键慢不过在条目最多 8 个的情况下线性搜索与 st_table 性能相差不大使用 ar_table 还是 st_table 是空间与时间的权衡。人们期望哈希表有 O(1) 访问速度因此思考让 ar_table 查找达 O(1) 的办法。SWAR 搜索ar_find_entry_hint 核心是在 8 字节数组中搜索特定字节适合 SWAR 技术。将 ar_hint 看作 8 字节整数可同时对所有字节执行相同操作。以在 8 字节数字中查找空字节为例详细解释了操作步骤。统计零位因 CPU 有专门处理位图的指令需考虑字节序使用不同函数ntz 或 nlz统计零位数结果除以 CHAR_BIT。整数除以常量 8 会被优化为右移操作。不仅能判断是否有字节为 NULL还能确定其位置且可通过清除最低有效位获取下一个 NULL 字节位置。掩码生成ar_table 的 hint 是任意数字需将匹配字节变为 0其他变为非 0可通过 XOR 异或运算先构建掩码再进行后续操作。集成到 Ruby 中作者首次尝试用 find_bytes 函数替换 for 循环结果失败因 ar_equal 调用可能改变查找的 Hash。后来修改代码直接跳到第一个匹配的 hint基准测试显示查找第一个键和最后一个键性能接近未命中时速度更快但查找第一个键性能下降。作者决定对第一次匹配特殊处理去掉多余条件以优化性能。 加速小型 Ruby 哈希表：SWAR 搜索技术助力查找性能从 O(n) 提升至 O(1)
写作缘由作者虽讨厌写博客文章但为思考问题、整合知识仍强迫自己写且文章发布后常冒新点子。这篇文章源于上一篇关于缩小 Ruby 哈希表文章发布后的新想法。AR 表并非哈希表当条目数不超 8 个时Ruby 的 Hash 类实际是键值对数组。介绍了其数据结构ar_table 为节省内存只存哈希码低字节增加哈希冲突可能但可接受。其查找例程是线性搜索性能为 O(n)可通过实验验证查找第 8 个键比第 1 个键慢不过在条目最多 8 个的情况下线性搜索与 st_table 性能相差不大使用 ar_table 还是 st_table 是空间与时间的权衡。人们期望哈希表有 O(1) 访问速度因此思考让 ar_table 查找达 O(1) 的办法。SWAR 搜索ar_find_entry_hint 核心是在 8 字节数组中搜索特定字节适合 SWAR 技术。将 ar_hint 看作 8 字节整数可同时对所有字节执行相同操作。以在 8 字节数字中查找空字节为例详细解释了操作步骤。统计零位因 CPU 有专门处理位图的指令需考虑字节序使用不同函数ntz 或 nlz统计零位数结果除以 CHAR_BIT。整数除以常量 8 会被优化为右移操作。不仅能判断是否有字节为 NULL还能确定其位置且可通过清除最低有效位获取下一个 NULL 字节位置。掩码生成ar_table 的 hint 是任意数字需将匹配字节变为 0其他变为非 0可通过 XOR 异或运算先构建掩码再进行后续操作。集成到 Ruby 中作者首次尝试用 find_bytes 函数替换 for 循环结果失败因 ar_equal 调用可能改变查找的 Hash。后来修改代码直接跳到第一个匹配的 hint基准测试显示查找第一个键和最后一个键性能接近未命中时速度更快但查找第一个键性能下降。作者决定对第一次匹配特殊处理去掉多余条件以优化性能。