Le Blog du Poilu

Et si on vous expliquait simplement le principes des CPU multi-coeurs ?

La question revient régulièrement : C’est quoi un CPU bi ou quadri-core ? De plus, la même question amène souvent à une mauvaise interprétation du principe, qui est de dire qu’un Bi-coeur de 2.5Ghz (par ex) est équivalent à un Mono-coeur de 5Ghz (on multiplie la fréquence par le nombre de coeurs). Pour les nantis et les habitués ça peut faire sourire, mais pour qui n’a pas la moindre idée de comment fonctionne un CPU la réflexion n’est pas si idiote.

Récemment la question a été posée sur un forum et j’ai alors improvisé une explication de vulgarisation pour tenter d’expliquer la chose. Il semblerai que l’explication ai été satisfaisante. Ce pourquoi j’ai décidé de la développer ici pour en faire profiter d’éventuels âmes perdues en quête de choses simples à comprendre.

Et si vos programmes étaient des voitures…

…et le CPU la route qu’elles utilisent.

Pour comprendre les apports et limitations d’un CPU multi-coeur rien ne vaut une bonne vieille métaphore. Et comme souvent, la question peut-être traité grâce à des petites voitures.

Prenez le cas des autoroutes, et des véhicules qui l’empruntent. Imaginez maintenant que sur cette autoroute les véhicules circulent tous à la même vitesse qui est une valeur fixe, en étant tous à la suite l’un de l’autre. Dites vous que l’autoroute représente le CPU, et les véhicules les données à traiter. La puissance du CPU étant représentée par le temps qu’il faut à un véhicule pour aller du début à la fin de cette route, plus exactement par le temps nécessaire à ce qu’un ensemble de véhicules fasse ce trajet. Car l’exécution d’un programme ne se résume jamais au seul traitement d’une donnée esseulée, mais par une multitude.

En théorie.

Pour comparer un CPU mono-core à un CPU Bi-core il suffit de comparer une autoroute ayant une seule voie de circulation, à une autre en ayant deux.
Admettons que l’autoroute simple permette aux véhicules de circuler à 200km/h, mais que l’autoroute double les limite à 100km/h. Cet exemple simple va permettre de comprendre qu’un CPU bi-core à 2.5Ghz n’est pas forcement équivalent à un CPU de 5Ghz.

On assimile bien le fait que sur l’autoroute à deux voies les données vont moins vite et que le temps mis par un véhicule pour passer du point A au point B sera moitié moindre sur l’autoroute simple, dans ce cas le CPU bi-core est clairement défavorisé du fait de sa vitesse inférieure. Mais, comme je disais au-dessus, un programme ne se résume pas à un seul véhicule. Si on considère un ensemble de données, ce qui compte c’est le résultat de la globalité. Et si l’on doit faire transiter 100 véhicules alors, mathématiquement parlant, les choses s’équilibrent. En effet, l’autoroute double pouvant faire passer deux véhicules en même temps là où l’autre n’en fera passer qu’un seul on peut se dire que ce doublement de trafic permet de compenser la vitesse inférieure de moitié. Oui, à une condition: que la distance séparant chaque véhicule soit la même dans les deux cas (nous verrons plus loin que c’est loin d’être toujours le cas), et bien sûr que les véhicules soient identiques (même longueur). Dans ce cas on arrive effectivement à un résultat similaire pour les deux. Le CPU bi-core compensera sa vitesse réduite par la possibilité d’envoyer des données en parallèle.

Ceci est un cas d’école, le cas idéal si je puis dire. Mais d’une certainement manière on comprend aussi que parallélisme et vitesse ne sont pas forcément lié. Ainsi dans l’absolu le mieux ça reste une autoroute à plusieurs voies où les véhicules peuvent circuler vite. Mais vu que techniquement il devient difficile d’augmenter la vitesse des véhicules (c’est même encore plus difficile dans le cas d’une autoroute à voies multiples) la tendance actuelle est d’augmenter le nombre de voies de circulation.

