MPI vs openMP dla pamięci współdzielonej

Powiedzmy, że jest komputer z 4 procesorami, każdy z 2 rdzeniami, więc całkowicie 8 Rdzeni. Z moim ograniczonym zrozumieniem myślę, że wszystkie procesory mają tę samą pamięć w tym przypadku. Teraz, czy lepiej jest użyć bezpośrednio openMP lub użyć MPI, aby uczynić go ogólnym, aby Kod mógł działać zarówno na Ustawieniach rozproszonych, jak i współdzielonych. Ponadto, jeśli użyję MPI dla współdzielonego ustawienia, wydajność spadnie w porównaniu z openMP?

Author: Shibli, 2012-07-04

4 answers

W większości platform pamięci rozproszonej składających się obecnie z węzłów SMP lub NUMA nie ma sensu nie używać OpenMP. OpenMP i MPI mogą doskonale ze sobą współpracować; OpenMP karmi rdzenie na każdym węźle, a MPI komunikuje się między węzłami. To się nazywa programowanie hybrydowe. Był uważany za egzotyczny 10 lat temu, ale teraz staje się głównym nurtem w wysokowydajnych komputerach.

Co do samego pytania, prawidłowa odpowiedź, biorąc pod uwagę podane informacje, zawsze było jedno i to samo: to zależy .

 28
Author: Hristo Iliev,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-07-14 19:33:09

Czy potrzebujesz lub chcesz MPI lub OpenMP (lub obu) w dużym stopniu zależy od rodzaju używanej aplikacji i czy twój problem jest głównie związany z pamięcią lub CPU (lub obu). Co więcej, zależy to od rodzaju sprzętu, na którym pracujesz. Kilka przykładów:

Przykład 1

Potrzebujesz równoległości, ponieważ kończy ci się pamięć, np. masz symulację i rozmiar problemu jest tak duży, że Twoje dane nie mieszczą się w pamięci pojedynczego / align = "left" / Jednak operacje wykonywane na danych są dość szybkie, więc nie potrzebujesz większej mocy obliczeniowej.

W tym przypadku prawdopodobnie chcesz użyć MPI i uruchomić jeden proces MPI na każdym węźle, w ten sposób maksymalnie wykorzystać dostępną pamięć, ograniczając komunikację do minimum.

Przykład 2

Zazwyczaj masz małe zbiory danych i chcesz tylko przyspieszyć swoją aplikację, która jest obliczeniowo ciężka. Ponadto, nie chcesz poświęcić dużo czasu na myślenie o równoległości, ale bardziej o algorytmach w ogóle.

W Tym Przypadku OpenMP jest twoim pierwszym wyborem. Musisz tylko dodać kilka instrukcji tu i ówdzie (np. przed pętlami for, które chcesz przyspieszyć), a jeśli twój program nie jest zbyt skomplikowany, OpenMP zrobi resztę za ciebie automatycznie.

Przykład 3

Chcesz wszystko. Potrzebujesz więcej pamięci, czyli więcej węzłów obliczeniowych, ale chcesz również przyspieszyć Zwiększ swoje obliczenia w jak największym stopniu, tj. uruchamiając więcej niż jeden rdzeń na węzeł.

Teraz twój sprzęt wchodzi w grę. Z mojego osobistego doświadczenia, jeśli masz tylko kilka rdzeni na węzeł( 4-8), kara wydajności stworzona przez ogólny narzut korzystania z OpenMP (tzn. uruchamianie wątków OpenMP itp.) to więcej niż narzut komunikacji wewnętrznej MPI procesora (tj. wysyłanie wiadomości MPI między procesami, które faktycznie dzielą pamięć i nie potrzebowałyby MPI do komunikować).
Jednakże, jeśli pracujesz na maszynie z większą liczbą rdzeni na węzeł (16+), konieczne będzie użycie podejścia hybrid, tzn. równoległe z MPI i OpenMP w tym samym czasie. W tym przypadku równoległość hybrydowa będzie konieczna, aby w pełni wykorzystać zasoby obliczeniowe, ale jest również najtrudniejsza do kodowania i utrzymania.

Podsumowanie
Jeśli masz problem, który jest na tyle mały, że można go uruchomić tylko na jednym węźle, użyj OpenMP. Jeśli wiesz, że potrzebujesz więcej niż jednego węzła (a więc zdecydowanie potrzebujesz MPI), ale wolisz czytelność kodu/wysiłek nad wydajnością, używaj tylko MPI. Jeśli używanie tylko MPI nie daje prędkości, którą chcesz / potrzebujesz, musisz zrobić to wszystko i przejść do hybrydy.

Do drugiego pytania (w przypadku, gdy nie stało się jasne):
Jeśli konfiguracja jest taka, że w ogóle nie potrzebujesz MPI (ponieważ zawsze będziesz działał tylko na jednym węźle), użyj OpenMP, ponieważ będzie szybciej. Ale jeśli wiesz, że potrzebujesz MPI tak czy inaczej, chciałbym zacząć od tego i tylko dodać OpenMP później, gdy wiesz, że wyczerpałeś wszystkie rozsądne opcje optymalizacji dla MPI.

 48
Author: Michael Schlottke-Lakemper,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-07-05 13:01:44

Do użycia na takiej pojedynczej maszynie pamięci współdzielonej, polecam OpenMP. To sprawia, że niektóre aspekty problemu są prostsze i może być szybsze.

Jeśli kiedykolwiek planujesz przenieść się na maszynę z pamięcią rozproszoną, użyj MPI. Oszczędzi ci to rozwiązania tego samego problemu dwa razy.

Powodem, dla którego mówię, że OpenMP może być szybszy, jest to, że dobra implementacja MPI może być na tyle sprytna, aby zauważyć, że jest używana w środowisku pamięci współdzielonej i zoptymalizować jego zachowanie odpowiednio.

 4
Author: Hbcdev,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-07-04 15:42:16

Dla szerszego obrazu, programowanie hybrydowe stało się popularne, ponieważ OpenMP korzysta z topologii pamięci podręcznej, używając tej samej przestrzeni adresowej. Ponieważ MPI może mieć te same dane replikowane w pamięci (ponieważ proces nie może udostępniać danych) , może cierpieć z powodu anulowania pamięci podręcznej.

Z drugiej strony, jeśli poprawnie podzielisz swoje dane, a każdy procesor ma prywatną pamięć podręczną, może dojść do punktu, w którym twój problem zmieści się całkowicie w pamięci podręcznej. W tym przypadku masz super linear przyspieszenie.

Mówiąc w pamięci podręcznej, istnieją bardzo różne topologie pamięci podręcznej na ostatnich procesorach i zawsze: to zależy...

 3
Author: RSFalcon7,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-07-04 21:30:42