Le mul­ti­threa­ding : plus de puissance pour les pro­ces­seurs

Les ap­pli­ca­tions et les jeux modernes posent des défis toujours plus grands au niveau du matériel. Outre les gra­phiques par­ti­cu­liè­re­ment so­phis­ti­qués et les exigences énormes en matière de mémoire, la vitesse du cœur du pro­ces­seur doit rester par­ti­cu­liè­re­ment im­por­tante pour un travail fluide avec un PC ou un or­di­na­teur portable. Pour relever ces défis, les fa­bri­cants de matériel in­for­ma­tique dé­ve­lop­pent ré­gu­liè­re­ment de nouvelles tech­niques et ar­chi­tec­tures pour leurs pro­ces­seurs. L’une de ces tech­niques est le mul­ti­threa­ding. Ici, le pro­ces­seur parvient à traiter plusieurs threads, une petite unité de calcul, plus ou moins si­mul­ta­né­ment. Comment cela fonc­tionne-t-il ?

Pour augmenter la vitesse des cœurs du pro­ces­seur sans avoir à modifier la vitesse d’horloge, le mul­ti­threa­ding permet au CPU de traiter plusieurs tâches si­mul­ta­né­ment. Pour être plus précis : plusieurs threads sont traités en même temps. Un thread peut être compris comme un élément d’un processus. Les pro­grammes peuvent être divisés en processus et ces processus à leur tour en threads in­di­vi­duels. Chaque processus est constitué d’au moins un thread.

Les processus sont gé­né­ra­le­ment exécutés de manière sé­quen­tielle, c’est-à-dire l’un après l’autre. Ce n’est pas optimal, car de cette manière, les tâches fas­ti­dieuses bloquent le matériel. Si un autre processus est né­ces­saire spon­ta­né­ment, il doit quand même attendre son tour. Avec le mul­ti­threa­ding, plusieurs threads sont traités si­mul­ta­né­ment. Bien que cette af­fir­ma­tion ne soit également que par­tiel­le­ment correcte : la si­mul­ta­néité réelle ne peut que rarement être garantie, mais elle peut être atteinte en attendant.

Mais la pseudo-si­mul­ta­néité permet également d’améliorer les per­for­mances : le système organise et calcule les threads de manière si in­tel­li­gente que l’uti­li­sa­teur a l’im­pres­sion d’un trai­te­ment simultané. Cette forme de con­cur­rence ne doit pas être confondue avec les pos­si­bi­li­tés des pro­ces­seurs multi-cœurs. Si le système comporte plusieurs mi­cro­pro­ces­seurs, plusieurs processus sont également traités si­mul­ta­né­ment.

Pour que le mul­ti­threa­ding soit efficace, le logiciel doit y être préparé. Si les dé­ve­lop­peurs ne divisent pas ou ne peuvent pas diviser leurs pro­grammes en plusieurs threads, la tech­no­lo­gie ne fonc­tion­nera pas. Les joueurs, par exemple, cons­ta­tent souvent une baisse des per­for­mances lorsque le mul­ti­threa­ding est activé. Dans ce cas, les jeux in­for­ma­tiques ne sont pas conçus pour cette tech­no­lo­gie. La tentative du système de traiter plusieurs threads si­mul­ta­né­ment a alors un effet néfaste.

Le but ultime du mul­ti­threa­ding est d’augmenter la vitesse de calcul d’un or­di­na­teur et donc ses per­for­mances. Pour y parvenir, on essaie d’optimiser la charge CPU. Au lieu de maintenir un processus pendant une longue période, le système passe ra­pi­de­ment à la tâche suivante avec le mul­ti­threa­ding, même s’il attend toujours des données. De cette façon, il n’y a pra­ti­que­ment pas de temps d’attente.

En même temps, le système réagit plus ra­pi­de­ment aux chan­ge­ments de priorités. Les uti­li­sa­teurs ou les ap­pli­ca­tions ont besoin d’une autre tâche de manière soudaine et imprévue : grâce aux niveaux de priorité et aux threads courts, le pro­ces­seur peut également se consacrer ra­pi­de­ment à une autre tâche.

Cette tech­no­lo­gie est prin­ci­pa­le­ment conçue pour accélérer les ap­pli­ca­tions in­di­vi­duelles qui se composent de plusieurs processus et threads. De cette manière, plusieurs tâches du même logiciel peuvent être traitées plus ou moins en parallèle. Cela a du sens dans le montage vidéo, par exemple : ici, une scène peut être rendue en arrière-plan pendant que l’uti­li­sa­teur monte la scène suivante.

Grâce au mul­ti­threa­ding, les fa­bri­cants de puces ont la pos­si­bi­lité d’accélérer leurs pro­ces­seurs sans générer une con­som­ma­tion d’énergie beaucoup plus élevée. Alors que des fré­quences d’horloge plus élevées génèrent également plus de chaleur, qui doit ensuite être dissipée à grands frais, ce n’est pas le cas avec le mul­ti­threa­ding.

Le mul­ti­threa­ding résulte d’une in­te­rac­tion entre le matériel et le logiciel. Les pro­grammes et les processus sont dé­com­po­sés en threads in­di­vi­duels et traités par l’unité centrale dans ces unités plus petites. Une dis­tinc­tion est faite entre le mul­ti­threa­ding matériel et le mul­ti­threa­ding logiciel.