En pratique.

Dans la réalité des faits les données à traiter sont bien souvent liées entre elles, et il est difficile de faire emprunter une voie différente à des données qui sont liées. Là c’est la programmation qui compte, c’est au développeur de jouer le rôle d’aiguilleur et de faire en sorte qu’un maximum de voitures puissent être envoyées en parallèle. Mais bien évidemment, plusieurs programmes peuvent utiliser les voies multiples pour faire passer leurs données de manière simultanées. C’est comme si une voie faisait passer des voitures de marque X et l’autre voie des voitures de marque Y. Dans le cas de la voie double chaque voie est dédiée à une marque, une autoroute simple se verrait obligée de mélanger les voitures des deux marques, avec entre chaque changement de marque, une perte de temps supplémentaire inhérente à ce changement. Pour le transit de véhicules de marques distinctes en même temps, les voies multiples sont donc l’idéal, chacun profitant pleinement de la vitesse possible sur l’autoroute, sans devoir attendre son tour.
Qui plus est, en cas d’embouteillage sur une voie, toute l’autoroute ne sera pas bloquée, les autres voies seront encore capables de faire circuler des véhicules. Ces cas arrivent lorsqu’un programme se bloque et/ou s’accapare l’intégralité des ressources du CPU, comme s’il se réservait l’usage exclusif d’une voie de circulation.

Mais revenons à notre aiguilleur : Malheureusement pour nous, le boulot est énorme pour celui-ci. Car rares sont les applications naturellement douées pour utiliser le parallélisme.
Il faut se dire que bien souvent une donnée a besoin du résultat d’un calcul précédent pour pouvoir être traitée. C’est comme si un véhicule ne pouvait s’engager sur une voie qu’à l’expresse condition qu’un autre ai déjà fini son trajet, afin de signaler au suivant quelles sont les conditions de route. Donc il s’agit pour le développeur d’arriver à séparer les traitements au maximum, faire le tri dès la programmation de ce qui peut être envoyé sans attendre et ce qui nécessite un résultat précédent. Cela ne suffit pas toujours, bien sûr. Chaque coeur d’un CPU est autonome avec ses propres unités de traitements, ses propres registres. Chaque voie dispose ainsi de ses propres échangeurs, stations services et gares de péage. Le seul moyen de passer d’une voie à l’autre est de sortir de l’une, emprunter le réseau secondaire, puis accéder à l’autre voie. Le réseau secondaire est matérialisé par les caches L2 partagés entre les coeurs des CPU type Intel Core 2 Duo, ou L3 sur les récents AMD Phenom. Pire, les actuels CPU quadri-core d’Intel sont en fait deux autoroutes double-voies mises côte-à-cote. Dans ce cas, pas de cache Lx, et donc pas de réseau secondaire. Il faut emprunter les petites routes départementales: c’est à dire passer par le FSB, et la RAM pour changer de double-voie. Grosse perte de temps en perspective ! Mais ces cas sont relativement rares et ces CPU n’en souffrent que très peu au final.

D’autres limites.

Là on touche à une autre limitation des CPU multi-coeurs: L’approvisionnement en données.
En effet, pour que le flot de véhicules soit régulier et ininterrompu, il faut que les voies d’accès à l’autoroute permettent d’y faire rouler sans encombre tous les véhicules. C’est ce qu’on appel le FSB (Front Side Bus). Je vous épargne les détails, d’autant plus que le principe du FSB est légèrement mis à mal par les processeurs AMD ayant un contrôleur mémoire intégré, il reste tout de même un bus de données pour faire venir celles-ci à bon port.
Il faut savoir que plus on s’éloigne de l’autoroute et plus les temps de trajets seront long. Ainsi pourrait-on comparer la RAM (mémoire centrale) à une ville construite à une encablure de l’autoroute (avec ses restos routiers, etc.), alors que les disques durs et autres lecteurs optiques sont les petits villages au fin fond de la campagne. Le disque dur est à l’informatique ce que Vesoul est au monde urbain : un endroit où il nous faut trois plombes pour y aller, quelque soit la route empruntée. La RAM pouvant plus se comparer à toutes les banlieues en bordure du périphérique parisien, il suffit parfois de quelques centaines de mètres pour entrer dans Paris.

