Won't this hash function on doubles, with a 2^14 size hash table, collide -1.0 and 1.0 -2.0 and 2.0 .. 32.0, 33.0, -32.0, and -33.0
The most important chunk of the double is the low exponent bits, from bit 62 to bit 52, and the high mantissa bits, in 51.... We are getting 10 exponent bits and 4 mantissa bits into the low 14 bits of the hash. I think 4 and 10 would be better, and getting the sign bit in as well: return (value >> 30) ^ (value >> 12) ^ value. On Wed, Dec 23, 2009 at 7:50 AM, Lars Bak <[email protected]> wrote: > I've just uploaded a binary with the allocation change (including lea). > Let's see whether it makes a difference. > //Lars > > > On Wed, Dec 23, 2009 at 1:56 AM, <[email protected]> wrote: > >> >> http://codereview.chromium.org/501170/diff/1/3 >> File src/ia32/macro-assembler-ia32.cc (right): >> >> http://codereview.chromium.org/501170/diff/1/3#newcode738 >> src/ia32/macro-assembler-ia32.cc:738: >> UpdateAllocationTopHelper(result_end, scratch); >> I assume the order was changed here generate instructions with better >> scheduling (it would be nice if the change log said more about why >> changes were made...) The result is probably going to be used almost >> immediately. On a previous compiler I found using lea instead of or_ >> was faster because the address generation unit has faster bypass. >> >> >> http://codereview.chromium.org/501170 >> > > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > -- William Hesse Software Engineer [email protected] Google Denmark ApS Frederiksborggade 20B, 1 sal 1360 København K Denmark CVR nr. 28 86 69 84 If you received this communication by mistake, please don't forward it to anyone else (it may contain confidential or privileged information), please erase all copies of it, including all attachments, and please let the sender know it went to the wrong person. Thanks.
-- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
