问题标签 [rayon]

Rayon看起来非常适合集合的算法并行化，Faster非常适合 x86 平台上的矢量化 (SIMD)，例如Vec<f32>. 我试图将它们结合起来，迭代器似乎彼此不喜欢。有没有办法将这两个库用于可以同时受益于矢量化和并行化的算法？就像 Faster 示例中的这个：

我正在使用人造丝来产生相当大的返回值。将所有返回值收集到Vec. 有没有办法避免创建Vec并直接作为可迭代对象使用？

这是一个不起作用的示例：

操场

有没有办法检测人造丝中的溢出并迫使它恐慌而不是无限循环？

操场

The Rayon documentation say it guarantees that using Rayon APIs will not introduce data races.

How can the compiler know that the method called by the closures is not sharing mutable state, for example RefCell<T> and Cell<T>, or using structs that are not thread-safe, for example Rc<T>?

I understand that core::marker::Sync marks types that are safe to share between threads but I don't understand how the Rayon type declarations and the compiler enforce it!

我正在尝试从标准输入中逐行读取 JSON 对象流，并从它们中提取“值”键作为字符串：

eprintln!()永远不会被调用并且我的内存不足，因为我使用一个巨大的文件作为输入。为什么map()不只返回一个我可以使用的迭代器，而是等待它的输入结束？

我试图找到一个矩阵的鞍点，一个借来的向量数组。为此，鞍点是矩阵的一个元素，它要么在其列中最小且在其行中最大，要么在其列中最大且在其行中最小。

错误在最后.collect：

我知道这是由于迭代器受到collect函数不是预期类型的​​影响，但对我来说它应该是正确的，我不清楚为什么它不是。

我正在考虑使用 Rayon 的并行迭代器功能，但我担心迭代小集合的性能。

并行开销有时会导致小型集合的速度变慢。如果我为多线程做必要的准备，那么迭代 2 个元素比使用单线程版本要慢。如果我有 4000 万个元素，并行性会给我带来线性的性能提升。

我读到了ParallelIterator::weight(0.6.0)，但我不明白我是否应该为小型收藏品优化这种极端情况，或者 Rayon 是否聪明并处理引擎盖下的所有事情。

已ParallelIterator::weight处理元素的 为 1。有关良好定义，请参阅相关文档，但处理单个元素很便宜。

谷歌把我送到了一个旧的文档页面。自 0.8.0 版以来Weight已弃用并删除。

我想将 Select.rs 的Find-iterator 转换为 Rayon ParallelIterator。我无法通过简单地使用 API 来做到这一点。我怀疑我必须实现或扩展一个特征，但我不知道该怎么做。

我试过收集 Iterator 和 using into_iter，但无济于事。

这会导致错误

我看到该方法par_iter不存在，但该方法似乎也不存在iter。

我认为有一种方法可以实现这一点，而无需创建对 select.rs 的拉取请求 - 无论哪种方式，我们都将不胜感激。

我有一个从各种输入生成哈希的函数。我想存储一个这样的哈希，Arc<[u8; 16]>以便我可以在线程和结构之间共享它。之前，我将它存储为Vec<u8>，通过通道传递，然后将其转换为[u8; 16]本地。显然效率低下，因此Arc<[u8; 16]>. 但是当我进行转换时，我得到了这样的错误：

还有11个这样的错误。的所有一些变化Foo cannot be shared between threads safely。这是所有错误的要点。

这是我的代码片段：

这是完整的来源。
弧文档
人造丝文档

编辑：忘了提到我使用的是 2018 版稳定版。

语境

我有一个情况，多个线程必须更新存储在共享向量中的对象。但是向量很大，要更新的元素数量比较少。

问题

在一个最小的示例中，要更新的元素集可以由包含要更新的元素的索引的（散列）集来标识。因此，代码可能如下所示：

这在 Rust 中显然是不允许的：big_vector_of_elements不能同时在多个线程中可变地借用。但是，将每个元素包装在例如Mutex锁中似乎是不必要的：这种特定情况在没有显式同步的情况下是安全的。由于索引来自一组，因此它们保证是不同的。没有两次迭代par_iter接触向量的同一个元素。

重申我的问题

编写一个并行改变向量中元素的程序的最佳方法是什么，其中同步已经通过选择索引来处理，但是编译器不理解后者？

一个接近最佳的解决方案是将所有元素包装big_vector_of_elements在某个假设的UncontendedMutex锁中，这将是一种变体，Mutex在无竞争的情况下速度快得离谱，并且在发生争用（甚至恐慌）时可能需要任意长的时间。理想情况下，对于 any ， anUncontendedMutex<T>也应该与 , 具有相同的大小和对齐方式。TT

相关但不同的问题：

多个问题可以用“使用 Rayon 的并行迭代器”、“使用chunks_mut”或“使用split_at_mut”来回答：

• 如何在分区数组上运行并行计算线程？
• 并行处理 vec：如何安全地做，或者不使用不稳定的特性？
• 如何将不相交的切片从向量传递到不同的线程？
• 不同的线程可以写入同一个 Vec 的不同部分吗？
• 如何让每个 CPU 内核可变地访问 Vec 的一部分？

这些答案在这里似乎无关紧要，因为这些解决方案意味着迭代整个big_vector_of_elements，然后为每个元素确定是否需要更改任何内容。从本质上讲，这意味着这样的解决方案如下所示：

该解决方案所花费的时间与 的大小成正比big_vector_of_elements，而第一个解决方案仅在与 的大小成比例的多个元素上循环indices_to_update。