Auteur Sujet: Hyper-Threading  (Lu 14203 fois)

0 Membres et 1 Invité sur ce sujet

Breizh 29

  • Client Bouygues Fibre +
  • Abonné Orange Fibre
  • *
  • Messages: 4 279
  • Guilers 29820 (29N)
Hyper-Threading
« Réponse #24 le: 02 mai 2015 à 03:05:55 »
Sous Linux:

Pour résumer, les CPU sont répartis dans des struct sched_domain.
Par défaut, sur les systèmes multi-sockets, chaque socket est dans un domaine séparé.
Sur les systèmes multi-threads (le cas de l'hyperthreading, donc), chaque groupe de core (le physique et le ou les virtuel(s) sont dans un domaine séparé.

Lorsqu'une tâche demande de la ressource, elle est alloué à un groupe (le plus vide, j'imagine).
Lorsqu'un groupe est "saturé", des tâches peuvent être exportés vers un autre groupe.

Cela signifie qu'un process reste toujours dans le même groupe (sauf saturation CPU) et profite donc grandement du cache.
Cela signifie également que deux process séparés font être alloués à deux cores physiques si possible.

Ok merci pour l'explication, mais pourquoi aller jusqu'à saturation avant de changer de CPU ?
L'autre a le même cache  ???
Dans toutes vos explications, j'ai l'impressions que un seul  CPU bosse si la charge n'est pas sufisante.
Je me trompe ?

Pourtant je n'ai pas le sentiment que un travail plus l'autre aux vue des T°

vivien

  • Administrateur
  • *
  • Messages: 47 078
    • Twitter LaFibre.info
Hyper-Threading
« Réponse #25 le: 02 mai 2015 à 08:04:20 »
De nombreux programmes (la majorité) ne peuvent exploiter qu'un seul processus (donc un seul core) : les opérations ne sont pas décomposées en différents taches pour être traitées en parallèle.

Seuls les programmes qui sont des gros consommateurs sont optimisés pour équilibrer le travail sur plusieurs processus.

Un exemple : Tu ouvres un gros fichier .csv avec Calc ou un capture Wireshark de plusieurs centaines de Mo : L'opération est longue mais utilise un seul processus => Un processeur bi-coeur ira plus vite qu'un processeur 8 cœurs car les fréquences des 2 cœurs sont plus élevées qu'un 8 cœurs.

Pour un serveur, c'est pareil : un client qui fait un téléchargement https va utiliser un seul cœur. Par contre un Xeon E5-1410 @2.80GHz va réussir à gérer 10 Gb/s de transfert https sur un seul cœur. Habituellement sur un serveur tu as plusieurs requêtes en parallèle donc là cela utilises bien les différents cœur de ton PC.

Je comprend pourquoi Netflix arrive a gérer plus de 10 Gb/s de trafic par serveur alors le processeur est moyen de gamme (Intel® Xeon E3-1260L => 4 cœurs, 8 threads, 8M Cache, 2.40 GHz) et qu'il y a seulement 32Go de ram. Les E/S doivent être impressionnantes, mais sont gérées par 36 disques de 3 To SAS. Si le serveur sait gérer 18 Gb/s, cela fait en fait 500 Mb/s par disque, c'est possible.

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
Hyper-Threading
« Réponse #26 le: 02 mai 2015 à 09:59:50 »
Ok merci pour l'explication, mais pourquoi aller jusqu'à saturation avant de changer de CPU ?
L'autre a le même cache  ???
Dans toutes vos explications, j'ai l'impressions que un seul  CPU bosse si la charge n'est pas sufisante.
Je me trompe ?

Pourtant je n'ai pas le sentiment que un travail plus l'autre aux vue des T°

L'explication qu'on t'a donné s'applique à Linux, pas à Windows :)

Sous Windows, une tache est équilibrée sur tous les CPU (physiques ou virtuels) à tour de role : lance une tache mono-thread et ouvre le gestionnaire de taches. Normalement tu devrais voir tous les core avec une meme charge. En principe, la charge est divisée par le nombre de coeurs, donc si 2 cores = 50% chacun, 4 cores=25% chacun, etc.

Pour changer ce comportement et assigner une tache à un seul coeur pour améliorer le fonctionnement, il faut règler l'affinité : dans le gestionnaire de taches, clic-droit sur la tache et faire définir l'affinité. Une fenetre s'ouvre et il faut cocher un seul CPU dans la liste.

Cette gestion pénalise le fonctionnement des traitements mono-thread sous Windows à cause de la moindre efficacité du cache de chaque coeur. Il me semble que cela avait été amélioré à partir de Windows 7. Les versions Server ont le meme "défaut" mais sur un Server on a en principe bien plus qu'une tache à traiter !

corrector

  • Invité
Hyper-Threading
« Réponse #27 le: 02 mai 2015 à 10:30:40 »
Je ne comprends pas...

vivien

  • Administrateur
  • *
  • Messages: 47 078
    • Twitter LaFibre.info
Hyper-Threading
« Réponse #28 le: 02 mai 2015 à 14:34:33 »
C'est pas contre productif de faire tourner une tâche de core en core très rapidement ?

C'est vrai que que sous windows j'ai été étonné mais j'ai déjà observé qu'un logiciel qui consomme beaucoup de CPU va charger les différents core à 25% (4 cœurs) ou 50% (bi-cœurs)

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
Hyper-Threading
« Réponse #29 le: 02 mai 2015 à 14:43:00 »
@corrector c'est quoi que tu comprends pas ? Mon explication ou la logique de Microsoft ?

@vivien en effet la tache sera moins efficace. J'ai du SMP depuis 2002 et c'est un problème connu de Windows. Pire il me semble que sous 2000/XP il pouvait commuter 2 taches parallèles d'un CPU à l'autre. D'où des outils comme SMP seesaw pour régler les affinités des tâches.

