Auteur Sujet: Hyper-Threading  (Lu 15552 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Hyper-Threading
« le: 28 avril 2015 à 11:24:45 »
Aujourd'hui, une grande partie des processeurs d’Intel intègrent de Hyper-Threading. C'est le cas des core-i3 (PC fixes et portables) et des core-i5 (pour les portables uniquement) et des core-i7 (PC fixes et portables).

Schématiquement, l’hyper-threading consiste à créer deux processeurs logiques sur une seule puce, chacun doté de ses propres registres de données et de contrôle, et d’un contrôleur d’interruptions particulier. Ces deux unités partagent les éléments du cœur de processeur, le cache et le bus système. Ainsi, deux sous-processus peuvent être traités simultanèment par le même processeur. Cette technique multitâche permet d’utiliser au mieux les ressources du processeur en garantissant que des données lui sont envoyées en masse. Elle permet aussi d’améliorer les performances en cas de défauts de cache (cache misses). Source : Wikipedia

J'ai un processeur Intel Core™ i3-2120, équipé de 2 cœurs avec de l'Hyper-Threading et qui est donc vu par les différentes systèmes d’exploitation comme 4 CPU, ce qui est normal.

Ce qui m'étonne, c'est le répartition de charge quand j’utilise 2 CPU au maximum : Le système d’exploitation (Linux 3.19 ici avec Ubuntu 15.04) va faire tourner les 2 processus de temps en temps sur le même cœur physique si je comprend bien les courbes ci-dessous :

Au début, les CPU 1 et 2 sont utilisés, ensuite on passe au CPU 2 et 3, puis 1 et 2 de nouveau, CPU 1 et 4 ensuite, CPU 1 et 2, CPU 3 et 4,....

Bref, je ne sais pas si le cœur 1 correspond au CPU 1 et 2 et le coeur 2 au CPU 3 et 4, mais l'utilisaiton de 2 Threads d'un même cœur, tout en laissant le second cœur inutilisé est contre performant, non ?



Les caractéristiques de mon Core™ i3-2120 :

butler_fr

  • Client Bbox adsl
  • Modérateur
  • *
  • Messages: 3 588
  • FTTH orange
Hyper-Threading
« Réponse #1 le: 28 avril 2015 à 11:36:09 »
question que je me suis posé également...
honnêtement le fonctionnement de l'hyperthreading est flou.

est ce que utilisés simultanèment les 2 coeurs logiques ont la même perf ou 1 sera plus perf que l'autre?
en cas d'usage qui n'est pas multi thread est ce qu'il ne vaut pas mieux désactiver le mécanisme?

bref pleins de questions ;)

Optrolight

  • Client Orange Fibre
  • Modérateur
  • *
  • Messages: 4 675
  • Grenoble (38) @Optrolight
    • Optroastro
Hyper-Threading
« Réponse #2 le: 28 avril 2015 à 11:49:44 »
L'hyper threading est je crois gérer par l' OS. Donc à part les jeux je crois qu'il gère vraiment au mieux!!

Fredwww

  • Expert Orange
  • Abonné Orange Fibre
  • *
  • Messages: 369
Hyper-Threading
« Réponse #3 le: 28 avril 2015 à 11:55:13 »
Dans ce cas de figure d'alternance entre les différents cores/threads, les changements de contexte doit être vraiment contre productif si on compare à 2 CPU pleinement utilisé tout le long (cas d'Hyper Threading désactivé).

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 479
  • Malissard (26)
Hyper-Threading
« Réponse #4 le: 28 avril 2015 à 12:44:57 »
2 process en HT seront moins rapides que 2 process sur 2 coeurs différents. Dans le cas 1 Intel avance 20 à 30% de gain. Dans le cas 2 on peut espérer x2.

Sous Linux, il faut regarder /proc/cpuinfo pour l'affectation des id.

Optrolight

  • Client Orange Fibre
  • Modérateur
  • *
  • Messages: 4 675
  • Grenoble (38) @Optrolight
    • Optroastro
Hyper-Threading
« Réponse #5 le: 28 avril 2015 à 12:54:55 »
2 process en HT seront moins rapides que 2 process sur 2 coeurs différents. Dans le cas 1 Intel avance 20 à 30% de gain. Dans le cas 2 on peut espérer x2.

Sous Linux, il faut regarder /proc/cpuinfo pour l'affectation des id.

Bien sur car les threads sont découpés  et/ou alterné sur un même core physique!

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 479
  • Malissard (26)
Hyper-Threading
« Réponse #6 le: 28 avril 2015 à 13:04:42 »
J'ai oublié de dire que le HT est désactivé sur mon i7 de bureau (effets de bord bizarres sur ma carte gfx Nvidia et VirtualBox) mais qu'il est actif sur mon portable en i3 et mon pro en i5.

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Hyper-Threading
« Réponse #7 le: 28 avril 2015 à 13:13:35 »
Sous Linux, il faut regarder /proc/cpuinfo pour l'affectation des id.

C'est intéressant !

