我有兴趣优化一些大文件的散列（优化挂钟时间）。 I / O已经进行了足够的优化，I / O设备（本地SSD）仅以大约25％的容量进行分流，而其中一个CPU内核完全超出。
我有更多核心可用，并且将来可能会有更多核心。到目前为止，如果我碰巧需要同一个文件的多个哈希值，我只能使用更多内核，同时说MD5和SHA256。我可以使用相同的I / O流来提供两个或更多哈希算法，并且我可以免费获得更快的算法（就挂钟时间而言）。据我了解大多数哈希算法，每个新位都会改变整个结果，并且它本身就具有挑战性/不可能并行。
是否有任何主流哈希算法可并行化？ 是否存在可并行化的非主流哈希（并且至少具有可用的示例实现）？
由于未来的CPU趋向于更多内核并且时钟速度趋于平稳，有没有办法提高文件散列的性能？ （除了液氮冷却超频？）或者它本身是不可并行化的？
答案 0 :(得分：12)
这个领域实际上有很多研究正在进行中。美国国家标准与技术研究院目前正在举办一场设计下一代政府级哈希函数的竞赛。大多数提案都可以并行化。
一个例子：http://www.schneier.com/skein1.2.pdf
维基百科对比赛当前状态的描述：http://en.wikipedia.org/wiki/SHA-3
答案 1 :(得分：7)
你有什么样的SSD？ MD5的我的C实现在单个Intel Core2内核（2.4 GHz，而不是最新的Intel）上以400 MB / s的速度运行。你真的拥有支持1.6 GB / s带宽的SSD吗？我想要一样！
树哈希可以应用于任何哈希函数。有一些细微之处，Skein规范试图处理它们，在函数本身中集成一些元数据（这不会改变很多性能），但Skein的“树模式”不是提交给的“Skein” SHA-3。即使选择Skein作为SHA-3，树模式哈希的输出也不会与“plain Skein”的输出相同。
希望在某些时候定义标准，以描述通用树哈希。现在没有。但是，已经定义了一些协议，它们支持使用Tiger散列函数的自定义树散列，名称为“TTH”（Tiger Tree Hash）或“THEX”（Tree Hash Exchange Format）。 TTH的规范似乎有点难以捉摸;我找到一些关于草稿的提法，这些草稿已经移动或消失了。
不过，我对这个概念有点怀疑。它有点整洁，但只有当您能够比单个内核处理的数据更快地读取数据时才能提供性能提升，并且，如果正确的功能和正确的实现，单个内核可以每秒散列大量数据。分布在多个内核上的树形散列要求将数据发送到适当的内核，1.6 GB / s不是有史以来最小的带宽。
SHA-256和SHA-512不是很快。在SHA-3候选者中，假设x86处理器处于64位模式，其中一些实现了高速（我的2.4 GHz Intel Core2 Q6600超过300 MB / s，只有一个内核 - 这就是我能得到的例如，SHA-1）宝马，SHABAL或Skein。从密码学的角度来看，这些设计有点太新了，但MD5和SHA-1已经加密“破解”（在MD5的情况下非常有效，理论上对于SHA-1而言）所以任何第二轮SHA-3候选者应该没事。
当我提出我的“预见”上限时，我预见处理器将继续变得比RAM更快，以至于散列成本将被内存带宽相形见绌：CPU将等待时钟周期备用来自主RAM的数据。在某些时候，必须修改整个线程模型（许多核心的一个大RAM）。
答案 2 :(得分：4)
你没有说你需要你的哈希。 如果您不打算与外界交换，只是为了内部使用，只需将每个文件分成块，计算并存储所有校验和。然后，您可以通过向每个核心投掷一个块来使用多个核心。
我想到的两个解决方案是将文件划分为固定大小的块（更简单，但对于不需要所有电源的较小文件将使用较少的内核）或固定数量的块（将为每个文件使用所有核心）。实际上取决于您想要实现的目标以及文件大小分布的样子。
另一方面，如果您需要外部世界的哈希值，正如您可以从其他回复中读到的那样，“标准”哈希值是不可能的（例如，如果您想发送SHA1哈希值以供其他人检查）不同的工具）所以你必须看看别的地方。就像在存储文件时计算哈希值，以便以后检索，或者在后台使用“免费”核心计算哈希值并存储以供以后检索。
更好的解决方案取决于您的约束条件以及投资空间，时间或CPU功率的位置。