seb

  • Pau Broadband Country (64)
  • Abonné SFR fibre FttH
  • *
  • Messages: 515
  • FTTH 1 Gbps sur Pau (64)
Hyper-Threading
« Réponse #30 le: 02 mai 2015 à 16:39:25 »
De nombreux programmes (la majorité) ne peuvent exploiter qu'un seul fil d'exécution (donc un seul core) : les opérations ne sont pas décomposées en différents taches pour être traitées en parallèle.
Petite correction sémantique : un processus peut être constitué de plusieurs fils d'exécution (threads).
À moins qu'ils n'aient rien à se dire du tout en interne ou que l'exécution doive se faire de façon distribuée sur plusieurs machines, il est plus efficace pour un programme d'utiliser un seul processus constitué de deux fils d'exécution (qui vont partager la même mémoire), que deux processus constitués d'un seul fil (qui devront faire appel aux mécanismes de communication inter-processus pour s'échanger des informations).

corrector

  • Invité
Hyper-Threading
« Réponse #31 le: 03 mai 2015 à 01:46:49 »
L'explication qu'on t'a donné s'applique à Linux, pas à Windows :)

Sous Windows, une tache est équilibrée sur tous les CPU (physiques ou virtuels) à tour de role : lance une tache mono-thread et ouvre le gestionnaire de taches. Normalement tu devrais voir tous les core avec une meme charge. En principe, la charge est divisée par le nombre de coeurs, donc si 2 cores = 50% chacun, 4 cores=25% chacun, etc.
Comment une seule tache est divisée en plusieurs?

C'est comme l'homéopathie, tu arrives à diluer une seule molécule?

corrector

  • Invité
Hyper-Threading
« Réponse #32 le: 03 mai 2015 à 01:54:42 »
Petite correction sémantique : un processus peut être constitué de plusieurs fils d'exécution (threads).
À moins qu'ils n'aient rien à se dire du tout en interne ou que l'exécution doive se faire de façon distribuée sur plusieurs machines,
Si tes threads sont très interdépendants, ça n'a peut être aucun intérêt de les paralléliser!

Sur une machine multi unités d'exécution (CPU ou "core"), tu as en général de nombreuses tâches en cours ou en attente d'exécution. Terminer plus vite une seule de ces tâche n'est pas forcèment utile.

il est plus efficace pour un programme d'utiliser un seul processus constitué de deux fils d'exécution (qui vont partager la même mémoire), que deux processus constitués d'un seul fil (qui devront faire appel aux mécanismes de communication inter-processus pour s'échanger des informations).
Les communications interprocessus ne sont pas forcèment moins efficaces que les communication intraprocessus. On peut utiliser exactement les mêmes outils : sémaphores, mutex, etc.

corrector

  • Invité
Hyper-Threading
« Réponse #33 le: 03 mai 2015 à 01:59:47 »
Un exemple : Tu ouvres un gros fichier .csv avec Calc ou un capture Wireshark de plusieurs centaines de Mo : L'opération est longue mais utilise un seul processus => Un processeur bi-coeur ira plus vite qu'un processeur 8 cœurs car les fréquences des 2 cœurs sont plus élevées qu'un 8 cœurs.
La lecture d'un fichier est une opération linéaire.

Pour un serveur, c'est pareil : un client qui fait un téléchargement https va utiliser un seul cœur. Par contre un Xeon E5-1410 @2.80GHz va réussir a gérer 10 Gb/s de transfert https sur un seul cœur.
Gérer une connexion HTTPS (coté client ou serveur) est typiquement le genre de chose qui n'admet aucun parallélisme.

Par contre coté client le rendu d'une page Web n'a pas besoin d'être fait dans un seul processus : chaque image existe indépendamment, et peut être décodée par un thread différent.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Hyper-Threading
« Réponse #34 le: 03 mai 2015 à 14:33:25 »
Citer
Comment une seule tache est divisée en plusieurs?
Je crois que tu as mal compris.
Si tu as une charge de 1 CPU, et que tu disposes de 4 CPU, tu peux tout à faire répartir cette charge de 1 sur les 4.
Le scheduleur tic à relativement haute fréquence : bien que d'un point de vu technique, la charge n'existe que sur un CPU à la fois, d'un point de vu relatif, tu la vois "un peu sur chaque".
Tu sais, c'est comme les effets visuelles (blur etc) : tu as l'impression de voir plusieurs fois la même chose, alors qu'elle n'existe, pour chaque instant T, qu'à un seul endroit.

Citer
La lecture d'un fichier est une opération linéaire.
Oui et non
Au niveau IO, la lecture d'un fichier peut être en fait la lecture de plusieurs morceaux de fichier (le regroupement de tout ces morceaux faisant le fichier en lui même). Et ces morceaux peuvent ne pas être linéairement placés (au niveau logique, je ne parle pas du niveau physique évidement).

Si je prends une base de données par exemple, je peux probablement faire un "select *" sur mon unique table, sans pour autant faire une lecture linéaire (depuis le début du fichier jusqu'à la fin).

corrector

  • Invité
Hyper-Threading
« Réponse #35 le: 03 mai 2015 à 16:33:31 »
Je crois que tu as mal compris.
Si tu as une charge de 1 CPU, et que tu disposes de 4 CPU, tu peux tout à faire répartir cette charge de 1 sur les 4.
Le scheduleur tic à relativement haute fréquence : bien que d'un point de vu technique, la charge n'existe que sur un CPU à la fois, d'un point de vu relatif, tu la vois "un peu sur chaque".
Ah je crois que j'ai compris, c'est pour pas user plus un CPU qu'un autre en fait.

Je fais pareil avec mes chaussettes (et pas mes sockets).