Rust中的高吞吐量流处理( 二 ) _Rust

文章插图
图片
哦！带通道的新版本花费了两倍时间，这是怎么了？
2.环形缓冲器你可以用火焰图进行测试，但还是省省时间吧！
无论多小，所有通道库的构建都会产生额外的费用，并行化所带来的好处必须大于此种开销，才能保证系统正常运作。这种情况下的瓶颈是通道send（）和recv（）。由于Rust中的标准库mpsc通道相对缓慢，但仍有其它替代方案，比如，crossbeam-channel 。
为此，我们分析了4个不同的通道库，结果如下：

文章插图
图片
显然，ringbuf和rtrb速度最快。因为它们的环形缓冲区无锁，扮演着“单个生产者-单个消费者”的角色。单个生产者意味着只有一个管道将数据放入队列，另一个管道将负责数据输出，这比“多生产者队列”开销小。
此外，这些程序库也是非阻塞式的。当队列已满时，如果尝试推送，它将提示“error”而不是“block”，“空队列”亦是如此。
为使用这些环形缓冲区库，我添加了自旋锁，以便在通道阻塞时继续重试。事实证明，这也是高频交易架构中所使用的方法。
我还发现，在等待时增加非常短的“休眠”时间整体性能就能提高。这可能是由于当核心使用率达到100%或高于某些温度时，启动CPU就会发生节流的现象。
如下是新的pop()和push(value)帮助器：

文章插图
图片
我们将用新方法展示：

文章插图
图片
【Rust中的高吞吐量流处理】速度确实比以前快了，但也快不了多少，现在，就让我们把并行化提升至另一个层次。
3.更多的并行化目前，我们为哈希创建了两个线程，一个用于SHA512，另一个用于BLAKE3 。两者中较慢的那个将成为我们技术发展的瓶颈。为证明这一点，我重新运行了原始的单线程示例，仅使用SHA512哈希，结果如下：

文章插图
图片
这与并行哈希示例中的性能非常接近，意味着，总体上花在哈希上的大部分时间都是由SHA512产生。
那么，如果我们同时创建更多的线程并将多个数字进行散列排列呢?让我们试一试。我们将创建2个SHA512哈希线程和2个BLAKE3哈希线程来启动。
4.可视化每个线程都拥有自己的输入和输出队列。我们将用循环顺序将生成的数字循环发送至每个线程并用相同的顺序读取结果。