Differences

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

--- commit:2014:10_09 [2014/10/09 13:34] – crutzen
+++ commit:2014:10_09 [2016/03/30 15:23] (current) – external edit 127.0.0.1
@@ 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.
-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;
   * 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''.
-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).
+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 |}}
-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 |}}