Par défaut Myrian détecte automatiquement un nombre maximum de threads à utiliser pour chaque processus (en fonction du nombre de cœurs sur un nœud NUMA, ce qui correspond au nombre de cœurs sur un socket la plupart du temps). Dans certains cas, cette détection automatique fonctionne mal (du fait de la couche de virtualisation). Une préférence permet de passer outre cette détection automatique à partir de la 2.1.2 (MAX_THREAD_COUNT dans le [MAIN] de _intrasense.txt). Il est possible de connaître le nombre de threads effectivement utilisés par Myrian en ouvrant le log <user>.status.txt. Le nombre de threads est donné par la ligne « omp_set_num_threads=… ».

 

Mesures effectuées avec la 2.2:

Lorsque le nombre de threads à utiliser dans Myrian n’est pas défini correctement de manière automatique, le meilleur choix est 6 ou 8 en fonction de l’utilisation principale de Myrian.

Lorsqu’on mesure les performances en fonction du nombre de threads, on obtient de bonnes parallélisation jusqu’à 6 ou 8 threads :

• Jusqu’à 6 threads, la parallélisation est correcte presque tout le temps.
• Avec 8 threads, on a le même comportement la plupart du temps. Il y a quelques exceptions, les méthodes d’affichage 2d en particulier. De plus on aperçoit souvent une grosse augmentation du temps de calcul dans le pire des cas, ce qui pourrait induire des saccades (à l’affichage entre autres).
• Au-dessus de 8 threads, il vaut souvent mieux réserver les ressources pour d’autres taches.

Du coup, en simplifiant un peu, il vaut mieux utiliser au plus :

• 6 threads pour une activité principale de visualisation
• 8 threads lorsqu’on compte faire beaucoup de segmentation, recalage et rendu 3D…

Bien sûr, cela dépend aussi des ressources disponibles sur le serveur, du nombre d’utilisateurs simultanés…

 

 

PS : Il s’agit des résultats des tests sur une VM précise. Je ne sais pas si ces résultats sont valides quelle que soit l’architecture matérielle et logicielle. En particulier, ces résultats ne seront plus valides si on a moins de 6/8 cœurs sur chaque nœud NUMA. Dans les autres cas, je ne vois pas pourquoi ces résultats ne seraient pas valides.

PS2 : Si dans _intrasense.txt, on choisit un nombre de CPU (dans MAX_THREAD_COUNT) supérieur au nombre de CPU logiques disponibles sur la machine, Myrian crashe.

PS3 : (Pour EQD) Lorsqu’on utilise un schedule dynamic (car plus efficace que le schedule static dans certains cas), on observe la plupart du temps une réduction importante des gains dus à la parallélisation lorsqu’on approche, puis dépasse le nombre de threads disponible sur un processeur physique (entre 8 et 16 threads sur la machine de test). Ce comportement s’explique par l’overhead de synchronisation entre les threads. Celui-ci devient bien plus important quand on travaille sur plusieurs processeurs physiques en même temps. Dans ces cas-là, l’utilisation d’un schedule static est parfois plus efficace lorsqu’on travaille sur un grand nombre de cœurs. Mais à mon avis il vaut mieux favoriser les gains de vitesse pour un nombre de threads plus faible.