對不起，問一個問題一個我知之甚少的話題，但這種想法真的被竊聽了我，我一直沒能找到在互聯網上的任何答案。「嗯並行化」算法不能由多個線程加快
背景： 我正在和我的一位計算機科學研究的朋友談話。我大多在特設的發展，所以我大部分的CS概念的理解是在功能級（我知道如何使用他們，而不是他們的工作）。他說，轉換「以及並行化」算法已經在單個線程運行到一個運行在多線程並沒有導致他期待處理速度提高一點。
推理： 我問他是什麼計算機的體系結構，他是上運行此算法，他說，16核心（非虛擬化）。根據我對多核處理器的瞭解，在多核上運行的算法的處理速度增加應該大致與其並行化程度成正比。
問題： 算法如何「正確並行化」並正確編程以在真正的多核處理器上運行，而不是多跑幾次？是否有一些我在這裏失蹤的信息，或者更可能是實施的問題？
其他的東西：我問是否這些線程可能佔用比任何單獨的內核可用的功率更大，顯然每個內核運行在3.4 GHz。這比算法所需要的要多得多，並且在運行診斷程序時，內核在運行時不會超時。
性能與核心數量往往是一個S-狀的曲線 - 首先，它明顯增加，但由於鎖定，共享緩存以及他們的債務進一步核不加那麼多，甚至可能會降低喜歡拍攝。因此沒有什麼神祕的。如果我們知道更多關於算法的細節，可以找到一個想法加快速度。
你介意解釋一下你在說什麼嗎？我明白你所說的對於非並行或非並行算法會是正確的，但不一定在我描述的情況下。在多核運行時，性能只會非常小的增加，所以它看起來甚至沒有遵循S曲線。 – Dustin
很可能共享東西。共享內容可能並不明顯。
其中最常見的非顯而易見的共享資源是CPU緩存。如果線程正在更新相同的高速緩存行，那麼高速緩存行必須在CPU之間反彈，從而放慢一切。
這可能是因爲訪問（即使只讀）在內存中彼此靠近的變量而發生的。如果所有訪問都是隻讀的，那麼它是可以的，但是如果即使一個CPU正在寫入該緩存行，它也會強制反彈。
解決這個的蠻力方法是將共享變量到看起來像結構：
struct var_struct {
int value;
char padding[128];
};
而不是硬編碼128，你可以研究什麼樣的系統參數或預處理宏定義的超高速緩存行您的系統類型的大小。
可以發生共享的另一個地方是系統調用。即使看似無辜的職能也可能在全球鎖定。我似乎回想起有關解決這個問題的Linux，並回顧了返回進程和線程標識符以及父標識符的函數的鎖。
謝謝，我正在和另一位研究員交談，他說了類似的話......我會試着看看是否屬於這種情況。 – Dustin
讓你的朋友編寫代碼並讓計算機發布這個特定實例的細節。對你的問題的一般回答「爲什麼隨機並行代碼不加速？」填寫了幾本教科書和研究會議。 – Novelocrat