Biuletyn nr 35

Biuletyn KDM
1 | 2 | 3 | 4 | 5
6 | 7 | 8 | 9 | 10
11 | 12 | 13 | 14
15 | 16 | 17 | 18
19 | 20 | 21 | 22
23 | 24 | 25 | 26
27 | 28 | 29 | 30
31 | 32
Lista biuletynów

Biuletyn nr 35 (5 października 2011)

Spis treści

Konstrukcja multi-zadań w systemie kolejkowym PBS

Autor: Maciej Szpindler

Opiszemy tu funkcjonalność systemu kolejkowego PBS (Torque) pozwalającą tworzyć multi-zadania obliczeniowe, które można też nazwać zadaniami z parametrem. Służy do tego konstrukcja o nazwie job_array.

Idea działania polega na utworzeniu zadania parametryzowanego, które zostanie uruchomione wielokrotnie dla wartości parametru z określonego zakresu. Parametrem jest liczna naturalna. Zbiór takich zadań, nazwany przez nas multi-zadaniem, jest reprezentowany przez system PBS jako tablica zadań.

Podobny efekt można uzyskać za pomocą skryptu, który wielokrotnie wykona komendę qsub tworząc kolejne nowe zadanie w systemie kolejkowym. Zamiast tego wygodniej utworzyć multi-zadanie, którego każde zadanie składowe oparte jest o ten sam skrypt kolejkowy.

Multi-zadanie tworzymy dodając opcję -t do komendy qsub lub do skryptu kolejkowego. Argumentem dla tej opcji jest lista liczb oddzielonych przecinkami - każda z liczb identyfikuje kolejne zadanie składowe lub dwie liczby oddzielone minusem - zakres numerów zadań składowych.

Przykładowo zadanie tworzymy:

qsub -t 0,1,2,3 job.pbs

lub równoważnie:

qsub -t 0-3 job.pbs

w efekcie uzyskamy multi-zadanie złożone z 4 zadań, które w systemie kolejkowym widoczne jest w następujący sposób:

qstat
Job ID               Username Queue    Jobname          SessID NDS   TSK Memory Time  S Time
-------------------- -------- -------- ---------------- ------ ----- --- ------ ----- - -----
132042-0.halo2       mszpindl halo2    pbs_array-0         --      1  --    8gb 00:01 Q   -- 
132042-1.halo2       mszpindl halo2    pbs_array-1         --      1  --    8gb 00:01 Q   -- 
132042-2.halo2       mszpindl halo2    pbs_array-2         --      1  --    8gb 00:01 Q   -- 
132042-3.halo2       mszpindl halo2    pbs_array-3         --      1  --    8gb 00:01 Q   --

Ten sam efekt uzyskamy umieszczając w skrypcie PBS linie z dyrektywą:

#PBS -t 0-3

Zauważmy, że powstały 4 zadania o identyfikatorach 132042-x.halo2, gdzie 132042 oznacza identyfikator multi-zadania, natomiast x numer zadania składowego. Aby odwołać się do zadania składowego x, używamy identyfikatora 132042-x.

Podobnie pliki wynikowe (przekierowane standardowe wyjście i wyjście błędu programu) znajdą się w plikach nazywanych NAZWA_ZADANIA.oPBS_ID-x oraz NAZWA_ZADANIA.ePBS_ID-x, gdzie x oznacza numer odpowiedniego zadania składowego.

Jako parametr w zadaniach składowych możemy użyć zmiennej środowiskowej o nazwie:

$PBS_ARRAYID

która przyjmuje wartość liczbową odpowiadającą numerowi zadania składowego. Jest ona dostępna z poziomu skryptu kolejkowego. Można użyć jej przykładowo jako parametru sterującego wyborem plików z danymi wejściowymi lub innymi parametrami sterującymi wykonaniem programu.

Uwaga: wykonanie zadań wchodzących w skład multi-zadania nie jest równoległe, tzn. zadania te nie zawsze będą wykonywać się równocześnie, a także kolejność ich wykonania nie jest określona. Ponadto zakłada się niezależność zadań składowych, co znaczy że musi być możliwe wykonanie ich całkowicie niezależnie od siebie.

Optymalizacja oprogramowania na systemie Notos

Autor: Maciej Cytowski

