Thread, Multi-threading et Hyper-threading

THREAD:
Terme se rapportant au fonctionnement d'un processeur quel que soit son modèle ou sa technologie.
_________________________________________________________________
MUTLI-THREADING:
Voir plus sur cette page, il est toutefois conseillé de commencer la lecture ici !
_________________________________________________________________
HYPER-THREADING:
Voir plus sur cette page, il est toutefois conseillé de commencer la lecture ici !
_________________________________________________________________


Tous les programmeurs sont familliers avec l'écriture de programmes "sequentiels". Vous avez sûrement écrit, un jour, un programme qui affichait "Bonjour !" ou un programme qui triait une liste de nom ou encore un autre qui donnait la liste des nombres premiers.Ceux sont des programmes "sequentiels", avec un début, un séquence d'éxécution et une fin. A n'importe quel moment du programme, il n'y a qu'un seul point d'éxécution, qu'une seule instruction à éxécuter.

Un "thread" est similaire à un programme séquentiel décrit ci-dessus, un "thread" unique possède un début, une séquence d'éxécution et une fin; à chaque instant de d'éxécution d'un "thread", il n'y a qu'une seule instruction à éxécuter. Toutefois, un "thread" n'est pas un programme à part entière, il ne peut pas s'éxécuter tout seul mais uniquement avec un programme.

DEFINITION: Un thread est une lot d'instructions sequentielles contrôlé par un programme.

SYNONYMES: On trouve parfois dans certains articles se rapportant à la programmation système, ces termes: "lightweight process" ou encore "execution context"; Ce dernier terme étant très spécifique à la programmation système ( C++ ou assembleur).

EXEMPLE CONCRET:

Vous allez me dire, jusqu'ici, j'ai sorti des belles phrase, mais on à rien compris ! Eh bien je vais essayer d'y remédier en vulgarisant un peu le sujet.
Comme je l'explique plus haut, un "thread" est une partie séquentielle d'un programme, une certaine quantité d'instructions qui peut s'éxécuter de manière autonome mais toujours sous le contrôle d'un programme.
Concrètement, que se passe-t-il dans un processeur pendant l'execution d'un "thread" ? Imaginons un processeur "X", car sa marque ou son modèle ne change rien à notre exemple, imaginons un programme "ABC" que le processeur "X" doit éxécuter. Le programme "ABC" présente son premier "thread" au processeur "X", nous appelerons ce "thread" le thread "0", le thread "0" est composé de 10 instructions pour l'exemple:

PROCESSEUR "X"

0-0/ABC
1-0/ABC
2-0/ABC
3-0/ABC
4-0/ABC
5-0/ABC
6-0/ABC
7-0/ABC
8-0/ABC
9-0/ABC
10-0/ABC-éxécution finie !

A chaque étape du fonctionnement du processeur "X" est associé un "thread" (0), avec ses instructions (de 0 à 10), appartenant à un programme (ABC). Le principe est simple à comprendre, mais cette théorie prend toute sa valeur lorsqu'on complique le problème: imaginons un deuxième programme "DEF" qui demande au même processeur l'éxécution d'un "thread" composé lui aussi de 10 instructions:

PROCESSEUR "X"

0-0/ABC
0-0/DEF
1-0/DEF
1-0/ABC
2-0/ABC
2-0/DEF
3-0/DEF
3-0/ABC
4-0/ABC
4-0/DEF
5-0/ABC
5-0/DEF
6-0/DEF
6-0/ABC
7-0/ABC
7-0/DEF
8-0/DEF
9-0/DEF
8-0/ABC
10-0/DEF-éxécution finie !
9-0/ABC
10-0/ABC-éxécution finie !

Résultat: les "thread" sont imbriqués les uns dans les autres et tous ne se finissent pas en même temps car ceci est dû à la différence des instructions utilisées, une instruction d'adressage mémoire prend moins de cycle processeur qu'une comparaison sur 16 ou 32 bits, mais là on rentre dans le domaine de la programmation très avancée.

________________________________________________________________
MULTI-THREADING
________________________________________________________________

Là, ça devient interressant pour l'utilisateur lambda de pc ou autre machine puisqu'on va parler de performance. Le multithreading, c'est le fonctionnement en architecture parallèle de plusieurs processeurs, donc un système de répartition des "thread": Reprenons notre exemple précédent avec l'utilisation d'un deuxieme precesseur "Y":

PROCESSEUR "X" PROCESSEUR "Y"

