search for: murmurhash2

While I've not reviewed the patch in too much detail, it looks promising. Can you run some end-to-end benchmarks to make sure that cache pressure in the full program or other variables not accounted for in a micro-benchmark don't dominate performance? Specifically the nightly tester includes a number of real programs and machinery to measure total compile time. On Sat, Feb 6, 2010 at 7:09

...tp://en.wikipedia.org/wiki/MurmurHash http://www.codeproject.com/KB/recipes/hash_functions.aspx as well as in the patch description itself. Patch and benchmark attached. Gregory -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FoldingSetNodeID-use-MurmurHash2-instead-of-SuperFas.patch Type: text/x-diff Size: 4202 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100206/b1f04413/attachment.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: hash_bench.c Type: text/x-csrc Si...

On 2010-02-06 17:09, Gregory Petrosyan wrote: > Some additional info can be found at: > > http://murmurhash.googlepages.com/ > http://en.wikipedia.org/wiki/MurmurHash > http://www.codeproject.com/KB/recipes/hash_functions.aspx > > as well as in the patch description itself. Patch and benchmark attached. > > +/// This version additionally assumes that 'len %

On Feb 7, 2010, at 1:03 PM, Gregory Petrosyan wrote: > On Sat, Feb 06, 2010 at 04:51:15PM -0800, Chandler Carruth wrote: >> While I've not reviewed the patch in too much detail, it looks >> promising. Can you run some end-to-end benchmarks to make sure that >> cache pressure in the full program or other variables not accounted >> for in a micro-benchmark don't

...che pressure in the full program or other variables not accounted > for in a micro-benchmark don't dominate performance? Specifically the > nightly tester includes a number of real programs and machinery to > measure total compile time. Ok, now with some kinda-hard numbers! murmurhash2 | superfasthash | - 6.6404 seconds (6.6697 wall clock) | 6.6204 seconds (6.8557 wall clock) + 2.6722 seconds (2.7064 wall clock) | 2.7962 seconds (2.7502 wall clock) + 8.6725 seconds (8.6662 wall clock) | 8.7526 seconds (8.7162 wall clo...

On 13 February 2012 00:59, Talin <viridia at gmail.com> wrote: > Here's my latest version of Hashing.h, which I propose to add to llvm/ADT. > Comments welcome and encouraged. > /// Adapted from MurmurHash2 by Austin Appleby Just out of curiosity, why not MurmurHash3 ? This page seems to suggest that #2 has some flaw, and #3 is better all round: https://sites.google.com/site/murmurhash/ Would it be possible to use CityHash instead for strings? http://code.google.com/p/cityhash/ Thanks, Jay.

Here's my latest version of Hashing.h, which I propose to add to llvm/ADT. Comments welcome and encouraged. On Thu, Feb 9, 2012 at 11:23 AM, Talin <viridia at gmail.com> wrote: > By the way, the reason I'm bringing this up is that a number of folks are > currently working on optimizing the use of hash tables within LLVM's code > base, and unless we can come up with a

Changes with nginx 1.0.1 03 May 2011 *) Change: now the "split_clients" directive uses MurmurHash2 algorithm because of better distribution. Thanks to Oleg Mamontov. *) Change: now long strings starting with zero are not considered as false values. Thanks to Maxim Dounin. *) Change: now nginx uses a default listen backlog value 511 on Linux. *) Featur...

...1:22 AM, Jay Foad <jay.foad at gmail.com> wrote: > On 13 February 2012 00:59, Talin <viridia at gmail.com> wrote: > > Here's my latest version of Hashing.h, which I propose to add to > llvm/ADT. > > Comments welcome and encouraged. > > > /// Adapted from MurmurHash2 by Austin Appleby > > Just out of curiosity, why not MurmurHash3 ? This page seems to > suggest that #2 has some flaw, and #3 is better all round: > > https://sites.google.com/site/murmurhash/ > > The main reason is because there's no incremental version of 3. If you look a...