Biuletyn nr 33

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 33 (2 lutego 2011)

Spis treści

Obrona rozprawy doktorskiej Łukasza Bolikowskiego

Dnia 2 lutego 2011 roku o godz. 14:00 w Instytucie Badań Systemowych PAN odbyła się obrona rozprawy doktorskiej Łukasza Bolikowskiego, założyciela i pierwszego redaktora naczelnego Biuletynu.

Tytuł rozprawy: "Methods of semantic drift reduction in large similarity networks" (Metody redukcji dryfu semantycznego w wielkich sieciach podobieństwa).

Serdeczne gratulacje od całego zespołu KDM dla Łukasza, Duygu i Leona!

Więcej informacji

Testy skalowalności pakietu NAMD na halo2

Autor: Maciej Cytowski, Maciej E. Marchwiany

Do przeprowadzania testów skalowalności użyto plików inputowych z projektu PRACE. Testowy układ składał się z ponad 10^6 atomów. Taka wielkość układu pozwalała na badanie zachowanie algorytmu na dziesiątkach procesorów bez obawy o zmianę zachowania algorytmu wraz z istotnym zmniejszeniem liczby atomów przypadających na jeden procesor.

Wyniki

Badano skalowalność trzech skompilowanych wersji pakietu NAMD w wersji 2.7b3:

  • Linux-x86_64 – binarka zoptymalizowana na architekturze Opteron, Athlon64, Intel EMT64
  • Linux-x86_64-ibverbs – binarka pozwalająca na użycie InfiniBandu
  • Halo2 – binarka skompilowana ze źródeł na klastrze halo2

Wszystkie testy zostały przeprowadzone na klastrze halo2. Zbudowany jest on z czterordzeniowych procesorów AMD Opteron z16GB pamięci, połączonych ze sobą w architekturze NUMA. Szczegółowy opis klastra pojawił się we wcześniejszych numerach. Otrzymane wyniki czasowe przedstawia wykres 1.

Namd s1.png
Wykres 1. Zależność czasu obliczeń w funkcji liczby użytych procesorów.

Wykres 1. pokazuje, iż zwiększanie liczby procesorów nawet powyżej 200 istotnie wpływa na czas obliczeń. Widać ponadto, że najlepsze rezultaty uzyskano przy użyciu Linux-x86_64-ibverbs. Binarki Linux-x86_64 oraz Halo2 mają bardzo zbliżone wyniki czasowe, jednak dla niewielkiej liczby rdzeni (mieszczącej się w ramach jednego węzła) wersja Halo2 uzyskuje lepszą wydajność. Charakter widocznych funkcji pozwala sadzić. iż dalsze (powyżej 256) zwiększanie liczby wykorzystywanych procesorów w dalszym ciągu będzie przynosić zmniejszenie całkowitego czasu obliczeń.

Na wykresie 2. przedstawiono skalowanie pakietu (stosunek czasu obliczeń na jednym procesorze podzielony przez czas obliczeń na N procesorach) dla wszystkich trzech badanych binarek oraz teoretyczne skalowanie w funkcji liczby użytych procesorów.

Namd s2.png
Wykres 2. Stosunek czasu obliczeń na jednym procesorze podzielony przez
czas obliczeń na N procesorach w funkcji liczby procesorów.

Na wykres 2. dużo dokładniej widać skalowanie pakietu. Widać, że do 32 procesorów NAMD skaluje się niemal liniowo. Dalsze zwiększanie liczby używanych rdzeni nadal zwiększa wydajność obliczeń i nawet powyżej 128 rdzeni kod dobrze się skaluje. Ze wszystkich testowanych binarek najlepsze wyniki dla dużej liczby procesorów otrzymano dla Linux-x86_64-ibverbs. Podczas gdy dla malej liczby wykorzystywanych rdzeni znacznie lepiej skaluje się wersja Linux-x86_64 (mimo lepszej wydajności Halo2). Wydaje się, że takie zachowanie pakietu może w dużej mierze wynikać z architektury używanego klastra oraz ilości rdzeni w jednym węźle.

