Z ankiety przeprowadzonej wśród top500 wynika, że przemysł zmierza w kierunku wykładniczego wzrostu liczby rdzeni przetwarzających . Największe superkomputery wykorzystują MPI do komunikacji między węzłami, chociaż nie wydaje się, aby istniał wyraźny trend równoległości w węzłach, przy najprostszym (ale niekoniecznie najbardziej wydajnym) podejściu do mapowania pojedynczego procesu MPI na każdym rdzeniu, automatycznie równoległa kompilacja, OpenMP, pthreads, CUDA, Cilk i OpenCL.
Należę do grupy naukowców utrzymujących i rozwijających kod, który może zostać wykorzystany na największych superkomputerach na świecie. Zakładając, że czas programisty jest ograniczony, w jaki sposób mogę przygotować się na przyszłość, aby móc skorzystać z wydajności najpotężniejszej maszyny na świecie? Jakie założenia powinienem przyjąć na temat architektury połączeń procesów? Jakie paradygmaty ucierpią, gdy wejdziemy w erę manycore? Czy języki partycjonowanej globalnej przestrzeni adresowej będą dostępne „w produkcji” na maszynach petascale?
źródło
Odpowiedzi:
Perspektywa historyczna
Naprawdę niemożliwe jest określenie, jak będą wyglądać nowe paradygmaty w przyszłości, na przykład dobra historyczna perspektywa Sugeruję przeczytanie „ Wzrostu i upadku HPF” Kena Kennedy'ego . Kennedy opisuje dwa pojawiające się wzorce, MPI w porównaniu do inteligentnego kompilatora, i opisuje, w jaki sposób MPI miał odpowiednią liczbę wczesnych użytkowników i elastyczność do dominacji. HPF ostatecznie rozwiązało problemy, ale było już za późno.
Pod wieloma względami kilka paradygmatów, takich jak PGAS i OpenMP, podąża za tym samym trendem HPF. Wczesne kody nie były wystarczająco elastyczne, aby można je było dobrze wykorzystać i pozostawiły dużą wydajność na stole. Ale obietnica, że nie trzeba zapisywać każdej części algorytmu równoległego, jest atrakcyjnym celem. Dlatego zawsze poszukuje się nowych modeli.
Wyczyść trendy w sprzęcie
Teraz sukces MPI był często cytowany jako ściśle związany ze sposobem modelowania sprzętu, na którym działa. Z grubsza każdy węzeł ma kilka procesów, a przekazywanie komunikatów do lokalnego punktu do punktu lub poprzez skoordynowane operacje zbiorcze jest łatwe w przestrzeni klastrowej. Z tego powodu nie ufam nikomu, kto podaje paradygmat, który nie jest ściśle zgodny z nowymi trendami sprzętowymi, tak naprawdę przekonałem się o tej opinii dzięki pracy Vivak Sarakar .
W związku z tym oto trzy trendy, które wyraźnie rozwijają się w nowych architekturach. Pozwólcie, że wyjaśnię, że w HPC jest obecnie sprzedawanych dwanaście różnych architektur. To mniej niż 5 lat temu tylko z x86, więc w najbliższych dniach pojawi się wiele możliwości korzystania ze sprzętu na różne i interesujące sposoby
Obecne modele
Obecny model ma głębokość 3 poziomów. Chociaż istnieje wiele kodów dobrze wykorzystujących dwa z tych poziomów, niewiele pojawiło się przy użyciu wszystkich trzech poziomów. Uważam, że aby dostać się do egzascale, należy zainwestować w ustalenie, czy kod może działać na wszystkich trzech poziomach. Jest to prawdopodobnie najbezpieczniejsza ścieżka do iteracji w obecnych trendach.
Pozwól, że przejdę do modeli i tego, jak będą musiały się zmieniać w oparciu o przewidywane widoki nowego sprzętu.
Rozpowszechniane
Gracze na poziomie rozproszonym w dużej mierze należą do języków MPI i PGAS. MPI jest obecnie wyraźnym zwycięzcą, ale języki PGAS, takie jak UPC i Chapel, robią postępy w kosmosie. Jednym z dobrych wskazań jest HPC Benchmark Challenge. Języki PGAS zapewniają bardzo eleganckie implementacje testów porównawczych.
Najciekawsze jest to, że chociaż model ten obecnie działa tylko na poziomie węzła, będzie ważnym modelem wewnątrz węzła dla architektur kafelkowych. Jednym ze wskazań jest układ Intel SCC, który zasadniczo działał jak system rozproszony. Zespół SCC stworzył własną implementację MPI i wielu zespołom udało się przenieść biblioteki społecznościowe do tej architektury.
Ale szczerze mówiąc, PGAS ma naprawdę dobrą historię do wkroczenia w tę przestrzeń. Czy naprawdę chcesz zaprogramować interpolację MPI, a następnie wykonać tę samą intranodę? Jedną wielką kwestią związaną z tymi kafelkowymi architekturami jest to, że będą miały różne prędkości zegara na chipach i duże różnice w przepustowości do pamięci, więc wydajne kody muszą to wziąć pod uwagę.
Pamięć współdzielona w węźle
Widzimy tutaj, że MPI często jest „wystarczająco dobry”, ale PThreads (i biblioteki pochodzące z PThreads takie jak Intel Parallel Building Blocks) i OpenMP są nadal często używane. Powszechnie uważa się, że nadejdzie czas, gdy będzie wystarczająco dużo wątków pamięci współdzielonej, że model gniazda MPI zepsuje się dla RPC lub potrzebujesz lżejszego procesu działającego na rdzeniu. Już widać wskazania, że systemy IBM Bluegene mają problemy z MPI z pamięcią współużytkowaną.
Jak komentuje Matt, największym wzrostem wydajności kodów intensywnych obliczeniowo jest wektoryzacja kodu szeregowego. Chociaż wiele osób uważa, że jest to prawdą w przypadku akceleratorów, ma to również krytyczne znaczenie dla maszyn w węźle. Wierzę, że Westmere ma 4 szerokie FPU, więc można uzyskać tylko jedną czwartą flopów bez wektoryzacji.
Chociaż nie widzę obecnego OpenMP dobrze wchodzącego w tę przestrzeń, jest miejsce dla chipów o niskiej mocy lub płytek, aby używały więcej lekkich nici. OpenMP ma trudności z opisaniem, jak działa przepływ danych, a gdy używanych jest więcej wątków, widzę tylko ten trend, który jest coraz bardziej przesadzony, po prostu spójrz na przykłady tego, co trzeba zrobić, aby uzyskać prawidłowe pobieranie wstępne z OpenMP.
Zarówno OpenMP, jak i PThreads na wystarczającym poziomie kursu mogą skorzystać z wektoryzacji niezbędnej do uzyskania dobrego procentu piku, ale to wymaga złamania algorytmów w sposób, który jest wektorem naturalny.
Koprocesor
Wreszcie pojawiło się pojawienie się koprocesora (GPU, MIC, Cell acclerators). Staje się jasne, że żadna droga do egzaskalii nie będzie kompletna bez nich. Na SC11 każdy uczestnik nagrody Bell wykorzystał je bardzo skutecznie, aby dostać się do niskich petaflopów. Podczas gdy CUDA i OpenCL zdominowały obecny rynek, mam nadzieję, że kompilatory OpenACC i PGAS wejdą w kosmos.
Aby przejść do egzascale, jedną z propozycji jest połączenie układów o niskiej mocy z wieloma koprocesorami. To całkiem nieźle zabije środkową warstwę bieżącego stosu i użyje kodów, które zarządzają problemami decyzyjnymi na głównym chipie i przenoszą pracę do koprocesorów. Oznacza to, że aby kod działał dość skutecznie, osoba musi ponownie przemyśleć algorytmy pod kątem jąder (lub kodeków), czyli równoległych fragmentów instrukcji bez rozgałęzień. O ile mi wiadomo, rozwiązanie tej ewolucji jest dość szeroko otwarte.
Jak wpływa to na twórcę aplikacji
Teraz przejdź do swojego pytania. Jeśli chcesz uchronić się przed nadchodzącą złożonością eksaskalowych maszyn, powinieneś zrobić kilka rzeczy:
Jeśli chcesz dzisiaj być wydajnym, MPI + CUDA / OpenCL jest wystarczająco dobry, ale UPC się tam rozwija, więc nie jest to zły pomysł, aby poświęcić kilka dni i się go nauczyć. OpenMP pomaga Ci zacząć, ale prowadzi do problemów, gdy kod wymaga ponownej refaktoryzacji. PThreads wymaga całkowitego przepisania kodu do jego stylu. Co sprawia, że MPI + CUDA / OpenCL jest obecnie najlepszym modelem.
Czego tu nie omawiamy
Podczas gdy cała ta rozmowa o eksaskalach jest przyjemna, czymś, o czym tak naprawdę tu nie dyskutowano, jest pobieranie danych z maszyn. Chociaż nastąpiło wiele postępów w systemach pamięci, nie widzimy ich w klastrze towarowym (po prostu zbyt cholernie drogie). Teraz, gdy intensywne przetwarzanie danych staje się głównym tematem wszystkich konferencji poświęconych superkomputerowi, z pewnością nastąpi większy ruch w przestrzeni o dużej przepustowości pamięci.
Powoduje to inny trend, który może się zdarzyć (jeśli zaangażują się odpowiednie agencje finansujące). Maszyny staną się coraz bardziej wyspecjalizowane w zakresie wymaganego rodzaju obliczeń. Widzimy już, że maszyny „intensywnie przetwarzające dane” są finansowane przez NSF, ale te maszyny są na innym torze niż Grand Challenge Exascale 2019.
Stało się to dłużej niż oczekiwano, poproś o referencje tam, gdzie ich potrzebujesz w komentarzach
źródło
Zacznijmy od omówienia strategii dla kodu intranode (obliczenia, które nie dotykają interkonektu), ponieważ uważam, że MPI jest dobrym wyborem dla kodu interode. Myślę, że nie ma sensu mówić o węzłach z mniej niż 100 rdzeniami, a więc przynajmniej z obecnym GPU lub MIC.
Faktem jest, że same pthreads nie mogą zapewnić maksymalnej wydajności jakiegokolwiek nowoczesnego układu, ponieważ musisz skorzystać z jednostki wektorowej (prawda od pierwszego Craya). Na Intel i AMD możesz używać wewnętrznych, ale nie są one przenośne i moim zdaniem niezgrabne. CUDA i OpenCL mają wektoryzację wbudowaną w bibliotekę i ułatwiają uzyskanie maksymalnej wydajności. Cały nowy sprzęt, o którym wiem, ma ten wymóg wektorowy, więc każde rozwiązanie powinno to wziąć pod uwagę. Dla mnie CUDA / OpenCL to aktualna droga.
Następnie wszystkie te maszyny będą mieć NUMA, co jest trudniejsze do zaprogramowania, ale myślę, że strategia jądra działa. Dzielisz pracę i dane na małe jednostki. Prawdopodobnie zostaną one zaplanowane automatycznie, tak jak dzieje się to obecnie w CUDA i OpenCL, ale można określić zależności. W przypadku problemów, które pasują do paradygmatu przesyłania strumieniowego, dzielenie to można również wykonać automatycznie. Intel TBB to robi, ale wolę podejście biblioteki wyższego poziomu, którego przykładem są Thrust i Cusp , które mogą atakować CUDA lub (wkrótce) TBB.
źródło
Spróbuję krótszej odpowiedzi niż niektórzy z moich cenionych kolegów w tym temacie ;-)
Moją wiadomością do wszystkich moich studentów jest to, że czas programisty jest cenniejszy niż czas procesora. Oznacza to, że jeśli masz czas na konwersję 100% kodu z wydajnością 80%, aby uruchomić na dużych komputerach - przy użyciu podejścia wysokiego poziomu - to lepiej, niż gdy używasz czasochłonnego niskiego poziomu podejście, które daje 100% wydajności na 20% twojego kodu. W konsekwencji jestem wielkim fanem bibliotek wysokiego poziomu. Moimi ulubionymi w tym obszarze są wątki budujące blok (TBB), ponieważ pozwalają mi spojrzeć na algorytmy w najbardziej zewnętrznych pętlach i na wysokim poziomie. Może także robić wszystko, co możesz zrobić z pthreads bez żartów związanych z funkcjami systemu operacyjnego itp. Nie jestem fanem podejść, które dotyczą wewnętrznych pętli, ponieważ jest to zły poziom do wykorzystywania zasobów równoległych intranod - - więc nie OpenMP,
Nie mogę rozmawiać z autorytetem o OpenCL, CUDA itp.
źródło
Odpowiedzi wcześniej opublikowane są doskonałe, ale koncentrują się głównie na architekturze węzłów, co, jak sądzę, odzwierciedla fakt, że MPI jest ogólnie uważany za wystarczający jako modele programowania międzywęźlowego w większości przypadków i że w zmaganiach jest równoległość intranodowa.
Oto moje próby odpowiedzi na dwa pytania, na które jeszcze nie ma odpowiedzi lub odpowiedzi w stosunkowo ograniczonym zakresie:
Jakie założenia powinienem przyjąć na temat architektury połączeń procesów?
Rozważę trzy właściwości sieci:
Opóźnienie jest odwrotnie proporcjonalne do częstotliwości. Wiemy, że skalowanie częstotliwości uległo stagnacji. Można zatem stwierdzić, że opóźnienie prawdopodobnie nie zmniejszy się znacząco w przyszłości. Opóźnienie wysyłania i odbierania MPI na Blue Gene / Q wynosi około 2 us, co odpowiada 3200 cyklom. Ponad połowa tego opóźnienia to oprogramowanie, ale duża część tego jest wymagana przez standard MPI; ekstensywne dostrajanie może zmniejszyć opóźnienie zbliżone do 1 nas, szczególnie jeśli można stwierdzić, że symbole wieloznaczne MPI nie będą używane.
W każdym razie opóźnienie sprzętowe wstrzykiwania pakietów w systemach Blue Gene i Cray wynosi około 1 nas. Co więcej, zwiększenie współbieżności na poziomie węzłów utrudnia utrzymanie tej liczby na tak niskim poziomie, ale jestem optymistą, że projektanci sprzętu znajdą sposoby na utrzymanie opóźnienia poniżej 5 nas w dającej się przewidzieć przyszłości.
Przepustowość sieci jest trywialnie zwiększana poprzez zwiększenie liczby łączy sieciowych. To jednak tylko część historii. Jeden umieścił 1000 węzłów wychodzących w węźle i nie był w stanie ich użyć, jeśli procesor (y) nie mogą prowadzić sieci z pełną przepustowością. Na przykład niektóre superkomputery wąskie gardło w autobusie (np. HyperTransport) zamiast w sieci, pod względem przepustowości wstrzykiwań.
Nie ma podstawowych ograniczeń przepustowości sieci, tylko praktyczne. Przepustowość kosztuje pieniądze i energię. Projektanci systemów będą musieli uwzględnić kompromisy między przepustowością sieci a innymi częściami maszyny podczas opracowywania przyszłych systemów. Wiele kodów nie jest ograniczonych przepustowością sieci, więc wydaje się mało prawdopodobne, abyśmy zobaczyli maszyny o znacznie większej przepustowości na połączenie w przyszłości. Jednak przepustowość na węzeł powinna wzrosnąć proporcjonalnie do mocy obliczeniowej, dlatego w celu zwiększenia skali musi istnieć wiele połączeń na węzeł.
Trzecią właściwością sieci, która jest często pomijana w modelach formalnych, jest liczba wiadomości, które można wysłać jednorazowo. Posiadanie sieci z opóźnieniem 1 ns i / lub przepustowością 1 TB / s, która może wysyłać tylko 1 wiadomość naraz, byłoby całkowicie bezużyteczne dla większości zastosowań. Ważne jest, aby móc jednocześnie wysyłać wiele wiadomości z wielu wątków, a sieć nie mogła się zawalić w wyniku niezgody. Zarówno systemy Cray, jak i Blue Gene osiągają obecnie ponad 1 MMPS (milion wiadomości na sekundę). Nie pamiętam dokładnych liczb, ale oba są w stanie osiągnąć znaczną część szczytowej przepustowości przy małych wiadomościach. Idealna sieć może być w stanie osiągnąć szczytową przepustowość przy dowolnym komunikacie o rozmiarze, ale w praktyce jest to niemożliwe ze względu na nagłówek pakietu i powiązane koszty księgowości. Jednak,
To jest niepełna i niedoskonała odpowiedź. Inni mogą spróbować go poprawić lub zasugerować rzeczy, które powinienem poprawić.
Czy języki partycjonowanej globalnej przestrzeni adresowej będą dostępne „w produkcji” na maszynach petascale?
Systemy Cray XE, XK i XC mają wysokiej jakości kompilator UPC i CAF. Systemy Blue Gene mogą być dostarczane z XLUPC i XLCAF, ale nikt tego nie prosi, więc nie jest dostarczany. PERCS ma produkcyjne kompilatory XLUPC i XLCAF, ale nie ma dużych instalacji dostępnych dla społeczności naukowej.
Coarrays są częścią Fortran 2008, chociaż implementacje w Intel i GNU Fortran nie są jeszcze wysokiej jakości. Uważa się, że implementacja Intela działa, ale działa dość wolno (na ten temat jest artykuł w PGAS12).
Jeśli chodzi o model programowania PGAS (ponieważ modele programowania - a nie języki programowania - są przedmiotem pierwotnego pytania), biblioteka Global Arrays jest w wielu przypadkach rozsądnym przybliżeniem jakości produkcji. Jako środowisko wykonawcze nie jest tak niezawodne jak MPI, ale MPI jest dość wyjątkowy pod względem jakości implementacji. Implementacja ARMCI ARMCI-MPI sprawia, że Global Arrays jest znacznie bardziej stabilny, choć w niektórych przypadkach wolniejszy.
Stosunkowo łatwo jest zaimplementować konstrukcje typu PGAS w jakości produkcyjnej przy użyciu MPI-3 RMA. Jeśli ktoś opublikuje nowe pytanie na ten temat, chętnie na nie odpowiem.
źródło
Naprawdę ogromne ilości rdzeni otwierają również trywialną, ale zaskakująco przydatną perspektywę - wystarczy użyć jej do przeprowadzenia wielu iteracji całej symulacji.
Znaczna część badań obliczeniowych sprowadza się obecnie do skanowania pewnej przestrzeni parametrów, przeszukiwania dużej puli warunków początkowych lub obliczania rozkładu niektórych wyników w sposób ponownego próbkowania; wszystkie te zadania są krępująco równoległe, a zatem odporne na Amdahla.
źródło
Podejrzewam, że nawet najbardziej przemyślane odpowiedzi na to pytanie staną się nieaktualne za pięć do dziesięciu lat. Biorąc pod uwagę niepewność przyszłych paradygmatów programowania, warto poświęcić dużo czasu na wstępną optymalizację bazy kodu.
źródło
Właśnie miałem opublikować tę odpowiedź na to pytanie , ale została ona zamknięta jako duplikat tego, więc oto:
Może to zabrzmieć trochę solomonicznie, ale z mojego doświadczenia wynika, że przyszłość należy do podejść hybrydowych, w których kilka wielordzeniowych węzłów pamięci współużytkowanej z wielowątkowymi jądrami jest połączonych za pośrednictwem paradygmatu pamięci rozproszonej, takiego jak MPI.
Jest jednak kilka problemów i nie dotyczą one wcale sprzętu. Po pierwsze, większość programistów równoległych jest mocno zainwestowanych w kody typu MPI i bardzo niechętnie są pierwszymi, którzy wdrażają ponownie część lub całość swojej bazy kodu za pomocą nowego paradygmatu. Brak osób korzystających z pamięci współdzielonej prowadzi do wolniejszego postępu algorytmów dla tego obszaru, co sprawia, że każda inwestycja wydaje się jeszcze bardziej bezcelowa.
Drugim problemem jest to, że wszyscy kojarzą paralelizm pamięci współużytkowanej z OpenMP . Chociaż OpenMP to przyjemny, szybki i brudny sposób rozwiązywania małych, prostych problemów na niewielkiej liczbie procesorów, jest to absolutnie okropny model programowania dla prawdziwej równoległości pamięci wspólnej. Chociaż wszyscy w pewnym momencie nauczyliśmy się kilku prostych i wydajnych paradygmatów programowania równoległego, np. Puli wątków lub harmonogramów , nie są one łatwe do wdrożenia przy użyciu OpenMP i, szczerze mówiąc, nie jest to rodzaj równoległości, która OpenMP zachęca programistów do korzystania.
Podsumowując, bariera przejścia od czysto rozproszonej pamięci do paradygmatu wyłącznie / częściowo współdzielonej pamięci jest dość wysoka. Jeśli chcesz efektywnie korzystać z wątków, musisz zapomnieć o OpenMP i samodzielnie zarządzać wątkami i współbieżnością (cześć pthreads , do widzenia Fortran).
Ale po co w ogóle stosować podejście hybrydowe? Cóż, chociaż MPI skaluje się do tysięcy rdzeni, podstawowym modelem jest model synchronizacji i statycznych wzorców komunikacji. Jest to dobre w przypadku niektórych problemów, np. Symulacji miliardowych cząstek, ale nieoptymalne w przypadku trudniejszych lub drobnoziarnistych problemów. Paradygmaty pamięci współużytkowanej znacznie ułatwiają dynamiczne równoważenie obciążenia i / lub komunikację asynchroniczną, ale wymagają dużego wysiłku programistycznego.
źródło