On Fri, Feb 10, 2017 at 7:03 AM, Connor Abbott wrote:
> On Thu, Feb 9, 2017 at 4:16 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
>> Hello
>>
>> IMPORTANT NOTE: Using the uint32_t data type, quad_hash*quad_hash will
>> overflow as soon as the hash table has more than 2**16=65536=64K
>> elements.
On Thu, Feb 9, 2017 at 4:16 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
> Hello
>
> IMPORTANT NOTE: Using the uint32_t data type, quad_hash*quad_hash will
> overflow as soon as the hash table has more than 2**16=65536=64K
> elements. To enable more than 64K elements in hash table, the data
> typ
Hello
IMPORTANT NOTE: Using the uint32_t data type, quad_hash*quad_hash will
overflow as soon as the hash table has more than 2**16=65536=64K
elements. To enable more than 64K elements in hash table, the data
types need to be changed to uint64_t - unfortunately uint64_t
arithmetic operations will
The same rationale applies here as for the hash table.
Power of two size should give better performance,
and using the algorithm hash = sh + i/2 + i*i/2
should result in only distinct hash values when hitting collisions.
V4: Feedback from Jason Ekstrand
- Split cleanup of set_rehash into separa
2015-03-16 6:49 GMT+01:00 Connor Abbott :
> Ok, so I think I managed to find the source of the bug. When inserting
> elements into the set/hash table, we computed the initial probe
> address *before* doing the rehash. In the case where inserting an
> element led to a rehash, this meant that we'd us
Ok, so I think I managed to find the source of the bug. When inserting
elements into the set/hash table, we computed the initial probe
address *before* doing the rehash. In the case where inserting an
element led to a rehash, this meant that we'd use the wrong starting
address when actually inserti
On Fri, Mar 13, 2015 at 6:37 PM, Thomas Helland
wrote:
> The same rationale applies here as for the hash table.
> Power of two size should give better performance,
> and using the algorithm hash = sh + i/2 + i*i/2
> should result in only distinct hash values when hitting collisions.
> Should give
The same rationale applies here as for the hash table.
Power of two size should give better performance,
and using the algorithm hash = sh + i/2 + i*i/2
should result in only distinct hash values when hitting collisions.
Should give a performance increase as we can do bitmasking instead
of a modulo
