hyperthreading et turbo boost dans la multiplication matricielle - performances plus mauvaises avec l'hyper threading

Question

J'ajuste mon code GEMM et je le compare avec Eigen et MKL. J'ai un système avec quatre cœurs physiques. Jusqu'à présent, j'ai utilisé le nombre de threads par défaut d'OpenMP (huit sur mon système). Je pensais que cela serait au moins aussi bon que quatre threads. Cependant, j'ai découvert aujourd'hui que si j'exécute Eigen et mon propre code GEMM sur une grande matrice dense (1000x1000), j'obtiens de meilleures performances en utilisant quatre threads au lieu de huit. L'efficacité est passée de 45% à 65%. Je pense que cela peut également être vu dans ce graphique https://plafrim.bordeaux.inria.fr/doku.php?id=people:guenneba

La différence est assez importante. Cependant, les performances sont beaucoup moins stables. Les performances sautent un peu à chaque itération, aussi bien avec Eigen qu'avec mon propre code GEMM. Je suis surpris que l'Hyperthreading rende les performances si mauvaises. Je suppose que ce n'est pas une question. C'est une observation inattendue sur laquelle j'espère trouver un retour.

Je vois qu'il est également suggéré de ne pas utiliser l'hyper enfilage.
Comment accélérer le produit matriciel de la bibliothèque Eigen ?

J'ai une question concernant la mesure des performances maximales. Ce que je fais maintenant est d'exécuter CPUz et de regarder la fréquence pendant que j'exécute mon code GEMM, puis d'utiliser ce nombre dans mon code (4,3 GHz sur un système overclocké que j'utilise). Puis-je me fier à ce chiffre pour tous les threads ? Comment puis-je connaître la fréquence par thread pour déterminer le maximum ? Comment puis-je prendre en compte correctement le turbo boost ?

Answer 1

L'objectif de l'hyperthreading est d'améliorer l'utilisation du CPU pour les codes présentant une latence élevée. L'hyperthreading masque cette latence en traitant deux threads à la fois, ce qui permet un parallélisme accru au niveau des instructions.

Cependant, un noyau de produit matriciel bien écrit présente un excellent parallélisme au niveau des instructions et exploite donc presque 100% des ressources du CPU. Il n'y a donc pas de place pour un deuxième "hyper" thread, et les frais généraux liés à sa gestion ne peuvent que diminuer les performances globales.

Answer 2

Sauf si j'ai raté quelque chose, ce qui est toujours possible, votre CPU a une horloge partagée par tous ses composants, donc si vous mesurez sa fréquence à 4,3 GHz (ou autre), c'est la fréquence de tous les composants pour lesquels il est logique de déterminer une fréquence. Imaginez le chaos si ce n'était pas le cas, certains cœurs fonctionnant à un rythme, d'autres à un autre ; les composants partagés (par exemple l'accès à la mémoire) deviendraient ingérables.

Pour ce qui est de l'hyperthreading qui détériore les performances de votre multiplication matricielle, je ne suis pas surpris. Après tout, l'hyperthreading est une technique de parallélisation du pauvre, dupliquant les pipelines d'instructions mais pas les unités fonctionnelles. Une fois que vous avez fait hurler votre code en poussant vos n*10^6 des emplacements mémoire contigus à travers les FPU, un changement de contexte en réponse à un blocage du pipeline ne va pas aider beaucoup. Au mieux, l'autre pipeline va crier pendant un moment avant qu'un autre changement de contexte ne vous prive de cycles d'horloge utiles, au pire, l'arrangement minutieux des données dans la hiérarchie de la mémoire sera horriblement altéré à chaque changement.

L'hyperthreading n'est pas conçu pour la vitesse de calcul numérique parallèle mais pour améliorer les performances d'une charge de travail beaucoup plus générale ; nous utilisons des CPU polyvalents dans le calcul à haute performance non pas parce que nous voulons l'hyperthreading mais parce que tous les CPU numériques parallèles spécialisés ont disparu.

Answer 3

En tant que fournisseur de services de concurrence multithread, j'ai étudié l'impact de l'hyperthreading sur les performances dans diverses conditions. J'ai constaté qu'avec un logiciel qui limite ses propres threads à forte utilisation à un maximum de processeurs physiques disponibles, la présence ou l'absence de HT fait très peu de différence. Les logiciels qui tentent d'utiliser plus de threads que cela pour des travaux de calcul lourds, ne sont probablement pas conscients de ce qu'ils font, se fiant simplement au nombre total de processeurs (qui double sous HT), et fonctionnent de manière prévisible plus lentement. L'avantage le plus important de l'activation de la HT est peut-être le fait que vous pouvez exploiter au maximum tous les processeurs physiques, sans que le reste du système ne se mette à ramper. Sans HT, les logiciels doivent souvent laisser un processeur libre pour que le système hôte fonctionne normalement. Les Hyperthreads ne sont que des threads commutables supplémentaires, ce ne sont pas des processeurs supplémentaires.