缓存与平行数组在 hash_strmap 和 gold_hash_map 中的应用
2007 年我写过一篇关于平行数组与CPU缓存文章,最近,我在 hash_strmap 和 gold_hash_map 中应用了这种设计思想,有这么几个字段可以使用平行数组:
hash value cache
对于一些对象,计算它们的 hash value 很昂贵,而对于另外一些对象,计算它们的 hash value 很廉价;所以,我们是否做 hash 缓存对 hash table 性能很重要。
更有意思的是,hash 缓存一般只在 hash table 的增长阶段访问(rehash),而在查找阶段,不需要访问 hash 缓存,于是,可以把 hash cache 从数据结构的结点中提取出来,放到一个分离的平行数组中。所谓平行数组,也就是:以前是访问 pNode[i].hash ,现在是 pHash[i] ,很简单的概念。
更有意思的是,我们可以随时启用(enable)或禁用(disable) hash 缓存,在 hash_strmap 的测试中,启用它大约会使插入操作的平均性能提升一倍。具体到实现上,我们甚至不需要额外的变量来表示 hash 缓存是否启用,只需要将 pHash 设成一个特殊的值来表达它是禁用的,现在设的是整数 8 (与“不”谐音),当然需要强制类型转换 pHash = (size_t*)(8)。
link array
这个仅使用在 gold_hash_map 中,因为在 hash_strmap 中,link 和 offset (指向 strpool 的偏移)一起占用 8 字节(在64位环境中刚好一个指针宽度)。
hash table 使用开地址解决 hash 冲突,这样在同一个桶(bucket) 中的所有 Node 是用一个单向链表链接起来的,传统实现是使用指针做链接,gold_hash_map 和 hash_strmap 使用数组下标做链接,这样不但可以在任何时候重新链接(比如gold_hash_map 和 hash_strmap 都支持排序,而排序打乱了数组下标,所以排序之后需要重新链接),并且,在 64 位环境中还可以节约一半的内存。
传统的做法是将 link 作为 Node 的一个成员,这样很简单也很自然,gold_hash_map 一开始就是这样实现的,然而,仔细分析我们会发现,在 hash table 的查找中,对 link 访问的概率是很低的,请看代码:
1 2 3 4 5 6 7 8 |
size_t find_i(const Key& key) const { size_t n = nElem; HashTp h = HashTp(hash(key)); size_t i = h % nBucket; for (LinkTp p = bucket[i]; tail != p; p = pLink[p]) if (equal(key, keyExtract(pElem[p]))) return p; return n; // not found } |
只有在桶(bucket)中得到的第一个 Node 不匹配 key 的时候,才需要访问 link,而在 hash table 中,这样的第一个 Node 不匹配 Key 的概率是相对很小的,并且把它控制得很小是一个 hashfunc 优劣的评价标准。
另一方面,虽然内存现在很白菜价,并且会继续更加白菜价,然而CPU cache仍然非常昂贵。如果link和data成员都放在Node中,CPU加载data (代码中的Elem)时也会加载link,而加载进来的link却很少会被访问到。这就是为什么要把link分出去。
将link分出去还带来了一个额外的好处:hash cache 分出去了,link 也分出去了,Node 中现在就只剩下 data 了,Node 就没有存在的必要了,Node数组就是 data 数组了!这样完全省去了专门写 iterator 的代码,直接将 iterator 定义成指针就OK了。
查找失败时
查找总有找不到的时候,当查找的 Key 不存在的时候,并且 h%nBucket 刚好打进一个不空的桶:
并且,在这种情况下,需要遍历完整个 linked list 才能知道 Key 真的不存在,所以此时至少需要访问一次 pLink 数组。
似乎此时情况变得很坏!然而再仔细分析上面的条件:只有在 Key 不存在,并且并且 h%nBucket 刚好打进一个不空的桶!如果我们把 hash tab 的装载因子 (load factor)设得小一些,比如(0.3),这个概率就会变小,从而对 pLink 数组的访问需求也变小了。因为 link 用的是整数,所以,如果我们知道整个 hash tab 不会装太多东西,我们可以把 LinkTp 设成较小的整数类型(比如 unsigned short,16位,这样最多可以在 gold_hash_tab 中装入 65535 条记录)。从而,相同的内存空间,我们可以把装载因子调得更小,从而使得访问 pLink 数组的概率更小,并且 hash 冲突的概率也更小了。
hash_strmap 的 LinkTp 是固定的(unsigned int),无法改变,这是刻意为之,因为这种灵活性对 hash_strmap 带来的好处太小了,不值得付出那么多努力。
总结
使用了这么多的技巧和设计思想,结果如何呢??gold_hash_map 完败几乎所有 hash map 的实现!
以前看过这文章,不甚理解。
重读一遍,终于明白了。
gold_hash_map中有三个数组,内存占用应该要比其它的hash_map要多。
不过考虑到如果map中装的是大一些的对象,gold_hash_map所占的内存不算什么。
[reply]hengyunabc[/reply]
不是这样的,hash 和 link 分出去之后,是 4 个数组:bucket, data, hash, link, 其中后三个是平行数组。
gold_hash_map 总的内存占用比传统 hash map 要小,因为只有 4 块连续的内存,没有大量小对象导致的内存碎片,链接域(link 和 bucket)用的内存也小。
另外:现在 hash_strmap 也可以自定义 LinkTp(link type)了。