Processeurs multicœurs : vers un plafond de verre ? |
————— 29 Septembre 2020 à 16h12 —— 26235 vues
Depuis Bulldozer, mais plus encore avec Zen - Zen 2 en étant l'apogée - AMD a prouvé que la puissance des processeurs pouvait passer par un nombre de cœurs en forte hausse. Alliée à la technologie des chiplets, les puces ainsi produites ont dévoilé un rapport performances / prix ahurissant, bien que les prestations restaient, aux débuts, encore inférieures en jeu. Tant bien que mal, Intel s'est joint à la danse en développant à une vitesse remarquable des dies plus volumineux de son architecture Skylake, d'où les multiples refreshs, si bien que les OS, jeux et logiciels actuels auraient bien du mal à revenir à des processeurs moins threadés.
Les cœurs, une arme redoutable
Pourtant, le multicœur était déjà présent sur un autre segment : l'informatique embarquée - comprenez ici les smartphones - dès 2011, avec le Cortex A7 pouvant monter à 8 cœurs big.LITTLE. L'idée ici était de disposer d'unités de calcul plus performantes mais aussi moins économes, et de les allumer / éteindre au besoin. Néanmoins, le choix d'intégration de clusters n'est pas anodin : multiplier les unités logiques permet d'augmenter linéairement la puissance de calcul et la consommation, là où la fréquence fait s'envoler le pompage de Watts quadratiquement. Pour autant, les octocœurs sont toujours majoritaires en notre chère année 2020 : tout n'est donc pas rose.
Hé oui, avoir de la puissance n'est rien sans la maîtrise qui lui est associée, et c'est bien ce qui pêche ici. À intégrer toujours plus de cœurs, beaucoup se retrouvent, finalement, vacants du fait de programmes qui peinent à se paralléliser suffisamment. Outre la limite théorique de la loi d'Amdahl - un programme ne pourra jamais être exécuté plus vite que sa partie séquentielle, avec comme corollaire une inutilité croissante du rajoute des cœurs sur une puce déjà bien testicouillue - les difficultés de programmation se font également sentir dans la pratique, les écosystèmes n'étant pas toujours adaptés à la parallélisation, en particulier quand les langages de programmation restent majoritairement orienté sur un paradigme n'explicitant pas ou pas suffisamment le flot de données.
Pourtant, la tendance - particulièrement sur les SoC mobiles - est à la multiplication des bouzins programmables, mais sous la forme d'accélérateurs dédiés. GPU, NPU (Neural Processsing Unit), IPU (Image Processing Unit), etc : nombreux sont les nouveaux composants utilisant l'espace proposé par la conjecture de Moore (doublement de la densité d'intégration des transistors tous les deux ans) pour proposer des fonctionnalités plus avancées. Qu'en sera-t-il pour notre bon vieux x86 ? Les communications sur Alder Lake et l'hétorogène tendent vers une réponse affirmative. À suivre ! (Source : SemiEngineering)
 | Un poil avant ?FSP annonce de la grosse alimentation, avec ses Hydro PTM PRO 80 Plus Platinum ! | Un peu plus tard ...Comptoiroscope • Mafia et le jeu des 7 erreurs | |
Parce que si il arrive a faire avancer deux threads efficacement, quelque part c'est parce que le coeur à des tas de ressources disponibles qu'il ne parvient à à occuper avec un seul thread. Signe d'un ordonnanceur peut-être pas suffisamment efficace. Du coup en mono, la moitier du coeur se tournerait les pouces
Certes, avec 2 coeurs on peut gagner un peu avec les changements de contexte, mais si on en arrive à observer un temps de réponse (temps d'attente avant la reprise du main thread) en dizaines, centaines voire milliers de millisecondes pour expliquer l'avantage pris dans ces cas "pathologiques", le problème est toujours là avec plus de coeurs, juste masqué.
Au-delà de 2 coeurs on finit par retrouver la même problématique sous une autre forme, et en définitive ça impose de programmer de façon particulièrement abstraite et donc tout sauf optimale. Tous comptes faits, on se retrouve à mal utiliser un OS et des modèles logiciels parfaitement inadaptés, en réalité simplement car le plafond de verre était déjà atteint (il n'y a qu'à voir à quel point ça a piétiné en single thread hors instructions vectorielles/SIMD ajoutées et la retranscription par l'OS lui-même de code rendu obsolète) mais il fallait "innover" pour vendre.