Artykuł ten opisuje kroki optymalizacji przykładowego programu równoległego na systemie Blue Gene/P. W celu zaprezentowania podstawowych technik optymalizacji w sposób jasny i zrozumiały wybrany został prosty problem numeryczny - równoległe mnożenie macierzy. Opisywane metody mogą być również stosowane w przypadku bardziej skomplikowanych kodów obliczeniowych.

Kompilatory Blue Gene/P - rekomendacje

Jak opisywaliśmy w Biuletynie nr 34 kompilacja na systemie Notos odbywa się przy użyciu tzw. cross-kompilatorów na węźle dostępowym. Oznacza to, że kody powinny być zawsze kompilowane na węźle dostępowym, a uruchamiane poprzez system kolejkowy na komputerze Blue Gene/P.

Dostępne są kompilatory z dwóch rodzin:

  • Rodzina kompilatorów XL: C/C++ oraz Fortran - wbudowane optymalizacje kodu specyficzne dla architektury Blue Gene/P, związane m.in. z obsługą podwójnej jednostki zmiennoprzecinkowej (FPU), kolejnością wykonywania instrukcji oraz wykorzystaniem wielopoziomowej pamięci,
  • Rodzina kompilatorów GNU: C, C++ oraz Fortran - nie tworzą wysoce zoptymalizowanego kodu na architekturę Blue Gene/P, nie generują kodu dla podwójnej jednostki zmiennoprzecinkowej (FPU), nie wspierają OpenMP.

Przy kompilacji programów na system Blue Gene/P powinniśmy wszędzie gdzie to możliwe korzystać z rodziny kompilatorów XL. Kod maszynowy tworzony przez te kompilatory jest zawsze bardziej wydajny. Kody, które kompilujemy oraz uruchamiamy na systemie Notos, są zwykle napisane przy użyciu biblioteki MPI (Message Passing Interface). Przed kompilacją programów należy ustawić środowisko użytkownika komendą:

module load mpi_default

Udostępnione są następujące kompilatory:

  • C: mpixlc, mpixlc_r
  • C++: mpixlcxx, mpixlcxx_r
  • Fortran: mpixlf{77|90|95|2003}, mpixlf{77|90|95|2003}_r

Kompilatory z przyrostkiem "_r" w nazwie służą do kompilacji kodów wielowątkowych (używających kilku wątków obliczeniowych w ramach pojedynczego procesu). Kod maszynowy tworzony dzięki tym kompilatorom linkowany jest z bibliotekami typu thread-safe. Kompilatorów tych można używać również w przypadku aplikacji nie używających mechanizmu wielowątkowości. Należy używać tych kompilatorów zawsze wtedy gdy nie mamy pewności czy nasza aplikacja wykorzystuje wielowątkowość.

Kompilatory XL posiadają wiele opcji optymalizacji kodu. Oto najważniejsze z nich:

  • -O2 - dokonuje zestawu optymalizacji, które uznane zostały przez deweloperów kompilatora za najlepszą możliwą kombinację,
  • -O3 -qstrict - dokonuje pewnych intensywnych optymalizacji m.in. dotyczących pamięci (opcja -qstrict wyłącza najbardziej agresywne optymalizacje, co pozwala na zachowanie dokładności numerycznej),
  • -O3 - dokonuje agresywnych optymalizacji, które mogą zmieniać semantykę programu (np. zastąpić dzielenie mnożeniem przez odwrotność),
  • -qhot - włącza wysoko-poziomowe transformacje kodu (m.in. zamianę kolejności pętli)
  • -qipa - włącza mechanizm Inter-Procedural Analysis (IPA), który dokonuje analizy struktury całego programu i odwołań pomiędzy jego procedurami (umożliwia m.in. inlining),
  • -O4 = -O3 -qhot -qipa=level=1,
  • -O5 = -O3 -qhot -qipa=level=2,
  • -qarch=450 - tworzy kod dla architektury PowerPC 450 i pojedynczej jednostki zmiennoprzecinkowej,
  • -qarch=450d - próbuje wygenerować kod dla architektury PowerPC 450 i podwójnej jednostki zmiennoprzecinkowej (operacje SIMD),
  • -qtune=450 - optymalizuje pliki obiektowe dla architektury PowerPC 450,
  • -qhot=simd - tworzy kod SIMD wszędzie, gdzie jest to możliwe.