Revenons à notre autoroute. Déjà on aura compris que plus on va chercher loin les données plus elles mettrons de temps à arriver. Le problème principal des CPU multi-coeurs, c’est qu’ils n’ont qu’une seule route permettant d’y aller. Imaginez une autoroute de 16 voies où les limitations de vitesses seraient au-delà du 200km/h… mais que pour y accéder vous êtes obligés de passer par une route départementale limité à 90km/h, sans possibilité de doubler. Pire: une fois arrivé au bout de l’autoroute c’est le même type de petite route qui vous attend.
On sent bien qu’il y a comme un gros problème là!

Bon, tout n’est pas aussi catastrophique. D’abord la RAM joue parfaitement son rôle, grâce à la vitesse à laquelle on peut accéder à la route depuis les banlieues on perd moins de temps. Mais ça ne résous pas tous les problèmes d’engorgements (je vois 2-3 parisiens qui hausse le sourcil au fond…).
Là il n’y a pas de miracle: D’une part la tendance reste à l’augmentation de la vitesse de transit intermédiaire. Dans la pratique c’est le FSB (ou l’équivalent) dont la fréquence va augmenter. Ce, afin de mieux pouvoir alimenter le CPU en données et éviter que celui-ci n’attende, ou mouline dans le vide. Ensuite les mémoires cache présentent au sein même du CPU sont là pour éviter justement d’avoir à trop devoir chercher les données à l’autre bout du monde. Le cache intégré au CPU tourne à la même vitesse que celui-ci, les données y sont donc quasi-immédiatement accessibles (à quelques poils de mammouth près). Enfin, des techniques de pré-chargement opèrent tout le long du processus. Ces techniques sont mises en oeuvres directement par le CPU qui va tenter de deviner quelles sont les données dont il va avoir besoin dans les prochains calculs, sans attendre les résultats précédents pour confirmation. Ainsi peut-il aller chercher les véhicules dont il va avoir besoin, les placer sur une aire de stationnement et les envoyer sur l’autoroute dès que ce sera leur tour.

Il faut dire qu’à ce petit jeu, les dernières générations de CPU sont plutôt douées. On parle de taux de prédictions fiables proche du 95% (C’est pas Paco qui pourrait en faire autant!). Et il vaut mieux que cela soit fiable, car en cas de loupé c’est tout le monde qu’il faut faire dégager de la voie de circulation, des accès et des routes alentours, tout ça pour finalement aller chercher la bonne voiture là où elle se trouve. En espérant que celle-ci soit à Chaville et non à Vesoul…
Notre petit aiguilleur de tout à l’heure peut malgré tout apporter sa contribution. En programmant son logiciel pour qu’il mette le maximum de monde en banlieue plutôt que de tout laisser en Auvergne, au risque de devoir faire moult allers-retours coûteux.

Le système d’exploitation

Souvent pointé du doigt (du moins essentiellement quand il s’agit de Windows) pour une soit-disant mauvaise gestion des multi-coeurs, le système d’exploitation a aussi son mot à dire dans tout ça. C’est lui qui va collaborer avec le CPU pour gérer les files d’attentes pour accéder à l’autoroute. Et surtout qui va décider qui va utiliser quelle voie. L’ordonnanceur du système est le gendarme de la route. C’est lui qui décide quelle application va accéder aux ressources à tel instant.
Qu’on se le dise, tous les systèmes d’exploitations, Windows y compris, sont parfaitement à l’aise avec des machine à coeurs multiples.