Pour le mul­ti­threa­ding matériel, les pro­grammes in­di­vi­duels four­nis­sent leurs processus divisés en threads. Le système d’ex­ploi­ta­tion prend en charge la gestion des threads et décide du moment où le thread est transmis en premier au CPU. Le pro­ces­seur traite ensuite les threads soit si­mul­ta­né­ment, soit pseudo-si­mul­ta­né­ment.

Dans la pratique, on peut trouver dif­fé­rentes réa­li­sa­tions du mul­ti­threa­ding basé sur le matériel.

Le SoEMT (pour « Switch on Event Mul­ti­threa­ding » en anglais) fonc­tionne avec deux threads : l’un est au premier plan et l’autre à l’arrière-plan. Le chan­ge­ment de niveau, appelé chan­ge­ment de contexte, s’effectue par le biais d’évé­ne­ments. Il peut s’agir, par exemple, d’une entrée uti­li­sa­teur, mais aussi d’un message indiquant qu’un thread est toujours en attente de données et ne peut donc pas être traité plus avant. Le système passe alors ra­pi­de­ment au deuxième thread et relègue l’autre à l’arrière-plan. Le trai­te­ment de ce thread ne se poursuit que lorsque les in­for­ma­tions requises sont arrivées. De cette manière, le système réagit ra­pi­de­ment et crée une pseudo-si­mul­ta­néité entre les threads au premier plan et en arrière-plan.

Le « mul­ti­threa­ding temporel » est également appelé « mul­ti­threa­ding à gros grains ». On parle de « gros grain » parce que cette technique est plus adaptée aux temps d’attente plus longs. Alors que d’autres tech­niques réa­gis­sent encore plus ra­pi­de­ment, le SoEMT joue sur ses points forts avec des blocs de threads plus im­por­tants.

Alors que le SoEMT déclenche le passage d’un thread à l’autre par un événement, avec le « Time-Slicing », cela se produit à des in­ter­valles de temps fixes. Même si le thread n’est pas encore terminé, le pro­ces­seur en calcule un autre et ne revient qu’à l’in­ter­valle suivant pour continuer à tra­vail­ler sur le thread. Toute pro­gres­sion sur un thread est en­re­gis­trée en mémoire.

Le défi consiste à choisir la longueur ap­pro­priée de l’in­ter­valle. Si l’in­ter­valle est trop court, les processus ne peuvent guère pro­gres­ser de manière sig­ni­fi­ca­tive. Si l’in­ter­valle est trop long, en revanche, on perd la pseudo-si­mul­ta­néité. En tant qu’uti­li­sa­teur, on remarque alors que les processus sont traités les uns après les autres et non en parallèle.

La tech­no­lo­gie mul­ti­threa­ding SMT (« Si­mul­ta­neous Mul­ti­threa­ding » en anglais) assure une réelle si­mul­ta­néité. Les threads attendent leurs calculs dans ce qu’on appelle des pipelines. Le pro­ces­seur traite plusieurs pipelines en parallèle. Ainsi, au lieu de passer d’un thread à l’autre, les parties des processus sont en fait traitées si­mul­ta­né­ment. Un seul pro­ces­seur se comporte comme plusieurs pro­ces­seurs (logiques). Dans la pratique, le SMT est combiné à la tech­no­lo­gie multi-cœur : ainsi, un système doté de deux cœurs de pro­ces­seur peut ap­pa­raître au monde extérieur comme s’il possédait huit cœurs.

Avec le mul­ti­threa­ding côté logiciel, seule l’ap­pli­ca­tion est res­pon­sable de la division des processus en threads. Seuls les threads in­di­vi­duels arrivent au système d’ex­ploi­ta­tion et au pro­ces­seur. Ainsi, dans ce scénario, le matériel n’est même pas conscient des con­nexions et traite chaque thread in­di­vi­duel­le­ment. Le système définit un niveau de priorité pour chaque thread. Les niveaux plus élevés sont traités plus ra­pi­de­ment. Les nouveaux processus qui doivent être terminés ra­pi­de­ment peuvent être in­ter­ca­lés avec cette technique. Dans le cas du processus à long terme, un seul thread est terminé et les threads suivants se re­trou­vent plus loin dans la fil d’attente.

Bien que ces deux tech­no­lo­gies puissent sembler si­mi­laires à première vue, le mul­ti­tâche et le mul­ti­threa­ding reposent sur deux idées dif­fé­rentes. En principe, le mul­ti­tâche signifie seulement que plusieurs pro­grammes fonc­tion­nent en même temps. L’unité centrale passe d’une tâche à l’autre. Cependant, les ap­pli­ca­tions ne sont pas calculées si­mul­ta­né­ment, ni en même temps ni en pseudo-simultané. En règle générale, le système d’ex­ploi­ta­tion prend en charge l’or­ga­ni­sa­tion des dif­fé­rentes tâches et attribue les processus en attente à l’unité centrale. Pour l’uti­li­sa­teur, il semble que plusieurs pro­grammes soient traités si­mul­ta­né­ment, mais en fait ils sont toujours alternés.

Le mul­ti­threa­ding vise un degré de si­mul­ta­néité plus élevé. Toutefois, cette technique cherche avant tout à accélérer les pro­grammes in­di­vi­duels. Alors que le mul­ti­tâche permet à dif­fé­rents pro­grammes de fonc­tion­ner côte à côte, les threads in­di­vi­duels du mul­ti­threa­ding pro­vien­nent d’un même programme. Le trai­te­ment simultané de ces sections du processus permet alors au logiciel de fonc­tion­ner plus ra­pi­de­ment.