Saturday, June 29, 2019

Programare paralela


APD - o materie foarte interesanta, dar avand in vedere ca se face cu Nasu' cursul este foarte, foarte plictisitor. Se predau o gramada de algoritmi, mai intai paraleli (ca idee pentru mai multe procesoare in acelasi sistem sau pentru multithreading), apoi distribuiti (pentru mai multe sisteme care ruleaza acelasi program, in principiu). Sunt cativa algoritmi clasici, cei distribuiti sunt baza pentru examen (alegerea liderului, stabilirea topologiei, algoritmi unda- daca stii astea sigur treci), plus inca 2-3 exemple simple la algoritmi paraleli, gen cautare paralela, mutexuri, problema cititorilor si scriitorilor
In principiu materia e foarte putina comparativ cu PC, sunt doar cativa algoritmi de invatat. La examen se corecteaza mult, mult mai lejer
Punctajul e ca la PC 
- 4 puncte pe teme, 
- 1 punct pe lab, 
- 1.5 puncte pe teste la lab si la curs, 
- 6.5 puncte trunchiate la 6. 
Laboratorul este decent, desi la inceput o sa para destul de complicat. Temele au fost foarte simple, 2 din ele, a fost una mai naspa in java, asistentul si-a facut testele foarte dubios si a trebuit sa ii explic pe forum ca nu merge cum ar trebui (era o parsare pe niste texte si nu isi definise bine delimitatorii.. o gramada de probleme de aici), dar ideea temei nu era grea, pacat ca au fost teste tampite. Ultimele 2 teme se gaseau pe net, a 3-a oricum era foarte simpla si nu avea sens sa o copiezi, iar a 4-a nu era chiar la fel, dar te puteai inspira. Oricum, temele au fost decente. 
La examen au picat destul de putini, corectarea a fost lejera.
Cum treci: 

- mergi la lab, 
- faci 2 teme (alea usoare) sau macar o tema cu punctaj mare pe testele de curs. 
La examen ar trebui sa stii in mare fiecare algoritm pentru ca da din orice, inclusiv din ce te astepti mai putin, in afara de algoritmi genetici nu e nimic care sa nu se poata da.
Cum iei 10: mai simplu ca la PC, in orice caz, faci temele, vii la lab si inveti bine algoritmii aia pentru examen, oricum da doar din ei.



APD (Algoritmi Paraleli si Distribuiti)

Curs: Elena Apostol
Laborator: Radu-Ioan Ciobanu

https://www.wisdomjobs.com/e-university/parallel-computing-interview-questions.html

Trupa de la PC, inca un semestru; de data asta prezentand tot felul de algoritmi pt calcul paralel (multithreaded) si distribuit (pe diverse statii/cluster).

Curs: interesant pana la un punct; acopera ceva despre openMP (care se rezuma cam la o singura instructiune) paralelism in Java si mesaje cu openMPI. Plus o groaza de algoritmi scrisi intr-un pseudocod ceva mai bizar, care se vor cere la examen + complexitati. Din ce am auzit, cursul seamana surprinzator de mult cu cel de la seria CC (adica pdf-urile erau aceleasi...). Parerea proprie si personala: se putea aloca mai mult timp si imbunatati tehnica de predare :/
Testele de prezenta sunt destul de dificile uneori. 

Laboratorul: am nimerit bine; explicatii bune, punctaj ok, asistent super. Cealalta semigrupa a facut cu o persoana... a very special snowflake :)), acelasi care a scris si exercitiile pt laburi. Seamana cu laboratorul de PA ca nivel de dificultate - insa aici erau ceva mai multe probleme si se foloseau algoritmi care nu erau in curs. Because why not? Urat de debuggat si mult de scris - beware.

