Xxhash: 在基准测试中添加 Meow 哈希

meow_hash 完全取决于硬件加速 AES 指令的存在。

我怀疑它在没有这些指令的情况下甚至不会编译，因为代码很短，而且我没有看到任何软件备份代码路径。 此外，我可以读取的所有 AES 指令都使用直接的 Intel 内在指令，因此无论硬件功能如何，它都不能跨架构移植。

这不一定是“坏”的事情：毕竟，作为回报，他们获得了长输入的极快速度。

但重点是：依赖于这种专门的硬件指令集，可移植性不在功能列表中。

作为副作用，它甚至无法在用于 xxHash 基准测试的平台上运行。

也许我应该花一些时间记录下来。

这不再是真的，你应该重新审视这个。

是的，看了公告，喵喵在几次修改中改进了很多。
它甚至宣布与 ARM 兼容。

我需要一些时间来深入了解它。

我只是粗略的看了一下，没有找到软件备份路径。 也许它就在那里，而我只是错过了它。
此外，我还不知道不同的 AES 硬件模块是否能保证产生完全相同的哈希值，或者是否有更多的哈希值（比如可能以不同方式预设并需要机器特定指令统一的附加参数）。 在本地计算和使用散列是一回事，在这种情况下，精确表示并不重要。 写入/序列化值并期望在任何其他系统上准确读取/复制它是另一种方式。 互操作性的那部分有点棘手。
但再一次，也许它就在那里，我只是需要一些时间来研究它。

作为参考，这是针对我的最新版本 2.0 GHz Core i7 Gen 2 (Sandy Bridge)

叮当 7.0.1
标志： -O3 -march=native

./xxhsum 0.6.5 (64-bits little endian), by Yann Collet
Sample of 100 KB...
XXH32               :     102400 ->    54765 it/s ( 5348.2 MB/s)
XXH32 unaligned     :     102400 ->    53782 it/s ( 5252.1 MB/s)
XXH64               :     102400 ->   104882 it/s (10242.4 MB/s)
XXH64 unaligned     :     102400 ->   105935 it/s (10345.2 MB/s)
XXH32a              :     102400 ->    78027 it/s ( 7619.8 MB/s)
XXH32a unaligned    :     102400 ->    75624 it/s ( 7385.2 MB/s)
XXH64a              :     102400 ->    77204 it/s ( 7539.5 MB/s)
XXH64a unaligned    :     102400 ->    76209 it/s ( 7442.3 MB/s)
XXH auto            :     102400 ->   105179 it/s (10271.4 MB/s)
XXH auto unaligned  :     102400 ->   101546 it/s ( 9916.6 MB/s)
XXH32 auto          :     102400 ->   107646 it/s (10512.3 MB/s)
XXH32 auto unaligne :     102400 ->   104364 it/s (10191.8 MB/s)
XXH64 auto          :     102400 ->   107443 it/s (10492.4 MB/s)
XXH64 auto unaligne :     102400 ->   105843 it/s (10336.3 MB/s)
meow auto           :     102400 ->   214435 it/s (20940.9 MB/s)
meow auto unaligned :     102400 ->   213289 it/s (20829.0 MB/s)

使用-march=penryn -mno-sse4.2 -mno-avx和 C 实现：

