Hyperthreading - Page 1

hello

Alors voilà mon problème, je travaille sur un Xeon EM64T 2.8GHz (qui normalement possede l'hyperthreading (flag ht dans /proc/cpuinfo)).
J'ai fait un programme qui contient un thread pour calculer la moitié de mon traitement et la moitié restante s'execute dans le main.
Pourtant je n'observe aucun gain en vitesse alors que je pensais que les threads étaient distribués sur les unité processeurs logiques.
Est ce qu'il faut activer l'Hyperthreading quelque part ? l'OS sur lequel je bosse c'est une RedHat Advanced Server (ou un truc du genre, si la version est importante je peux aller verifier ca)

Merci d'avance

L'hyperthreading n'augmentera pas la vitesse de ton traitement, qu'il soit actif ou non.
Les processeurs logiques sont cela : logiques. Ils partagent la même unité de traitement, et dans ton cas, les traitements étant identiques, il y a contention sur cette unité lorsque les processeurs virtuels essaient de l'utiliser simultanément (ie un seul des processeurs logiques tourne à un instant donné).

ça dépend : son calcul peut nécessiter plusieurs phases assez différentes, par exemple il peut avoir besoin d'accéder à la mémoire à un certain moment et plus du tout le reste du temps (donc pendant qu'un thread accède à la mémoire l'autre peut faire ses calculs) ; dans ces cas-là on doit pouvoir gagner pas mal...

C'est assez théorique. Ca ne marche pas sur la majorité des applications. Certains éditeurs de logiciels recommandent même de désactiver l'hyperthreading pour augementer les performances (par exemple Terminal Server et VMware) ^^
Mais sur le papier c'est vrai que y'a des cas où théoriquement ça doit pouvoir améliorer les performances.

L'hyperthreading est activé dans le bios et ton Linux est un SMP ?

spectras :
Certains éditeurs de logiciels recommandent même de désactiver l'hyperthreading pour augementer les performances (par exemple Terminal Server et VMware) ^^

Oui enfin ça c'est pour les softs qui sont pas fait pour, je veux dire que dans le cas de LionelA, il peut peut-être se débrouiller pour que ses deux threads interagissent bien ^^ (c'est pas parce que ses 2 threads calculent la même chose qu'ils interagiront mal...)

Le truc c'est que on ne peut pas se débrouiller. On essaie avec, on essaie sans et on voit ce qui est le plus performant. Il n'existe pas de technique connue pour tirer parti de l'hyperthreading, ou au moins pour limiter la casse (certaines applis ont des chutes de performance de l'ordre de 20 à 30% avec l'hyperthreading actif).

J'ai pris Terminal server et VMware comme exemples, parce que c'est les deux plus récents auxquels j'ai été confronté, mais un rapide google indique que c'est vrai aussi avec : Oracle, SQL Server, Citrix...

Des fois t'as même des applications où selon le processeur, l'hyperthreading fait gagner ou perdre en perfs. C'est notamment le cas de apache : sur des Prescott l'hyperthreading augmente les perfs, tandis que sur des Xeon il les diminue.

ben c'est ce que je dis, c'est pas des softs fait pour... le programme de lionela serait sans doute nettement plus facile à adapter qu'oracle ou SQL server ^^

ok ca explique pourquoi j'ai pas gagné en perf
la fonction qui est appelée dans le thread et dans le main lit la mémoire tout le temps (c'est un decompresseur) et je pense pas pouvoir y faire quelque chose...
j'utilise a un moment l'unité de calcul des mmx mais ca doit representer meme pas 1% du temps total donc je crois que je vais abandonner l'idée des threads.
Pour que ca soit efficace, faudrait l'executer sur un dual core alors.

ben si t'es effectivement limité par la bande passante avec la RAM, le dual core n'arrangera rien non plus...

Ca dépend du dual core.
Celui de AMD peut largement améliorer les choses si l'un des threads utilise les données générées par l'autre notamment ^^

ok merci beaucoup les gars

spectras :
Ca dépend du dual core.
Celui de AMD peut largement améliorer les choses si l'un des threads utilise les données générées par l'autre notamment ^^

Oui enfin dans le cas de LionelA ça ne s'applique pas...

(tiens d'ailleurs c'est une bonne question ça : si j'ai un processus qui remplit un buffer juste pour l'envoyer à un autre processus (i.e. un pipe), que je sais que les deux processus ont tous les deux besoin d'à peu près la même puissance de calcul, et que le débit est nettement supérieur à la taille du cache divisée par la granularité de l'OS, est-ce qu'il y a des OS qui permettent de scheduler les processus pour qu'ils s'exécutent sur les deux coeurs simultanément, sans qu'il y ait une latence trop élevée entre les deux ?)

Hmmm c'est une bonne question, mais qui pose des problèmes à mettre en oeuvre.

* avec un débit supérieur à la taille du cache / la période du tick, même si l'os schedule les deux processus pour tourner simultanément, il doit forcément y avoir un mécanisme de synchronisation pour l'accès au buffer. Et ce mécanisme passe par l'os.
* si l'un des deux processus a besoin de moins de cpu que l'autre pour réaliser son traitement sur un jeu de données particulier, soit l'os en profite pour lui reprendre la main et ça remplit plus la condition initiale, soit le processeur est inutilisé pendant le reste du temps. (ok tes contraintes éliminent ce cas, mais l'implémentation dans un scheduler peut difficilement ne pas le prévoir)
* une contrainte de ce type signifie aussi que les processus en question ne peuvent pas s'exécuter tant que les deux processeurs ne sont pas dispos, ce qui pose problème pour plusieurs raisons =>
-- si l'os attend que les deux cpus soient dispos en même temps, ça peut délayer pas mal le jeu de processus
-- si l'os attend d'avoir un des cpus, le verrouille et attend d'avoir l'autre, la durée du verrouillage est du temps perdu pour l'un des cpu.

Et pour donner un exemple d'os qui fait ça, VMware le fait. Quand tu as une machine virtuelle biproc, le noyau vmware lui attribue deux cpu physiques simultanément.
En pratique, utiliser cette fonctionnalité te plombe tes performances, essentiellement pour la 3ème raison. Pire, ça plombe aussi les performances de toutes les autres machines virtuelles.

spectras :
Hmmm c'est une bonne question, mais qui pose des problèmes à mettre en oeuvre.
* avec un débit supérieur à la taille du cache / la période du tick, même si l'os schedule les deux processus pour tourner simultanément, il doit forcément y avoir un mécanisme de synchronisation pour l'accès au buffer. Et ce mécanisme passe par l'os.

Ben oui, évidemment...

* si l'un des deux processus a besoin de moins de cpu que l'autre pour réaliser son traitement sur un jeu de données particulier, soit l'os en profite pour lui reprendre la main et ça remplit plus la condition initiale, soit le processeur est inutilisé pendant le reste du temps. (ok tes contraintes éliminent ce cas, mais l'implémentation dans un scheduler peut difficilement ne pas le prévoir)

