訪問相同內存的核心數量是否有實際限制？

Question

當前向計算機添加內核的趨勢是否會繼續？或者，對於一組內存可以提供的內核數量是否存在一些理論上的或實際的限制？

換句話說：是將來容易的大功率臺式電腦在使用一組內存1024個內核，還是容易有32組記憶，每個由32個內核訪問？

或者另一種方式：我有一個4核的機器上運行良好，使用總CPU的顯著量多線程程序。隨着這個項目的規模不斷擴大，並做了更多的工作，我能否有理由相信更強大的機器可以運行它？ 或我應該認真思考如何在多臺機器上運行多個會話（或以任意多組內存）來完成工作？

換句話說，是一種純粹的多線程方法來設計將我留在死衚衕裏？ （由於使用單線程方法，並取決於幾年前CPU速度的持續改進）。該程序不太可能在花費超過3,000美元的機器上運行。如果那臺機器不能完成這項工作，工作就不會完成。但是，如果這臺3000美元的機器實際上是由32臺獨立電腦組成的網絡（雖然它們可能共享相同的散熱風扇），並且我繼續採用大規模多線程方法，但機器將能夠完成這項工作，但該程序不會，我會陷入一個尷尬的境地。

分佈式處理看起來比多線程更大的痛苦，但如果這可能在我的未來，我想要一些警告。

Answer 1

會增加內核的計算機目前的趨勢繼續下去嗎？

是，GHz的比賽結束。在現有技術上再加快速度是不現實的。物理學已經開始了。製造芯片的技術可能會發生戲劇性的變化，這讓我們能夠繞過這一切，但這顯然不是「即將到來」。

如果我們不能擁有更快的核心，獲得更多能量的唯一途徑是擁有更多核心。

或者是否對一組內存可以提供的內核數量有一定的理論或實際限制？

絕對有一個極限。在共享內存系統中，內存是共享資源並且帶寬有限。

Max processes = (Memory Bandwidth)/(Bandwidth required per process) 

現在 - 這是每個進程的帶寬「數字將緩存減少，但緩存成爲他們是否是一致的彼此，因爲每個人都訪問內存中的同一區域效率較低。 （您不能緩存存儲器寫如果另一個CPU可能需要你寫的）

當你開始談論龐大的系統，這樣的共享資源成爲主要的問題。它可能是內存帶寬，CPU週期，硬盤訪問，網絡帶寬。這涉及整個系統的結構。

---

你似乎真的在追求未來的願景，所以你可以做好準備。這是我的要求。

我想我們將看到軟件開發人員在他們的程序中看到並行的方式發生了變化。目前，我認爲很多軟件開發人員認爲使用多線程的唯一方法是讓他們中的很多人執行相同的操作。麻煩的是，他們都在爭奪同樣的資源。這就意味着需要引入大量的鎖定，這會導致性能問題，以及微妙的錯誤，這些錯誤會令人生氣並且耗費時間來解決。

這是不可持續的。

製造在20世紀初就開始了，建造大量汽車的最快方式並不是讓很多人在一輛車上工作，然後，當這件事完成時，將他們全部移動到下一輛車。將汽車的建造過程分解爲許多小型工作，其中一項工作的產出將成爲下一個工作的補充。他們稱之爲裝配線。在硬件設計中，它被稱爲管道鋪設，我認爲我們會看到越來越多的軟件設計轉向它，因爲它最大限度地減少了共享資源的問題。

好的 - 在一個階段的輸出和下一個輸入仍然有一個共享資源，但這只是在兩個線程/進程之間，並且更容易處理。標準方法也可以用於這些接口的製作方式，消息隊列庫似乎正在取得重大進展。

雖然沒有一個解決所有問題的方法。這種類型的管線對於可以吸收一些延遲的高吞吐量應用非常適用。如果你不能忍受延遲，你別無選擇，只能去'一個任務'的許多工作人員的路線。那些是你理想地想要扔在SIMD機器/像GPU一樣的陣列處理器的那些，但它只能真正勝過某種類型的問題。這些問題是有很多數據需要以相同的方式處理的問題，並且數據項之間的依賴關係很少或根本不存在。

掌握了流水線系統的消息隊列技術和類似知識，並通過OpenCL等庫在GPU上實現細粒度的並行處理，可以讓您深入瞭解光譜的兩端。

Answer 2

更新：多線程代碼可能運行在羣集計算機上，因此此問題可能沒有我想象的那麼重要。

我仔細檢查了JLS第17章中的Java內存模型，發現它並不是而是鏡像了大多數計算機的典型註冊表緩存主存模型。多內存機器有機會將數據從一個內存轉移到另一個（並且從一個機器上的一個線程運行到另一個機器上運行的另一個線程）。於是我開始尋找可以在多臺機器上運行的JVM。我發現了幾個舊的參考文獻 - 這個想法已經存在，但沒有遵循。然而，如果我正在讀他們的公關權，那麼一家公司Terracotta似乎有些東西。

無論如何，它似乎是PC通常包含幾個集羣計算機時，可能會有一個多機JVM。

我在Java世界以外找不到任何東西，但微軟的CLR應該提供相同的機會。 C和C++以及所有其他.exe語言可能會更困難。然而，Terracotta的網站更多地討論了在多臺機器上連接JVM而不是一個JVM，所以他們的技巧也可能適用於可執行語言（如果需要，也可能是CLR）。