Xxhash: XXH3 图表未显示，添加更多哈希

虽然我找不到我的 Pentium 3 笔记本电脑的充电器，但我确实有一堆旧的 Pentium 4 塔，当我们用 Core 2 Duos 替换它们时，它们运行良好，我可能可以在其中一个上运行一个长凳.

同意。
我打算有 2 个部分用于基准测试，其中一个专门用于需要特殊硬件支持的哈希。

xxh3 图表似乎没有显示在 README.md 上。

是的，这是一个令人讨厌的点。 图表存储在“发布”部分，以便注意“污染”存储库。 它们可以从其他网站上看到，我在XXH3 blogpost 演示文稿中使用它们。 它也适用于我的降价编辑器。 但是，当从 Github README.md链接时，它不再显示。 我看不出一个很好的理由，这似乎是 Github 特有的限制。

因此，将需要解决方法。
如果可能的话，我真的希望不污染存储库，尽管这是我目前的 B 计划。 我过去一直使用的其他图像托管服务被证明是不可靠的，所以我几乎没有选择。

为什么不把它放在 gh-pages 分支并与raw.githubusercontent.com链接？

URL 转换如下：

https://github.com/user/repo/blob/master/path/to/file
https://raw.githubusercontent.com/user/repo/master/path/to/file <= note: no /blob/

gh-pages分支仍然有助于存储库的权重。 这将导致git clone下载更多数据。

话虽如此，这种方法比将图像直接放在活动分支dev中有所改进。

好吧，我认为您的折线图作为 SVG 会更好。 zopflipng 只能将其缩小到 320K，甚至将其缩小 50% 并再次压缩只能将我们带到 203K。

我怀疑一个优化良好的 SVG（如果你给我一份我可以优化它）会占用那么多，虽然

这是我机器上的高速公路和喵。 喵哈希显然无法在缓存行中幸存……

（哎呀，它以字节为单位……我希望我有 6 GB 的缓存 :joy :)

您的折线图作为 SVG 会更好

我不太了解svg ，但我担心演示文稿质量的控制。
使用png文件，我知道它的外观，因此知道它的显示方式。
相比之下， svg文件必须由“某物”解释，我不确定这种解释有多普遍、丰富或同质。

svg图表的一个很好的例子可以在这里看到：
https://github.com/injinj/smhasher

与我过去看到的平均svg图表相比，它们相当不错，但即使在那里，绘图质量似乎也因浏览器而异，我更喜欢excel演示风格.

顺便说一句，你自己的png图表的来源是什么？ 它似乎由 github 托管。

此外，svgs 非常标准，它们总是看起来不错。

我不能把它拖放到编辑器中，所以我把它放在svgshare上。 但是，那肯定是 SVG。

此外，在我的示例中，优化的 PNG 为 27k，而 SVG 为 56k（此处未优化）。 但是，您的图表可能会有所不同，因为您的图表要大得多。

但是， gzip -9 -k "Hash speeds-2.svg" -c > "Hash speeds-2.svgz"只产生 10 kb（是的，svgz 只是压缩了）

链接到交互式版本怎么样（假设这是我 99% 确定的 Google 表格）？

你可能有一个低分辨率的 png 或 svg，当他们点击它时，他们可以看到实际数据。

这看起来是个好主意。

不要以为我对这些东西一无所知。 这不是 Google 表格，我只是使用基准程序生成.csv格式的跟踪，并将其导入我的本地 tabler，MS Excel for Mac，以创建图形。 我将不得不学习如何以一种令人愉快的演示方式将所有这些联系起来。 我确信它充满了我无法想象的小细节，虽然一切都可以学习，但需要时间，这是一种供不应求的资源。

嗯，看起来强大的 Pentium 4 仍然存在。 但是它没有硬盘，所以它是 live USB（我在想 Arch Linux 32，因为我的 VM 上有 Manjaro）

您是否拥有用于基准测试的原始代码树（或至少是存储库和提交哈希）？ 我希望最好使用完全相同的版本，因此这是一个公平的比较，因为散列函数的更改会影响结果。

一种进行令人愉快的演示的方式

使用 Google Docs，我可以做到：

点击互动版

要在 Github markdown 中执行此操作，您必须混合使用 html 和 markdown：

