AMD pense big et LITTLE

AMD travaille également à un processeur composé de plusieurs types de coeurs. Comme ARM et son big.LITTLE, comme Intel et sa technologie FOVEROS, AMD planche sur une solution hybride.

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.

AMD

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. 

AMD

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.

Soutenez Minimachines, partagez le !


Jaune
5 commentaires sur ce sujet.
  • 25 août 2020 - 16 h 43 min

    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.

    Répondre
  • 26 août 2020 - 0 h 32 min

    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.

    Répondre
  • 27 août 2020 - 8 h 53 min

    @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é.

    Répondre
  • 27 août 2020 - 12 h 59 min

    @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).

    Répondre
  • 27 août 2020 - 17 h 14 min

    @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.

    Répondre
  • LAISSER UN COMMENTAIRE

    *

    *