Teme:  3. La prima de scris un algoritm si paralelizat cu openMP (aka bagi #pragma omp for peste tot si vezi daca merge), a 2-a in Java si destul de comoda. A 3-a a fost mai lunga: un program care sa ia niste poze, pe urma sa stabileasca un arbore de acoperire pt retea si sa trimita bucati din poza pt procesare (aplicat blur, sharpen, etc.) la fiecare sistem iar la final sa primeasca bucatile inapoi si sa construiasca poza modificata.

La examen: structura de la PC - dat pe numere, 1 subiect de 2 puncte, 1 de un punct si 2 la alegere (fiecare de 1 punct, se puncteaza un singur subiect). De obicei primul exercitiu face diferenta intre trecut si picat...problema apare cand primul subiect iti cere sa scrii un algoritm de 2-3 pagini (problema terminarii), care in curs e prezentat cu 4 idei pe jumatate de slide...Nu-s prea echilibrate foile de examen dar se corecteaza ok...sa zicem. Se cam vedea dupa nota cine si ce numar a avut...


Bibliografie extra
https://ftp.utcluj.ro/pub/users/civan/CPD/1_RESURSE/Open_Book_2010_buildingPP_Kaminsky.pdf
https://ftp.utcluj.ro/pub/users/civan/CPD/1_RESURSE/Open_Book_2014_ParProcBook_Mathloff.pdf
http://web.stanford.edu/~jlmcc/papers/PDP/Volume%201/Chap1_Part1_PDP86.pdf

Definitie: doua operatii se pot executa in paralel daca sunt independente. Calculul seriei Fibonacci folosind formula: F(n) = F(n-1) + F(n-2) nu poate fi făcut folosind un algoritm paralel deoarece fiecare termen depinde de cel anterior.



What is Parallel Computing?

 Serial Computing:

  • Traditionally, software has been written for serial computation:
    • A problem is broken into a discrete series of instructions
    • Instructions are executed sequentially one after another
    • Executed on a single processor
    • Only one instruction may execute at any moment in time
    Serial computing
    For example:
    Serial computing
 Parallel Computing:
  • In the simplest sense, parallel computing is the simultaneous use of multiple compute resources to solve a computational problem:
    • A problem is broken into discrete parts that can be solved concurrently
    • Each part is further broken down to a series of instructions
    • Instructions from each part execute simultaneously on different processors
    • An overall control/coordination mechanism is employed
    Parallel computing
    For example:
    Parallel computing
  • The computational problem should be able to:
    • Be broken apart into discrete pieces of work that can be solved simultaneously;
    • Execute multiple program instructions at any moment in time;
    • Be solved in less time with multiple compute resources than with a single compute resource.
  • The compute resources are typically:
    • A single computer with multiple processors/cores
    • An arbitrary number of such computers connected by a network
 Parallel Computers:


  • Virtually all stand-alone computers today are parallel from a hardware perspective:
    • Multiple functional units (L1 cache, L2 cache, branch, prefetch, decode, floating-point, graphics processing (GPU), integer, etc.)
    • Multiple execution units/cores
    • Multiple hardware threads

    IBM BG/Q Compute Chip with 18 cores (PU) and 16 L2 Cache units (L2)
  • Networks connect multiple stand-alone computers (nodes) to make larger parallel computer clusters.
  • For example, the schematic below shows a typical LLNL parallel computer cluster:
    • Each compute node is a multi-processor parallel computer in itself
    • Multiple compute nodes are networked together with an Infiniband network
    • Special purpose nodes, also multi-processor, are used for other purposes

  • The majority of the world's large parallel computers (supercomputers) are clusters of hardware produced by a handful of (mostly) well known vendors.
    Source: Top500.org
Designing and Building Parallel Programs Ian Foster
https://pdfs.semanticscholar.org/09ed/7308fdfb0b640077328aa4fd10ce429f511a.pdf?_ga=2.236562818.262307220.1561817530-644819069.1561817530

GPRM : a high performance programming framework for manycore processors - teza de doctorat


Processors with large numbers of cores are becoming commonplace. In order to utilise the available resources in such systems, the programming paradigm has to move towards increased parallelism. However, increased parallelism does not necessarily lead to better performance. Parallel programming models have to provide not only flexible ways of defining parallel tasks, but also efficient methods to manage the created tasks. Moreover, in a generalpurpose system, applications residing in the system compete for the shared resources. Thread and task scheduling in such a multiprogrammed multithreaded environment is a significant challenge. In this thesis, we introduce a new task-based parallel reduction model, called the Glasgow Parallel Reduction Machine (GPRM). Our main objective is to provide high performance while maintaining ease of programming. GPRM supports native parallelism; it provides a modular way of expressing parallel tasks and the communication patterns between them. Compiling a GPRM program results in an Intermediate Representation (IR) containing useful information about tasks, their dependencies, as well as the initial mapping information. This compile-time information helps reduce the overhead of runtime task scheduling and is key to high performance. Generally speaking, the granularity and the number of tasks are major factors in achieving high performance. These factors are even more important in the case of GPRM, as it is highly dependent on tasks, rather than threads. We use three basic benchmarks to provide a detailed comparison of GPRM with Intel OpenMP, Cilk Plus, and Threading Building Blocks (TBB) on the Intel Xeon Phi, and with GNU OpenMP on the Tilera TILEPro64. GPRM shows superior performance in almost all cases, only by controlling the number of tasks. GPRM also provides a low-overhead mechanism, called “Global Sharing”, which improves performance in multiprogramming situations. We use OpenMP, as the most popular model for shared-memory parallel programming as the main GPRM competitor for solving three well-known problems on both platforms: LU factorisation of Sparse Matrices, Image Convolution, and Linked List Processing. We focus on proposing solutions that best fit into the GPRM’s model of execution. GPRM outperforms OpenMP in all cases on the TILEPro64. On the Xeon Phi, our solution for the LU Factorisation results in notable performance improvement for sparse matrices with large numbers of small blocks. We investigate the overhead of GPRM’s task creation and distribution for very short computations using the Image Convolution benchmark. We show that this overhead can be mitigated by combining smaller tasks into larger ones. As a result, GPRM can outperform OpenMP for convolving large 2D matrices on the Xeon Phi. Finally, we demonstrate that our parallel worksharing construct provides an efficient solution for Linked List processing and performs better than OpenMP implementations on the Xeon Phi. The results are very promising, as they verify that our parallel programming framework for manycore processors is flexible and scalable, and can provide high performance without sacrificing productivity.
https://pdfs.semanticscholar.org/bebd/2e04e60fbb7f157ff4037c12bf4c93b2b905.pdf?_ga=2.131835148.262307220.1561817530-644819069.1561817530


În programare un algoritm de calcul paralel sau concurent, în opoziție cu unul secvențial, este un algoritm care poate fi executat (simultan) pe porțiuni pe mai multe mașini de calcul, apoi reasamblat pentru aflarea rezultatului final. Algoritmii de calcul paralel sunt importanți datorită îmbunătățirilor aduse sistemelor de calcul multiprocesor. În general e mai ușor să construiești un singur microprocesor rapid decât o serie de microprocesoare lente care îndeplinesc aceeași funcție. În prezent creșterea vitezei unui singur procesor nu mai este posibilă atingăndu-se pragul superior în ceea ce privește mărimea și temperatura de funcționare. Atingerea acestui prag face practică implementarea de sisteme multiprocesor și pe sistemele de dimensiuni reduse cum ar fi calculatoarele personale. Cuprins
1 Motivație
2 Problematica programării paralele
2.1 Exemple de aplicații
3 Proiectarea unui algoritm paralel
3.1 Problema comunicației
3.2 Partiționarea problemei
3.3 Alocarea
4 Limitele programării paralele
4.1 Factorii ce afectează performanța algoritmilor paraleli[2]
 Conceptul de paralelism a fost investigat în ultimele trei decenii. În trecut, calculul paralel rămăsese la nivel de concept, deoarece costurile inițiale legate de implementare erau ridicate. Din aceste cauze nu era practică investitia inițială într-un sistem de calcul paralel. În ultimii ani o dată cu scaderea costurilor tehnologiei au apărut o multitudine de mașini de calcul care pot reduce timpul de rezolvare al problemelor prin implementarea unor algoritmi de calcul paralel. Problematica programării paralele Orice rezolvare de problemă prin programare paralelă, necesită în prealabil determinarea necesității adoptării unei soluții paralele, deoarece pot exista soluții de rezolvare secvențiale mai eficiente. Un exemplu de problemă de calcul paralel ar fi simularea unui cutremur și determinarea punctului cel mai afectat de acesta.   Următorii pași presupun: Identificarea părților paralelizabile ale programului Identificarea botellneck-urilor Identificarea potențialilor inhibitori ai paralelismului. Un exemplu de astfel de inhibitor ar fi acela de dependență al datelor, așa cum am demonstrat în problema seriei lui Fibonacci Investigarea cât mai multor algoritmi de calcul paralel, unele soluții fiind mai eficiente decât altele. Exemple de aplicații Modelare și simulare: prognoza meteo, dinamica moleculară Inteligența artificială: rețele neuronale Grafica: Multimedia, realitate virtuală, cinematografie Motoare de căutare Proiectarea unui algoritm paralel Una dintre cele mai importante trăsături ale unui algoritm paralel este divizarea problemei în subprobleme care pot fi distribuite pe mai multe taskuri. Pentru proiectarea unui algoritm paralel se pot considera o serie de abordări. Prima ar fi paralelizarea unui algoritm secvențial deja existent. Pentru aceasta va trebui să se determine paralelismul care apare în mod natural în cadrul unui algoritm secvențial . Uneori, se preferă găsirea unei soluții diferite de cea oferită de algoritmul secvențial ceea ce presupune o regândire a întregului algoritm. Indiferent de modul de abordare în cadrul unui algoritm paralel nu se pot ignora o serie de considerații importante. Una din acestea este costul de comunicație între procese. Dacă la un algoritm secvențial costul sau complexitatea este exprimată în spațiu (mărimea memoriei ocupate) și timp (numărul de cicli de ceas) necesar pentru a executa un program, la cel paralel trebuie luat în considerare și modul în care se comunică între procese. Problema comunicației Există unii algoritmi de calcul paralel care nu au nevoie de comunicare între procese. Spre exemplu dacă ne imaginăm un algoritm paralel care face conversia unei imagini color în una alb negru. Datele din acea imagine pot fi distribuite pe mai multe taskuri independente. Acest tip de probleme sunt denumite "embarrassingly parallel" [1] (paralelism jenant) deoarece comunicarea ]între taskuri este foarte redusă. Cei mai mulți algoritmi paraleli sunt algoritmi complecși în care comunicația între procese are o importanță majoră. Complexitatea algoritmilor paraleli este calculată în funcție de memoria folosită și timp. Ei trebuie să mai optimizeze folosirea unei alte resurse, comunicarea între procese/procesoare. Sunt două modalități prin care procesele/procesoarele comunică: Memorie partajată sau Folosind mesaje. Modelul cu memorie partajată se referă la programarea într-un mediu multiprocesor pentru care comunicația între procese se realizează prin intermediul unei memorii comune. Modelul cu transfer de mesaje este adecvat implementării unui algoritm paralel într-o rețea de calculatoare. Pentru ca un program să poată fi executat în paralel acesta trebuie descompus într-o serie de procese. Aceasta descompunere presupune partiționarea algoritmului și alocarea proceselor. Partiționarea reprezintă specificarea setului de taskuri care implementează algoritmul în modul cel mai eficient pe o mașină de calcul paralel. Alocarea reprezintă modul de distribuire a task-urilor procesoarelor. Partiționarea problemei Granularitatea unui algoritm Performanța unui algoritm de calcul paralel depinde de granularitate. Aceasta se referă la mărimea task-ului în comparație cu timpul necesar comunicației și sincronizării datelor. Dacă timpul necesar comunicației și sincronizării este mai mare decât timpul de execuție al task-ului atunci granularitatea este mică. O soluție este partiționarea programului în taskuri de dimensiuni mai mari cu o granularitate grosieră. Dezavantajul acestei metode este reducerea gradului de paralelism. Îmbunătățirea performanțelor unui algoritm de calcul paralel se face prin găsirea unui compromis între mărimea task-ului și consumul suplimentar de resurse. De obicei este găsită o corelare între numărul de taskuri, dimensiunea acestora și menținerea la minimu necesar a consumului suplimentar de resurse. Cea mai bună granularitate este cea obținută prin adaptarea algoritmului pe platforma hardware pe care rulează. În majoritatea cazurilor overhead-ul asociat comunicațiilor și sincronizării este mare în comparație cu timpul de execuție caz în care se preferă o granularitate grosieră. Partiționarea unui algoritm se poate face în două moduri: Statică: Partiționarea se face înainte de execuție. Avantajul acestei metode este acela că necesită un volum redus de comunicații. Pe de altă parte metoda aceasta prezintă dezavantajul ca gradul de paralelism să fie dat de datele de intrare. Dinamică: Generarea task-urilor este făcută în timpul de execuție al programului. Avantajul acestei metode este dat de menținerea procesoarelor ocupate cu prețul creșterii volumului comunicației dintre procese. Alocarea task-urilor în funcție de disponibilitate Alocarea Alocarea reprezintă distribuirea de taskuri procesoarelor. Planificarea ca și în cazul partiționării poate fi statică sau dinamică. În cazul alocării statice sarcinile și ordinea de execuție sunt cunoscute înainte de execuție. Algoritmii de calcul paralel ce folosesc planificarea statică necesită un volum mic de comunicare între procese potrivită pentru cazurile când costurile de comunicație este mare. În cazul planificării dinamice alocarea sarcinilor este făcută la rulare. Această tehnică permite distribuirea uniformă a încărcării procesoarelor și oferă flexibilitate în utilizarea unui număr mare de procesoare. Astfel dacă un procesor termină mai repede task-ul alocat i se poate atribui un alt task mărind în acest mod eficiența algoritmului. Dezavantaje: volumul de "overhead" este mare modul de execuție este greu de urmărit analiza performanțelor devine dificilă, ca urmare a alocării task-urilor în timpul rulării. Limitele programării paralele Conform legii lui Amdahl accelerarea unui program este dată de următoarea formulă: {\displaystyle acc={\frac {1}{(1-P)}}} {\displaystyle acc={\frac {1}{(1-P)}}}, unde P reprezintă porțiunea din cod care poate fi paralelizată. Dacă nici o porțiune a programului nu poate fi paralelizată atunci accelerarea este 1 (algoritm secvențial). Daca P=1 (tot codul poate fi paralelizat), atunci accelerarea este infinită (cel puțin teoretic). Dacă luam în considerare că un algoritm paralel rulează pe mai multe procesoare obținem următoarea formulă: {\displaystyle acc={\frac {1}{{\frac {P}{N}}+{S}}}} {\displaystyle acc={\frac {1}{{\frac {P}{N}}+{S}}}}, unde P reprezintă partea din algoritm care poate fi paralelizată, N reprezintă numărul de procesoare și S partea care nu a fost paralelizată.Cu toate că un algoritm paralel are limitele sale conform celei de-a doua formule putem concluziona că aceștia sunt foarte eficienți în rezolvarea problemelor de dimensiuni mari, în care partea secvențială rămâne neschimbată.
