Displaying 6 results from an estimated 6 matches for "fnv1".
Did you mean:
fn1
2016 Jun 01
6
LLD's default --build-id choice
Nico brought up this topic and made me think whether the current choice of
--build-id was the right one or not.
Currently, we compute a FNV1 hash for an entire resulting file and store it
to .note.gnu.build-id section. It's one of the slowest parts of the linker
because reading every byte takes time. IIRC, it usually takes about 10% of
total link time.
In the first place, I believe it was not a good decision to make GCC (and
theref...
2012 Feb 08
2
[LLVMdev] We need better hashing
...;ve been replacing std::map and FoldingSet
with DenseMap in a number of places, and plan to do more of this. The thing
is, for complex key types, you really need to have a custom DenseMapInfo,
and that's where having a good hash function comes in.
There are a bunch of hash functions out there (FNV1, SuperFastHash, and
many others). The best overall hash function that I am currently aware of
is Austin Appleby's MurmurHash3 (http://code.google.com/p/smhasher/).
For LLVM's use, we want a hash function that can handle mixed data - that
is, pointers, ints, strings, and so on. Most of the...
2012 Feb 09
0
[LLVMdev] We need better hashing
...map and FoldingSet
> with DenseMap in a number of places, and plan to do more of this. The thing
> is, for complex key types, you really need to have a custom DenseMapInfo,
> and that's where having a good hash function comes in.
>
> There are a bunch of hash functions out there (FNV1, SuperFastHash, and
> many others). The best overall hash function that I am currently aware of
> is Austin Appleby's MurmurHash3 (http://code.google.com/p/smhasher/).
>
> For LLVM's use, we want a hash function that can handle mixed data - that
> is, pointers, ints, strings,...
2012 Feb 13
5
[LLVMdev] We need better hashing
...gt;> with DenseMap in a number of places, and plan to do more of this. The thing
>> is, for complex key types, you really need to have a custom DenseMapInfo,
>> and that's where having a good hash function comes in.
>>
>> There are a bunch of hash functions out there (FNV1, SuperFastHash, and
>> many others). The best overall hash function that I am currently aware of
>> is Austin Appleby's MurmurHash3 (http://code.google.com/p/smhasher/).
>>
>> For LLVM's use, we want a hash function that can handle mixed data - that
>> is, poin...
2012 Feb 17
0
[LLVMdev] We need better hashing
...seMap in a number of places, and plan to do more of this. The thing
>>> is, for complex key types, you really need to have a custom DenseMapInfo,
>>> and that's where having a good hash function comes in.
>>>
>>> There are a bunch of hash functions out there (FNV1, SuperFastHash, and
>>> many others). The best overall hash function that I am currently aware of
>>> is Austin Appleby's MurmurHash3 (http://code.google.com/p/smhasher/).
>>>
>>> For LLVM's use, we want a hash function that can handle mixed data -
>&g...
2012 Feb 18
2
[LLVMdev] We need better hashing
...r of places, and plan to do more of this. The thing
>>>> is, for complex key types, you really need to have a custom DenseMapInfo,
>>>> and that's where having a good hash function comes in.
>>>>
>>>> There are a bunch of hash functions out there (FNV1, SuperFastHash, and
>>>> many others). The best overall hash function that I am currently aware of
>>>> is Austin Appleby's MurmurHash3 (http://code.google.com/p/smhasher/).
>>>>
>>>> For LLVM's use, we want a hash function that can handle mix...