Lors de l’AMD Fusion Developer Summit qui s’est tenu il y a quelques mois, un invité avait fait sensation : Jem Davies, Vice-Président chez ARM, en charge de la
Lire la suite ...

Merci pour cette newz Damien  

Enorme cette news. Je trouve les inovations apportées par ARM fort intéressantes.

C'est 20us et non 20ms

Effectivement, c'est corrigé

Le "Black Silicon" ressemble à quelque chose de déjà vu...
 
(MDO ou un truc du genre, avec un nom à la con appliqué au design en micro-électronique)

En gros ils remettent au gout du jour l'architecture CISC, après l'avoir éliminé il y a 20 ans pour des archi RISC, puis remplacé au fur et a mesure par des architectures hybrides RISC / CISC...

Salut,
 
Je ne comprends pas ton commentaire sur CISC vs RISC qui est une notion de jeu d'instruction (ISA). On ne parle pas de jeu d'instruction ici. Le débat ici parle d'architecture hétérogène, qui est un vieux sujet. En gros j'ai un système composé d'un gros multicore gourmand avec ses domaines de voltage que je peux couper pour éviter les courants de fuite, et lancer le calcul sur un coeur plus petit (le A7 ici).
 
Le véritable souci n'est pas de coller le silicium d'un A7 dans une puce contenant un A15. C'est la complexité de l'OS pour supporter ces migrations: doit-il "vider" l'ensemble des caches du gros CPU avant de basculer au petit pour assurer un fonctionnement correct des applications déjà lancées (des millisecondes de perdues pour vider les caches en L3), ou peut-il simplement endormir le gros coeur. Pour cela il faut que les caches du coeur endormi sachent répondre aux requêtes de cohérence d'autres coeurs tout en étant en mode "rétention de données", et pendant que le coeur de calcul est, lui, complètement coupé (bonjour les domaines d'horloge et de voltage nécessaires).
 
Nonal

Pas vraiment.
 
D'autant plus que là ils parlent bien de deux Cortex A15 et A7 qui ont le même jeux d'instruction mais diffèrent seulement par leur domaine d'utilisation.

Cela dit, le débat de ARM est-il "CISC ou RISC" fait quand même sens: autant il reste pas mal d'orthogonalité dans les jeux d'instructions d'ARM, autant il existe quelques instructions _délirantes_, rajoutées par Thumb2.
 
Par exemple, le TBB:
  a/ lit un octet en mémoire (lire un octet n'est pas une opération simple pour un CPU de largeur de bus >8 bits : il faut placer venant de la mémoire les données au bon endroit). Sans compter le mode d'adressage pour calculer l'endroit où est la donnée.
  b/ décale et étend le signe des données lues
  c/ additionne avec position actuelle du programme (PC).
  d/ Saute vers cette adresse (je vous laisse imaginer la complexité des branchements dans les CPU modernes).
 
Vous trouvez ca très RISC ? Moi non. Fort heureusement cette instruction peut fort bien se micro-coder. Cela dit, quand on en est à micro-coder des instructions, est-on encore RISC ?
 
Nonal

De toute façon il est plus question de "désoptimisation vis-à-vis de la surface pour optimiser vis-à-vis des performances" qu'autre chose.
 
En d'autres termes, on reprend avant les archis "unifiées" type Sandy Bridge (FPU réutilisant les unités de calcul de l'ALU), mais on peut aussi voir ça dans la direction totalement opposée, en partant du principe de généricité des opérations utilisées pour virer purement et simplement les unités "spécialisées" type FPU pour les émuler... comme AMD l'a fait avec Cayman et les ops complexes (trigo notamment).
 
 
Sauf erreur, Bulldozer est un amas de Black Silicon justement... (FPU "découplée" des ALU, blabla sur le faible % de transistors actifs par cycle...)