Views

Biuletyn nr 28

From KDMwiki

Jump to: navigation, search
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 28 (23 czerwca 2008)

Spis treści

Witajcie na świecie!

Autorzy: Dział KDM

Od niedawna wśród pracowników centrum KDM jest świeżo upieczony Tata. Dnia 20 kwietnia 2008 przyszła na świat Barbara Danuta, córka Ani i Maćka Cytowskiego. Córeczka i mama czują się świetnie; tata też.

Error creating thumbnail: convert: unable to open image `/media/wwwold.icm.edu.pl/kdmwiki-dir2/images/2/20/Basia_Cytowska.jpg': No such file or directory.
convert: missing an image filename `/media/wwwold.icm.edu.pl/kdmwiki-dir2/images/thumb/2/20/Basia_Cytowska.jpg/400px-Basia_Cytowska.jpg'.
Basia Cytowska z tatą (od prawej)

Dla Basi w tym numerze biuletynu powitanie, a dla Rodziców serdeczne gratulacje!

Architektura Cell BE w ICM

Autor: Maciek Cytowski

Od pewnego czasu w ICM wykorzystywane są procesory Cell Broadband Engine (w skrócie Cell, Cell BE lub CBEA). Kilka projektów realizowanych w ICM potwierdziło przydatność tej architektury w obliczeniach naukowych. Warto się jej przyjrzeć bliżej.

Procesory Cell BE są rezultatem pracy tzw. stowarzyszenia STI (Sony, Toshiba, IBM) i były projektowane przez 4 lata (od marca 2001). Stowarzyszenie STI przyznaje się do wydania niemalże 400 milionów $ na ten cel. Co mogło być powodem przyznania temu projektowi aż takiego budżetu? Oczywiście konsole do gier! Procesor Cell BE pojawił się po raz pierwszy na rynku w konsoli PlayStation3 (w skrócie PS3) w listopadzie 2006 w Japonii. W tym czasie uniwersytety i instytuty naukowe na całym świecie zastanawiały się już jak oficjalnie wyjaśnić sensowność zakupu konsoli do gier do celów naukowych. ICM był jednym z nich. Pierwsze konsole PS3 pojawiły się w ICMie w czerwcu 2007 i od razu zostały zaprzęgnięte do pracy przy analizie danych astronomicznych pochodzących z polskiego obserwatorium w Las Campas w Chile. Poniższy wykres prezentuje porównanie czasu wykonania zadania na pojedynczym procesorze AMD Opteron klastra halo, konsoli PS3 (ponad 7x szybciej) oraz serwerze QS21 wyposażonym w dwa procesory Cell (ponad 19x szybciej).

