Xxhash: 更新 README.md 和基准

@Cyan4973你认为你可以在下一个版本之前更新表格吗？

可能，是的。
但我不确定什么是最好的，现在更新自述文件，还是等待v0.8.0更好。

同时，我还设置了https://github.com/Cyan4973/xxHash/wiki/Performance-comparison 。

主要思想是 README 将只能呈现几个数字，这是一种非常概括的视图，而更多涉及的比较将在 wiki 中进行。

我可以等到v0.8.0 。

此外，这些是最新的图表还是仅适用于v0.7.0 ？

不确定它是否是v0.7.0 ，但它绝对不是最新版本。
是的，也要更新。

测试时，能否确保在 GCC+AVX2 上使用-mno-avx256-split-unaligned-load标志？ 这将为 GCC 提供更公平的基准。

当然 ！

我试过了，在mingw64中，发生了一些非常奇怪的事情：
$#$ xxh3 $#$ 的seeded变体最终比非种子变体快得多....

gcc + nosplit + avx2 ，未播种：34 GB/s
gcc + nosplit + avx2 ，种子：45 GB/s
clang + avx2 ，两者：46 GB/s

这是出乎意料的。 unseeded变体应该是更快的变体......

如果有的话， seeded变体检查种子是否是0 ，在这种情况下，遵循unseeded变体，所以它应该是等价的。
但是，基准实际上在每次迭代时都会更改种子，因此seeded变体无法利用此快捷方式。

尽管如此，它并没有解释为什么它_faster_。
seeded变体应该在运行时构建一个新的secret ，然后将新创建的秘密作为参数传递给热循环。 如果有的话，与unseeded变体相比，这是 _more_ 的工作，它只是通过预先计算的secret而不需要任何运行时工作。

我猜 GCC 试图不断折叠kSecret并且失败得很惨。 我得检查组装。

我的速度稍慢（58.9 / 60），但不是您遇到的数量。 这是使用 GCC 9.2.0 在 mingw64 上完成的。

xxhsum.exe 0.7.3 (64-bit x86_64 + AVX2 little endian), GCC 9.2.0, by Yann Collet
Sample of 100 KB...
XXH32                    :     102400 ->    82306 it/s ( 8037.7 MB/s)
XXH32 unaligned          :     102400 ->    81725 it/s ( 7981.0 MB/s)
XXH64                    :     102400 ->   164036 it/s (16019.2 MB/s)
XXH64 unaligned          :     102400 ->   163824 it/s (15998.4 MB/s)
XXH3_64b                 :     102400 ->   603802 it/s (58965.1 MB/s)
XXH3_64b unaligned       :     102400 ->   491521 it/s (48000.1 MB/s)
XXH3_64b seeded          :     102400 ->   614401 it/s (60000.1 MB/s)
XXH3_64b seeded unaligne :     102400 ->   493891 it/s (48231.5 MB/s)
XXH128                   :     102400 ->   574206 it/s (56074.8 MB/s)
XXH128 unaligned         :     102400 ->   489953 it/s (47847.0 MB/s)
XXH128 seeded            :     102400 ->   579336 it/s (56575.8 MB/s)
XXH128 seeded unaligned  :     102400 ->   496284 it/s (48465.3 MB/s)

你有什么 GCC 版本？ 你能运行gcc -S -masm=intel (flags) xxhash.c -o xxhash.s然后给我 xxhash.s 吗？

我在mingw64上使用相同版本的 gcc， v9.2.0 #$ ：
gcc version 9.2.0 (Rev2, Built by MSYS2 project)

另请注意，我正在按照您的建议使用-mno-avx256-split-unaligned-load进行编译。 没有它，两种变体都将降至 30 GB/s。

请注意这是否有意义，但我在为自定义secret保留的堆栈区域前面找到了与XXH_align()语句的直接链接。

在当前代码中，该区域以 8 个字节对齐（不知道为什么）。 如果它在 8 或 16 字节上对齐，那么seeded变体的速度会得到提升。 如果它在32或64字节上对齐，那么速度会 ___down___，达到未播种变体的水平。

这与预期背道而驰。 就好像avx2未对齐的加载比对齐的加载更快。

请注意， kSecret与64字节对齐，但即使我更改了该语句，性能也不会改变。

我看到对齐方式略有变化，但变化不大。

删除优化编译指示并使用-O3有帮助吗？

你能运行 gcc -S -masm=intel (flags) xxhash.c -o xxhash.s 然后给我 xxhash.s 吗？

https://gist.github.com/Cyan4973/6266189692549d2fa9deab7cc086ccfb

更详细的版本：

https://gist.github.com/Cyan4973/bf74a910f1906e16703495cc9f064728

我看到对齐方式略有变化，但变化不大。

我想知道这是否可能是cpu特定的效果......

我得到相同的速度，所以它可能是特定于 cpu 的。

至于详细的版本，我的眼睛：joy：

呃…… @Cyan4973 ，为什么 0.7.3 SSE2 在 Windows 7 x64 上静默执行？ 创建#343。

该死的，这最好不是另一个 Unicode 包装错误.......

Visual Studio 暗示用于 x64 编译的 SSE2

嗯，当然会。 x86_64 需要 SSE2。 这就是我们选择 SSE2（和 NEON）的原因之一，没有兼容性检查。

它还假定 x86 上的 SSE2，因为 Windows 7 及更高版本需要它。

目前，性能比较更新为：
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

在达到v0.8.0时，wiki 的部分内容将用于更新README.md内的性能部分。

README.md已更新为最近的基准测量，从wiki中提取