Analiza i modelowanie wydajności obliczeń Lab 6. Wielowątkowość i dostęp do pamięci podręcznej
Cel: Przetestowanie możliwości przypisywania wątków do rdzeni oraz sprawdzenie wpływu przypisania na wydajność
Kroki:
1. Uruchom w terminalu polecenie wypisania zawartości pliku \proc\cpuinfo . Przeanalizuj wydruk na ekranie – w szczególności numerację poszczególnych rdzeni fizycznych i procesorów logicznych (w przypadku istnienia jakiejś formy sprzętowej wielowątkowości (SMT, simultaneous multithreading, hyperthreading itp.) numeracje te są różne). Dla każdego z widzianych przez system operacyjny logicznych procesorów (oznaczających wątki sprzętowe, ID wyświetlany w linii oznaczanej processor), linia physical id oznacza numer gniazda (mikroprocesora), a linia core id zawiera numer rdzenia fizycznego (inne interesujące z punktu widzenia wydajności dane zapisywane w \proc\cpuinfo to np.
częstotliwość pracy w MHz, rozmiar pamięci podręcznej L3, liczba fizycznych rdzeni (cpu cores), liczba procesorów logicznych (siblings), itp.). Wypisz w tabeli o formacie podanym poniżej odczytane wartości
log_proc ID 0 1 2 3 4 5 ...
core ID CPU ID
Numeracja logicznych procesorów jest istotna z punktu widzenia wydajności, gdyż posługuje się nią system operacyjny przy wykonywaniu kolejnych wątków systemowych jako przypisanych do kolejnych procesorów logicznych. W przypadku mikroprocesorów z SMT, zazwyczaj najpierw numerowane są wątki po jednym na fizyczny rdzeń, a dopiero potem wątki korzystające z SMT.
2. Uruchom w terminalu polecenie numactl -H (numactl nie zawsze znajduje się w standardowych dystrybucjach Linuksa, powinno jednak być łatwe znalezienie
odpowiedniego pakietu dla konkretnej wersji systemu). Zgodnie z dokumentacją (man numactl) numactl korzysta z informacji w \proc\cpuinfo . Polecenie uruchomione z opcją -H wypisuje na ekranie nie tylko numery kolejnych procesorów logicznych, ale także przyporządkowanie fizycznych elementów pamięci DRAM procesorom logicznym (a w efekcie także wątkom pracującym na procesorach logicznych – utożsamianych często z wątkami sprzętowymi). W przypadku komputerów wieloprocesorowych (pojedyncze gniazdo mikroprocesora określane jako node), node distances odnosi się do faktu pamięci o niejednorodnym dostępie (NUMA), gdzie układy DRAM są przypisywane konkretnym gniazdom (za pomocą kanałów pamięci), a dostęp do własnych układów jest szybszy niż dostęp do układów przypisanych innym gniazdom (dostęp odbywa się przez pośredniczące kanały połączeń miedzy gniazdami). Różnice w czasie dostępu do konkretnych pul pamięci znajdują odbicie w wartościach node distances.
3. Bardziej szczegółowe informacje o przypisaniu pamięci wątkom można uzyskać korzystając z pakietu likwid. Uruchomienie polecenia likwid-topology pozwala na wyświetlenie
przypisania procesorom logicznym (i wykonywanych na nich wątkom) modułów pamięci podręcznej – konkretnie likwid-topology wypisuje grupy wątków sprzętowych
korzystających wspólnie z jednego modułu pamięci podręcznej odpowiedniego poziomu.
[Na serwerze ESTERA skrypt likwid-topology znajduje się w katalogu /home/students_wo/common_files/likwid/bin/ ]
4. Ostatnim z nowych wykorzystywanych w laboratorium narzędzi jest program htop. Jest to wersja polecenia top wzbogacona o wypisywanie na ekranie obciążenia konkretnych procesorów logicznych (graficzna reprezentacja procentu zajętości czasu CPU) 5. Pierwszym z zadań laboratorium jest zaobserwowanie działania polecenia numactl z
opcjami umożliwiającymi przydzielenie wątków konkretnym procesorom logicznym. W tym celu należy wykorzystać program latency_throughput_multithreaded_vector_flops z laboratorium nr 3 (wersja o najwyższej osiągniętej w trakcie laboratorium wydajności – dla liczby wątków równej liczbie rdzeni powinna osiągać wydajność mierzoną lokalnie, bez narzutu systemowego, co najmniej 90% wydajności teoretycznej całego serwera,
wskazówka dla Estery: #define LOCAL_SIZE 16)
1. dla wybranej wersji programu liczbą wątków należy sterować za pomocą parametru NO_TH – linia ok. 180 w pliku latency_throughput_multithreaded_vector_flops.c – po zmianie pliku źródłowego konieczna jest rekompilacja (należy pamiętać o opcji
wektoryzacji w pliku Makefile)
[ tylko wersja w pełni wykorzystująca możliwości systemu, (na serwerze ESTERA ok.
700 GFLOP/s dla 20 wątków) , pozwala łatwo zaobserwować różnice wynikające z różnego przypisania wątków do rdzeni ]
6. Uruchom wybrane zadanie na kolejnych procesorach logicznych (jeden wątek na procesor, liczba wątków jest równa liczbie procesorów logicznych) i obserwuj osiągniętą wydajność (program latency_throughput_multithreaded_vector_flops wypisuje wydajność w GFLOP/s – wartością osiągającą ok. 700 GFLOP/s jest wydajność zmierzona bez narzutu na
tworzenie wątków, rozgrzewkę itp.: Main program - calculations based on local
measurements (no system overhead)). Wyniki zapisz w tabeli o poniższym formacie (po przeczytaniu uwag poniżej tabeli):
Liczba wątków/procesorów logicznych 1 2 4 8 16 20 itd.
skok 1
skok 2, %nr_proc+x skok nr_proc/2, %nr_proc+x
Liczba procesorów rośnie aż do osiągnięcia całkowitej liczby rdzeni w systemie (dla serwera ESTERA 20). Kolejne wiersze odpowiadają przyjmowaniu jako kolejnych procesorów do przypisania wątków, procesorów oddalonych o zadany skok (wartości parametru skok można dopasować do konkretnej maszyny uwzględniając jej charakterystykę). W przypadku przekroczenia liczby nr_proc (liczby procesorów logicznych maszyny), należy zacząć od początku, pomijając procesory już uwzględnione Np. dla skoku 4 wywołanie z 8 procesorami może mieć postać:
numactl -C 0,4,8,12,16,20,24,28 ./latency_throughput_multithreaded_vector_flops a z 16 procesorami postać:
numactl -C 0,4,8,12,16,20,24,28,32,36,1,5,9,13,17,21 ./latency_throughput_multithreaded_vector_flops
(dla ułatwienia wzorce dla różnych wartości skoku można zapisać w pliku i wykorzystywać dla kolejnych uruchomień w tym i kolejnych punktach)
[wzorce dla serwera Estera znajdują się na stronie przedmiotu, w pliku wzorce_Estera.txt]
- zilustruj na rysunku sposób przypisania wątków (W0, W1, W2, itd.) do rdzeni, w przypadku ośmiu wątków i różnych wartości parametru skok (można wykorzystać schemat maszyny w postaci tabelki – l to procesor logiczny a zaznaczone zostały wartości dla skok=4:
mikroprocesor (gniazdo, socket) - 0 mikroprocesor (gniazdo, socket) - 0
rdzeń r - 1 r - 2 r - 3 r - 4 r - 5 r - 6 r - 7 r - 8 r - 9 r - 0 r - 1 r - 2 r - 3 r - 4 r - 5 r - 6 r - 7 r - 8 r - 9
l0 l20 l1 l21 l2 l22 l3 l23 l4 l24 l5 l25 l6 l26 l7 l26 l8 l28 l9 l29 l10 l30 l11 l31 l12 l32 l13 l33 l14 l34 l15 l35 l16 l36 l17 l37 l18 l38 l19 l39
W0 W1 W2 itd.
tabelka uwzględnia hyperthreading)
- uzyskane wyniki zilustruj na wykresie zależności wydajności od liczby procesorów, po jednej krzywej dla każdej wartości parametru skok. Wyciągnij wnioski z przebiegu krzywych.
7. Rozpakuj paczkę latency_and_pining.tgz, skompiluj i uruchom w standardowej konfiguracji.
8. Dokonaj podobnej analizy jak dla zadania latency_throughput_multithreaded_vector_flops, tym razem dla problemu random_pointer_chasing_mth (w wersji wielowątkowej z paczki).
Przeprowadź badania dla rozmiaru tablicy znalezionego w lab. 5 jako dającego
reprezentatywne wyniki dla opóźnienia dostępu do pamięci DRAM (zmień odpowiednio ustawienie DEFAULT_WORKING_SIZE w pliku random_pointer_chasing_mth.c). Liczbą wątków wykonujących obliczenia można sterować za pomocą parametru NO_TH w pliku random_pointer_chasing_mth.c. Wyniki zapisz w tabeli, takiej jak w p.6, lecz zawierającej przepustowość w GB/s. Skonstruuj wykres zależności przepustowości od liczby wątków, podobnie jak w p.6. Wyciągnij wnioski z przebiegu krzywych.
[ Dla serwera Estera wartość 64MB (i wyższe) dla DEFAULT_WORKING_SIZE, przy skoku DEFAULT_STRIDE powyżej 64B (128B i więcej) powinny dać reprezentatywne wyniki – w eksperymentach mozna pozostawić domyślne wartości z paczki ]
9. Uruchom zadanie z 40 wątkami (pełne wykorzystanie SMT). Dla jakich typów aplikacji, jak można wywnioskować z uzyskanych w tym i poprzednim punkcie wyników, szczególne przydatne może być wykorzystanie sprzętowej wielowątkowości?
Dalsze kroki:
1. Przeprowadź badania dla algorytmu random_pointer_chasing_mth dla trzech dodatkowych rozmiarów tablicy znalezionych jako dające reprezentatywne wyniki dla opóźnienia dostępu do kolejnych poziomów pamięci podręcznej: L3, L2, L1 (sterując parametrem
DEFAULT_WORKING_SIZE, należy także zmienić parametr DEFAULT_STRIDE na odpowiedni do pomiaru opóźnienia danego poziomu pamięci podręcznej). Wyniki zapisz w trzech tabelach, takich jak w p.8 i skonstruuj trzy wykresy takie jak w p.8. Wyciągnij wnioski z przebiegu krzywych na wykresach.
[ szczególnie interesujące może być wykorzystanie pamięci L3 – współdzielonej przez wszystkie rdzenie pojedynczego mikroprocesora, można rozważyć dwa rozmiary pamięci, które dawały te same opóźnienia dostępu dla przypadku jedno-wątkowego (np. 0,5MB i 16MB, oba ze skokiem np. 256B) i zobaczyć jak wyglądać będzie sprawa w przypadku wielowątkowym i różnych sposobach przypisania wątków do procesorów logicznych ; w przypadku pamięci L1 i L2 współdzielenie dotyczy tylko wątków pracujących na jednym rdzeniu przy wykorzystaniu simultaneous multithreading (hyperthrading) )
2. Przeprowadź eksperymenty dla innych wartości skoku, dla których mogą pojawić się ciekawe efekty, w przypadku pamięci każdego z rodzajów: DRAM, L3, L2, L1 Sprawozdanie:
1. Zrealizowane kroki, spostrzeżenia z analizy kodu (a także ewentualnie odpowiadającego kodu asemblera i uzyskanych wartości liczników sprzętowych), wykresy, opis wykresów, wnioski