./xxhsum 0.6.5 (64-bits little endian), by Yann Collet
Sample of 100 KB...
XXH32               :     102400 ->    54106 it/s ( 5283.8 MB/s)
XXH32 unaligned     :     102400 ->    53303 it/s ( 5205.4 MB/s)
XXH64               :     102400 ->   107245 it/s (10473.1 MB/s)
XXH64 unaligned     :     102400 ->   107774 it/s (10524.8 MB/s)
XXH32a              :     102400 ->    78394 it/s ( 7655.6 MB/s)
XXH32a unaligned    :     102400 ->    79666 it/s ( 7779.9 MB/s)
XXH64a              :     102400 ->    78907 it/s ( 7705.7 MB/s)
XXH64a unaligned    :     102400 ->    78179 it/s ( 7634.6 MB/s)
XXH auto            :     102400 ->   108878 it/s (10632.6 MB/s)
XXH auto unaligned  :     102400 ->   105124 it/s (10266.0 MB/s)
XXH32 auto          :     102400 ->   105819 it/s (10333.9 MB/s)
XXH32 auto unaligne :     102400 ->   103970 it/s (10153.3 MB/s)
XXH64 auto          :     102400 ->   110021 it/s (10744.2 MB/s)
XXH64 auto unaligne :     102400 ->   107109 it/s (10459.9 MB/s)
meow auto           :     102400 ->    15962 it/s ( 1558.8 MB/s)
meow auto unaligned :     102400 ->    16022 it/s ( 1564.6 MB/s)

这不再是真的，你应该重新审视这个

...aaand 在 Meow 0.5 中又是这样； 在最新版本中，他们再次只有 x64 AES 代码路径 :)

所以是的，Meow Hash 有点特定于 x86_64 和 Nehalem+，或者它必须切换到慢速 af 回退版本。

同时，XXH3 为所有 x86_64（包括 Core 2 和朋友）、Pentium 4+（Windows 7+ 需要）、ARMv7-A w/NEON（适用于大多数 Android 和所有 iOS 设备（原始 iPhone 除外） )、ARM64（所有最近的 iPhone 和 Android）、VSX POWER9（许多服务器和超级计算机都有这些，但它是一个小众市场），如果这还不够，即使是标量版本，即使在 32 位上也仍然非常快目标，因为它们有一个不错的乘数。

我开始收集更多的基准测试结果，因为这些年来有几个此类请求。
从这个开始，这是一个经常性的请求。

meowHash确实非常快，对于大数据（~100 KB）的得分与XXH3大致相同，因此比XXH128快一点。
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

话虽如此， meowHash确实是为大数据设计的。 当涉及到_small_数据时，性能没有可比性，因为该算法需要很大的固定成本，在小数据上很难摊销。

一个令人担忧的发展是“如何表示和解释结果”存在差异。
对于大数据，它相当简单，一个排序表就足够了，可以立即了解排名。
但是对于小数据，它似乎更复杂。
到目前为止，我已经使用了图表，提供了每个不同长度和场景的速度结果。 凭借 _more_ 信息的特点，它必然更难以解释。

因此，不清楚读者在找到突出的顶部表格中的第一个性能数据后，是否会费心查看下面的其他图表，从而指导其选择，同时可能会遗漏其用例的重要信息。

另一个问题是关于图表本身。 可以相对容易地扩展排序表。 当然有限制，但一般来说，添加一个竞争者只会增加一行。
但是，在图表中，每个竞争者都由一条线表示。 线条往往重叠。 只有这么多颜色可供选择等等。很快，如果代表的竞争者的数量很大，那就是一团糟。
因此，如果小数据性能需要图形，则严重限制了可以表示的竞争者数量。

添加包含“原始”基准数据的段落虽然值得称道，但却是一个糟糕的替代品。

因此，我正在考虑“总结”小数据测试结果，并创建一个可以在排名表中使用的“性能数字”，以至少给出小数据总体性能的提示。 有兴趣的读者仍然需要寻找更准确的信息（图表），但至少可以以相对简单的方式传达某些算法比其他算法更适合小数据的概念。

仍然存在一个问题，即图表只能代表有限的 nb 个竞争者，而且可能读者想要观察的那个不是所选列表的一部分（即使原始数据可用）。

我想知道是否有更好的方法来表示图形。 比准备好的屏幕截图更动态的东西，允许用户选择哪些竞争者应该可见。

相比之下添加了喵喵哈希：
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

向表中添加条目很好。
但是我仍然需要一种更好的方法来为大量候选人绘制图表。