Error creating thumbnail: convert: unable to open image `/media/wwwold.icm.edu.pl/kdmwiki-dir2/images/b/bf/Ogleps3.png': No such file or directory.
convert: unable to open file `/media/wwwold.icm.edu.pl/kdmwiki-dir2/images/b/bf/Ogleps3.png'.
convert: missing an image filename `/media/wwwold.icm.edu.pl/kdmwiki-dir2/images/thumb/b/bf/Ogleps3.png/480px-Ogleps3.png'.

Artykuł ten zainspirowany został ostatnimi wydarzeniami z życia warszawskiego centrum KDM. 18 kwietnia 2008 ICM podpisało umowę o współpracy z firmą IBM Polska (http://www.icm.edu.pl/web/guest/ibmicm). Pierwszym wspólnym przedsięwzięciem jest utworzenie wspólnego centrum kompetencyjnego, dotyczącego programowania na procesorach Cell i architekturach hybrydowych. Drugim ważnym wydarzeniem jest zainstalowanie w ICM serwerów QS21 firmy IBM wyposażonych w procesory Cell. Komputer blader, bo o nim tutaj mowa, jest dosyć ciekawą architekturą przypominającą (nie przez przypadek) komputer RoadRunner, który jako pierwszy superkomputer przełamał barierę 1 PetaFlops'a (więcej w artykule Maćka Filochy).

Architektura Cell

Najnowsza odsłona procesora Cell (PowerXCell 8i) ma 65nm
Najnowsza odsłona procesora Cell (PowerXCell 8i) ma 65nm

Często mówi się, że procesor Cell był specjalnie projektowany jako alternatywa dla zwykłych procesorów biurkowych (Opteron, Core 2,..) z jednej strony i specjalizowanych procesorów-akceleratorów (GPU, FPGA,..) z drugiej. Faktycznie jest w tym trochę prawdy. Wystarczy przyjrzeć się bliżej architekturze Cell. Jądrem CBEA jest tzw. PPE (Power Processing Element) - "zwykły" procesor o architekturze Power. PPE nie było jednak projektowane jako główna siła obliczeniowa Cell'a. Do tego mają tutaj służyć wektorowe jednostki SPE (Synergistic Processing Element), których jest aż 8. Wszystkie taktowane są, podobnie jak PPE, zegarem 3.2 GHz i połączone z pamięcią główną poprzez wydajną szynę EIB. Jak narazie z opisu możnaby wnioskować, że Cell to zwykły procesor wielordzeniowy (gdzie wielo- równe jest 9!). Byłoby tak, gdyby nie kilka istotnych szczegółów. Po pierwsze jednostki SPE mają malutką pamięć podręczną (tzw. LS o rozmiarze 256KB), w której programista musi przechować instrukcje wykonywanego programu wraz z danymi wejściowymi/rezultatami obliczeń. Po drugie transfer danych z pamięci głównej do SPE musi zostać również zorganizowany przez programistę (mechanizm DMA). Zaletą jest to, że instrukcje SPE związane ze ściąganiem danych z pamięci głównej do podręcznej mogą być wykonywane równolegle z obliczeniami (tzw. double-buffering). Z tych wszystkich terminów wynika, że aby wykorzystać pełną siłę procesora Cell trzeba się trochę napracować. Ale tutaj uwaga: zyski mogą być duże. Teoretyczna wydajność obliczeniowa Cell'a to aż 250 GFlops'ów (w pojedynczej precyzji). Co więcej znane nam są przypadki prawie pełnego wysycenia tej sporej liczby - Matrix Multiply by Daniel Hackenberg.

Trochę więcej o samej architekturze Cell'a można przeczytać np. w artykule napisanym przez jego twórców: - Synergistic Processing in Cell's Multicore Architecture.

Error creating thumbnail: convert: unable to open image `/media/wwwold.icm.edu.pl/kdmwiki-dir2/images/c/c0/Schema_Cell.jpg': No such file or directory.
convert: missing an image filename `/media/wwwold.icm.edu.pl/kdmwiki-dir2/images/thumb/c/c0/Schema_Cell.jpg/600px-Schema_Cell.jpg'.

Obliczenia naukowe na procesorach Cell

"The Potential of The Cell Processor for Scientific Computing" jest klasycznym (i jednym z pierwszych) artykułów traktujących o przydatności procesora Cell do obliczeń naukowych. W pracy tej znalazły się porównania czasu wykonania jąder obliczeniowych kilku kluczowych algorytmów używanych w obliczeniach, takich jak mnożenie macierzy gęstych, mnożenie macierzy rzadkiej przez wektor, proste obliczenia siatkowe (tzw. stencil) oraz jedno- i dwu- wymiarowe FFT. Oprócz tego prezentowane są również wyniki benchmarków wykonywanych na architekturach Cell, AMD Opteron, Intel Itanium2 oraz Cray X1E.

Możliwość relatywnie taniego zakupu architektury Cell (PlayStation3) spowodowała bardzo szybko rosnącą liczbę projektów magisterskich, doktorskich czy innych badawczych opartych na pojedynczych lub połączonych w klastry konsolach PS3 ("A rough guide to scientific computing on the PlayStation 3"). Należy tutaj pochwalić stowarzyszenie STI, które dostarczyło profesjonalne wsparcie dla osób pragnących zainstalować na swojej konsoli Linux-a. Instruktarz jak to zrobić znaleźć można jeszcze nawet dziś na stronach firmy IBM (An introduction to Linux on the PLAYSTATION 3). Niestety środowisko akademickie nie odwdzięcza się STI w należyty sposób. Nie od dziś wiadomo bowiem, że ceny konsol do gier są dużo niższe od rzeczywistych kosztów ich produkcji. Ponieważ szyld pobliskiego mi sklepu komputerowego oznajmia co roku: "Komputery na komunię", to wiadomo, że takie "zabawki" nie mogą być po prostu zbyt drogie. Firmy produkujące konsole kalkulują swój zysk poprzez odpowiednio wysokie ceny komponentów, rozszerzeń oraz co najistotniejsze gier komputerowych. O ile zakup konsoli dla instytutu naukowego można jeszcze jakoś uzasadnić to dokupywanie do niej regularnie najnowszych wersji "strzelanek" już chyba mniej.

Wszystko to byłoby prawdą gdybyśmy nie brali pod uwagę wielkiej pracy włożonej przez środowisko naukowe w produkowanie kolejnych przykładów na to, że procesor Cell nadaje się doskonale do wielu naukowych zastosowań. Z drugiej strony firma IBM odpowiadając na "naukowe zachcianki i wskazówki" stworzyła nową linię rozwoju procesorów Cell. W najnowszym PowerXCell 8i polepszono znacznie wydajność obliczeń w podwójnej precyzji.

Do wyróżniających się projektów naukowych opartych na architekturze Cell należy zaliczyć:

Blader- szczegóły

Zainstalowany niedawno w ICM komputer blader to prototyp węzła wspominanej już amerykańskiej instalacji RoadRunner. Węzeł ten składa się z trzech serwerów typu blade. Pierwszy z nich to serwer LS21 wyposażony w dwa dwu-rdzeniowe procesory AMD Opteron. Dwa pozostałe to serwery QS21 (pierwsza instalacja w Polsce), każdy wyposażony w dwa procesory Cell. Pomysł architektów komputera RoadRunner był taki, aby na każdy rdzeń procesora Opteron przypadał jeden akcelerator Cell. Maszyną dostępową jest LS21 (blader). Z niego użytkownicy mogą logować się na serwery QS21, nazwane odpowiednio b1 oraz b2. Dokładna specyfikacja techniczna maszyny znajduje się na stronie blader-a.

Pomysł stworzenia komputera przypominającego węzeł instalacji w Los Alamos związany jest z dosyć intensywnym rozwojem bibliotek, kompilatorów i rozszerzeń językowych na tego typu architektury. Wszystkie te narzędzia tworzone są właśnie specjalnie dla RoadRunner'a i są udostępnione na stronach internetowych firmy IBM. Z ciekawszych pozycji należy tutaj wymienić:

  • kompilatory XLC oraz XLFortran dla CBEA
  • XLC Single Source Compiler - kompilator, który nie boi się dyrektyw OpenMP
  • Accelerated Library Framework (ALF) - API do tworzenia bibliotek na akceleratorach
  • Data Communication and Synchronization Library (DACS) dla architektur hybrydowych opartych na CBEA
  • Cell Full System Simulator - symulator architektury Cell wraz z narzędziami do debugowania/profilingu kodów (zintegrowane z Eclipse)

Programowanie procesorów Cell

Artykuł ten postanowiłem wzbogacić prostym przykładem wykorzystania architektury Cell. Podobnie jak w przypadku lekcji o OpenMP, UPC czy CAF nasz program będzie obliczał przybliżenie liczby Pi korzystając ze wzoru:

Parser nie umiał rozpoznać (Missing texvc executable; please see math/README to configure.): \pi = 4 \int_0^1 \frac{1}{1+x^2}


i całkowania numerycznego metodą prostokątów.

Generalnie napisanie programu na procesorze Cell wygląda zwykle tak:

  • przygotowanie wersji jedno-rdzeniowej i skompilowanie jej na PPU
  • wykrycie i wydzielenie ewentualnych fragmentów do zrównoleglenia
  • przygotowanie i skompilowanie wydzielonego programu na SPU
  • zaprojektowanie zarządzania procesami SPU oraz przesyłu danych z pamięci głównej do Local Store każdego SPU

Program wyliczający wartość liczby Pi pod względem obliczeniowym składa się z jednej pętli. Wersja szeregowa w języku C była prezentowana w artykule o UPC. Zrównoleglenie tego programu jest trywialne, wystarczy podzielić pętle na kilka mniejszych i obliczenia przeprowadzać niezależnie na dostępnych rdzeniach. Na końcu trzeba wykonać jeden krok sumujący wyniki otrzymane na każdym z rdzeniów.

Programując równoległe algorytmy na procesorze Cell zwykle zakładamy, że PPU jest procesorem zarządzającym obliczeniami. Ma on przygotowywać paczki danych wejściowych dla każdego wątku SPU a następnie wątki te uruchamiać. Aby każdy z wątków SPU mógł być zarządzany równolegle, zwykle stosuje się również mechanizmy rozproszenia po stronie PPU. Najczęściej jest to mechanizm oparty na bibliotece pthreads, który dla każdego wątku SPU przydziela jeden pwątek.

Każdy wątek SPU musi od procesora zarządzającego otrzymać indeksy początkowy i końcowy swojego kawałka pętli, ilość rozpatrywanych podziałów odcinka [0,1] (liczba N) oraz adres miejsca w pamięci głównej, do którego mają zostać zapisane rezultaty obliczeń.

Paczkę danych wejściowych definiujemy za pomocą struktury context w pliku nagłówkowym globals.h:

 1 typedef struct {
 2         int Nstart;
 3         int Nend;
 4         int N;
 5         float *pi;
 6 } context;

Program PPU zarządzający obliczeniami (patrz poniżej) składa się z funkcji main (linie 31-58) oraz procedury pthread_run_spe (linie 11-28). Funkcja main spełnia kilka podstawowych funkcji. Po pierwsze dla każdego z liczby SPU_THREADS wątków wypełnia paczkę context danymi (linie 39-42). Po drugie uruchamia wątki pthreads (linia 43). Wątki te obsługiwane są przez procedurę pthread_run_spe. Po zakończeniu wykonania wątków następuje synchronizacja (linie 46-47), wykonanie kroku sumowania (linie 49-50) oraz zwolnienie zaalokowanej wcześniej pamięci (linie 52-53). Warto tutaj zauważyć, że do alokacji i zwalniania pamięci używane są tutaj funkcje malloc_align oraz free_align pochodzące z biblioteki libmisc. Związane jest to z faktem, że do poprawnego działania mechanizmów przesyłu danych pomiędzy pamięcią główna a pamięcią lokalną SPU wymagane jest odpowiednie uliniowienie danych (w podobnym celu użyta została konstrukcja attribute w linii 36). Na końcu głównej funkcji programu PPU wynik obliczeń wypisywany jest na ekran (linia 55).

Przyjrzyjmy się teraz procedurze pthread_run_spe. Głównym jej zadaniem jest uruchomienie kontekstu SPU przy wykorzystaniu gotowego programu, którego nazwa zdefiniowana jest w linii 7. W szczególności aby utworzyć kontekst wywołujemy spe_context_create (linia 18). Następnie aby załadować program SPU dla tego kontekstu, wywołujemy spe_program_load (linia 19). Funkcja spe_context_run uruchamia obliczenia na SPU. Po ich zakończeniu należy wyczyścić bufory procesora Cell z wszelkich śladów pozostawionych przez konteksty SPU (polecenie spe_context_destroy w linii 25). Wywołanie pthread_exit kończy wątek pthreads.

 1 #include <stdio.h>
 2 #include "globals.h"
 3 #include <libspe2.h>
 4 #include <pthread.h>
 5 #include <libmisc.h>
 6
 7 extern spe_program_handle_t pi_spu;
 8
 9 #define SPU_THREADS 8
10
11 void *pthread_run_spe(void *arg){
12
13         spe_context_ptr_t spe_ctx;
14         context *data = (context *)arg;
15         void *argp;
16         unsigned int entry;
17
18         spe_ctx = spe_context_create(0, NULL);
19         spe_program_load (spe_ctx, &pi_spu);
20
21         entry=SPE_DEFAULT_ENTRY;
22         argp=data;
23
24         spe_context_run(spe_ctx, &entry,0,argp,NULL,NULL);
25         spe_context_destroy(spe_ctx);
26
27         pthread_exit(NULL);
28 }
29
30
31 int main(){
32   int i;
33   int N=1024;
34   float pi=0.0;
35   pthread_t pthreads[SPU_THREADS];
36   context ctxs[SPU_THREADS] __attribute__ ((aligned(16)));
37
38   for(i=0;i<SPU_THREADS;i++){
39         ctxs[i].N=N;
40         ctxs[i].Nstart=(N/SPU_THREADS)*i;
41         ctxs[i].Nend=(N/SPU_THREADS)*(i+1);
42         ctxs[i].pi=(float*) malloc_align(sizeof(float),7);
43         pthread_create(&pthreads[i], NULL, &pthread_run_spe, &ctxs[i]);
44   }
45
46   for (i=0; i<SPU_THREADS; i++)
47      pthread_join (pthreads[i], NULL);
48
49   for(i=0;i<SPU_THREADS;i++)
50         pi+=*(ctxs[i].pi);
51
52   for(i=0;i<SPU_THREADS;i++)
53         free_align(ctxs[i].pi);
54
55   printf("PI = %f\n",pi);
56
57   return (0);
58 }


Program SPU (patrz poniżej) ma tylko dwa fragmenty, które wymagają wyjaśnienia. Po pierwsze musi on dokonać ściągnięcia danych z pamięci głównej Cell-a do pamięci lokalnej SPU. Po drugie musi zapisać rezultat obliczeń w pamięci głównej pod wskazanym przez kontekst adresem. Pierwsza czynność realizowana jest przez funkcję spu_mfcdma32 wywołaną z parametrem MFC_GET_CMD (linia 19). Dzięki temu możliwe jest zapisanie w lokalnej zmiennej ctx całej paczki przygotowanej i przekazanej do kontekstu przez PPU. Aby rezultat obliczeń (w postaci zmiennej pi) zapisać w pamięci głównej używamy tej samej funkcji spu_mfcdma32, ale tym razem wywołanej z parametrem MFC_PUT_CMD (linia 38). Musimy do tego celu wskazać mechanizmowi MFC dokładny adres. Ten odczytujemy z wcześniej przekazanej nam w paczce PPU informacji (ctx.pi). Warto zwrócić jeszcze uwagę na mechanizm synchronizacji ściagania danych z pamięci głównej używany w liniach 20 i 39. W przypadku ogólnym dopuszczane są sytuacje, w których ściąganie danych odbywa się podczas obliczeń, gdyż funkcje spu_mfcdma32 nie blokują wykonania wątku SPU. Dzięki tej możliwości możemy tworzyć wydajne jądra obliczeniowe SPU, w oparciu o mechanizm double-buffering (prowadzenie obliczeń dla paczki danych, podczas gdy kolejna paczka ściągana jest z pamięci głównej). Warto pamiętać o tym mechanizmie!


 1 #include <stdio.h>
 2 #include <malloc.h>
 3 #include "globals.h"
 4 #include <libmisc.h>
 5 #include <spu_mfcio.h>
 6 #include <simdmath.h>
 7
 8 volatile context ctx;
 9
10 int main(unsigned long long id,unsigned long long parm)
11 {
12   int i;
13   unsigned int tag_id=0;
14   float pi;
15   float h;
16
17   spu_writech(MFC_WrTagMask,-1);
18
19   spu_mfcdma32((void*)(&ctx),(unsigned int)parm, sizeof(context), tag_id, MFC_GET_CMD);
20   (void)spu_mfcstat(MFC_TAG_UPDATE_ALL);
21
22   pi=0.0;
23
24   h = (float)(1.0/(ctx.N*ctx.N));
25
26   for(i=ctx.Nstart;i<ctx.Nend;i++) {
27         float x;
28         float y;
29         x=(1.0+(0.5+i)*(0.5+i)*h);
30         y=1.0/x;
31         pi=pi+y;
32   }
33
34   pi*=(float)(4.0/ctx.N);
35
36   int tag_putback=0;
37
38   spu_mfcdma32((void*)(&pi),(unsigned int)(ctx.pi),4,tag_putback,MFC_PUT_CMD);
39   (void)spu_mfcstat(MFC_TAG_UPDATE_ALL);
40
41   return 0;
42 }

Do uruchomienia programu niezbędna jest poprawna kompilacja. Do tego celu możemy wykorzystać albo kompilator gcc (w wersji dla PPU i SPU) albo kompilator XLC firmy IBM. Cały projekt wraz z potrzebnymi plikami Makefile znaleźć można na b1 oraz b2 w katalogu z przykładami: /opt/cell/icm_examples/pi_simple.tgz.

Pliki binarne w Fortranie na tornado

Autor: Maciek Cytowski

Jak rozwiązać następujący problem: utworzony na klastrze Halo plik binarny chcę wczytać z poziomu języka Fortran na komputerze Tornado ?

Tak jak w swoim artykule wspominał Łukasz Bolikowski (Biuletyn_nr_21), istnieje spora różnica w zapisie binarnym na klastrze i na Cray-u X1. W pierwszym przypadku domyślnie używanym porządkiem jest little-endian, w drugim big-endian. Na komputerze Tornado istnieje bardzo wygodne polecenie assign, które pozwala z poziomu bibliotek języka programowania odczytywać binarne pliki zapisane w innym porządku (bez potrzeby rekompilacji programu!!).

Na halo tworzymy prosty program, zapisujący do pliku binarnego DATA.BIN (z RCW) 10 liczb typu REAL:

 1         PROGRAM WRITE_REALS
 2         REAL TAB(10)
 3         INTEGER I
 4 
 5         DO I=1,10
 6                 TAB(I)=1.0/I
 7         ENDDO
 8 
 9         OPEN(7,FILE="DATA.BIN",FORM='UNFORMATTED')
10 
11         DO I=1,10
12                 WRITE(7) TAB(I)
13         ENDDO
14 
15         CLOSE(7)
16         STOP
17         END

Kompilujemy go za pomocą komend:

use_pgi
pgf77 -o write_reals write_reals.F

i uruchamiamy:

./write_reals

Otrzymany w ten sposób plik kompiujemy na Tornado:

scp DATA.BIN tornado:/cpes/$user/

W katalogu /cpes/$user/ na Tornado piszemy krótki program do odczytu danych z pliku:

 1         PROGRAM READ_REALS
 2         REAL TAB(10)
 3         INTEGER I
 4         OPEN(7,FILE="DATA.BIN",FORM='UNFORMATTED')
 5         DO I=1,10
 6                 READ(7) TAB(I)
 7                 WRITE(*,*) TAB(I)
 8         ENDDO
 9         CLOSE(7)
10         STOP
11         END

Kompilujemy go za pomocą komendy:

ftn -o read_reals read_reals.F

i uruchamiamy:

./read_reals

Ten sam program skompilowany i uruchomiony na klastrze Halo bez żadnego problemu wypisałby na ekran wynikowych 10 liczb typu REAL. W przypadku Tornado powinniśmy zobaczyć ekran podobny do następującego:

lib-5016 : UNRECOVERABLE library error 
  An EOF or EOD has been encountered unexpectedly. 

Encountered during a sequential unformatted READ from unit 7
Fortran unit 7 is connected to a sequential unformatted  file: "DATA.BIN"
Abort (core dumped)

Rozwiązaniem tego problemu jest użycie narzędzia assign w następujący sposób:

 assign -N swap_endian f:DATA.BIN

Kluczowe w tym wypadku jest użycie opcji -N swap_endian, która nakazuje bibliotekom I/O Fortranu skorzystanie z dodatkowego filtru przy odczycie z pliku DATA.BIN (zmieniającego LE na BE). Zadane poleceniem assign ustawienia zapisywane są standardowo w pliku /tmp/.assign.$user. Należy pilnować obecności tych plików, gdyż po ewentualnych awaryjnych rebootach maszyny mogą one zniknąć. Bezpiecznym rozwiązaniem jest dopisanie w ~/cshrc ścieżki:

setenv FILENV ~/.assign.$user

Wówczas ustawienia polecenia assign będą zapisywane w naszym katalogu domowym.

Dzięki skorzystaniu z assign program ./read_reals odczytuje już dane poprawnie:

1.
0.5
0.333333343
0.25
0.200000003
0.166666672
0.142857149
0.125
0.111111112
0.100000001
STOP  

Polecam lekturę man assign.

OpenMP na klastrze halo - update

Autor: Maciek Cytowski

Ostatnio jeden z użytkowników centrum KDM zgłosił się do nas z pytaniem jak uruchamiać programy korzystające z dyrektyw OpenMP na klastrze Halo. W tym krótkim artykule spróbuję odpowiedzieć na to pytanie. Będzie to tak naprawdę lekkie odświeżenie informacji zawartych w artykule o OpenMP.

Jak wiadomo rozszerzenie OpenMP stosuje się w przypadku architektur o pamięci współdzielonej, co do niedawna oznaczało możliwość skorzystania z maksymalnie dwóch procesorów na klastrze Halo. Konfiguracja klastra jakiś czas temu wzbogaciła się o 12 węzłów wyposażonych w 4 (dual-core) procesory AMD Opteron 2.2GHz i 16 GB pamięci RAM. Oznacza to, że w obrębie jednego węzła możemy wykorzystać nawet 8 rdzeni.

Jak to zrobić?

  • Krok pierwszy: wprowadzamy dyrektywy OpenMP do naszego programu.

Prostym i krótkim przykładem może być tutaj program przybliżający wartość liczby Pi:

1.        program openmpi
2.        implicit none
3.        integer i, n
4.        real sumpi, mypart, x
5.        parameter (n = 1000000)
6.
7.        sumpi = 0.0
8.  !$omp parallel do default(none)
9.  !$omp&  private(i, x, mypart)
10. !$omp&  shared(n, sumpi)
11.       do i = 1, n
12.         x = (i + 0.5) / n
13.         mypart = 1.0/(1.0 + x**2)
14. !$omp critical
15.         sumpi = sumpi + mypart
16. !$omp end critical
17.       end do
18.       sumpi = 4.0 * sumpi / n
19.       print *, sumpi
20.       end program
  • Krok drugi: kompilujemy program, np. komendą:
use_pgi
pgf77 -mp openmpi.f -o openmpi.x
  • Krok trzeci: piszemy skrypt kolejkowy dla naszego programu. Może on wygląć np. tak:
 1 #!/bin/tcsh
 2 #PBS -N test
 3 #PBS -l nodes=1:ppn=2
 4 #PBS -l walltime=00:15:00
 5 
 6 #limity mozliwe do ustawienia - man pbs_resources
 7
 8 echo Job started
 9 echo "  "  at `date`
10 echo "  "  on host `hostname`
11 echo "  "  working directory is $PBS_O_WORKDIR
12 echo "  "  will run on `cat < $PBS_NODEFILE`
13 echo
14
15 setenv OMP_NUM_THREADS 2
16 ./openmpi.x

Oczywiście ustawienia czasu walltime będą się różnić w zależności od Państwa wymagań. Powyższy skrypt napisany jest w "starym stylu" dla 2 procesorów. Aby zwiększyć ich liczbę musimy podmienić linie 3 oraz 15 na:

  • w przypadku 4 rdzeni:
3 #PBS -l nodes=1:ppn=4
..
15 setenv OMP_NUM_THREADS 4
  • w przypadku 8 rdzeni:
3 #PBS -l nodes=1:ppn=8
..
15 setenv OMP_NUM_THREADS 8

Należy tutaj pamiętać, aby przed uruchomieniem obliczeń docelowych sprawdzić "skalowalność" i poprawność napisanego przy użyciu OpenMP programu poprzez wykonywanie krótkich testów (np. w kolejce test). Mimo, że korzystanie z dyrektyw OpenMP nie jest trudne, czasem zdarza się, że mały błąd powoduje wygenerowanie całkowicie bezużytecznego kodu. Co więcej niektóre programy mogą się po prostu kiepsko "zrównoleglać".

Magia Petaflopa - nowa lista TOP500

Autor: Maciej Filocha

Na zakończonym przed trzema dniami dorocznym spotkaniu europejskiego środowiska HPC, czyli konferencji ISC'08, zgodnie z tradycją ogłoszono kolejną listę TOP500. 31-sza lista miała dość wyjątkowy charakter, ponieważ po raz pierwszy pojawił się na niej komputer, który przełamał kolejną, w pewnych kręgach "magiczną", barierę 1 Petaflopa/s (milion miliardów operacji zmiennoprzecinkowych na sekundę). Z zaskakującą regularnością przekraczane są kolejne "schodki" - w roku 1986 Cray 2 osiągnął wydajność 1 Gigaflopa/s, jedenaście lat później ASCI Red Intela pobił Teraflopa/s, kolejne jedenaście lat czekaliśmy na Peta-. Jak tak dalej pójdzie, to w 2019 będzie już Exaflop/s...

O samej konferencji i czerwcowej liście TOP500 powiemy nieco więcej w przyszłym biuletynie, natomiast na razie wypada napisać parę zdań o zwycięzcy. Nowa, zbudowana przez IBM i kosztująca 100 milionów dolarów instalacja Departamentu Energii USA (który posiada cztery z pięciu najmocniejszych maszyn świata), jest systemem hybrydowym, zbudowanym z 6562 dwurdzeniowych procesorów AMD oraz 12240 procesorów typu Cell (IBM Model QS22 blade servers). Roadrunner, bo tak nazywa się ten superkomputer, ma 98 terabajtów pamięci i mieści się w 278 szafach typu BladeCenter. Na stronie IBM oraz w Wikipedii można znaleźć więcej informacji technicznych o nim. Benchmark LINPACKa, używany do ustalania listy TOP500, osiągnął wynik 1026 Tflop/s, a testy na najwydajniejszych aplikacjach "rzeczywistych" wypadły niewiele gorzej. O procesorach Cell i związkach ICM z Roadrunnerem pisze w bieżącym biuletynie Maciek Cytowski.

Co do samej nazwy - Roadrunner nie jest strusiem (Pędziwiatrem), jak sugerował polski tytuł znanej kreskówki, tylko ptakiem zamieszkującym pustynie zachodnich stanów USA i Meksyku, zwanym po polsku kukawką...