Bawiłem się PETSc i zauważyłem, że kiedy uruchamiam mój program z więcej niż jednym procesem przez MPI , wydaje się, że działa jeszcze wolniej ! Jak mogę sprawdzić, co się dzieje?
Bawiłem się PETSc i zauważyłem, że kiedy uruchamiam mój program z więcej niż jednym procesem przez MPI , wydaje się, że działa jeszcze wolniej ! Jak mogę sprawdzić, co się dzieje?
Odpowiedzi:
Może to wynikać z czynników architektonicznych :
Jeśli ta sama przepustowość pamięci jest dostępna dla jednego lub więcej procesów, wówczas prawie nie będzie przyspieszania, ponieważ SpMV i powiązane operacje algebry liniowej są ograniczone przepustowością pamięci.
Może się również zdarzyć, że narzut komunikacyjny przytłoczy obliczenia lokalne. Na przykład w liniowych metodach iteracyjnych zalecamy co najmniej 10.000 niewiadomych na proces.
lub czynniki liczbowe :
Równoległe warunki wstępne są często słabsze niż ich odpowiedniki szeregowe. Na przykład blok Jacobi staje się słabszy, im więcej bloków używasz. Dlatego należy uwzględnić dodatkowy czas poświęcony na dodatkowe iteracje liniowe. Warunki nieliniowe na ogół nie działają w ten sposób, więc iteracje Newtona są często stałe.
Gdy próbujesz zrównoważyć program, musisz zrównoważyć wiele kosztów, ale przede wszystkim są
Jeśli twoje obliczenia są krępująco równoległe, wówczas koszt komunikacji będzie bardzo niski (tylko wejście i wyjście), a koszt zarządzania powinien być bardzo niski.
Jeśli masz współzależności między obliczeniami, koszt komunikacji może znacznie wzrosnąć. Jeśli masz skomplikowany algorytm, którego wypełnienie zajmuje dowolne obliczenie, wówczas złożoność zarządzania rośnie, gdy próbujesz efektywnie wykorzystać posiadane zasoby.
Podobnie jak w przypadku każdej formy optymalizacji, kluczem jest przeprowadzenie testu porównawczego. Zobacz, jak to działa bez MPI, jak działa z MPI i jednym procesem, a następnie jak skaluje się.
Jeśli grasz w CUDA, spróbuj podać znacznie więcej danych. Jeden test tutaj spowodował ujemne przyspieszenie. Daliśmy mu 1000 razy więcej danych, a wersja GP-GPU zakończyła się prawie w tym samym czasie, podczas gdy wersja działająca na głównym procesorze zajęła 1000 razy więcej.
Poleciłbym wykonać następujące czynności:
Utwórz profil czasu wykonywania kodu, z równoległością i bez. Jeśli masz wątpliwości, jak to zrobić, możemy pomóc, jeśli lepiej opisasz swój kod.
Możesz teraz skupić się na częściach, które poruszają się wolniej równolegle. Należy pamiętać, że komunikacja między procesami może być powolna. Jak zauważyli Mark i Sean, fakt, że problem można podzielić na wątki, nie oznacza, że będzie to skuteczne. Musisz przyjrzeć się temu głębiej. Ale jeśli profilujesz swój kod, może to pomóc w znalezieniu istniejących błędów. Moje dwa centy.
Jeśli wyjaśnisz bardziej szczegółowo, co robisz, np. Za pomocą przepływu pracy, ktoś może być w stanie udzielić ci lepszego wyjaśnienia.