Biblioteka zadań równoległych z .net 4.0 a MPI.NET

Question

Czy biblioteka zadań równoległych do narzędzia .net 4.0 zastępuje MPI.NET w celu obliczeń o wysokiej wydajności?

Znaleziono tutaj MPI.NET http://www.osl.iu.edu/research/mpi.net/svn/ to wysokowydajna, łatwa w użyciu implementacja interfejsu Message Passing Interface (MPI) dla środowiska Microsoft .NET. MPI jest de facto standardem do pisania programów równoległych działających w systemie pamięci rozproszonej, takich jak klaster obliczeniowy.

.NET 4 TPL mówi: „Task Parallel Library (TPL) jest zbiorem typów publicznych i API w System.Threading i System.Threading.Tasks nazw w wersji .NET Framework 4. Celem TPL ma sprawić, że programiści będą bardziej produktywni, upraszczając proces dodawania równoległości i współbieżności do aplikacji, TPL dynamicznie skaluje stopień współbieżności, aby jak najefektywniej korzystać z wszystkich dostępnych procesorów, a dodatkowo TPL zajmuje się partycjonowaniem pracy, planowanie wątków w wątku, obsługa anulowania, zarządzanie stanem i inne szczegóły niskiego poziomu. Korzystając z licencji TPL, możesz zmaksymalizować wydajność swojego kodu, koncentrując się na pracy, którą zaprojektował twój program. "

Moim celem jest zbudowanie aplikacji, która może działać w systemie Windows HPC 2008 ... w którą stronę się wybrać?

Answer 1

Przekazywanie wiadomości to inny sposób rozwiązania problemu programowania równoległego. Axum i Erlang używają przekazywania wiadomości. Nie są tak naprawdę porównywalne bezpośrednio, ponieważ obaj odnoszą się do dwóch konkretnych implementacji.

Zaletą, jaką widziałem przy przekazywaniu komunikatów, jest to, że wszelkie granice sieci/procesów mogą być przezroczyste, a przekazywana wiadomość nie jest zależna od wątków (wszystkie wiadomości i aktorzy mogą być w jednym wątku).

TPL, z mojego ograniczonego rozumowania, jest do zbudowania na/wymienić/znacznie poprawić bieżący model gwintowania w .NET, tj. Masz rzeczywiste wątki, które kontrolujesz i komunikujesz się przez przekazywanie argumentów lub używanie stanu współdzielonego.

Jeśli od podstaw, a projekty są podzielone na bardzo małe segmenty kodu, proponuję MPI.NET. Jeśli typ pracy jest obciążony przez procesor (np. Praca matematyczna), sugerowałbym trasę TPL.

Edycja: długa edycja, ta odpowiedź jest stara! MPI.NET jest bezpośrednio dostosowany do HPC, ponieważ sprawia, że ​​granica komunikacyjna węzłów HPC jest przejrzysta i konfigurowalna. MPI.NET wysyła komunikaty do punktów końcowych - są to punkty zdefiniowane jako adresy IP/Port w plikach konfiguracyjnych. Kod nie wie, że punkt końcowy przekracza granicę sieci.

Jeśli zdecydujesz się na TPL w HPC (nie masz pewności, czy jest obsługiwany), myślę, że Twój kod będzie musiał być świadomy węzłów i sposobu przenoszenia przetwarzania z jednego do drugiego, więc nie czerpiesz żadnych korzyści.

Answer 2

Z tego co rozumiem, TPL nie obsługuje rozproszonego przetwarzania, podczas gdy robi to MPI.NET.