.net 4.0任務並行庫與MPI.NET

.NET 4.0任務並行庫取代MPI.NET以實現高性能計算？.net 4.0任務並行庫與MPI.NET

MPI.NET在這裏找到http://www.osl.iu.edu/research/mpi.net/svn/是Microsoft的.NET環境中的消息傳遞接口（MPI）的高性能，易於使用的實現。 MPI是編寫在分佈式內存系統（如計算集羣）上運行的並行程序的事實標準。（TPL）是.NET Framework版本4中System.Threading和System.Threading.Tasks命名空間中的一組公共類型和API。 TPL通過簡化嚮應用程序添加並行和併發的過程來提高開發人員的工作效率TPL通過動態調整併發度來最有效地使用所有可用的處理器另外，TPL處理工作的分區， ThreadPool上的線程調度，取消支持，狀態管理以及其他底層細節。通過使用TPL，您可以最大限度地提高代碼的性能，同時關注您的程序旨在完成的工作。「

我的目標是建立一個可以在Windows HPC 2008上運行的應用程序 ......哪條路要走？

來源

2010-06-03 Jalal El-Shaer

消息傳遞是解決並行編程的想法不同的方式。 Axum和Erlang都使用消息傳遞。它們並不直接相媲美，因爲它們都涉及兩個特定的實現。

我已經看到了消息傳遞的好處是任何網絡/進程邊界可以製成透明和自身傳遞該消息不依賴於底層的螺紋（所有消息和演員可以在一個線程）。

從我有限的理解來看，TPL可以在.NET中構建/替換/大大改進當前的線程模型，也就是說，您可以控制實際的線程並通過傳輸參數或使用共享狀態進行通信。

如果從地上爬起來，並設計適合被分成代碼非常小的部分，那麼我建議MPI.NET。如果工作類型是CPU密集型（如數學工作），我會建議TPL路線。

編輯：很長一段時間的編輯，這個答案是舊的！ MPI.NET直接適用於HPC，因爲它使HPC節點的通信邊界透明且可配置。 MPI.NET將消息發送到端點 - 這些點被定義爲配置文件中的IP /端口地址。該代碼不知道端點跨越網絡邊界。

如果您在HPC上選擇TPL（不確定是否支持它），那麼我認爲您的代碼必須知道節點以及如何將處理從一個傳輸到另一個，因此您沒有任何收益。

來源

2010-06-04 15:57:13

那麼，你建議MPI.NET的HPC應用程序？ – 2010-06-12 09:27:29

看一看PLZ http://resourcekit.windowshpc.net/MORE_INFO/SeqToParallelHPC.html – 2010-06-12 09:30:07

嗨jalchr，它不是簡單的不幸。如果你正在進行繁重的數學提升（例如，它會嚴重扼制單線程），請參閱TPL，它是標準模型中線程化的良好框架。 MPI.NET（對我而言，Axum是唯一有益的領域）是當前的網絡，演員可以在網絡端口上偵聽而不消耗CPU。 MPI.NET不太適合。 – 2010-06-12 18:03:21

據我瞭解TPL不支持分佈式計算，而MPI.NET一樣。

來源

2010-06-24 07:45:57 Peladao

.net 4.0任務並行庫與MPI.NET

回答

相關問題