0-0/ABC 0-0/DEF
1-0/ABC 1-0/DEF
2-0/ABC 2-0/DEF
3-0/ABC 3-0/DEF
4-0/ABC 4-0/DEF
5-0/ABC 5-0/DEF
6-0/ABC 6-0/DEF
7-0/ABC 7-0/DEF
8-0/ABC 8-0/DEF
9-0/ABC 9-0/DEF
10-0/ABC-éxécution finie ! 10-0/DEF-éxécution finie !

Et voilà, les "thread" sont affectés chacun à un processeur différent, ce qui signifie en théorie, un gain de temps multiplié par le nombre de processeurs. Toutefois, le "thread" 0 du programme "DEF" se terminera avant celui du programme "ABC" puisqu'il utilise des instructions moins gourmandes en cycle processeur, comme le démontre le test précédent.
Allez, encore un exemple pour bien cerner toutes les finesses d'un système multi-threading:
Le programme "ABC" demande l'éxécution simultanée de deux "thread", nommés "0" et "1" de dix instructions chacun pendant que le programme "DEF" demande l'éxécution d'un "thread" nommé "0", observons:

PROCESSEUR "X" PROCESSEUR "Y"

0-0/ABC
0-1/ABC 0-0/DEF
1-1/ABC 1-0/DEF
1-0/ABC 2-0/DEF
2-1/ABC 3-0/DEF
2-0/ABC 4-0/DEF
3-1/ABC 5-0/DEF
3-0/ABC 6-0/DEF
4-0/ABC 7-0/DEF
4-1/ABC 8-0/DEF
5-1/ABC 9-0/DEF
5-0/ABC 10-0/DEF-éxécution finie !
6-1/ABC
6-0/ABC
7-0/ABC
7-1/ABC
8-1/ABC
8-0/ABC
9-1/ABC
9-0/ABC
10-1/ABC-éxécution finie !
10-0/ABC-éxécution finie !

Aïe ! que se passe-t-il ? pourquoi le processeur "Y" n'a pas été mis plus à contribution pour gagner du temps ? Simple: un "thread" de peut pas être réparti sur plusieurs processeurs car ses instructions s'enchainent dans des parties de mémoires spécifiques à chacun des processeurs. Mais , alors, pourquoi le deuxieme "thread" du programme "ABC" ne s'est-il pas "branché" sur le processeur "Y" ? Là aussi la réponse est simple: les différents "thread" d'un même programme ne peuvent s'éxécuter que sur un seul processeur car avant de pouvoir être traité et executé par un processeur, un programme se voit attribué une zone de mémoire. Cette zone de mémoire est vérrouillée par le processeur qui va éxécuter le programme pour empêcher l'autre processeur d'y accèder, faute de quoi, c'est le crash du système assuré !

Heureusement certains programmes peuvent accèder à plusieurs processeurs en même temps, en se faisant passer pour plusieurs programmes, donc avec des "thread" bien distincts, ces programmes bénéficient donc de toute la puissance des deux processeurs. Pour l'exemple, on peut citer des soft comme "Discret /3DS max, Adobe /After Effect, e-on software /Vue d'Esprit", la liste est très loin d'être complète, on en compte des centaines voir plus...
Quel est le gain de performance ? il est d'environ de X 1.6 à X 1.84 selon les systèmes et les architectures pour le dual-processing (2 processeurs, le plus repandu).
Pourquoi pas un gain X 2 ? Il ne faut pas perdre de vue que le ou les processeur(s) ne gère(nt) pas que des "thread" émits par des programmes utilisateur, il y a aussi les programmes résidents ou TSR (Terminate and Stay Resident) induits par le système, ceux sont en grande partie les fameux "drivers" de périphériques, il y a les interruptions système comme les appuis clavier ou les mouvement souris, l'imprimante, les accès disques, le bus PCI et là encore j'en oublie une grand partie !
Pour information les sytèmes multi-processeurs existe en 2, 4, 8, 16?, 32 voir 64 processeurs !
En fonction des système et des types de processeurs, la gestion des "thread" à l'interieur de ces derniers peut varier, surtout sur le système d'attribution des "priorités" à chaque "thread"...

Termes à retenir: pour deux processeurs, on emploi le mot de DUAL-PROCESSING (DP) ou BI-PROCESSING (en français et en France uniquement), pour 4 et au-delà, on dit MULTI-PROCESSING (MP), sur des PC, le système de répartition des "thread" le plus répandu et le SMP (pour Symmetric Multi Processing) ou chaque processeur possède une priorité égale dans le traitement des tâches.

Il nous reste à voir une dernière technologie en la matière: "l'hyper-threading"...

_____________________________________________________________
HYPER-THREADING
_____________________________________________________________


