Document:puissance du processeur

Une définition du Jargon Français.
Aller à : Navigation, rechercher

Voici les raisons pour lesquelles l'amélioration des performances d'un unique programme offerte par une machine récente est souvent décevante.

Dans certains contextes la vitesse de traitement dépend de la puissance de calcul (en jargon ce traitement est « CPU bound ») plutôt que d'autre chose (vitesse de l'affichage, performances des disques ou du réseau...). Cela dépend du type de traitement, des données, des machines et logiciels employés.... Sur une machine bien dimensionnée les problèmes dont la vitesse de résolution dépend ainsi avant tout du travail d'un processeur sont en théorie rares, toutefois c'est le cas des belles interfaces graphiques que nous employons quasi tous, du gros des jeux (immense marché) et du HPC (gourmand en machines haut-de-gamme).

Un ordinateur classique ne disposa longtemps que d'une unité d'exécution. Il ne peut simultanément animer deux processus puisque son processeur n'exécute à tout moment précis qu'une seule instruction. Un logiciel dit ordonnanceur accorde par conséquent aux processus, tour à tour, de courts laps de temps du processeur en découpant des « tranches temporelles » afin d'octroyer un peu de temps à l'un, durant lequel le processeur exécute les instructions qui le composent, puis à un autre, puis à un autre... Aucune saccade n'est perceptible car ces tranches sont de courte durée à l'échelle humaine (lorsque tout fonctionne convenablement chaque processus dispose au minimum de plusieurs centaines de tranches par seconde).

C'est un peu comme si les bébés-processus pleuraient : papa-processeur câline l'un durant quelques dizaines de secondes afin de tenter de le calmer, puis court en calmer un autre, et ainsi de suite.

Accélérer en ajoutant une machine complète laisse à désirer car, entre autres, contraint à acquérir du matériel inutile puisque l'on n'a somme toute besoin que d'un processeur plus puissant et, pis, toute communication entre ces processus exécutés sur autant de machines distinctes doit cheminer sur un réseau donc n'est pas aussi rapide que s'ils se trouvaient sur la même (à coût donné un bus est plus performant qu'un LAN).

Le faire en augmentant la fréquence d'horloge du processeur ou la finesse de sa gravure (afin de réduire le chemin que le courant électrique parcourt en son sein, donc les latences) est très difficile pour des raisons relevant de la physique (en résumé: surchauffe, signaux parasites...).

Ajouter plus d'un processeur à la carte mère semble raisonnable, et intégrer plusieurs unités d'exécution dans un seul processeur (composant physique) est encore plus économique.

C'est pourquoi la grande mode des années 2000 chez les fondeurs consiste à augmenter le nombre de cœurs placés dans un même processeur. Cela avait commencé avec le superscalaire dès les années 1960, est revenu à la fin des années 1980 puis s'imposa avec le Pentium et règne depuis le milieu des années 2000.

L'utilisateur en bénéficie chaque fois que plusieurs programmes fonctionnent simultanément car l'ordonnanceur répartit les processus actifs sur autant de cœurs que possible.

Il est par ailleurs souhaitable qu'un nouveau processeur accélère un (seul!) processus car lorsque l'on joue ou analyse des données sismiques peu importe que les programmes en tâche de fond avancent vite, on souhaite surtout que le jeu ou la simulation, donc dans de nombreux cas un seul processus, soient rapides.

Cela complique le problème.

La plus simple solution consiste à bricoler de façon à « pousser la cadence » du cœur sur le moment utile (voir par exemple Intel Turbo Boost).

Une autre consiste à morceler le logiciel de sorte que tous les calculs relativement indépendants les uns des autres soient effectués aussi simultanément que possible, chacun grâce à une unité d'exécution.

Dans un cas idéal tous les pans du calcul progressent ainsi simultanément, en parallèle. Si le programme est un jeu, par exemple, un pan s'occupera de rendre l'image suivante tandis qu'un autre calculera le nouvel état du monde virtuel, en un flot continu.

Morceler ainsi de sorte que plusieurs instances du programme (qui seraient autant de processus) profitent chacune d'une unité d'exécution est tentant, toutefois organiser leurs efforts et les laisser partager des résultats intermédiaires, donc leur ménager un canal de communication, est difficile.

Le plus simple consiste à installer ces pans dans le même espace d'adressage, de sorte que les variables de l'un soient directement accessibles par un autre.

La plus réaliste approche est le multithreading car, du point de vue du développeur, un seul exemplaire du programme fonctionne en mobilisant toutes les ressources de la machine, et il peut en son sein créer des « pans », sous forme d'autant de fonctions qui partageront si nécessaire certaines variables, s'inter-appelleront directement et qu'il peut considérer comme si chacune était toujours active car un thread l'exécutera.

Pour cela le logiciel doit être programmé sous forme de threads (les « pans »). C'est de plus en plus répandu.

Le gain théorique procède du fait que les threads s'exécutent en parallèle donc en utilisant au mieux les unités d'exécutions. En pratique à tout moment certains threads galopent tandis que d'autres attendent des données, par exemple lues/écrites sur une mémoire de masse ou un réseau.

Cela contraint à programmer d'une façon nouvelle, donc entre autres à modifier tout code source existant ainsi que les habitudes des développeurs, d'autant que l'environnement logiciel nécessaire au multithreading est souvent moins mature et le débogage confine vite à l'atroce car ressemble à l'activité du célibataire sans enfant auquel on a demandé de garder une douzaine de pré-ados agités.

Il faut également que le système d'exploitation gère les threads, ce qui est le cas général depuis 2005.

Le multithreading ne résout pas tous les problèmes de ce genre car certains types de traitements s'y prêtent mal voire pas, ou nécessitent de fréquentes synchronisations entre des threads qui réduisent le gain de l'exécution parallélisée.

Une bonne part de l'attention des professionnels concernés porte toutefois sur cela car l'évolution du matériel le rend difficile à éviter.

Direction.png Voir aussi : paralléliser, À propos du traitement.