C++ 我需要批处理并行编程吗？

我正在写一个带有EM处理（雷达应用）的光线跟踪器。对雷达的许多不同模拟位置执行以下操作：

光线跟踪会生成大量数据

EM后处理，生成标量，然后删除光线跟踪数据

每个模拟点将封装在其自己的类实例中（全部分组在一个

std:：vector

），其中包含该模拟点的雷达位置规范、仅读取的数据引用（由所有模拟点共享）以及用于存储其结果的属性（因此每个模拟点都有自己的属性）。由于这种设置，我认为使用

for_each

循环和

std:：execution:：par_unseq

策略，而无需采取进一步措施，可以从中获益。对吗

---

然而，问题是光线跟踪生成的数据太多，例如，当有10000个模拟位置时，当调度程序决定首先执行所有光线跟踪时，我可能会耗尽内存，因为允许使用

par unseq

执行此操作。因此，我的想法是为循环编写一个普通的

，为每个

循环提供一个内部并行的

，比如说，当时有100个模拟点。这对我的情况来说是最佳解决方案吗？还是我完全误解了并行事物的工作原理？
引用标准，
§25.3.3/8
，可以发现（我的重点）：

执行
时调用的语义​::​未排序的策略
，
执行​::​并行策略
，或执行​::​并行未排序策略

允许在系统无法并行算法调用（例如，由于缺乏资源）时，实现退回到顺序执行

---

因此，标准允许实现在遇到资源占用时退回到顺序执行。

退回到顺序处理不是一个非常严重的惩罚，如果您能够自己防止这种情况，您会更好吗？我会认为，如果批处理的数量远远大于内核的数量，那么额外的惩罚是非常有限的，但你总是把资源放在安全的一边。@JeroenBoschma两点。退回到顺序处理可能会导致严重的损失，但是如果内存不足，您就没有选择了，是吗？第二，虽然您可能会想出自己的手动缓解方法，但它必须在安全和性能方面与您正在使用的标准库实现竞争。假设我赌的是实现该库的团队。如果您实现了它，我鼓励您度量和比较这两种方法。安全性是另一个更难一目了然评估的问题。一个虚拟的示例代码片段可能比一堆文本更能说明问题。当您需要对线程进行细粒度控制时，可以手动安排。您还可能受益于消息队列之类的功能。