Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:2014:10_09

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
commit:2014:10_09 [2014/10/09 13:17] crutzencommit:2014:10_09 [2016/03/30 15:23] (current) – external edit 127.0.0.1
Line 7: Line 7:
 =====Introduction===== =====Introduction=====
  
-Pour rappel, le commit 2089 s’était concentré essentiellement sur les problèmes manifestes de performances de l’assemblage de la matrice de raideur structurale en parallèle, constatés étonnement suite au commit 2071. Ceux-ci provenaient notamment de la compétition entre les threads OpenMP et tbb. +Pour rappel, le commit 2089 s’était concentré essentiellement sur les problèmes manifestes de performances de l’assemblage de la matrice de raideur structurale en parallèle, constatés étonnamment suite au commit 2071. Ceux-ci provenaient notamment de la compétition entre les threads OpenMP et tbb. 
  
 La figure ci-dessous confirme le retour espéré des performances antérieures au commit 2071, tout du moins pour les simulations lagrangiennes de profilage. Le cas-test est le profilage du channel en formalisme lagrangien. Les courbes en trait plein sont relatives à la révision 2041 de Metafor (tel que présenté à la conférence ICOMP’14 et donc antérieur au commit 2071), les croix à la révision 2089. Le temps de référence du speedup est celui du job à 1 thread de la révision 2041. On peut remarquer des performances plutôt similaires entre les deux révisions de METAFOR, hormis le speedup du buildK en 12 threads désormais encore plus convaincant. La figure ci-dessous confirme le retour espéré des performances antérieures au commit 2071, tout du moins pour les simulations lagrangiennes de profilage. Le cas-test est le profilage du channel en formalisme lagrangien. Les courbes en trait plein sont relatives à la révision 2041 de Metafor (tel que présenté à la conférence ICOMP’14 et donc antérieur au commit 2071), les croix à la révision 2089. Le temps de référence du speedup est celui du job à 1 thread de la révision 2041. On peut remarquer des performances plutôt similaires entre les deux révisions de METAFOR, hormis le speedup du buildK en 12 threads désormais encore plus convaincant.
Line 19: Line 19:
 Des analyses ont été menées avec l’Amplifier du Parallel Studio. Elles ont pointé des problèmes de performances vers la base de données, largement sollicitée par la convection désormais parallélisée. La synchronisation des threads par le spin mutex défini dans la méthode ''define()'' de la base de données était responsable du problème. Des analyses ont été menées avec l’Amplifier du Parallel Studio. Elles ont pointé des problèmes de performances vers la base de données, largement sollicitée par la convection désormais parallélisée. La synchronisation des threads par le spin mutex défini dans la méthode ''define()'' de la base de données était responsable du problème.
  
-Désormais, le vecteur membre ''std'' de la classe ''DBSet'' est remplacé par un vecteur concurrent pour pouvoir s'affranchir du mutex requis par la méthode ''define()''. Ce choix de vecteur assure, selon la documentation de tbb, que :+Désormais, le vecteur ''std'' membre de la classe ''DBSet'' est remplacé par un vecteur concurrent pour pouvoir s'affranchir du mutex requis par la méthode ''define()''. Ce choix de vecteur assure, selon la documentation de tbb, que :
   * plusieurs threads peuvent agrandir la dimension du conteneur et ajouter de nouveaux éléments de manière concurrente;   * plusieurs threads peuvent agrandir la dimension du conteneur et ajouter de nouveaux éléments de manière concurrente;
   * agrandir le conteneur n’invalide pas les itérateurs et indices existants.   * agrandir le conteneur n’invalide pas les itérateurs et indices existants.
Line 25: Line 25:
 Les temps d’accès concurrents dans la base de données ne sont ainsi quasiment plus pénalisés. Toutefois, cela pourrait occasionner une légère dégradation inévitable pour un accès séquentiel par rapport au vecteur ''std''. Les temps d’accès concurrents dans la base de données ne sont ainsi quasiment plus pénalisés. Toutefois, cela pourrait occasionner une légère dégradation inévitable pour un accès séquentiel par rapport au vecteur ''std''.
  
-A présent, le speedup global de la parallélisation est plus acceptable pour un petit-cas de profilage en formalisme ALE : environ 4.5 (voir figure ci-dessous).+A présent, le speedup global de la parallélisation est plus acceptable pour un petit cas-test de profilage en formalisme ALE : environ 4.5 (voir figure ci-dessous). Le speedup de la convection ALE s'élève à environ 7.5.
  
 {{ :commit:2014:speedupconcurrentvector.png |}} {{ :commit:2014:speedupconcurrentvector.png |}}
  
-Une seconde option était le recours à un mutex read-write dans la DB au lieu du spin mutex. Les performances étaient cependant plus en retrait (voir figure ci-dessous).+Une seconde option était le recours à un mutex read-write dans la DB au lieu du spin mutex utilisé auparavant. Les performances étaient cependant plus en retrait que celles de la première option (voir figure ci-dessous).
  
 {{ :commit:2014:speeduprwmutex.png |}} {{ :commit:2014:speeduprwmutex.png |}}
Line 44: Line 44:
 </code> </code>
  
- --- //[[Y.Crutzen@ulg.ac.be|Yanick Crutzen]] 2014/07/10 //+ --- //[[Y.Crutzen@ulg.ac.be|Yanick Crutzen]] 2014/10/09 //
  
  
commit/2014/10_09.1412853468.txt.gz · Last modified: 2016/03/30 15:22 (external edit)

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki