Question

在我尝试过数百万个48位RGB像素的3种主要哈希算法中，性能差异很小。 Yann Collet的xxHash碰撞次数最少，时间最差（坏）*碰撞（坏）：

Time=0.454 sec  XXH32_HASH_RGB        0.2486% Hash Collisions  =>     
1       time*coll=1.6258  << Lowest Time * collisions
Time=0.490 sec  fasthash32_HASH_RGB   0.2554% Hash Collisions  => 
1.0273  time*coll=1.7878 
Time=0.460 sec  MurmurHash3_x86_32    0.2542% Hash Collisions  => 
1.0225  time*coll=1.6421

MurmurHash3由Austin Appleby编写，并在公众场合......

fasthash32 // Merkle-Damgard构造的压缩功能。

我忽略了PixelMunchingMonster哈希吗？

每个算法一次从内存数组中提供6个字节的数据，并输出32位值。

for(pidx=0; pidx < num_pix; pidx++)  {  // II is uint16 *, need 3/pixel
  time_event(E_XXH32_HASH_RGB, tsa, E_TIME_EVENT, debug);  // HASH! HASH!
  //MurmurHash3_x86_32((const void *)(fmem+pidx*3),6,seed,(void *)(&h32));
  //h32=(unsigned int)fasthash32((const void *)(fmem+pidx*3), 6, seed);
  h32=(unsigned int)XXH32((const void *)(fmem+pidx*3), (size_t) 6,seed);
}

GCC为win7 / 64编译，对我的金属，Intel 2700k进行了微调：

gcc -D__USE_MINGW_ANSI_STDIO -O4 -ffast-math -finline-functions -m64 -Ofast -march = corei7-avx -mtune = corei7 -Ic：/ bin / xxHash-master -Lc：/ bin / xxHash-master c： /bin/stddev.c -oc：/bin/stddev.g6.exe

=============================================== ==

@ BrianP007你的意思是99.76％？如果是这样，你的计算有什么不对，或者你非常幸运。即使具有理想的均匀哈希函数，217MB / 48bpp~ = 36M像素也应该导致仅99.58％的非冲突。 - MooseBoys 1小时前

0.2486％哈希碰撞：89877 Diff_Color_Same_Hash / 36152320 pix

我挖出所有36M像素，将48位RGB压缩成32位散列，然后在每次计算散列时递增散列数据值。

总共36152320像素（7360 * 4912）有3种情况

A）唯一像素，1次点击=＆gt; 27558538

B）2+像素上的相同颜色=＆gt; 8503905

C）相同的哈希，不同的RGB == COLLISION！ =＆GT; 89877

来自badass传感器的量子随机数据是唯一的具体解释！

uint16_t * fmem是内存中的RAW文件BLOB。 PIDX是PIXEL_InDeX，0-36M Num_Pix = 36152320

代码非常白痴。呼！

for(pidx=0; pidx < num_pix; pidx++)  {  
  h32=(unsigned int)XXH32((const void *)(fmem+pidx*3), (size_t) 6,seed);
}

我使用了LOST魔法数字4815162342作为种子。我现在在名单上吗？

=============================================== ======

碰撞计数代码修复和新的碰撞/性能率......

我在碰撞处理代码中发现了一个错误。我只是看着成对的分类哈希。这适用于映射到一个像素/ rgb的唯一哈希，以及由于碰撞或正好共享2个点散列颜色而出现2次相同哈希的情况。

对于给定散列的3个实例的情况，第三个实例将在下一个循环中作为唯一的滑动。

修复方法是向下钻取最后一个哈希值，并将RGB集映射发送到Pixel_IDs映射到哈希值到单一函数。

如果它为具有该哈希值的每个像素返回1个唯一RGB，则不存在冲突：结果：unique_colors ++，冲突未更改

返回N＆gt; 1 RGB =＆gt; unique_colors + = N，collisions + = N

因此，如果4个像素具有共同的哈希值和2个不同的颜色（1个中的3个，其中1个，或2个和2个没有区别），则结果是2次碰撞和2种不同的颜色。

fasthash32                     => 0.6474% Hash Collisions; 0.439, 0.440, 0.440 sec
XXH32                          => 0.6296% Hash Collisions; 0.439, 0.439, 0.438 sec  
MurmurHash3_x86_32 => 0.6448% Hash Collisions; 0.466, 0.435, 0.434 sec

Murmur哈希可能有一个非常轻微的速度领先，但是XXH32的碰撞更少，所以我选择了XXH（尽可能减少意义）

对于额外的功劳，哪个更有效的InLining指令？

XXH和Murmur在＆＃34;＆＃34; FORCE_INLINE＆＃34;

方面不相容

I:\br3\pf.249465> gcc -D__USE_MINGW_ANSI_STDIO -O4 -ffast-math         -finline-function
s -flto -m64 -Ofast -march=corei7-avx -mtune=corei7 -Ic:/bin/xxHash-master -Lc:/
bin/xxHash-master c:/bin/stddev.c -o c:/bin/stddev.g6.exe
In file included from c:/bin/bpb.h:8:0,
                 from c:/bin/stddev.c:44:
c:/bin/xxHash-master/murmur3.c:16:0: warning: "FORCE_INLINE" redefined
 #define FORCE_INLINE __attribute__((always_inline)) inline
 ^
In file included from c:/bin/bpb.h:5:0,
                 from c:/bin/stddev.c:44:
c:/bin/xxHash-master/xxhash.c:90:0: note: this is the location of the     previous d
efinition
 #    define FORCE_INLINE static

注意：每个.c / .h行注释掉项目包含文件，同时测试另一个文件，因此每个文件都会按照自己的方式构建。

数百万UINT64 RGBZ图形像素的最快HASH算法

0 个答案: