我有一個關於多線程（Openmp和C代碼）的問題。將子線程拆分成新的子線程（Openmp）
我將在給定的文本文件中的16個不同的單詞之後執行搜索。這樣做的方法是創建一個for循環，該循環遍歷包含要搜索的每個單詞的數組。 16個不同的單詞意味着16個不同的線程可以同時運行。使用多線程的另一種方法是將文本文件切成x個相似大小的塊，並同時搜索每個塊。 我的問題是：我可以使用多線程爲每個單詞創建一個線程，然後將該特定的子線程分割成新的子線程來掃描一個大小的數據塊？
如果這是不可能/可行的，我想唯一的解決方案是手動將文本文件分割成不同的字符數組，然後使用#pragma爲每個要搜索的單詞。
只能對文本文件執行讀取操作，寫入操作僅限於分配給每個單詞的變量以便計數purpouses。即沒有比賽條件，除非我錯過了一些東西。
首先，16個單詞並不意味着16個不同的線程。每個線程本身都會帶來諸如同步開銷，不均衡的工作分配，產卵放鬆時間等因素，如果不仔細計算，將會導致完全損害並行性的好處。
如果工作數據之間不存在依賴關係，則可以極大地利用並行性。您的工作與您所表達的任何可能解決方案中的工作數據無關。尋找大量字符中的某些字符，與字符的排列無關（例如，在每個「C」與尋找「++」之後查看「++」）。
現在的問題是如何利用內存帶寬以及如何通過「分支預測」來消除丟失。
公用數據不同線程在內存綁定情況下非常好。讀取數據的第一個線程會將其加載到緩存中，而其他線程最終只會使用這一塊數據。所以數據只能從內存中加載一次。拆分數據也會導致只從內存中加載一次數據，因爲每個線程都會加載它的部分，然後刷新。所以，在這兩種情況下，內存負載非常相似。
你的代碼被稱爲「邏輯綁定」。分支預測是照顧非常重要的方面，但非常棘手。通用數據模塊發生故障的可能性很高。假設你必須找到一個紅色球在百萬個球。預測會傾向於做出「不存在」的自然選擇。但是說它在前100個球內失敗，所有在這次失敗後處理過的球都會以重做的方式結束，而你又回到原點。相反，如果發生分裂，「重做」的最壞情況不會像常見數據那樣糟糕。但我們無法保證。
選擇任何上述模塊，然後完全取決於您處置的架構。
SMT /邏輯核心與物理核心。使用上述任何一種SMT方法都會導致性能下降。物理內核。 您的想法是將一條線程拆分爲子線程是SMT的基礎。每個新的線程加起來追逐資源與同步開銷並且也是分支預測失誤的可能性。在增加物理線程的情況下，分支預測會限制性能。
分裂或公共數據，你的代碼是不可擴展的。最好的做法是利用最低數量。可用的物理內核。常見的數據帶來的複雜程度較低，應該很容易處理。最低數量的線程可以通過實驗找到。在此值之後，性能會保持不變。