初探 Times33算法

初探 Times33算法

作者:admin |  时间:2014-02-22 |  浏览:616 |  0 条评论

不约而同的,几乎所有的流行的hash map都采用了DJB hash function,俗称“Times33”算法。
Perl、Berkeley DB 、Apache、MFC、STL 等等。
times33的算法也很简单,就是不断的乘33。nHash = nHash*33 + *key++;
我没找到什么理论可以说明这种算法的合理性,据说只是通过测试和实践发现这个算法是比较好的。如果有哪位能够提供这方面的资料,不胜感激。
我把times33和一些其他哈希算法做过比较,times33确实比我找到的其他哈希算法都更快。另外,有人说times33对英文字母效率比较好,处理中文的时候效率就比较低;我对此进行了一些测试,发现times33在处理ascii和中文的时候,性能差异在千分之三以下,我认为这是正常的误差。
 
《打造最快的Hash表(和Blizzard的对话)》http://blog.csdn.net/zeronecpp/archive/2005/04/11/342756.aspx
这是在别人的blog上看到的一篇文章,讲述blizzard如何改良hash表的。在上述哈希算法里面有一段 “seed2 + (seed2 << 5)” 相当于乘以33,其实可以看作是times33算法的变种。我对blizzard这种实现方法的效率存有怀疑。
上述blizzard的哈希算法的核心如下(我给cryptTable赋了最简单的值,而且把dwHashType设为了1):

inline UINT CMyMap::HashKey(LPCTSTR key) const
{
    int dwHashType = 1;
    unsigned long seed1 = 0x7FED7FED, seed2 = 0xEEEEEEEE;
    int ch;
    while(*key != 0)
    {
        ch = toupper(*key++);
       
        //seed1 = cryptTable[(dwHashType << 8) + ch] ^ (seed1 + seed2);
        seed1 = ((dwHashType << 8) + ch) ^ (seed1 + seed2);
        seed2 = ch + seed1 + seed2 + (seed2 << 5) + 3;
    }
    return seed1;
}

我进行了一下测试,发现blizzard的哈希算法,分布不如经典的times33算法。它的分布如下:elements=10000, good=4293 bad2=1786 bad3=528 bad4=109 vbad=22
而经典times33算法的分布是:elements=10000, good=4443 bad2=1775 bad3=501 bad4=107 vbad=15
说明:这是我测试程序的输出,测试的时候,我通过InitHashTable()把bucket个数设为了12007。输出中的elements表示哈希表中一共存放了多少个元素,good表示“只有一个元素”的bucket个数,bad2表示“有两个元素”的bucket个数,bad3表示“有三个元素”的bucket个数,vbad表示“有五个或者五个以上元素”的bucket个数。
经典times33算法如下:

inline UINT CMyMap::HashKey(LPCTSTR key) const
{
    UINT nHash = 0;
    while (*key)
        nHash = (nHash<<5) + nHash + *key++;
    return nHash;
}

从代码可以很明显的看出,blizzard的这个hash算法的计算工作量也要比经典的times33算法大很多。
我的理解是:这是为了让让同一个字符串,可以根据dwHashType 的不同而计算出不同的独立的hash值。为了实现这个目的,blizzard的这个hash算法在性能上已经付出了一些代价。
//
// 以上是对hash算法的比较
/////////////////////////////////////////
// 以下是对hash表整体结构的比较
//
另外,blizzard这个算法本质上还是把数据放在hash bucket里面,也同样是在每个hash bucket里面有一个list队列。
只不过一般的hash表,在找到hash bucket之后,就逐个的直接比较element;而blizzard的这个hash表,则是用“额外的两个hash值的比较”来代替element的直接比较。孰优孰劣要看具体的应用环境。
考虑到计算三次hash值的工作量,我觉得如果设置一个合适的hash bucket count,blizzard的做法可能还要更慢。
上面我做的hash分布测试已经表明,当hash bucket count比elements大20%以上的时候,查找一个element的strcmp调用次数大约是(4443*1+1175*2*1.5+501*3*2+107*4*2.5+15*5*3)/10000=1.2269次,大约是1.2次。(4443个bucket只有一个element,因此一次strcmp就可以确认了。有1175个bucket有两个元素,平均要1.5次strcmp才能找到它。以此类推。)
做1.2次strcmp()和做2次HashKey()相信大家都知道谁比较耗时了。

看来,这个所谓”最快的hash表“似乎有点名不副实呢?还是另有玄机我没看透?
所谓"One-way hash"其实就是不可逆hash,主要是用来加密用的,和速度快不快没什么关系。实际上"One-way hash"为了达到不可逆的目的,通常总是要更慢一些。blizzard是我很喜欢的公司,我也是暴雪的铁杆fans,不过这次似乎有人夸暴雪夸错方向了:)
 
times33哈希算法(Perl、Berkeley DB、Apache中使用的hash算法)

unsigned int apr_hashfunc_default(const char *char_key, apr_ssize_t *klen)
{
    unsigned int hash = 0;
    const unsigned char *key = (const unsigned char *)char_key;
    const unsigned char *p;
    apr_ssize_t i;
    if (*klen == APR_HASH_KEY_STRING) {
      for (p = key; *p; p++) {
        hash = hash * 33 + *p;
      }
      *klen = p - key;
    }
    else {
       for (p = key, i = *klen; i; i--, p++) {
         hash = hash * 33 + *p;
       }
    }
    return hash;
}

对于给定的键值key,apr_hashfunc_default返回它在哈希表中的索引。默认哈希算法采用了目前最为流行的times 33哈希算法,目前该算法被广泛使用在多个软件项目包括perl和巴克利(Berkeley DB)数据库中。对于字符串而言这是目前所知道的最好的哈希算法,原因在于该算法的速度非常快,而且分类非常好。

转载:http://blog.sina.com.cn/s/blog_53efef610100hhnw.html

相关推荐

发表评论

电子邮件地址不会被公开。

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>