PrécédentSommaire

On en remet une couche

Les microprocesseurs actuellement les plus perfectionnés qui utilisent l'exécution dans le désordre ont fait apparaître une difficulté. Quand les unités de traitement sont multipliées, il n'est pas possible de les employer de façon optimale parce que les possibilités de parallélisme sont quand même limitées par des dépendances entre les instructions (mais cela ne vient-il pas en partie des compilateurs qui traduiraient les sources des programmes en se cantonnant à un instant donné dans une "fenêtre" trop réduite ?). En temps normal les 3 instructions par cycle d'horloge sont difficilement atteintes.

L'une des options trouvées pour la prochaine étape (il n'est pas question de gaspiller les millions de transistors ajoutés ou de stagner) s'appelle le simultaneous multithreading. L'idée est de faire fonctionner en parallélisme réel plusieurs processus indépendants qui occupent au mieux les unités à chaque cycle. Il peut par exemple y avoir 2 instructions de la première tâche, 1 de la deuxième, 2 de la troisième… à traiter à un instant donné. Ce sont donc plusieurs threads qui sont susceptibles d'être commutés si un plus grand nombre sont en cours d'exécution sur le processeur. Un mécanisme tenant compte des différentes causes possibles de ralentissement doit être utilisé pour dispatcher dynamiquement les instructions des n processus simultanés. Des modélisations réalisées montrent qu'une moyenne de plus de 6 instructions par cycle d'horloge peut être atteinte avec un circuit ayant 10 unités de traitement.

Le simultaneous multithreading se révèle plus efficace que les architectures à plusieurs processeurs comportant une même capacité de calcul globale parce que l'on peut tirer parti aussi bien du parallélisme au niveau des instructions d'une séquence que de celui entre les différents processus, et ceci à chaque instant. Différentes applications indépendantes peuvent cohabiter ainsi mais pour qu'une seule atteigne des performances maximales il faut qu'elle soit séparée en plusieurs threads concurrents, donc faire appel à un compilateur qui parallélise les programmes ou se reposer sur les développeurs (toujours les mêmes).