RE: Hyperthreading / SMP [Was: Compilation module - kernel 2.6.5 /sid-> Plex86]
Bonjour
Le lun 17/05/2004 à 19:46, Eric SCHAEFFER a écrit :
> Le lun 17/05/2004 à 18:52, Eric SCHAEFFER a écrit :
> > J'avais pas trouvé grand chose sur le net concernant linux et
> > l'hyperthreading.
>
> J'ai parlé trop vite :
>
> http://www-106.ibm.com/developerworks/linux/library/l-web26/
>
> Hyper-threading
> Hyper-threading, an innovation from Intel, is a major hardware
> enhancement supported by the 2.6 kernel. Basically, hyper-threading can
> create multiple virtual processors based on a single physical processor
> using simultaneous multi-threading technology (SMT); multiple
> application threads can be run simultaneously on one processor. To take
> full advantage of it, applications need to be multithreaded.
>
> Tests pentium HT :
> http://www.2cpu.com/articles/41_1.html
>
> Il semblerait donc qu'il faille utiliser un kernel SMP.
Je confirme, mais le 2.6 vanilla ou debian n'est pas encore au top sur
ce domaine : appliquez les patchs de Con Kolivas (Hyperthread smart
"nice" en particulier).
Sinon, l'hyper-threading c'est une magouille (grandement marketing) de
intel pour être plus dans la mouvance "parallélisme"...
Le principe est le suivant : le but est de mieux (comprendre : plus)
utiliser les différentes unités du CPU. Genre pendant qu'un process de
calcul en virgule flottante tourne, l'unité de calcul entier, elle, se
tourne les pouces... c'est pas génial...
Donc, on fait 2-3 modifs pour que le CPU se comporte comme s'il était 2
vu de l'extérieur... en se disant que, comme ça, l'OS va nous donner
plus de code à exécuter et donc on aura plus de chance de pouvoir
"boucher les trous" en réorganisant l'ordre d'exécution de tout ça...
En espérant que l'OS va lui donner à manger un autre processus qui
utilisera des unités jusque là inoccupées... c'est mieux ?
Ca peut : si on a de nombreuses tâches running différentes simultanées,
on peut espérer un gain de performance de l'ordre de 20-25%,...
sur une machine qui fait tourner 1 "job" unique (ie. un seul code
parallèle, plusieurs fois le même code séquentiel en sumultané, ou
encore des threads identiques,...), gain 0 :(
(benchs by myself pour le taf)
Bref, une machine "hyperthreadée" est loin d'une machine smp du point de
vue des perfs...
Pour plus de détails sur le comment :
http://developer.intel.com/technology/hyperthread/index.htm
Bruno
Reply to: