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
- Żetony specjalnego przeznaczenia: Pomyśl o dużych jednostkach wektorowych, takich jak akceleratory (widok zalecany przez Billa Dally z Nvidii)
- Low Power Chips: klastry oparte na ARM (w celu dostosowania budżetów energii)
- Układanie żetonów: pomyśl o układaniu żetonów o różnych specyfikacjach (dzieło Avant Argwal )
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:
- Rozwiń swoje algorytmy, aby pasowały do co najmniej trzech poziomów równoległej hierarchii.
- Zaprojektuj algorytmy pod kątem jąder, które można przenosić między dziedziczeniem.
- Zmniejsz potrzebę sekwencyjnych procesów, wszystkie te efekty pojawią się asynchronicznie, ponieważ synchroniczne wykonywanie jest po prostu niemożliwe.
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