Kompilowanie programu na architekturze Blue Gene/P powinno odbywać się w następujących krokach:

  • użycie podstawowego poziomu kompilacji: -O2 -qtune=450 -qarch=450,
  • próba użycia bardziej zaawansowanych, ale nie agresywnych optymalizacji: -O3 -qstrict -qtune=450 -qarch=450,
  • próba użycia agresywnej optymalizacji: -O3 -qtune=450 -qarch=450 (Uwaga: należy sprawdzić wyniki numeryczne),
  • próba wygenerowania kodu SIMD: -O2 -qhot=simd -qtune=450 -qarch=450d,
  • próba użycia transformacji wysoko-poziomowych: -O3 -qhot -qtune=450 -qarch=450 (Uwaga: należy sprawdzić wyniki numeryczne).

Przy pierwszych kompilacjach warto pamiętać również o opcji -g, dzięki której tworzona jest tablica symboli dla naszego kodu. W przypadku błędnego wykonania programu, opcja ta może nam pomóc w debugowaniu. Ponadto wzbogaci ona wszelkie informacje, które możemy uzyskać od narzędzi badania wydajności kodu. Ciekawostką jest, że w przypadku kompilatorów XL dla architektury Blue Gene/P opcja -g nie wpływa na wydajność wygenerowanego przez kompilator kodu maszynowego. Opcji tej można zatem używać zawsze.

Aby dowiedzieć się jakich optymalizacji dokonał kompilator warto użyć zestawu opcji raportowania: -qreport -qlist -qsource. Po kompilacji programu w katalogu roboczym pojawi się plik o rozszerzeniu .lst, który zawierać będzie informacje o optymalizacjach.

Przykładowy program

Przykładowy program to proste zagadnienie numeryczne - mnożenie dwóch macierzy kwadratowych. Realizację tego zadania rozważamy w kilku konfiguracjach, które wymienione zostały poniżej. Do artykułu załączone jest archiwum (zip) zawierające wszystkie przykładowe programy wraz ze skryptami kolejkowymi, które można wykorzystać do wstawiania zadań na maszynie Notos.

  • Implementacja z pojedynczym procesem: mxm.c
  • Implementacja z pojedynczym procesem oraz funkcją DGEMM: mxm_dgemm.c
  • Implementacja równoległa MPI: cannon.c
  • Implementacja równoległa MPI & OpenMP: cannon_omp.c
  • Implementacja równoległa MPI wykorzystująca funkcję DGEMM: cannon_dgemm.c

Równoległa implementacja mnożenia macierzy wykonana została na podstawie algorytmu Cannon-a.

Kolejne trzy sekcje poświęcone są użyciu różnych trybów optymalizacji do kompilacji przygotowanych programów. Opisane zostały czynności "krok po kroku", które można bezpośrednio powtórzyć w ramach ćwiczenia pracy i kompilacji na systemie Notos.

Implementacja single-core

Ta sekcja opisuje optymalizację implementacji mnożenia macierzy z pojedynczym procesem.

Wpierw spróbujemy skompilować i uruchomić program mxm.c.

Podstawowa optymalizacja

Spróbujemy wykorzystać podstawową optymalizację poziomu O2.

Skompiluj program za pomocą następującej komendy:

bgxlc_r -O2 -qtune=450 -qarch=450 -g mxm.c -o mxm

Wstaw zadanie do kolejki za pomocą komendy:

llsubmit mxm.ll

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 1024x1024: 16.75s (~128 MFlop/s, 3.7% maksymalnej teoretycznej wydajności )

Intensywna optymalizacja

Spróbujemy wykorzystać bardziej intensywną optymalizację wykonywaną przy użyciu poziomu O3. Aby zapewnić zgodność wyników numerycznych wykorzystamy opcję -qstrict.

Skompiluj program za pomocą następującej komendy:

bgxlc_r -O3 -qstrict -qtune=450 -qarch=450 -g mxm.c -o mxm

Wstaw zadanie do kolejki za pomocą komendy:

llsubmit mxm.ll

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 1024x1024: 6.28s (~342 MFlop/s, 10% maksymalnej teoretycznej wydajności)

