为啥要用位运算代替取模呢

 

  在hash中查找key的时候，经常会发现用&取代%，先看两段代码吧，

 

  JDK6中的HashMap中的indexFor方法：

    /**
     * Returns index for hash code h.
     */
    static int indexFor(int h, int length) {
        return h & (length-1);
    }

 

Redis2.4中的代码段：

    n.size = realsize;
    n.sizemask = realsize-1;
    //此处略去xxx行
   while(de) {
            unsigned int h;

            nextde = de->next;
            /* Get the index in the new hash table */
            h = dictHashKey(d, de->key) & d->ht[1].sizemask;
            de->next = d->ht[1].table[h];
            d->ht[1].table[h] = de;
            d->ht[0].used--;
            d->ht[1].used++;
            de = nextde;
        }

 

大家可以看到a%b取模的形式都被替换成了a&(b-1) ，当hashtable的长度是2的幂的情况下（疏忽，一开始没写），这两者是等价的，那为什么要用后者呢？

另一方面，为什么hashtable的长度最好要是2的n次方呢，这个不在本次讨论范围之列，原因简单说一下就是1、分布更均匀 2、碰撞几率更小  详情自己思考，JDK中的HashMap就会在初始化时，保证这一点：

    public HashMap(int initialCapacity, float loadFactor) {
        if (initialCapacity < 0)
            throw new IllegalArgumentException("Illegal initial capacity: " +
                                               initialCapacity);
        if (initialCapacity > MAXIMUM_CAPACITY)
            initialCapacity = MAXIMUM_CAPACITY;
        if (loadFactor <= 0 || Float.isNaN(loadFactor))
            throw new IllegalArgumentException("Illegal load factor: " +
                                               loadFactor);

        // Find a power of 2 >= initialCapacity
        int capacity = 1;
        while (capacity < initialCapacity)
            capacity <<= 1;

        this.loadFactor = loadFactor;
        threshold = (int)(capacity * loadFactor);
        table = new Entry[capacity];
        init();
    }

 

redis中也有类似的保证：

 

/* Our hash table capability is a power of two */
static unsigned long _dictNextPower(unsigned long size)
{
    unsigned long i = DICT_HT_INITIAL_SIZE;

    if (size >= LONG_MAX) return LONG_MAX;
    while(1) {
        if (i >= size)
            return i;
        i *= 2;
    }
}

 

 

言归正传，大家都知道位运算的效率最高，这也是&取代%的原因，来看个程序：

int main(int argc, char* argv[])
{
    int a = 0x111;
    int b = 0x222;
    int c = 0;
    int d = 0;

    c = a & (b-1);
    d = a % b;

    return 0;
}

 

 

看反汇编的结果：

13:       c = a & (b-1);
00401044   mov         eax,dword ptr [ebp-8]
00401047   sub         eax,1
0040104A   mov         ecx,dword ptr [ebp-4]
0040104D   and         ecx,eax
0040104F   mov         dword ptr [ebp-0Ch],ecx
14:       d = a % b;
00401052   mov         eax,dword ptr [ebp-4]
00401055   cdq
00401056   idiv        eax,dword ptr [ebp-8]
00401059   mov         dword ptr [ebp-10h],edx

 

可以看到，&操作用了:3mov+1and+1sub  %操作用了：2mov+1cdp+1idiv

 

我们可以查阅Coding_ASM_-_Intel_Instruction_Set_Codes_and_Cycles资料，发现前者只需5个CPU周期，而后者至少需要26个CPU周期（注意，是最少！！！） 效率显而易见。所以以后自己在写的时候，也可以使用前者的写法。

 

 

评论

13 楼 masuweng 2012-12-27  

masuweng 写道

写的不错。

12 楼 freezingsky 2012-11-15  

在各种四则运算中，位运算是最快的。在不少C方面的笔试里，会出现位运算的题目。考察的内容包括左移，右移，取反等。

11 楼 elan1986 2012-11-15  

不错！ 

10 楼 暴走娘 2012-11-15  

等价的，那可以直接代替了！

9 楼 masuweng 2012-11-15  

写的不错。

8 楼 madiot 2012-11-15  

chenchao051 写道

madiot 写道

b是2的n次方才等价，这就是为什么hashtable的长度是2的n次方，这还不在本文讨论范围呢，汗啊~~~

ht2次方并不完全是因为这个原因，更多是因为hash的分布均匀与减少hash碰撞。

说的是

7 楼 chenchao051 2012-11-14  

madiot 写道

b是2的n次方才等价，这就是为什么hashtable的长度是2的n次方，这还不在本文讨论范围呢，汗啊~~~

ht2次方并不完全是因为这个原因，更多是因为hash的分布均匀与减少hash碰撞。

6 楼 chenchao051 2012-11-14  

groovyzhou 写道

不等价，除非length是2的幂

感谢各位，我疏忽了，没写清楚，文章已改。

5 楼 groovyzhou 2012-11-14  

不等价，除非length是2的幂

4 楼 madiot 2012-11-14  

b是2的n次方才等价，这就是为什么hashtable的长度是2的n次方，这还不在本文讨论范围呢，汗啊~~~

3 楼 yanghdx 2012-11-14  

难道是b%2=0时 等价？

2 楼 空谷悠悠 2012-11-14  

果然，iteye推到首页就看到了这篇blog，明显不等价

1 楼 iminto 2012-11-14  

这两个不等价吧，我测试了结果不一样