https://ro.wikipedia.org/wiki/Algoritmi_de_calcul_paralel

Parallel Programming and Parallel Algorithms
http://www2.cs.siu.edu/~cs401/Textbook/ch7.pdf


Introduction to Parallel Computing
https://computing.llnl.gov/tutorials/parallel_comp/



Imagine similară

Algoritmi numerici
Imagine similară

https://informatica.hyperion.ro/wp-content/uploads/2017/11/ALGORITMI-PARALELI-SI-DISTRIBUITI.pdf

Etapele descrierii unui algoritm paralel.
• Identificarea partilor problemei care se pot executa in paralel
• Maparea partilor pe mai multe procesoare
• Impartirea datelor (de intrare, iesire si intermediare)
• Gestiunea accesului la datele comune mai multor procesoare

Metrici de performanta
– Timp de Executie,
- Suprasarcina,
- Accelerare,
- Eficienta,
- Cost

Imagini pentru parallel algorithm

Imagini pentru parallel algorithm
Imagini pentru parallel algorithm
ALGORITMI PARALELI ȘI DISTRIBUIȚI 
ÎNDRUMAR DE LABORATOR / SEMINAR
https://informatica.hyperion.ro/wp-content/uploads/2017/11/ALGORITMI-PARALELI-SI-DISTRIBUITI.pdf