Wnioski

Pakiet NAMD bardzo dobrze skaluje się na dziesiątkach, a nawet setkach procesorów. Uzyskane wyniki potwierdzają celowość prowadzenia obliczeń na wielu węzłach klastra halo2. Należy jednak pamiętać, iż skalowanie obliczeń w dużej mierze zależy od badanego układu, jeśli jest on niewielki pakiet będzie się skalował znacznie gorzej.

Testy skalowalności pakietu Quantum Espresso na halo2

Autor: Maciej E. Marchwiany

Testy skalowalności pakietu Quantum Espresso w wersjo 4.2.1 przeprowadzono na klastrze halo2. W ramach testów przebadano szereg układów krystalicznych o różnej symetrii i złożoności. Najbardziej interesujące wydają się wyniki uzyskane dla dużych układów mających dziesiątki atomów w superkomórce.

Wyniki

Wykres 1 przedstawia wyniki przeprowadzonych testów. Prezentowane jest przyspieszenie pakietu czyli stosunek czasu obliczeń na jednym procesorze do czasu obliczeń na N. Testowano układy:

  • Au 112 – kryształ srebra ze 112 atomami w superkomórce,
  • Au – kryształ srebra z 24 atomami w superkomórce,
  • MgO N=3 – kryształ tlenku magnezu z 54 atomami w superkomórce,
  • MgO N=4 – kryształ tlenku magnezu z 128 atomami w superkomórce,
  • SiC – kryształ węglika krzemu 64 atomami w superkomórce.
Qe s1.png
Wykres 1. Przyśpieszenie w funkcji liczby procesorów dla poszczególnych testów.

Na wykresie 1 widać, iż dla wszystkich badanych układów Quantum Espresso skaluje się niemal liniowo do 4 procesorów. Dla większej liczby używanych rdzeni nie obserwuje się już tak wyraźnej poprawy wydajności. Można zaobserwować silną zależność pomiędzy wielkością testowanego układu, a skalowaniem kodu. Dla dużych układów algorytm skaluje się dużo lepiej, choć nawet dla największych rozważnych superkomórek nie uzyskano dobrego skalowania na dziesiątki rdzeni. Takie zachowanie algorytmu wynika w dużej mierze ze sposobu zrównoleglenia kodu. W Quantum Espresso duży nacisk położono na zrównoleglenie kodu ze względu na obliczenia w różnych k-punktach, dlatego w testach o małej ich liczbie skalowanie jest znacznie gorzej.

Wnioski

Pakiet Quantum Espresso skaluje się bardzo dobrze na niewielkiej liczbie procesorów, ale dla dużej ich liczby wyniki są znacznie poniżej oczekiwań. Należy jednak pamiętać, iż skalowanie pakietu silnie zależy od wielkości badanego układu oraz rodzaju prowadzonych obliczeń.

Testy skalowalności pakietu BigDFT na klastrze halo2

Autor: Maciej E. Marchwiany

Testy skalowalności pakietu BigDFT przeprowadzono na klastrze halo2. Przebadano szeroką klasę układów, zaczynając od pojedyńczych atomów, przez molekuły, na strukturach krystalicznych kończąc. Tak szerokie spektrum badanych układów pozwala wyciągnąć ogólne wnioski o zachowaniu pakietu.

Wyniki

Pakiet BigDFT w wersji 1.4.0 został skompilowany za pomocą kompilatorów GNU z opcjami:

-O3 -ffast-math -funroll-loops -ftree-vectorize

oraz z biblioteką OpenMPI w wersji 1.4.2 skompilowanej gcc4.4.3.