Podwójna jednostka zmiennoprzecinkowa

Spróbujemy wykorzystać dostępną w architekturze PowerPC 450 podwójną jednostkę zmiennoprzecinkową.

Skompiluj program za pomocą następującej komendy:

bgxlc_r -O3 -qstrict -qtune=450 -qarch=450d -g mxm.c -o mxm

Wstaw zadanie do kolejki za pomocą komendy:

llsubmit mxm.ll

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 1024x1024: 3.46s (~620 MFlop/s, 18% maksymalnej teoretycznej wydajności)

Transformacje wysokiego poziomu

Spróbujemy wykorzystać transformacje wysokiego poziomu, które wykonywane są na kodzie przy użyciu przełącznika -qhot.

Skompiluj program za pomocą następującej komendy:

bgxlc_r -O3 -qhot -qtune=450 -qarch=450d -g -qreport -qlist -qsource mxm.c -o mxm

Dodatkowo używamy opcji raportowania: –qreport –qlist oraz –qsource. Kompilator tworzy plik listingu mxm.lst, który zawiera informację o dokonanych optymalizacjach.

Wstaw zadanie do kolejki za pomocą komendy:

llsubmit mxm.ll

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 1024x1024: 7.82s (~274 MFlop/s, 8% maksymalnej teoretycznej wydajności)

Mimo włączenia teoretycznie bardziej zaawansowanej optymalizacji wydajność kodu spadła z 18% na 8% maksymalnej teoretycznej wydajności. Aby dowiedzieć się dlaczego tak się stało należy przeanalizować optymalizacje dokonane przez kompilator. W pliku listingu widzimy, że kompilator przeanalizował strukturę kodu i wykrył typ wykonywanych obliczeń. Wykonana została zamiana fragmentu kodu na wbudowaną w kompilator XL implementację mnożenia macierzy podwójnej precyzji DGEMM. Ciekawostką jest fakt, iż nie jest to najbardziej zoptymalizowana wersja funkcji DGEMM dostępna na architekturze Blue Gene/P. Widać to po uzyskanych wynikach, gdyż nasza własna implementacja miała lepszą wydajność.

Funkcja DGEMM z biblioteki ESSL

Spróbujemy wykorzystać funkcję DGEMM dostępną w bibliotece IBM ESSL (Engineering and Scientific Subroutine Library). Biblioteka ESSL jest popularnym i wydajnym narzędziem wykorzystywanym na systemach Blue Gene/P. Zawiera implementacje algorytmów numerycznych z takich dziedzin jak algebra liniowa, zagadnienia własne, transformata Fouriera, sortowanie, interpolacja oraz generatory liczb losowych.

Tym razem wykorzystamy program mxm_dgemm.c. W kodzie tym dokonaliśmy zamiany pętli wykonujących mnożenie macierzy na wywołanie funkcji DGEMM. Zauważmy, że aby skorzystać z biblioteki ESSL musimy w programie załączyć plik nagłówkowy essl.h. Potrzebny jest również specjalny sposób kompilacji i linkowania. W przypadku kodów napisanych w języku C wymagane jest również linkowanie z niektórymi bibliotekami XL Fortran-a (biblioteka ESSL napisana została w języku Fortran).

Skompiluj program za pomocą następującej komendy:

bgxlc_r -O3 -qhot -qtune=450 -qarch=450d -g -I/opt/ibmmath/essl/4.4/include -c mxm_dgemm.c

Dokonaj linkowania za pomocą następującej komendy:

bgxlc_r -O3 -qhot -qtune=450 -qarch=450d mxm_dgemm.o -g -L/opt/ibmmath/essl/4.4/lib -lesslbg -lesslsmpbg -L/opt/ibmcmp/xlf/bg/11.1/bglib -lxlf90_r -lxlopt -lxl -lxlfmath -lxlsmp -o mxm_dgemm

Wstaw zadanie do kolejki za pomocą komendy:

llsubmit mxm.ll

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 1024x1024: 0.84s (~2.5 GFlop/s, 75% maksymalnej teoretycznej wydajności)

Implementacja równoległa

Ta sekcja opisuje optymalizację równoległej implementacji mnożenia macierzy na podstawie algorytmu Cannon-a.