[<img src="http://example.com/image.png"/>](http://example.com)

不幸的是，尽管图表是交互式的，但它看起来像是一个栅格。

终于启动了奔腾4。

戴尔尺寸 8300
3.0 GHz Intel Pentium 4 HT，512 KB 高速缓存
高达 256 MB 的 RAM 哈哈
XenialPup 7.5，因为我必须把它放在 CD 上——这东西太旧了，不能用 USB 驱动器启动。

现在，我使用了我在讨论线程中发布的调度二进制文件。

XXH32: 790.1 MB/s
XXH32 unaligned: 651.2 MB/s
XXH64: 365.5 MB/s
XXH64 unaligned: 320.6 MB/s
Using HashLong version __XXH3_HASH_LONG_SSE2
XXH3_64bits: 5043.7 MB/s
XXH3_64b unaligned: 4490.6 MB/s

这里没什么有趣的。 真是浪费时间。 ：傻笑：

哇，我从来不知道这东西真的是一台时间机器！

这种性能提升实际上是有道理的，因为 Pentium 4 毫无意义。 如果我的计算是正确的，单次 XXH32 迭代将需要高达 169 个周期，这要归功于其乘数上惊人的 14 个周期延迟。 但是， pmuludq只需要 7 个周期。 🤔

不幸的是，由于我们只有 256 MB 的 RAM，并且没有可以交换的驱动器，因此 benchHash 实用程序可能会出现一些问题：

benchmarking large inputs : from 512 bytes (log9) to 256 MB (log28)

钱币

我绝对想在一次运行中做尽可能多的哈希，但首先我需要稍微增加内存。 我知道塔可以一直到 4GB（这在 2004 年是疯狂的），而且周围有一堆旧的 RAM 棒，所以是的。

您是否拥有用于基准测试的原始代码树（或至少是存储库和提交哈希）？

只需使用发布标签v0.7.0 。
此外，通常dev分支尚未集成xxh3分支中的更改，因此它应该与v0.7.0具有相同的算法。

我们可能对 benchHash 实用程序有一点问题：

有一个（隐藏的）命令可以选择尺寸范围：

--minl=# : log size of smallest large-size test (default 9)
--maxl=# : log size of largest large-size test (default 28)

只需使用发布标签 v0.7.0。

不，我的意思是额外的哈希值。 您只需在源代码树中对 xxHash 进行基准测试。 或者，更好的是，让我们就哈希列表达成一致，这样我们就可以拥有相同的基准。 在那种情况下，我们会试探。 想使用 xxh3 分支。

• xxhashes 明显
• 公路哈希
• 杂音3
• SipHash13（所以我们可以展示它有多慢，因为那是“快速”版本）
• 城市64
• 农场哈希
• fnv64
• 冲突
• 海哈希
• 妈妈v2

SeaHash 非常慢，并且来自破坏 City64 和 Murmur 的同一个人是“完全不安全的” 。 您可以通过diffuse() 的输出对其进行异或运算，并将整个散列清零。

./xxhsum 0.7.0 (64-bits x86_64 + SSE2 little endian), Clang 8.0.0 (tags/RELEASE_800/final), by Yann Collet
Sample of 100 KB...
XXH3 mode: SSE2
XXH32               :     102400 ->    51483 it/s ( 5027.6 MB/s)
XXH32 unaligned     :     102400 ->    50516 it/s ( 4933.2 MB/s)
XXH64               :     102400 ->    74442 it/s ( 7269.7 MB/s)
XXH64 unaligned     :     102400 ->    72993 it/s ( 7128.3 MB/s)
XXH3_64bits         :     102400 ->   176086 it/s (17195.9 MB/s)
XXH3_64b unaligned  :     102400 ->   177122 it/s (17297.0 MB/s)
SeaHash             :     102400 ->    42722 it/s ( 4172.1 MB/s)
SeaHash unaligned   :     102400 ->    42410 it/s ( 4141.6 MB/s)

我们应该制作一个依赖收集脚本，这样它就可以为基准下载相同的版本，而不会将它们直接放在树中。

旁注：Safari 的日志可能会有所帮助：

这种多哈希比较器最好作为它自己的单独项目处理，因此克隆这个存储库实际上只是获取xxhash库。

基准程序已经为此设计：所有哈希依赖项都在hashes.h中声明，因此它是唯一需要更新的源文件（此外， Makefile将需要为这些引用其他源文件其他哈希）。

我当然可以在我的帐户下打开这样的项目，但有一个重要的副作用：作为xxhash的作者，结果可能会因怀疑偏袒而“受到污染”。
因此，也许我“只是”发布一个基准引擎并让其他人运行它会更好吗？

好的，现在我有 Google 的 Sip 和 Highway、xxhashes、t1ha2（由于 PIC 问题无法连接 t1ha0）、Meow、City64 和 Farm64。

我收集了周围所有的 512 MB 存储棒，将 Pentium 设置为 1.5 GB，这会好得多。 它现在也可以将 Puppy 存储在 RAM 中。 我本可以把它调到 2，但其中一个插槽似乎坏了。

我要让它消失，但首先，我将在 virtualbox 中运行 32 位二进制文​​件的 MacBook 上的值。 （仅限 i686，SSE2）

当然，我可能应该在其中扔一些 32 位哈希。

废话，我才意识到我使用了更新版本……😖

benchHashLog.txt
这是日志

HighwayHash C 是可悲的大声笑

我已经更新README.md以便图表现在可以直接看到。
图表只是存储在 github 问题板上。