If Hash is performance critical, is there a strong reason not to replace it with this?
return id & (clientTable[client].buckets - 1); I'd be interested to see evidence justifying mixing higher-order bits into the hash. If the current hash is necessary, is there a typo in the 128 bucket case? That should be 14, not 13, right? Otherwise the same bit is getting mixed in twice. Jamey On 1/10/11, Adam Jackson <[email protected]> wrote: > We do actually call Hash() on resource lookup, so let's not make it more > expensive than necessary. The compiler isnmay not be smart enough to > notice that we only ever have a power of two count of buckets, so > flatten the log2 math so it doesn't have to know. > > Signed-off-by: Adam Jackson <[email protected]> > --- > dix/resource.c | 14 +++++++------- > 1 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/dix/resource.c b/dix/resource.c > index 9cdddba..d2cf0e4 100644 > --- a/dix/resource.c > +++ b/dix/resource.c > @@ -343,19 +343,19 @@ static int > Hash(int client, XID id) > { > id &= RESOURCE_ID_MASK; > - switch (ilog2(clientTable[client].buckets)) > + switch (clientTable[client].buckets) > { > - case 6: > + case 64: > return ((int)(0x03F & (id ^ (id>>6) ^ (id>>12)))); > - case 7: > + case 128: > return ((int)(0x07F & (id ^ (id>>7) ^ (id>>13)))); > - case 8: > + case 256: > return ((int)(0x0FF & (id ^ (id>>8) ^ (id>>16)))); > - case 9: > + case 512: > return ((int)(0x1FF & (id ^ (id>>9)))); > - case 10: > + case 1024: > return ((int)(0x3FF & (id ^ (id>>10)))); > - case 11: > + case 2048: > return ((int)(0x7FF & (id ^ (id>>11)))); > } > return -1; > -- > 1.7.3.4 > > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