LABORATORUL NR.1 Introducere în clasa Thread .  Clasa Thread din pachetul java.lang: public class Thread extends Object implements Runnable
LABORATORUL NR.2 Introducere în bibliotecile OpenMP
- Structura unui program OpenMP
- Formatul unei directive
- Directiva pentru regiune paralela
- Directiva pentru partajarea lucrului
-  Directiva for
- Directiva sections
- Directiva single
- Directiva parallel for
Exemple : a) adunarea a doua matrici si b) inmultirea a doua matrici
LABORATORUL NR.3 Implementare fire de execuție. Un fir de executare este un program secvențial, ce poate fi executat concurent cu alte fire
LABORATORUL NR.4 Implementare semafoare. Semaforul este un tip de date, caracterizat deci prin valorile pe care le poate lua şi operaţiile în care poate interveni. O variabilă de tip semafor (general) poate lua ca valori doar numere naturale. Dacă valorile permise pot fi numai 0 sau 1, spunem că este vorba de un semafor binar. Conceptual, unui semafor s îi este asociată o mulţime de blocare Bs, iniţial vidă.
Exemplul 1. Problema grădinilor ornamentale
LABORATORUL NR.5 Implementarea şi testare algoritm de sortare paralelă
LABORATORUL NR.6 Implementarea unor algoritmi din metodele numerice
LABORATORUL NR.7 Testarea algoritmilor paraleli

Imagine similară

Paralalism cu Simulink din Matlab

Imagine similară

 Imagini pentru parallel algorithm

Imagine similară




VIDEOS
COURSERA - se apasa stanga mouse pe text si apare linkul
 Parallel Programming

No comments:

Post a Comment