最大限度地利用并行和树散列的API设计。

Question

传统上，哈希函数是单线程的，并且具有'Init-Update-Final‘API样式.这是对MD5，SHA-1/2/3，BLAKE2，举几个例子。

然而，也有并行散列函数和树散列的建议.BLAKE3和KangarooTwelve就是其中之一。

如果我们继续使用IUF，那么数据可用性可能成为影响整体性能的瓶颈。我可以想象，这些散列函数是“活动的”，因为它们被提供了一个大的，有时是完整的消息blob，因此散列API子程序可以自行决定如何使用数据，以及如何生成线程。

我可以想到的另一个问题是，系统负载与创建用于数据处理的并发线程有关。在IUF哈希实现中，资源使用可以限制在执行散列算法和保持散列上下文状态的使用上；但是为并行和树散列创建线程需要系统资源来支持线程和相关的同步原语。后者可能需要调用者/用户配置和调优，我相信。

我能想到的另一个问题是，在早期消息段之前到达后消息段的问题。虽然进程和缓冲区的简单解决方案是显而易见的，但太多的可处理段可能会成为内存维度中进程的一个burdon。

现在，在我开始在我的业余项目中实现并行和树散列算法之前，我应该了解典型和/或理想的API设计，它可以最大限度地提高这些类型散列算法的性能潜力。

附带注意:对类似于调度的API适配将是一个额外的好处。具体来说，如果答案既讨论了典型线程API(例如C11和/或POSIX线程)的使用，又讨论了类似调度的API，比如苹果的Grand Central Dispatch。我认为这是有好处的，因为我同意他们的文档，认为让系统根据需要动态创建和销毁线程是有益的。在这方面，对动态线程池的接触也将被视为一种奖励。

Answer 1

数据可用性

这可能是最不值得关注的问题。如果数据以比哈希算法实现慢得多的速度可用，那么这不是瓶颈。

系统负载

这是一个真正的问题，但不是一个重大的问题。任何有能力进行并发编程的程序员都可以编写在这方面高效的代码。

稍后到达

的早期段

对此可能没有很好的解决办法。没有一个有界能力的系统能够处理无限多的无序数据段。

API设计

并发对象

模型

现在大多数并发API都具有async-await语义，这很简单，它们也很适合类似调度的模型。大多数线程池API也有“异步”部分，但不一定是“等待”部分。

这就是为什么，在我的实验中，我选择了一种“队列-等待”方法，其中

• enqueue操作将作业放入线程池，
• await操作等待的不是一个特定的作业，而是所有当前排队的作业。

我还列出了调用者必须避免的一些未定义的行为。

哈希实现的

API设计

有关演示，请参见这

初始化函数保持不变。它的功能与其单线程对应的功能没有明显的变化。

update函数现在接受上述并发对象的实例，因此可以调用它来利用主机平台上的线程级并行性。

终结功能现在不同了。在此之前，单线程终结函数接受散列上下文，计算最终摘要，并设置一些终结保护，以防止它再次完成。

但是，通过并行和树散列，工作上下文中可能留下的数据还没有散列，因为update函数无法根据需要确定。因此，终结函数现在也接受并发对象的实例。

最后，我们有一个专门的阅读功能。对于许多传统的散列函数，“摘要读取”函数通常从一开始就读取散列摘要。然而，到目前为止，我们遇到的大多数并行和树哈希函数实际上都是XOFs。为了允许以两种方式读取它们，我在read函数中添加了一个“标志”参数，目前只支持“倒带”标志。