切換到並行編碼

Question

我們都爲單個處理器編寫代碼。 我想知道我們什麼時候能夠在多處理器上編寫代碼？

這個開關我們需要什麼（軟件工具，邏輯，算法）？

編輯：在我看來，因爲我們平行地完成許多任務，所以我們需要將這些現實生活中的解決方案（算法）轉換爲計算機語言。就像OOP編碼爲程序編碼做的一樣。面向對象編程風格比程序風格更加真實。所以我希望有這樣的解決方案。

Answer 1

沒有簡單的答案，並且在許多方面，即使是複雜的答案目前還不夠完善或不完整。如果你對你想要的回覆有更具體的瞭解，那麼你會得到更好的答案：指向開發庫和工具，教學材料，當前研究項目的指針和這方面的問題或其他內容？

Answer 2

我認爲最重要的要求是具有支持並行性的原生構造或可以自動生成並行代碼的良好語言。有相當多的語言符合這種描述，但沒有一種足夠流行，足以真正被認爲是主流使用。在，又被幾件事情引起的：

1. 就其本質而言，這些語言從今天的命令式語言非常不同，併爲此更難學習（或至少似乎是這樣）。
2. 他們經常缺乏好的工具和庫，使他們無法用於任何「真實」的項目。

當然，如果它更受歡迎，更多的人會願意學習它，並會有更多的支持，所以這是一種很難擺脫的週期。我想我們所能做的就是希望。 :)

Erlang設計的語言設計的例子 - 它實際上用於商業項目。

Answer 3

不幸的是，對於大規模併發編程 - 除非編譯器有幫助突破，否則我們會拋出許多關於算法的知識（我認爲Don Knuth甚至會這麼說）。閱讀關於Erlang的一瞥可能的未來。

Answer 4

我們需要的是高併發算法的自然抽象。參與者（想想：Erlang）在這個方向上走了很長的路，但他們不是一個萬能的解決方案。一些更具體的抽象如fork/join或map/reduce可以更容易地應用於常見問題。

所有這些併發抽象的訣竅是它們需要功能風格的編程。併發性與共享的可變狀態無法很好地匹配。正如他們所說的，「鎖被認爲是有害的」。由於大多數開發人員來自嚴格必要的背景，切換到無共享延續傳遞方法通常極具挑戰性。順便提一句，關於併發抽象，Clojure在這個方向上有一些非常有趣的特性。它不僅具有排序的參與者，還定義了一個事務性內存模型（思考：數據庫）以及全局的原子參考機制。這兩個特性允許併發操作共享「可變」狀態，而不必擔心鎖定或競態條件。

最後，它歸結爲教育。對併發抽象所需的大部分理論工作已經完成，我們只需要接受它。不幸的是，正如Erlang和Haskell所證明的那樣，有時候最好的想法仍然是一個非常邊緣的人羣。希望像Scala和Clojure這樣的努力能夠成功地將更先進的抽象技術帶入主流，將它們潛入現有的支持良好的平臺（JVM）。

Answer 5

最重要的要求是能夠將問題分解爲可以彼此獨立解決的較小問題。一旦你研究了你將如何做到這一點，那麼其他一切都會更容易思考和實施的進一步問題（例如「我的計算部分取決於其他部分 - 我該如何等待他們完成？」）。 ）成爲具體的，具體的事情，你可以研究或問這裏。

Answer 6

有幾種工具/語言流行或正在流行。如果您使用FORTRAN，C或C++，則可以使用OpenMP（不太難實現）或Message Passing Interface（MPI）庫（強大且最大的加速潛力，但也是複雜且困難的）。 OpenMP使用預處理器指令來標記可以並行化的區域，特別是循環。 MPI使用在進程之間來回傳遞數據的消息，最大的困難在於保持所有內容的同步，而不會造成瓶頸和等待進程。然而，我想說MPI絕對是在出路。在科學/高性能計算社區中已經很清楚，加速很少值得額外的開發時間。

至於未來的語言，請查看Fortress。它仍在設計中，但其目標是創建比FORTRAN更易於科學計算的語言。程序將以非常高的數學語法指定。另外，並行將是隱含的;程序員必須努力工作才能連續完成任務。另外，它受到Sun的支持，並基於Java，所以它將是可移植的。

Answer 7

對於java，你現在可以看看並行Java庫或DPJ（確定性並行Java！） 它將爲您提供從代碼提取並行性很大的幫助！