Intel a annoncé sa technologie Foveros en 2018, quant à ARM, cela fait plus de sept ans que la marque développe des solutions big.LITTLE avec le lancement de ses puces Cortex-A7. En 2017, elle faisait évoluer son concept avec DynamIQ. C’est désormais au tour d’AMD de sortir de ses cartons une architecture dans ce sens.
Le principe est toujours le même, confier des tâche simples à des cœurs de processeurs peu gourmands en énergie et ne réveiller les cœurs les plus performants (mais également les plus gourmands et les plus chauds) qu’au moment opportun. En alliant les deux types de cœurs, on pilote une solution plus efficace sur tous les tableaux.
Cette idée a fait son chemin et après Intel qui l’a reprise, c’est au tour d’AMD de s’y intéresser en mélangeant deux types de cœurs au sein d’un même processeur. Il ne s’agit pour le moment que de brevets et aucune annonce technologique officielle n’a été faite par la marque mais le principe d’une puce « Hétérogène » a été déposé par la marque. Ce qui signifie la compilation d’un ou de plusieurs cœurs à hautes performances et d’un ou plusieurs coeurs à plus basse consommation au sein d’une même solution.
Le présent brevet date de 2017 mais n’a émergé que récemment avant d’être repéré en ligne. Cela ne veut pas dire qu’AMD s’engagera forcément sur cette voie, beaucoup des dépôts de ce type n’ont qu’une vocation légale pour les marques. S’offrant ainsi la possibilité de protéger leurs arrières en montrant leur travail avant qu’une autre société ne leur réclame des royalties sur un concept. Il semble en tout cas que cette solution combine le meilleur des deux mondes. Avec un ou des coeurs Zen à très basse consommation associés à un ou plusieurs coeurs plus performants, AMD pourrait construire un processeur proposant une excellente autonomie et des performances élevées en usage sédentaire.
| 2,5€ par mois | 5€ par mois | 10€ par mois | Le montant de votre choix |
C’est la reprise :)
Le problème avec ce type d’architecture c’est que les tâches les plus simples sont en 2020 très consommatrices de ressources. Chez AMD on fait un coup un bon proc (Ryzen) et un autre un terrible (serie A9 – 10). ALors faudra lire les tests et voir si en situation réelle c’est vraiment intéressant.
Le problème quant on essaie de faire cohabiter des processeurs « gros » et des « petits », c’est le jeux d’instructions.
Jusqu’à présent, les processeurs ARMs utilisés en configuration Little/Big ont le même jeu d’instructions. Le même code peut être directement exécuté par tous les processeurs, c’est juste la vitesse qui change.
Sur les x86, où le jeu d’instruction est épais comme l’annuaire, on pourrait être tenté de supprimer des processeurs petits certaines instructions multimédia ou autre (AVX512, x87…) afin de réduire la taille du coeur. Il faudrait alors que l’OS hôte soit capable de basculer automatiquement les tâches utilisant des instructions rares vers le gros processeur… C’est possible, certainement, mais pas trivial.
Actuellement, ds sa tentative de little-big, Intel a désactivé la partie AVX du gros processeur, mais qui est
physiquement présente, ce qui gaspille du silicium, et réduit l’utilité du mélange.
@TREZA: Le problème quant on essaie de faire cohabiter des processeurs “gros” et des “petits”, c’est le jeux d’instructions.
Ça fait un moment (au moins depuis le 486) que les processeurs ne sont plus réellement x86 : les instructions x86 sont interprétées par le frontend en micro instructions. En interne le processeur fonctionne en fait sur une archi simplifiée type RISC, et le frontend se chargeant de faire la conversion du code x86 en micro-opérations réellement interprétables par le CPU. (Pour l’histoire c’est cette partie qui était buguée dans le bug de la division entière du premier Pentium, sur les générations suivantes Intel a ajouté un mécanisme permettant la mise à jour du microcode, pour pouvoir corriger d’éventuels bugs).
Bref ceci étant dit, on pourrait tout à fait imaginer un frontend compatible et des unités très simplifiées côté exécution sur le core little (ex: plusieurs unités d’entier, 1 unité flottante, et pas d’unité vectorielle type SSE). Le frontend se chargerait de convertir le code x86 pour qu’il tourne avec les ALU dispo) Avec ce type de core le code simple courant basé sur des entiers serait très économe, et les parties « optimisées » plus compliquées en MMX / SSE pourrait être traité par le frontend beaucoup plus lentement en étant décomposé par pleins de micro-instructions: Le core little serait très économe mais peu performant sur du code x86 optimisé. À l’inverse le gros core serait énergivore sur du code simple, mais très performant avec du code optimisé.
@fofo
Bon. Je ne vais pas m’énerver… mais l’antienne les x86 ont un RISC à l’intérieur… Non, pas vraiment. D’après le peu de ce qui est connu publiquement, les micro-opérations des x86 ne ressemblent pas vraiment à
des instructions RISC (d’ailleurs il n’y a aucune raison), chaque unité d’exécution a besoin d’un format d’opération différent pour paramétrer ce qu’il faut faire, Intel a essayé de nombreux modes avec même du load/store/execute comme micro-ops… Séquencer des instructions en opérations élémentaires poussées dans un pipeline (ou des unités d’exécution OoO), tous les CISCs l’ont toujours fait, depuis les années 60, avant même que les RISCs ne soient à la mode.
Ce qui était buggé sur le premier Pentium c’était la table de coefficients du diviseur SRT. Un processeur RISC aurait eu besoin la même table, rien à voir avec le microcode.
On peut garder un décodeur complexe et des kilos de microcode sur le petit processeur pour exécuter toutes les instructions multimédia SIMD ultracomplexes. Mais si un programme a été compilé exprès pour les utiliser au lieu d’autres instructions plus basiques, ce n’est pas pour les exécuter au ralenti, autant garder les vieilles. Le décodeur est une partie qui consomme beaucoup dans un x86, il faut le simplifier pour le basse conso. Il faudrait des flags pour que l’OS choisisse pour chaque librairie et programme les instructions utilisées (un peu comme les modes 32 et 64bits) et les assigner automatiquement au proc. qui-va-bien.
Ou juste laisser tomber le x86.
On sait bien que c’est foutu pour les téléphones & tablettes. Les PC portables ont maintenant une performance et autonomie acceptable (et le GPU consomme au moins autant que le CPU), et les serveurs ont d’autres contraintes (soit des dizaines de processeurs simples où x86 est foutu, soit des processeurs bien bourrins et là les défauts du x86 sont moins pénalisant).
@TREZA: Regarde les architectures ULV de chez Intel et tu comprendras la consommation et l’autonomie n’est plus un problème pour l’architecture x86.
[…] Les catégories M5, U28 et H55 sont nouvelles et vont donc permettre à Intel de proposer des puces vraiment très finement réparties suivant les besoins de chaque types. Cette logique big.LITTLE reprise ici par Intel semble la plus adaptée au marché actuel. Elle permet de proposer dans une architecture unique un éventail très large d’options. Mais fondamentalement les puces sont identiques. Le travail d’optimisation mené pour un H55 au niveau de son architecture aura des retombées sur le plus malingre des Core i3 de la gamme M5. Ce qui est un point très positif pour Intel comme pour les développeurs et les clients finaux. Un point de toutes façons nécessaire pour lutter contre ARM mais également contre AMD qui s’intéresse à cette même manière de concevoir les processeurs. […]