La programmation parallèle est désormais une incontournable solution aux problèmes de performance. Ce n’est pas la seule, mais elle ne peut être ignorée. Les nombreux coeurs et CPUs qui peuplent nos serveurs en sont la preuve. Elle peut aussi s’utiliser plus souvent qu’on pourrait le penser. Que ce soit pour diminuer les temps de réponse ou augmenter le débit. Nous vous proposons un état des lieux. Quels sont les usages? Quel est le degré de facilité? Comment se prémunir de la complexité? CPU ou GPU? À l’aide d’exemples de code, tout ce qui est nécessaire de mettre dans le cartable du développeur vivant dans l’air du temps.

1. Henri Tremblay
Responsable R&D
Performance et calcul parallèle
OCTO Technology

2. Démontrer que la
programmation parallèle doit
désormais faire partie de la
panoplie standard du
développeur moderne
2

3. La fin de la loi de Moore ?
Énoncée par Gordon Moore, co-fondateur d’Intel en 1965
Doublement du nombre de transistors sur une puce tous les 2 ans
Encore techniquement vraie mais la fréquence n’augmente plus depuis 2005.
Les fondeurs ont changés d’architecture pour augmenter la puissante des processeur :
multi cœurs.
3

4. Loi des rendements décroissants
Loi datant de 1768, énoncée par David Ricardo :
En augmentant la quantité utilisée d’un facteur, celle de l’autre
restant fixe, on obtient une quantité supplémentaire de
produits de moins en moins grande
VS
4

5. Évolution des architectures
CPU : multicoeurs
• La course au Hertz est finie
• Le nombre de cœurs est en constance
augmentation
GPU : des centaines de cœurs
• Surpuissant… en parallèle
5

6. Pourquoi paralléliser ?
Utilisation CPU : 13%
6

7. Bonus: C’est écologique!
Intel
X5560 (2.8 GHz, 4 cores, 95 watts)
vs
X5660 (2.8 GHz, 6 cores, 95 watts)
Même nombre de Watt
50% plus de puissance
Si on ignore la loi de Amdahl…
7

8. Loi d’Amdahl
La fraction du
temps d'exécution
qui ne peut tirer
profit de
l'amélioration
limite le gain de
performance global,
quelle que soit la
valeur de
l'amélioration de la
composante.
8

9. 9

10. Complexité: Race condition
10

11. Complexité: Double-checked locking
11

12. Complexité: Contention
12

13. Démo 1: Le code
13

14. 14

15. Exemple .Net: Séquentiel
15

16. Exemple : .Net à l’ancienne
16

17. Exemple : .Net Moderne
17

18. Exemple : Java 8
Arrays.stream(rows)
.parallel().forEach(row -> {
for (int j = 0; j < matBCols; j++) {
double temp = 0;
for (int k = 0; k < matACols; k++) {
temp += row.rowA[k] * matB[k][j];
}
row.rowResult[j] = temp;
}
});
18

19. Patterns
 Map / Reduce
 Fork / Join
 Actor
 Dataflow
 Software Transactional Memory (STM)
 Functional programming
 Atomic references
19

20. Exemple: STM
Passé (synchronized)
Présent (atomic)
Future (STM)
20

21. Quelques frameworks
 Java







Java 8: Parallel collections
Java 7 & JSR166: Fork / Join (java.util.concurrent)
Java 6: Future (java.util.concurrent)
GPars (http://www.gpars.org)
Akka (http://akka.io/)
Clojure STM (http://clojure.org/refs)
Multiverse (http://multiverse.codehaus.org)
 .Net
 .Net 4 (namespace System.Threading.Tasks)
21

22. 22

23. Approximation de PI
≈4p/n
p
3,14159265
3589793238
4626433832
795…
23

24. Batman equation
 Calcul de l’aire par un
algorithme de Monte-Carlo:
48,42
24

25. Batman equation: Séquentiel
25

26. Batman equation: Parallèle
26

27. GPGPU : Adapté au parallélisme de masse
 Exploiter la puissance de calcul des GPUs pour le traitement de
tâches massivement parallèles
 Adapté aux algorithmes parallélisables
 Peu adapté au traitement rapide de tâches séquentielles
Nvidia Tesla K20X




2688 cœurs – 3950 Gflops
4450 $
235 W
1,12 $ / Gflop
Xeon E7-8870




10 cœurs – 96 Gflops
4616 $
130 W
48, 08 $ / GFlop
27

28. GPGPU : Architecture « orientée débit »
Changement de paradigme
 Low-latency pour le CPU
 Orienté débit pour le GPU
Traitement des tâches dans l’ordre
 Basé sur le modèle SIMD
 Génération en masse de threads pour
traiter la même instruction
28

29. GPGPU : Les facteurs limitants
La multiplication des branches détériore les performances
 Les unités de calculs d’une branche doivent attendre les autres
 Sous-utilisation matérielle
Limitation matérielle
 Transfert de données entre les
mémoires CPU et GPU
29

30. Quelques frameworks GPU
 C/C++
 OpenCL
 Cuda
 C#
 GPU.NET (http://www.tidepowerd.com)
 Java
 Aparapi (http://code.google.com/p/aparapi)
 Rootbeer (https://github.com/pcpratts/rootbeer1)
 Scala
 ScalaCL (http://code.google.com/p/scalacl)
30

31. Batman equation: GPU
31

32. Autres utilisations
 Plusieurs étapes de validation
 Plusieurs calculs à faire
 Toutes les boucles que vous rencontrez!
32

33. Implémentation naïve
http-worker-1
http-worker-2
…
Thread
Swapping
http-worker-n
Calcul
Monte-Carlo
33

34. Implémentation parallèle
http-worker-1
http-worker-2
Thread pool
pool-worker-1
…
pool-worker-2
http-worker-n
Calcul
Monte-Carlo
34

35. Monte Carlo: 1 utilisateur
Séquentiel
Parallèle
35

36. Monte Carlo: 50 utilisateurs
Séquentiel
Parallèle
36

37. 37

38. Faut s’y mettre
38

39. Y’a pas le choix
39

40. Conclusion
C’est de
plus en
plus
simple
40

41. Questions
http://perfug.github.io/
+Henri
@henritremblay
htr@octo.com
http://brownbaglunch.fr
41

42. Démo
Sur GitHub
 Pour récupérer le projet
 git clone git://github.com/henri-tremblay/parallel-lab.git
 Pour compiler (tout est dans vanillapull)
 mvn install
 Pour exécuter
 mvn –pl webapp –Dspring.profiles.active=${mode}
• mode = vanilla | mono | naive | executor | pool |
akka
 Pour bencher

mvn –pl gatling gatling:execute -Dgatling.simulationClass=PricingSimulation
42