Rozpoczniemy od kompilacji i uruchomienia programu cannon.c. Przejdziemy następnie do pracy z programem cannon_dgemm.c.

Testy wydajności przeprowadzone zostały dla dwóch rozmiarów macierzy: 8192x8192 oraz 16384x16384. Rozmiar macierzy powinien zostać ręcznie ustawiony w programie w celu wygenerowania wyników podobnych do opisanych. Ponadto testy przeprowadzone zostały na dwóch partycjach komputera Blue Gene/P: pierwsza o rozmiarze 256 węzłów oraz druga o rozmiarze 1024 węzłów.

Implementacja MPI algorytmu Cannon'a

Najwpierw przetestujemy wydajność implementacji algorytmu Cannon'a wykorzystującego bibliotekę MPI.

Skompiluj program za pomocą następującej komendy:

mpixlc_r -O3 -qstrict -qtune=450 -qarch=450d -g cannon.c -o cannon

Używamy opcji kompilacji, które okazały się być najbardziej wydajnym podejściem w przypadku implementacji z użyciem pojedynczego procesu.

Wstaw zadanie do kolejki za pomocą komendy:

llsubmit cannon.ll

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 8192x8192: 11.4s (256 węzłów), 2.89s (1024 węzły)

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 16384x16384: 89.8s (256 węzłów), 23.2s (1024 węzły)

Implementacja MPI algorytmu Cannon'a wykorzystująca bibliotekę IBM ESSL

Jako drugą przetestujemy implementację algorytmu Cannon'a wykorzystującą bibliotekę MPI oraz funkcję DGEMM z biblioteki IBM ESSL.

Skompiluj program za pomocą następującej komendy:

mpixlc_r -O3 -qstrict -qtune=450 -qarch=450d -g -I/opt/ibmmath/essl/4.4/include -c

Dokonaj linkowania za pomocą następującej komendy:

mpixlc_r -O3 -qstrict -qtune=450 -qarch=450d cannon_dgemm.o -g -L/opt/ibmmath/essl/4.4/lib -lesslbg -L/opt/ibmcmp/xlf/bg/11.1/bglib -lxlf90_r -lxlopt -lxl -lxlfmath -lxlsmp -o cannon_dgemm

Wstaw zadanie do kolejki za pomocą komendy:

llsubmit cannon_dgemm.ll

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 8192x8192: 0.69s (256 węzłów), 0.36s (1024 węzły)

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 16384x16384: 4.24s (256 węzłów), 1.79s (1024 węzły)

Dodatkowo prezentujemy również czas wykonania mnożenia macierzy dla bardzo dużych rozmiarów macierzy. Te testy przeprowadziliśmy tylko i wyłącznie na partycji wielkości 1024 węzłów. Prezentowane wyniki mogą pomóc odpowiedzieć na pytanie: jak szybko jesteśmy w stanie przemnożyć dwie ogromne macierze kwadratowe na pojedynczej szafie obliczeniowej systemu Blue Gene/P.

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 131072x131072: 466.39s (1024 węzły)

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 262144x262144: 3511.05s (1024 węzły)

Implementacja hybrydowa

W tej sekcji opisujemy hybrydową implementację równoległego mnożenia macierzy na podstawie algorytmu Cannon'a. W opisie wykorzystujemy program cannon_omp.c oraz ponownie program cannon_dgemm.c, który tym razem linkujemy z wielowątkową wersją biblioteki IBM ESSL (SMP).

Wykonujemy testy, które mają na celu porównanie:

  • wydajności kodu MPI z wydajnością kodu MPI+OpenMP dla rozmiaru macierzy 16384x16384 na 1024 węzłach,
  • wydajności kodu MPI DGEMM z wydajnością kodu MPI DGEMM SMP dla rozmiaru macierzy 16384x16384, 131072x131072 oraz 262144x262144 na 1024 węzłach.

Implementacja hybrydowa MPI+OpenMP algorytmu Cannon'a

Skompiluj program za pomocą następującej komendy:

mpixlc_r -O3 –qsmp=omp -qstrict -qtune=450 -qarch=450d -g cannon.c -o cannon

Wstaw zadanie do kolejki za pomocą komendy:

llsubmit cannon_omp.ll

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 16384x16384: 23.18s (1024 węzły)

Jak widać różnica w wydajności wersji hybrydowej MPI+OpenMP oraz wersji tylko MPI jest znikoma.

Implementacja hybrydowa MPI+DGEMM SMP algorytmu Cannon'a

Skompiluj program za pomocą następującej komendy:

mpixlc_r -O3 -qstrict -qtune=450 -qarch=450d -g -I/opt/ibmmath/essl/4.4/include -c cannon_dgemm.c

Dokonaj linkowania za pomocą następującej komendy:

mpixlc_r -O3 -qstrict -qtune=450 -qarch=450d cannon_dgemm.o -g -L/opt/ibmmath/essl/4.4/lib -lesslsmpbg -L/opt/ibmcmp/xlf/bg/11.1/bglib -lxlf90_r -lxlopt -lxl -lxlfmath -lxlsmp -o cannon_dgemm

Wstaw zadanie do kolejki za pomocą komendy:

llsubmit cannon_dgemm_smp.ll

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 16384x16384: 1.91s (1024 węzły)

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 131072x131072: 459.28s (1024 węzły)

Zmierzony czas wykonania mnożenia macierzy o rozmiarze 262144x262144: 3506.28s (1024 węzły)

Zaobserwowaliśmy wzrost wydajności obliczeń przy zastosowaniu biblioteki w wersji SMP, który może mieć znaczenie przy obliczeniach w większych skalach.

Podsumowanie i literatura

Zaprezentowaliśmy sposoby optymalizacji kodu na architekturze Blue Gene/P, które należy brać pod uwagę przy rozwijaniu własnego oprogramowania, bądź kompilacji pakietów obliczeniowych. Równoległość obliczeń jest nierozłącznie związana z architekturą Blue Gene/P, a wydajność aplikacji równoległych w dużej mierze zależy od natury implementowanego problemu naukowego oraz od umiejętnego zaprogramowania równoległości. Należy jednak pamiętać również o optymalizacji, której można dokonać na poziomie pojedynczego rdzenia obliczeniowego, gdyż umiejętna optymalizacja kodu na tym poziomie może prowadzić do kilku- a nawet kilkudziesięciokrotnego zwiększenia wydajności.

W artykule wykorzystane zostały materiały przygotowane na tutorial programowania i obsługi komputerów równoległych przygotowany w ramach projektu POWIEW na konferencję 19th International Conference on Parallel Processing and Applied Mathematics (PPAM 2011).

Dostęp do europejskich zasobów PRACE

Autor: Maciej Marchwiany

Projekt PRACE (Partnership for Advanced Computing in Europe) koncentruje się na udostępnianiu dużych zasobów komputerowych dla szerokiej grupy użytkowników. Pozwala on na dostęp do najnowszych architektur oraz ogromnych mocy obliczeniowych umożliwiając prowadzenie badań z niemal wszystkich dziedzin nauki. Wielkość projektu pozwala na dużą dostępność do jego zasobów także dla naukowców z Polski.

W projekcie PRACE biorą udział ośrodki z 21 krajów europejskich. Polska reprezentowana jest przez konsorcjum wszystkich polskich centrów KDM (Poznań, Warszawa, Kraków, Wrocław, Gdańsk) prowadzone przez PCSS, Poznań.

Dostępne systemy

W projekcie PRACE dostępne są w szczególności dwa duże systemy komputerowe:

  • IBM Blue Gene/P – JUGENE – zainstalowany w GCS w Jülich, Niemcy. Maksymalna liczba dostępnych rdzeni obliczeniowych wynosi 294 912. Szczegółowy opis maszyny i zasady jej użytkowania można znaleźć na stronie: http://www.fz-juelich.de/jsc/jugene.
  • Bull Bullx cluster – CURIE – zainstalowany przez GENCI w ośrodku CEA w Bruyères-Le-Châtel, Francja. CURIE jest oparty głównie na architekturze x86 z thin i fat nodami połączonymi ze sobą za pomocą QDR Infiniband. Cała instalacja składa się ze 114 racków, co daje 92 160 rdzeni obliczeniowych. Peak performance całej maszyny wynosi 1.6 Petaflops. Pamięć dostępna na rdzeń jest równa 4 GBytes przy całkowitej pamięci na poziomie 360 Tbytes.