Je parle d'un scheduling manuel pour dire à l'OS "exécute ce processus simultanément sur ces deux processeurs", effectivement si c'était fait de manière automatique ce serait bien plus délicat (mais comme il y aurait de toute façon une différence significative de performance entre le cas où ça reste dans le cache et le cas où ça passe par la RAM, ce serait pas très désirable que tout d'un coup par décret de l'OS ça soit plus exécuté sur les deux processeurs en même temps...)

* une contrainte de ce type signifie aussi que les processus en question ne peuvent pas s'exécuter tant que les deux processeurs ne sont pas dispos, ce qui pose problème pour plusieurs raisons =>
-- si l'os attend que les deux cpus soient dispos en même temps, ça peut délayer pas mal le jeu de processus -- si l'os attend d'avoir un des cpus, le verrouille et attend d'avoir l'autre, la durée du verrouillage est du temps perdu pour l'un des cpu.

C'est vrai que je ne sais pas si en pratique il y a des cas où les schedulers des deux cores doivent être synchro... Si c'est pas le cas effectivement ça demanderait de mettre en place toute une machinerie supplémentaire (cela dit ce n'est pas aussi binaire que tu le prétends, les schedulers peuvent très bien communiquer entre eux, genre qd un processus va bientôt être terminé par un des schedulers, il le dit à l'autre pour qu'il lui dise de terminer l'autre processus)

Et pour donner un exemple d'os qui fait ça, VMware le fait. Quand tu as une machine virtuelle biproc, le noyau vmware lui attribue deux cpu physiques simultanément. En pratique, utiliser cette fonctionnalité te plombe tes performances, essentiellement pour la 3ème raison.

Oui enfin c'est relativement normal pour le coup, VMware ne peut pas communiquer avec les schedulers de l'OS, donc il n'a pas d'autre choix que d'attendre que les deux processus se terminent...

Pire, ça plombe aussi les performances de toutes les autres machines virtuelles.

Comment ça ?

C'est vrai que je ne sais pas si en pratique il y a des cas où les schedulers des deux cores doivent être synchro... Si c'est pas le cas effectivement ça demanderait de mettre en place toute une machinerie supplémentaire (cela dit ce n'est pas aussi binaire que tu le prétends, les schedulers peuvent très bien communiquer entre eux, genre qd un processus va bientôt être terminé par un des schedulers, il le dit à l'autre pour qu'il lui dise de terminer l'autre processus)

De ce que j'avais compris (mais il faudrait revérifier), le scheduler de Linux en tous cas s'exécute sur un seul cpu et dicte à tous les autres ce qu'ils doivent faire. Par contre il semblerait que l'ordonnanceur ne fasse pas ce travail à chaque interruption mais seulement selon une heuristique étrange. Faudrait y passer un peu plus que les 15 minutes que j'avais accordé à la chose l'autre fois.

Oui enfin c'est relativement normal pour le coup, VMware ne peut pas communiquer avec les schedulers de l'OS, donc il n'a pas d'autre choix que d'attendre que les deux processus se terminent...

VMware a tout le choix qu'il veut, et en plus sisi il communique avec le scheduler...c'est lui qui génère l'interruption virtuelle déjà au départ. Et puis il peut préempter la VM à tout moment.

Comment ça ?

Le fait d'avoir une VM biproc qui tourne sur un VMware dégrade fortement les performances de toutes les autres VM qui tournent sur le VMware.

spectras
:

C'est vrai que je ne sais pas si en pratique il y a des cas où les schedulers des deux cores doivent être synchro... Si c'est pas le cas effectivement ça demanderait de mettre en place toute une machinerie supplémentaire (cela dit ce n'est pas aussi binaire que tu le prétends, les schedulers peuvent très bien communiquer entre eux, genre qd un processus va bientôt être terminé par un des schedulers, il le dit à l'autre pour qu'il lui dise de terminer l'autre processus)

De ce que j'avais compris (mais il faudrait revérifier), le scheduler de Linux en tous cas s'exécute sur un seul cpu et dicte à tous les autres ce qu'ils doivent faire.

Ben comment un core fait si son processus se termine plus tôt que prévu Il avait reçu une liste de processus du scheduler et il prend le suivant, ou bien il relance le scheduler, ou bien... ?

Il y a une run queue par CPU, donc il peut piocher dedans. Par contre il ne me semble pas qu'il rappelle le scheduler (mais j'insiste sur le "il faudrait revérifier").