Un petit mot sur les machines à plusieurs CPU

Le Bi-CPU (et plus) existait bien avant l’avènement des CPU multi-coeurs. si ces derniers ont du « retard » par rapport au concept, c’est uniquement pour des raisons technologiques. Il était jusqu’à présent quasiment impossible de faire tenir deux CPU (ou plus) sur un même support. Après tout, combien de temps s’est-il écoulé entre la construction du premier tunnel, et l’ouverture du tunnel sous la Manche ?

Quelle différence entre ces deux concepts ?

Jusqu’à présent on parlait de CPU ayant plusieurs coeurs, ce qui consistait en fait à avoir plusieurs CPU sur le même support, la même plaquette, avec une seule connexion au reste de la machine. Maintenant il s’agit d’associer des CPU tout ce qu’il y a de plus traditionnels, dans une seule machine. Cela implique une machine spéciale. car il faut plusieurs supports pour pouvoir y placer les CPU.

Du point de vue de l’usage pur et dur, des logiciels, de l’utilisateur et du système d’exploitation, les deux solutions sont au final extrêmement similaires. En matière de performances pures on a de l’avantage des deux cotés. Le multi-coeur peut avancer le fait d’avoir un lien interne entre ses coeurs (mémoire cache) pour accélérer les échanges de données. L’autre répliquera en montrant son FSB propre à chaque CPU. Il a même une zone RAM dédiée à chaque CPU. Pas de partage ici, chacun le sien mais surtout chacun aura un usage exclusif de ce à quoi il a accès, contrairement au bar d’en-face où l’on partage tout.

Si le Bi-CPU ne s’était jamais vraiment imposés chez le particulier c’est essentiellement due à sa complexité de mise en oeuvre : Deux CPU ça coûte … deux fois plus cher qu’un seul. D’autant plus qu’on nous vendait (et on nous en vend toujours) des CPU « spéciaux » soit-disant dédiés à ce type de montage, alors qu’ils sont à peine différents de nos CPU de machine de bureau, excepté le prix à la hausse. Il faut aussi la carte mère, plus rare et donc beaucoup plus chère. Ajoutons un doublement de la quantité de RAM, pas toujours aussi bon marché qu’aujourd’hui.
Viennent enfin les problèmes liés au refroidissement, à la consommation électrique… et au prix d’une licence Windows qui est fonction du nombre de CPU pour les versions serveurs, tandis qu’il faut obligatoirement une version « Professionnel » pour les machines de bureau.
Mettre en place une machine Bi-CPU à l’époque c’était comme vouloir tracer une autoroute en haute montagne. Le Multi-coeur balaie d’un trait tous ces inconvénients, car il a tous les avantages du CPU unique (un seul support, etc.) avec une grande partie des avantages du Bi-CPU. C’est quand même plus facile de construire une autoroute en rase campagne, vous ne pensez pas ?

Mais les deux ayant des avantages (en terme de performances pures), on en est arrivé au stade où les machines Bi-CPU d’avant sont devenues des machines Bi-CPU avec des CPU multi-coeurs. Donc au lieu d’avoir deux CPU distincts, ou un CPU ayant deux ou quatre coeurs (en attendant les octo-coeurs, et plus), il existe des Bi-CPU de Bi-coeurs, voir de quadri-coeurs!
Vous imaginez un peu la largeur de l’autoroute ! Cela reste pour l’instant réservé aux machines d’exceptions, aux traditionnels serveurs et super-calculateurs qui sont ceux ayant le plus l’usage d’une augmentation massive du nombre de voie de circulation.

Fin du voyage

Il est temps de quitter la route et de profiter un peu du paysage. Maintenant que vous avez (j’espère) mieux compris comment fonctionne dans le principe nos CPU modernes (le CPU simple coeur étant en voie de disparition) vous appréhenderez mieux le trajet retour, ainsi que les prochains voyages aux destinations exotiques que nous réserve l’informatique de demain.