search for: lookup3

...still correlate directly to performance. OK, now with real numbers :-) First, the main thing: SuperFastHash appears to be the hash with best distribution. Use of MurmurHash instead generates 1.28% more collisions while doing nightly test in MultiSource/Applications. Second: I've also tested lookup3 hash, and its use generated 0.1% more collisions, compared to SFH. These results were a bit surprising for me! Number of hash table resizes is independent of used hashing algorithm, because hash table grows when 'nentries > nbuckets * 2'. Gregory

I'm working on a bug where LLVM takes over six minutes to compile a module. After some hand-editing, the module looks like this: class half { private: union uif { unsigned int i; float f; }; static const uif _toFloat[1 << 16]; }; const half::uif half::_toFloat[1 << 16] = { {0x00000000}, {0x33800000}, {0x34000000}, {0x34400000}, {0x34800000},

Stuart Hastings a écrit : > > { > {0x00000000}, {0x33800000}, {0x34000000}, {0x34400000}, > {0x34800000}, {0x34a00000}, {0x34c00000}, {0x34e00000}, > {0x35000000}, {0x35100000}, {0x35200000}, {0x35300000}, > {0x35400000}, {0x35500000}, {0x35600000}, {0x35700000}, > ... > {0xfffd8000}, {0xfffda000}, {0xfffdc000}, {0xfffde000}, > {0xfffe0000},

Hello World, I am trying to build NSD4 on Debian Squeeze and I get the following errors when running `make`. ``` $ pwd /home/wiz/src/nsd/tags/NSD_4_0_0_imp_5 $ make [... output omitted ...] gcc -g -O2 -o nsd-checkconf answer.o axfr.o buffer.o configlexer.o configparse acket.o query.o rbtree.o radtree.o rdata.o region-allocator.o tsig.o tsig-opens 4_pton.o b64_ntop.o -lcrypto configparser.o: In

.... > > OK, now with real numbers :-) > > First, the main thing: SuperFastHash appears to be the hash with best > distribution. Use of MurmurHash instead generates 1.28% more collisions while > doing nightly test in MultiSource/Applications. > > Second: I've also tested lookup3 hash, and its use generated 0.1% more > collisions, compared to SFH. > > These results were a bit surprising for me! > > Number of hash table resizes is independent of used hashing algorithm, because > hash table grows when 'nentries > nbuckets * 2'. Thanks for doing...

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

...8439879 Seq=2996061989 Len=0 Win=24820 183 0.00021 winclient -> sambaserver TCP D=111 S=4559 Ack=2996061990 Seq=418439879 Len=0 Win=64208 184 0.08077 winclient -> sambaserver NFS C NULL3 185 0.00016 sambaserver -> winclient NFS R NULL3 186 0.00024 winclient -> sambaserver NFS C LOOKUP3 FH=0000 /home 187 0.00015 sambaserver -> winclient NFS R LOOKUP3 Permission denied 188 0.00025 winclient -> sambaserver MOUNT3 C Null 189 0.00025 sambaserver -> winclient MOUNT3 R Null 190 0.00022 winclient -> sambaserver MOUNT3 C Mount /home 191 0.00302 sambaserver -> winc...

...n=0 Win=24820 > 183 0.00021 winclient -> sambaserver TCP D=111 S=4559 Ack=2996061990 > Seq=418439879 Len=0 Win=64208 > 184 0.08077 winclient -> sambaserver NFS C NULL3 > 185 0.00016 sambaserver -> winclient NFS R NULL3 > 186 0.00024 winclient -> sambaserver NFS C LOOKUP3 FH=0000 /home > 187 0.00015 sambaserver -> winclient NFS R LOOKUP3 Permission denied > 188 0.00025 winclient -> sambaserver MOUNT3 C Null > 189 0.00025 sambaserver -> winclient MOUNT3 R Null > 190 0.00022 winclient -> sambaserver MOUNT3 C Mount /home > 191 0.003...

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 dominate performance? Specifically the > nightly tester includes a number