Testowano układy:

  • H – atom wodoru,
  • C – atom węgla,
  • Ca2 – molekuła Ca2,
  • cyk – [3.3]antycyklofan,
  • MgO54 – kryształ tlenku magnezu z 54 atomami w superkomórce,
  • MgO128 – kryształ tlenku magnezu z 128 atomami w superkomórce,
  • Si – kryształ krzemu,
  • Si64 – kryształ krzemu z 64 atomami w superkomórce,
  • Si256 – kryształ krzemu z 256 atomami w superkomórce.

Wykres 1 przedstawia wyniki testów dla niewielkich układów. Prezentowane jest przyspieszenie pakietu czyli stosunek czasu obliczeń na jednym procesorze do czasu obliczeń na N procesorach.

Bigdft s1.png
Wykres 1. Przyśpieszenie w funkcji liczby procesorów dla poszczególnych testów.

Na wykresie 1 widać, że pakiet BigDFT bardzo źle skaluje się dla prostych układów. Dla pojedyńczych atomów praktycznie nie ma korzyści ze stosowanie więcej niż 2 rdzeni. Podobna sytuacja ma miejsce dla prostych molekuł jak Ca2. Dla bardziej złożonych układów jak [3.3]antycyklofan czy kryształ krzemu pakiet skaluje się znacznie lepiej, ale obserwuje się także silny spadek wydajności obliczeń po przekroczeniu pewnej liczby stosowanych rdzeni.

Wykres 2 przedstawia wyniki testów dla największych rozważanych układów. W związku z długim czasem obliczeń i zapotrzebowaniem na pamięć operacyjną (patrz dalej) niemożliwe było przeprowadzenie obliczeń dla niewielkiej liczby procesorów. Na wykresie 2 prezentowane jest przyśpieszenie względem 16 procesorów, czyli stosunek czasu obliczeń na 16 procesorach do czasu obliczeń na N procesorach.

Bigdft s2.png
Wykres 2. Przyśpieszenie w funkcji liczby procesorów dla poszczególnych testów.

Na wykresie 2 widać, że pakiet BigDFT dla odpowiednio dużego układu bardzo dobrze skaluje się na dziesiątki procesorów. Pozwala to wysnuć wniosek, iż dla odpowiednio dużego układu pakiet będzie się skalował na setki procesorów.

Podczas pracy z pakietem BigBFT bardzo istotne jest jego zapotrzebowanie na pamięć operacyjną. Tabela 1 przedstawia porównanie zużycia pamięci dla różnych badanych układów. Wszystkie dane zostały zebrane dla takiej samej gęstości meshu.

Tab. 1. Zapotrzebowanie na pamięć dla różnych układów.

#proc Wymagana pamięć [MB]
H Ca2 MgO Si Si256
1 23 125 25603 176 107395
2 20 58 13743 99 57569
4 10 56 6871 54 28785
8 5 54 611 31 14374
16 3 54 319 19 7197
32 54 161 19 3736
64 53 94 19 1875
128 49 1077
256 26 545


Z tabeli 1 wynika, iż zapotrzebowanie na pamięć pojedyńczego procesora silnie zależy od wielkości układu oraz od liczby używanych rdzeni obliczeniowych. Stosowanie większej liczby procesorów znacznie redukuje zapotrzebowanie na pamięć jednego rdzenia, co może umożliwić badanie większych układów przy ograniczonej pamięci przypadającej na jedne procesor. Widać także, że dla danego układu istnieje minimalne zapotrzebowanie na pamięć, którego nie da się zminimalizować przez zwiększanie liczby stosowanych procesorów. Należy jednak zwrócić uwagę na fakt, iż gęstość meshu oraz parametry algorytmu mogą istotnie zmienić wielkość wykorzystywanej pamięci.

Wnioski

Otrzymane wyniki potwierdzają dobre skalowanie pakietu BigDFT. Pozwalają ponadto sądzić, iż dla odpowiednio dużego układu pakiet będzie skalował się na setki procesorów. Widoczne jest także, duże zapotrzebowanie pakietu na pamięć operacyjną. Należy jednak pamiętać, że zachowanie algorytmu w dużej mierze zależy do badanego układu i parametrów prowadzenia obliczeń.