Cette technologie, qui vient, depuis quelques mois, d'être introduite par La société INTEL, est spécifique à une serie de processeur: les IA-32, basé sur la micro-architecture NetBurst, le seul connu chez nous, à l'heure où j'écris cet article est le Pentium 4B cadencé à 3.06Ghz.

Faute d'en posseder un, pas de test possible, mais juste une explication théorique du fonctionnement:
La technologie hyper-threading rend possible l'execution simultané de deux "thread" dans un seul processeur "physique". Celui ci est en réalité composé de deux processeurs "logiques" qui possèdent chacun leurs propres registres (adressage, donné, controle, segment et debugage) ainsi que leur propre controleur programmable d'interruptions (APIC). Désolé pour les termes barbares ! toutefois, ces deux processeur "logiques" doivent partager le coeur du processeur, composé du moteur d'instruction (core+execution engine), les caches, l'interface avec le bus système et le bios !
Toute personne connaissant bien le fonctionnement d'un système avec deux "vrai" processeurs, comprendra dans la description précédente, les limitation d'une telle architecture.

Les "threads" et l'hyper-threading:
Revennont au fonctionnement même de l'hyper-threading, comme dans un sytème à deux processeurs "physiques", les "thread" sont répartis vers les deux processeurs "logique" (je rappelle qu'il s'agit en fait d'un seul processeur "physique"). Je reprends l'exemple de deux programmes avec un "thread" chacun:


PROCESSEUR "X" et "Y" (partageant le même moteur d'instruction donc travaillant l'un après l'autre: défaut majeur de l'hyper-threading !)

0-0/ABC
0-0/DEF
1-0/DEF
1-0/ABC
2-0/ABC
2-0/DEF
3-0/DEF
3-0/ABC
4-0/ABC+4-0/DEF
5-0/ABC
5-0/DEF
6-0/DEF+6-0/ABC
7-0/ABC+7-0/DEF
8-0/DEF
9-0/DEF
8-0/ABC
10-0/DEF-éxécution finie !
9-0/ABC
10-0/ABC-éxécution finie !

On remarque immediatement que les instructions 4, 6 et 7 on pu être "combinées" ensemble au sein d'un même cycle processeur pour gagner du temps, on se retrouve donc dans un système à mi-chemin du mono processeur et du bi-processeur.
Limite de la technologie: Malheureusement, le gain obtenu par la méthode d'imbrication des instructions issues de differents "thread" est aléatoire car les imbrication ne sont pas toujours possibles surtout lorsqu'il s'agit de "thread" issus de deux programmes distinct dont les instructions arrivent au processeur de manière quasi-aléatoire. Les seuls programmes à bénéficier d'une imbrication maximum et donc d'une accélération maximum par rapport à un seul processeur sont ceux écris avec le jeu d'instruction IA-32, mais à ce jour, j'en connais aucun, mais il y a fort à parier que les patches et mises-à-jour vont arriver dans les mois à venir...

Note de l'auteur: Cette technologie n'en étant qu'à son début et la conccurence s'apprêtant à sortir une technologie équivalente, je considère cet article non terminé, d'autre essais doivent avoir lieu, notament avec l'hyper-threading + un soft developpé scécifiquement afin de connaitre le niveau d'imbrication maximum possible des instructions.

Remerciement: Tous ceux qui ont lu l'article du début à la fin (et de manière sequentielle, comme des bons petits thread .) Merci également à Babel, modérateur sur le forum du repaire, pour m'avoir demandé de le faire, sinon, cet article n'existerait pas. Merci également à mon chef qui n'a pas été capable de me griller pendant que j'écrivais cet article au lieu de bosser !

Trophy. (repairnaute-humoriste)

 

Merci XY/DEF fois

Une question toutefois (pour commencer)... et j'éspère que je ne vais pas froisser ton boss ,

Hyperthreading: le gain semble se faire sur les opérations que l'on peu combiner... quel est la particularité de ces opérations combinables par rapport à celle qui ne le sont pas. Sont-elles "courantes" dans un programme / un thread ?


