Softshake 2013 - Vivre en parallèle

  • 1,264 views
Uploaded on

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 …

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,264
On Slideshare
0
From Embeds
0
Number of Embeds
23

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Pourquoi ça vous tombe dessus là toute de suite: À cause de la loi de Moore!Henri:« Démontrer que la programmation parallèle doit désormais … »C’est une technologie mature et omniprésente. Elle ne doit plus être ignorée comme solution possible à vos problèmes de développement par peur de complexité.Évidemment, il y a encore des écueils, mais depuis quelques années, la complexité a été largement réduite.Mais commençons pas le début: Pourquoi ça vous tombe dessus là tout de suite?« Petit aparté: Toute présentation sur la programmation parallèle se doit de parler de la loi de Moore. Nous ne dérogerons pas à la règle donc, je reprends »

Transcript

  • 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