Discussion :

[gesav72643]

Salut à tous,
Je sollicite vos lumières sur un sujet qui me fait m’arracher les cheveux depuis quelques jours. Dans le cadre d'un projet de calcul intensif, je travaille sur des serveurs lames ProLiant BL460C équipés de processeurs Xeon 20 cœurs cadencés à 2.5GHz. Sur le papier, c'est une configuration de rêve pour du parallélisme, mais en pratique, je rencontre des comportements assez frustrants.
Un point spécifique qui m'interpelle dans la documentation et mes tests concerne la gestion de la topologie NUMA. J'ai remarqué que dès que mon application sature les 20 cœurs physiques, les temps d'accès à la mémoire deviennent totalement instables. C’est un peu rageant de voir une machine de cette envergure perdre en efficacité à cause de la latence entre les nœuds mémoire alors que la puissance brute est là.
À titre personnel, j'ai passé une bonne partie de mes nuits à monitorer l'affinité des threads. On oublie souvent que sur un châssis aussi compact qu'une lame BL460C, la gestion thermique et le partage des ressources entre les lames peuvent influencer le comportement du Turbo Boost. J'ai l'impression que le scheduler de l'OS a parfois du mal à comprendre que déplacer un thread sur un cœur "libre" mais distant peut coûter plus cher en performances que d'attendre un cycle local.
Avez-vous déjà travaillé sur ce type d'architecture à 20 cœurs ? Je me demande si le problème vient d'une mauvaise configuration de mon bios (Workload Profile) ou si c'est une limite intrinsèque de la gestion de la mémoire partagée sur des processeurs avec autant de cœurs.
Observation : On dirait que plus on multiplie les cœurs, plus le goulot d'étranglement se déplace de la puissance de calcul brute vers la simple logistique des données en RAM. Est-ce que le multithreading "standard" a encore un sens sans une gestion manuelle de l'affinité sur ce genre de monstre ?

[Artemus24]

Salut Gesav72643 et bienvenue dans le forum Developpez.net.

Je ne suis pas un spécialiste du parallélisme, mais je crois que le mieux est de gérer par toi-même le goulot d'étranglement et non laisser la machine le faire. Il suffit de mettre en attente le ou les prochain(s) processus jusqu'à ce qu'un thread se libère de la machine. Ce n'est pas bien compliqué à faire puisque je l'ai fait sur mon ordinateur pour résoudre des petits problèmes de programmation. Admettons que tu laisses toujours un thread de libre, celui que ta machine utilise pour gérer les autres, je pense que cela va résoudre ton problème de saturation.

[Ti-Slackeux]

Ca fait un moment que j'ai pas touché d'aussi gros bébé.

Le soucis, imho, c'est un soucis d'affinité CPU et mémoire locale pour justement éviter de se faire casser les perfs
par des migrations de threads.
Je crois qu'il faut aller voir côté threads pinning et l'allocation mémoire numa.
Il faut, je pense, une gestion très fine de l'affinité CPU et mémoire.
Température et workload n'auront qu'un effet secondaire dans tout çà.
Pas sur mais l'OS pourrait induire des soucis aussi >.<

hth,