C 将子线程拆分为新的子线程（Openmp）

我有一个关于多线程（Openmp和C代码）的问题

我将在给定文本文件中搜索16个不同的单词。方法是创建一个for循环，该循环在包含要搜索的每个单词的数组中运行。16个不同的单词表示可以同时运行的16个不同线程。使用多线程的另一种方法是将文本文件切成x个大小相似的块，并同时搜索每个块。 我的问题是：我是否可以使用多线程为每个单词创建一个线程，然后将特定的子线程拆分为新的子线程，以扫描一个大小的数据块

如果这不可能/不可行，我想唯一的解决方案是手动将文本文件拆分为不同的字符数组，然后对我要搜索的每个单词使用#pragma

---

将仅对文本文件执行读取操作，写入操作仅限于分配给每个字的变量，用于计算目的。也就是说，除非我错过了什么，否则将不会有比赛条件。

首先，16个单词并不意味着16个不同的线程。每个线程本身都会带来诸如同步开销、不平等的工作分配、繁殖松弛时间等因素，如果不仔细计算，将导致完全损害并行性的好处

在工作数据之间没有依赖关系的情况下，可以极大地利用并行性。您的工作独立于您所表达的任何一种可能的解决方案中的工作数据。要在大量字符池中查找某些字符，与字符的排列无关（例如，在每个“C”之后查找“++”，而不是查找“+”）

现在的问题是如何利用内存带宽，以及如何通过“分支预测”消除丢失的内存

不同线程的公共数据在内存受限的情况下非常好。第一个读取数据的线程将数据加载到缓存中，而其他线程最终将利用这一数据块。因此，数据只能从内存中加载一次。分割数据还将导致从内存中只加载一次数据，因为每个线程将加载其部分，然后清除。因此，这两种情况下的内存负载非常相似

您的代码被称为“逻辑绑定”。分支预测是需要注意的一个非常重要的方面，但非常棘手。通用数据模块发生故障的概率很高。假设你必须在一百万个球中找到一个红色的球。这种预测倾向于做出“不在场”的自然选择。但是如果它在前100个球内失败，那么失败后所有处理过的球都将在重做中结束，您将回到原点。相反，在拆分的情况下，“重做”的最坏情况不会像公共数据那样糟糕。但我们不能保证这一点

选择上述任何模块完全取决于您所使用的体系结构

SMT/逻辑核与物理核。在SMT中使用上述任何一种方法都会导致性能降低，而物理核的数量相同您将一个线程拆分为子线程的想法是SMT的基础。每个新线程都会增加资源追逐的开销，同时还可能导致分支预测失误。在增加物理线程的情况下，分支预测会限制性能

拆分或共享数据时，您的代码不可伸缩。最好的办法是利用最少数量的可用物理核。公共数据带来的复杂性较低，应该非常容易处理。通过实验可以找到最小的线程数。性能将在该值之后保持不变