MPI: rdzenie czy procesory?

Program OS Scheduler spróbuje optymalnie przydzielić oddzielne rdzenie do procesów równoległych aplikacji w systemie wielordzeniowym lub do oddzielnych procesorów w systemie wielordzeniowym.

Interesującym przypadkiem jest wielordzeniowy system multi cpu. Ponownie możesz pozwolić harmonogramowi OS zrobić to za Ciebie, lub możesz wymusić (logiczne/fizyczne) powinowactwo rdzenia do procesów, aby powiązać je z konkretnym rdzeniem.

Dystrybucja procesów na rdzenie i procesory jest obsługiwana przez system operacyjny i implementację MPI. Uruchamiany na pulpicie system operacyjny zazwyczaj umieszcza każdy proces w innym rdzeniu, potencjalnie redystrybuując procesy w czasie wykonywania. W większych systemach, takich jak superkomputer lub klaster, dystrybucja jest obsługiwana przez menedżerów zasobów, takich jak SLURM. Jednak tak się dzieje, jeden lub wiele procesów zostanie przypisanych do każdego rdzenia.

Regarding hardware, rdzeń może uruchamiać tylko jeden proces na raz. Technologie takie jak hyper-threading pozwalają wielu procesom współdzielić zasoby jednego rdzenia. Istnieją przypadki, w których dwa lub więcej procesów na rdzeń jest optymalnych. Na przykład, jeśli proces wykonuje dużą ilość We/Wy plików, inny może zająć jego miejsce i wykonać obliczenia, podczas gdy pierwszy jest zawieszony na odczycie lub zapisie.

W skrócie, podaj MPI liczbę procesów, które chcesz wykonać. Rozkład tych procesów jest wtedy obsługiwane przezroczyste dla użytkownika. Liczba używanych procesów powinna być określona przez wymagania aplikacji (Uprawnienia 2, liczba plików do odczytu), liczbę dostępnych rdzeni oraz optymalną liczbę procesów na rdzeń dla aplikacji.

Z performance view of MPI job, istnieją pewne wyraźne reguły: 1) jeśli kod jest czystym kodem MPI (BLAS nie jest dostrojony z openMP), wyłącz hyperthread i ustaw liczbę zadań na węzeł na rdzenie węzła 2) jeśli kod jest MPI + openMP, możesz ustawić PPN (procesy na węzeł) na rdzenie węzła i OMP_NUM_THEADS na 2 (jeśli są dwa wątki sprzętowe na rdzeń) 3) Jeśli kod jest MPI+openMP i klaster jest ogromny to można ustawić PPN (procesy na węzeł) na 1 i OMP_NUM_THEADS do logicznych liczb PROCESORA, aby zapisać narzut komunikacji

Polecenie mpirun używa listy hostów. Jeśli go nie podasz, prawdopodobnie użyje "localhost" i uruchomi tam wszystkie Twoje procesy. Jeśli uruchamiasz 3 procesy i masz 4-rdzeniową maszynę, prawdopodobnie uzyskasz dobre przyspieszenie, ponieważ system operacyjny zazwyczaj umieszcza je na różnych rdzeniach. Jeśli masz tylko dwa rdzenie, to jeden rdzeń otrzyma dwa procesy.

Poprzednia nie jest do końca prawdziwa, ponieważ system operacyjny może przenosić procesy, więc możesz użyć numactl, aby powiązać je z rdzeniem.

Jeśli znajdujesz się w klastrze wielu węzłów, a następnie dobrze skonfigurowany mpi wygeneruje plik hosta, w którym każdy węzeł pojawia się tyle razy, ile ma rdzeni. Tak więc w klastrze 4 węzłów z 8 rdzeniami na węzeł można zażądać do 32 procesów i oczekiwać zbliżonego do idealnego przyspieszenia. (Jeśli twój kod i algorytm na to pozwalają, oczywiście.) Żądanie 9 procesów w tym klastrze może umieścić 8 na jednym węźle, a 9 na innym, co oczywiście nie jest dobre dla wydajności. Można mieć nadzieję, że oprogramowanie klastra pochodzi z mpirun, który lepiej rozprzestrzenia procesy.