2010-06-03 6 views
6

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

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ć?

Odpowiedz

2

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.

+0

Proponujesz MPI.NET dla aplikacji HPC? –

+0

Spójrz na plz http://resourcekit.windowshpc.net/MORE_INFO/SeqToParallelHPC.html –

+0

Cześć jalchr, to nie jest takie proste niestety. Jeśli wykonujesz ciężkie matematyczne podnoszenie (tzn. Będzie to silnie dławić pojedynczy wątek), przejdź do licencji TPL, która jest dobrym szkieletem do gwintowania w standardowym modelu. Jedynym korzystnym obszarem dla MPI.NET (cóż, dla mnie Axum) jest obecnie sieć, w której aktorzy mogą słuchać na portach sieciowych bez zużywania procesora. MPI.NET nie byłby odpowiedni. –

6

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