我有一个关于多线程（Openmp 和 C 代码）的问题。
我将在给定的文本文件中搜索 16 个不同的单词。这样做的方法是创建一个 for 循环，该循环遍历包含要搜索的每个单词的数组。 16 个不同的词意味着可以同时运行 16 个不同的线程。使用多线程的另一种方法是将文本文件切成 x 个大小相似的块并同时搜索每个块。 我的问题是：我可以使用多线程为每个单词创建一个线程，然后将该特定子线程拆分为新的子线程来扫描一个大小的数据块吗？
如果这不可行/不可行，我想唯一的解决方案是将文本文件手动拆分为不同的字符数组，然后对我要搜索的每个单词使用#pragma。
只会对文本文件执行读取操作，而写入操作仅限于分配给每个单词的变量以用于计数目的。 IE。不会有比赛条件，除非我错过了什么。
【问题讨论】：
标签： c multithreading multiprocessing openmp pragma
首先，16 个单词并不意味着 16 个不同的线程。每个线程本身都会带来同步开销、工作分配不均、spawn-relax 时间等因素，如果不仔细计算，将导致完全损害并行性的好处。
在工作数据之间没有依赖关系的情况下，可以极大地利用并行性。您的工作独立于您所表达的任一可能解决方案中的工作数据。在大量字符中查找某些字符，与字符的排列无关（例如，在每个“C”之后查找“++”与查找“++”）。
现在的问题是你如何利用内存带宽以及如何通过“分支预测”解决丢失的问题。
Common Data 不同线程在内存受限的情况下非常好。第一个读取数据的线程会将其加载到缓存中，而其他线程最终会使用这块数据。所以数据只会从内存中加载一次。拆分数据也将导致仅从内存中加载一次数据，因为每个线程都会加载其部分然后刷新。因此，两种情况下的内存负载非常相似。
您的代码称为“逻辑绑定”。分支预测是非常重要的方面，但非常棘手。公共数据模块失败的概率很高。假设您必须在一百万个球中找到一个红色球。预测将倾向于做出“不存在”的自然选择。但是如果它在前 100 个球内失败，则在此失败后所有处理过的球都将最终重做，而你又回到了第一格。相反，在拆分的情况下，“重做”的最坏情况不会像普通数据一样糟糕。但我们不能保证。
选择上述任何模块完全取决于您所使用的架构。
SMT / 逻辑内核与物理内核。将上述任何一种方法与 SMT 一起使用都会导致性能降低。物理核心。 您将一个线程拆分为子线程的想法是 SMT 的基础。每个新线程都增加了资源追逐，同步开销和分支预测错误的可能性。在物理线程增加的情况下，分支预测会限制性能。
拆分或公共数据，您的代码不可扩展。最好的办法是利用最低数量。可用的物理内核数。通用数据带来的复杂性更低，应该很容易处理。最小编号可以通过实验找到线程数。在 this 值之后，性能将保持不变。
【讨论】：