W czasie trwania projektu udostępnione zostaną kolejne maszyny.

Dostęp do zasobów

Zasoby PRACE dostępne są dla użytkowników w ramach trzech form dostępu: Programme Access, Project Access i Preparatory Access. Programme Access jest dostępny wyłącznie dla największych europejskich projektów i ośrodków HPC, które udostępniają swoje zasoby w ramach PRACE. Project Access jest dedykowany dla naukowców oraz grup badawczych (włącznie z międzynarodowymi grupami badawczymi) trwającymi co najmniej rok. Preparatory Access pozwala na dostęp do zasobów podczas rozwijania oprogramowania i testowania ich skalowalności oraz przygotowywania projektów dla Project Access. Wnioski Project Access są rozważane dwa razy do roku. Wnioski Preparatory Access są przyjmowane ciągle.

Typy Preparatory Access

W projekcie PRACE istnieją trzy rodzaje dostępu do zasobów komputerowych w ramach Preparatory Access pozwalające na dostosowanie oferowanych zasobów do potrzeb konkretnego użytkownika.

  • A typ – Testy skalowalności kodów. Typ ten ma pozwalać na uzyskanie informacji o zachowaniu aplikacji (w szczególności skalowalności) pozwalające na optymalizacje przyszłych prac oraz określenie skalowalności kodu w zależności od różnych parametrów. Maksymalne zasoby dostępne w typie A wynoszą: 100,000 core hours na JUGENE i 50,000 core hours na CURIE. Maksymalny czas dostępu wynosi 2 miesiące (włącznie z czasem na złożenie raportu z prac).
  • B typ – Rozwijanie i optymalizacja kodów bez wsparcia PRACE. Wniosek musi zawierać plan prac oraz ich opis wraz z opisem posiadanych zasobów ludzkich pozwalających na wykonanie prac. Maksymalne zasoby dostępne w typie B wynoszą: 250,000 core hours na JUGENE i 200,000 core hours na CURIE. Maksymalny czas dostępu wynosi 6 miesięcy (włączając czas na złożenie raportu z prac).
  • C typ – Rozwijanie kodów z wsparciem ekspertów PRACE. Maksymalne zasoby dostępne w typie C wynoszą: 250,000 core hours na JUGENE i 200,000 core hours na CURIE. Maksymalny czas dostępu wynosi 6 miesięcy (włączając czas na złożenie raportu z prac).

Wnioski są rozpatrywane nie rzadziej niż raz na 2 miesiące.

Korzystanie z tzw. Preparatory Access zalecane jest dla projektów, które planują złożyć wniosek o dostęp projektowy. Aby uzyskać pozytywną opinię dla wniosku na Project Access wymagane jest wykazanie odpowiedniej skalowalności oprogramowania na wskazanych systemach. Testy skalowalności mogą być realizowane w dostępie typu A. W przypadku niedostatecznej skalowalności można skorzystać z dostępów typu B i C.

Jak wnioskować

Wszystkie wnioski muszą być przesyłane przez stronę internetową projektu PRACE: http://www.prace-ri.eu/hpc-access. Aplikacje są opiniowane przez ekspertów PRACE i na tej podstawie przyznawane są zasoby, dlatego bardzo ważne jest dokładne opisanie kodu i planu prac podczas składania wniosków. Szczególnie zachęcamy do wnioskowanie o dostęp typu C, w którym można uzyskać pomoc programistów pracujących dla projektu PRACE.

W obsłudze i pomocy technicznej dla projektów PRACE biorą udział polskie ośrodki, w tym ICM. Zapraszamy do współpracy.

Program PRACE pozwala na szeroki dostęp do dużych mocy komputerowych. Stanowi on dużą szansę dla polskich naukowców na uzyskanie dostępu do największych mocy obliczeniowych w Europie oraz pozwala na przeprowadzenie obliczeń w bardzo dużej skali. Szczegóły odnośnie składania wniosków oraz kryteriów ich oceniania można znaleźć na stronie: http://www.prace-ri.eu/Calls-for-Proposals?lang=en

Więcej informacji na temat sposobu składania wniosków można uzyskać pod adresem email: biueltyn@icm.edu.pl