Une remarque: les exemples parle de situations particulières où les threads démarrent au même moment (quand il y en a plusieurs). J'imagine que ce n'est pas le reflet de la réalité (j'imagine que c'est pour faciliter l'exemple... si c'est bien ça.. glisse le quelque part)
Par ailleurs je suis curieux de savoir quel est le nombre de threads traité par 1 proc à la fois en moyenne (ordre de grandeur 1... 10... 100... 1000?. Quand je dis à la fois, je veux dire.. à un moment x... combien de thread sont en cours. Et combien de thread sont lancé par 1 même logiciel... première par exemple... toujours en terme d'ordre de grandeur


Allez bon boulot.

 

Pour les threads: leur nombre est théoriquement infini mais voici un détail sur leur fonctionnement:

si tu est sous Win XP, fais Ctrl + Alt + Suppr, tu ouvres ainsi le gestionnaire de tâche, sous l'onglet "performance", tu peux voir le nombre actuel de thread, handles et processus...
...chez moi, à cet instant il y a 334 thread et 28 processus, cela signifie que mes 28 processus sont en train de tourner et qu'ils ont généré 334 threads, le proc les traites les uns derriere les autres comme si ils faisaient la queue. En fait c'est pas absolument exact, puisqu'un thread peut avoir une priorité et passer devant les autres (windows traite SES thread en priorité, on est jamais mieux servi que par soi-même !).

Pour un thread "normal", sans priorité spéciale, passe un fois toute les 334 fois dans le proc' ou disparait si son code et obsolète et est remplacé par un autre thread du même processus ou encore est remplacé par un thread d'un autre processus, si le processus précédent a disparu...


Si tu lances 35 programmes en même temps sur ton PC, il vont générer des milliers de thread, donc ils mettront d'autant plus de temps à être traité, il y a engorgement du cache mémoire L1 (pre-traitemement des instructions) voir dans le L2, voir pire dans la RAM ! à ce stade, ton PC est quasi-bloqué, toutefois si tu patientes et arrives à reprendre la "main" pour fermer les programmes , tu peux théoriquement récupérer ton PC, mais j'ai bien dis "théoriquement", car en principe l'invasion du cache L2 est fatal à la stabilité du système.


Départ des thread:
Sur un sytème classique à un processeur, les threads s'enchainent dans le proc' les uns derriere les autres, parfois imbriqués sur leur longueurs mais rarement plus de deux threads à la fois, l'exemple typique est celui du post original "un processeur / 2 threads" (c'est la réponse à ta question: imbrication(sur la longueur) à un instant X: 2 voir 3 thread).

Sur un système à deux processeurs parrallèles (ou "symmetric"), les threads partent en même temps simplement à cause de l'architecture de la carte-mère: les deux proc' ont le même cadencement, dont le signal est donné de manière synchrone ils sont donc synchronisés en permanence, ce qui simplifie les accès RAM et le partage des thread...

Operations (instructions) combinables avec l'hyper-threading:
il arrive que des instructions soient combinables par le simple fait du hasard (elles arrivent en même temps dans le coeur du proc, le moteur d'instruction ou interprêteur) , le plus souvent il s'agit d'opérations mathématiques simples, les multiplications sont combinables si le resultat et inferieur à un chiffre équivalent à 32 bits à cause des "registres". Les divisions, additions et soustractions peuvent également être traitées simultanément.
C'est pour cette raison qu'on soft de type AE ou 3DSmax, avec une intégration des instructions IA-32 (hyper-threading) permettrait d'obtenir un taux d'imbrication maximum et donc un gain de temps dans le traitement des données.

Que permet le mystérieux jeu d'instruction IA-32 ?
Plusieurs choses, plusieurs options de fonctionnement du proc':
- Un mode "attente" ou le deuxieme proc' "logique", si il tombe sur une opération imbricable, stoppe son fonctionnement jusqu'a ce que le premier tombe aussi sur une instruction du même type, alors ils imbriquent les deux instructions et repartent...
-Des instructions complémentaires permettent de "prédire" combien de temps un proc' doit attendre pour que sont homologue tombe lui aussi sur instruction imbricable, en allant voir simplement dans le cache L1. Il est parfois rentable en terme de temps de ne pas attendre, si l'instruction complémentaire est trop loin...
-Un mode "regroupement" permettant de stocker plusieurs instructions imbricables, de les traiter simultanément et de reprendre les instructions non imbricables et ainsi de suite...

En fait, chaque programmeur pourra construire sa stratégie d'imbrication, en plus du mode classique est déjà utilisé: le hasard !

Précision: AE et 3DSmax, à ce jour sont optimisés pour un fonctionnement multi-processeurs et rendu en reseau, je ne suis pas sûr que Adobe ou Discreet sortent une version "hyper-threading" de leur soft...

Ces précisions sont pour ton information, puisque tu me poses des questions interressantes sur le sujet (c'est pas souvent que je les entends, celles-là ) !

Je vais en intégrer une grande partie dans mon article original, qui sera un peu remanié pour l'occasion, de façon à ce que le plus grand nombre en profite.

Si t'as d'autres questions sur le sujet, dont les réponses méritent de figurer dans l'article final, faut pas hésiter !