CPU 1 (processor 0) => core id 0
CPU 2 (processor 1) => core id 1
CPU 3 (processor 2) => core id 0
CPU 4 (processor 3) => core id 1

Il faut donc privilégier le fonctionnement du CPU 1 avec le CPU 2 ou CPU4 quand on a seulement 2 threads (et éviter les combinaisons CPU 1 + CPU 3 / CPU 2 + CPU 4).

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family   : 6
model      : 42
model name   : Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
stepping   : 7
microcode   : 0x28
cpu MHz      : 1842.199
cache size   : 3072 KB
physical id   : 0
siblings   : 4
core id      : 0
cpu cores   : 2
apicid      : 0
initial apicid   : 0
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx lahf_lm arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs      :
bogomips   : 6587.30
clflush size   : 64
cache_alignment   : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family   : 6
model      : 42
model name   : Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
stepping   : 7
microcode   : 0x28
cpu MHz      : 1783.675
cache size   : 3072 KB
physical id   : 0
siblings   : 4
core id      : 1
cpu cores   : 2
apicid      : 2
initial apicid   : 2
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx lahf_lm arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs      :
bogomips   : 6587.30
clflush size   : 64
cache_alignment   : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family   : 6
model      : 42
model name   : Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
stepping   : 7
microcode   : 0x28
cpu MHz      : 2048.191
cache size   : 3072 KB
physical id   : 0
siblings   : 4
core id      : 0
cpu cores   : 2
apicid      : 1
initial apicid   : 1
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx lahf_lm arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs      :
bogomips   : 6587.30
clflush size   : 64
cache_alignment   : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family   : 6
model      : 42
model name   : Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
stepping   : 7
microcode   : 0x28
cpu MHz      : 1936.042
cache size   : 3072 KB
physical id   : 0
siblings   : 4
core id      : 1
cpu cores   : 2
apicid      : 3
initial apicid   : 3
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx lahf_lm arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs      :
bogomips   : 6587.30
clflush size   : 64
cache_alignment   : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

butler_fr

  • Client Bbox adsl
  • Modérateur
  • *
  • Messages: 3 588
  • FTTH orange
Hyper-Threading
« Réponse #8 le: 28 avril 2015 à 13:17:28 »
il y a moyen de le paramétrer ça?

butler_fr

  • Client Bbox adsl
  • Modérateur
  • *
  • Messages: 3 588
  • FTTH orange
Hyper-Threading
« Réponse #9 le: 28 avril 2015 à 13:24:49 »
un article trouvé sur internet...

Citer
It splits a real CPU (a core) into 2. One is the real core, called the physical core. The other is just a secondary core, called the logical core. This logical core can't do much, but it does provide a little increased parallism. It is far from being a real core. In fact, it offers 10-20% (est., likely less) the performance of a real physical core. That's right, barely any computing power. Its purpose was simply to increase parallelism in a world dominated by I/O bound (non-CPU intensive) processes (actually threads, but we won't split hairs here). When a CPU intensive (CPU bound) thread is switched to one of these cores, its performance will substantially degrade

https://bitsum.com/pl_when_hyperthreading_hurts.php

butler_fr

  • Client Bbox adsl
  • Modérateur
  • *
  • Messages: 3 588
  • FTTH orange
Hyper-Threading
« Réponse #10 le: 28 avril 2015 à 14:12:06 »
enfaite après quelques recherches l'article précédent est complètement naz!

un article d'IBM sur le sujet:
http://www.ibm.com/developerworks/library/l-htl/
basé sur les noyaux linux 2.4 et 2.5 (ça date)

Citer
Linux kernel 2.4.x was made aware of HT since the release of 2.4.17. The kernel 2.4.17 knows about the logical processor, and it treats a Hyper-Threaded processor as two physical processors. However, the scheduler used in the stock kernel 2.4.x is still considered naive for not being able to distinguish the resource contention problem between two logical processors versus two separate physical processors.

Citer
Consider a system with two physical CPUs, each of which provides two virtual processors. If there are two tasks running, the current scheduler would let them both run on a single physical processor, even though far better performance would result from migrating one process to the other physical CPU. The scheduler also doesn't understand that migrating a process from one virtual processor to its sibling (a logical CPU on the same physical CPU) is cheaper (due to cache loading) than migrating it across physical processors.

Citer
The 2.5 scheduler maintains one run queue per processor and attempts to avoid moving tasks between queues. The change is to have one run queue per physical processor that is able to feed tasks into all of the virtual processors.

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Hyper-Threading
« Réponse #11 le: 28 avril 2015 à 14:49:14 »
J'ai regardé pour le CPU du serveur LaFibre.info, un Intel Xeon CPU E31230 @ 3.20GHz, les cœurs HT ne sont pas à la fin, comme avec mon i3, mais ils suivent les cœurs physique :

$ cat /proc/cpuinfo
processor   : 0
core id      : 0

processor   : 1
core id      : 0

processor   : 2
core id      : 1

processor   : 3
core id      : 1

processor   : 4
core id      : 2

processor   : 5
core id      : 2

processor   : 6
core id      : 3

processor   : 7
core id      : 3