COMPTOIR
register

Un CPU à cache adaptatif, de quoi améliorer les performances sans nouvelle finesse de gravure ?

Après avoir pondu les peut être processeurs du futur, les chercheurs du MIT qui ont décidément beaucoup de matière grise à revendre en cette période estivale remettent le couvert. Leur idée se base sur un concept simple : au lieu de produire une puce "fixe" possédant deux ou trois niveaux de cache d'une certaine taille donnée, pourquoi ne pas concevoir une puce adaptative, allouant le cache de manière dynamique en fonction des programmes ? 

 

La recette semble porter ses fruits, puisque l'institut annonce des gains sur simulateur allant de 20 à 30% pour une consommation réduite de 35 à 85% ! Bon, le processeur simulé possède la bagatelle de 36 coeurs, possédant chacun 512 Ko de SRAM propre et 4 x 256 Mo de SRAM partagés. En fait, les applications simulées ne tirent pas parti de tous les coeurs, mais piquent du cache aux unités de calcul libres voisines afin de se satisfaire. Il s'agit donc d'une optimisation lors de l'exécution simultanée de plusieurs programmes faiblement multithreadés plus qu'une révolution pour les gourmandes applications de calculs parallèles. Pour gérer tout ce petit monde, un algorithme du nom tout mignon de Jenga est utilisé, et tel Tron, c'est lui qui surveille le partage des ressources.

Pour une utilisation multitâche, l'idée semble reluisante. Cependant il faut garder en tête que Jenga devra être implémenté en dur dans ce type de puce, introduisant potentiellement une latence supplémentaire lors des accès mémoire. Il faut également que ce dernier soit capable de communiquer efficacement avec n'importe quel coeur, ce qui n'est pas gagné d'avance non plus, comme l'a constaté AMD avec l'Infinity Fabric, qui est un des principaux goulots d'étranglement de Ryzen.

 

mem cache adaptif mit

Chacun son domaine, le splix.io des programmes !

 

Cette initiative va à contre-courant d'Intel, qui avait intégré de l'eDRAM jouant le rôle de gros cache L4 sur ses processeurs Broadwell et Kaby Lake-U. C'est sûr qu'avec des brouzoufs, on peut se permettre d'y aller à la force brute en intégrant directement une quantité importante de cache, et tant pis pour la consommation ! 

Un poil avant ?

La fibre déployée partout en France... via Altice ?

Un peu plus tard ...

Gamotron • Vous voyez le mal partout, c'est fou !

Les 26 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Un ragoteur qui pipotronne du Grand Est, le Mardi 15 Août 2023 à 15h37  
Ça serait pas mal d'arrêter de régurgiter une marque déposée (tout au plus) avec ces mentions à "Infinity Fabric"...

Ce "protocole" MOESI (et pourquoi pas MOISE, hein? Ça, c'est important! ) parfaitement standard n'a même pas de liaison propre, dans le cas des Ryzen actuels il est même probable qu'il n'emploie pas l'HyperTransport (d'ailleurs lui-aussi joli mot marketing), destiné à la base aux connexions "longue distance" (entre sockets) et dans sans aucun intérêt en communication intra-silicon. La même pour ce qui est des GPU.
par Nicolas D., le Lundi 24 Juillet 2017 à 18h41  
par Aquina le Lundi 24 Juillet 2017 à 17h51
En fait ça dépend de ton type de logiciel et de si il est mono ou multi-threadé non ? Du fait que tu cherches plutôt la rapidité d'exécution ou le nombres d'infos a traiter non ?

Désolé j'y connais que dalle la dedans alors pour les infos je suis preneur
C'est ambigüe, si on pense à un cache partagé, on peut bien "dire" que l'ensemble des deux coeurs qui partagent le cache c'est "un coeur physique" et que doubler le reste c'est "du multithreading amélioré" et donc tu pars d'un coeur avec plein de cache pour avoir deux coeurs logiques, le même cache et juste plus d'unitées de calculs, et paf, tu as plus de perfs en multicoeurs avec ton procc fort de base.
Ou alors, le point de vu de l'article, c'est de partager du cache entre unitées de calculs séparées (mais où est la séparation ? Pour ma part c'est sur le die que ca se joue). Dans ce cas on optimise les perfs monothreads quand tu as un CPU multi-core efficace.

Le ragoteur déco a bien raison, les gains seraient moins forts sur un 4 coeurs c'est clair, pas besoin de l'algo. Mais avec un threadripper à 16 threads, ça deviendrait moins négligeable ; idem sur des plateformes Intel dual ou triple socket.
Faut garder en tête que personne ne lira et n'inversitra si les gains ne font pas rêver
par Aquina, le Lundi 24 Juillet 2017 à 17h51  
par Un radoteur macagneur d'Alsace le Lundi 24 Juillet 2017 à 16h23
Toi, tu veux optimiser l'utilisation des ressources d'UN C?'UR PHYSIQUE avec beaucoup de thread, alors que là c'est le contraire, allouer plus de ressources à UN THREAD avec beaucoup de cœurs physiques. C'est juste le contraire.
Désolé j'ai peut être rien compris mais :
-Le ragoteur déco parle de division de processus : un coeur ( physique et /ou logique ) pourra faire tourner plusieurs processus en même temps ( surement un gain niveau matériel car potentiellement moins de coeurs a utiliser , mais a contrario les coeurs sont utilisés a fond donc surcout énergétique potentiel )
- Toi tu parle de mutualisation de processus : plusieurs coeurs ( physiques et/ou logiques ) , capables d'effectuer un processus en un temps record et de passer au suivant ( tu effectue donc le calcul beaucoup plus rapidement mais un a la fois )

En fait ça dépend de ton type de logiciel et de si il est mono ou multi-threadé non ? Du fait que tu cherches plutôt la rapidité d'exécution ou le nombres d'infos a traiter non ?

Désolé j'y connais que dalle la dedans alors pour les infos je suis preneur
par Un radoteur macagneur d'Alsace, le Lundi 24 Juillet 2017 à 16h23  
par Un #ragoteur déconnecté de Provence-Alpes-Cote d'Azur le Lundi 24 Juillet 2017 à 15h15
Maintenant, si au lieu des 36 cores il n'y en avait que 4 avec les mêmes ressources que 8, y compris la BP et la quantité de caches et capables de gérer 8 threads chacun, y'aurait juste pas besoin de leur tour infernale Jenga. C'est d'autant plus intéressant sous cet angle que ce qui est indiqué comme utilisant 10 threads (M ou B) pourrait parfaitement s'exécuter sur 8 cores virtuels issus d'un même core physique sans pénalité via les mécanismes OoO (800% des ressources pour les 10 threads qui n'en utilisaient peut-être que 400%), le cache étant alors limité à 1/4 au lieu de 10/36e, ce qui fait une différence absolument négligeable, tandis que pour les processus O et A les mécanismes d'économie d'énergie classiques fonctionnent parfaitement.
Toi, tu veux optimiser l'utilisation des ressources d'UN C?'UR PHYSIQUE avec beaucoup de thread, alors que là c'est le contraire, allouer plus de ressources à UN THREAD avec beaucoup de cœurs physiques. C'est juste le contraire.
par Un #ragoteur déconnecté de Provence-Alpes-Cote d'Azur, le Lundi 24 Juillet 2017 à 15h15  
Le problème c'est surtout le réalisme de l'idée : c'est tellement vite fait d'annoncer des gains énormissimes quand on part avec un biais lié à l'architecture elle-même qu'il faut plus que simplement ce papier pour se faire un avis... ça ressemble beaucoup trop à une publication destinée à appâter des investisseurs ne comprenant rien au sujet.

Maintenant, si au lieu des 36 cores il n'y en avait que 4 avec les mêmes ressources que 8, y compris la BP et la quantité de caches et capables de gérer 8 threads chacun, y'aurait juste pas besoin de leur tour infernale Jenga. C'est d'autant plus intéressant sous cet angle que ce qui est indiqué comme utilisant 10 threads (M ou B) pourrait parfaitement s'exécuter sur 8 cores virtuels issus d'un même core physique sans pénalité via les mécanismes OoO (800% des ressources pour les 10 threads qui n'en utilisaient peut-être que 400%), le cache étant alors limité à 1/4 au lieu de 10/36e, ce qui fait une différence absolument négligeable, tandis que pour les processus O et A les mécanismes d'économie d'énergie classiques fonctionnent parfaitement.
par Nicolas D., le Lundi 24 Juillet 2017 à 12h52  
par Un #ragoteur déconnecté de Provence-Alpes-Cote d'Azur le Lundi 24 Juillet 2017 à 11h36
La seule différence dans ces 2 phrases, c'est ton point de vue d'observateur.
Tout dépends jusqu'où tu étends le SMT alors conceptuellement on reste sur du partage optimisé oui. Sur du SMT tu mutualies tellement tout qu'il n'y a qu'un coeur physique, ici plusieurs (ça n'est qu'une optimisation pour augmenter les perfs mono sur un systeme multi, quand le SMT fait l'inverse). Le coeur de l'article est - il me semble - leur algo de placement qui justement gère la hiérarchie à la volée ; il ne me semble pas que le SMT soit un algorithme encore .

J'avoue que la maquette fait pas rêver, mais le cache DRAM c'est quand même ce qu'il y a sur les Broadwell desktop, et qui offre de sérieux gains !

C'est un papier qui offre des pistes, perso si sur un i9 décacore on peut piquer le L2 des autres coeurs pour avoir 10Mo théoriques sans surplus de latence visible (c'est tout le principe de Jenga) je suis preneur .

Après faut prendre du recul, un papier de recherche c'est ni une étude ni un pré-sample c'est clair
par Un #ragoteur déconnecté de Provence-Alpes-Cote d'Azur, le Lundi 24 Juillet 2017 à 11h36  
par Nicolas D. le Lundi 24 Juillet 2017 à 09h15
Non non, le SMT consiste à partager efficacement les ressources d'un coeur physique pour permettre l'execution de plusieurs processus quasi simultanément afin d'optimiser l'utilisation des ressources. Ici c'est l'inverse, on optimise à plusieurs coeurs l'utilisation de ressources qui était auparavant "propre".
C'est pas ça, mais exactement la même chose, en somme?

La seule différence dans ces 2 phrases, c'est ton point de vue d'observateur, dans les 2 cas le but est de mutualiser les ressources, le SMT va juste beaucoup plus loin qu'un "simple" partage des caches.

J'ai maté vite fait le PDF et faut dire ce qui est, il pue l'embrouille... bon, en même temps, quand on te présente un cache "virtuel" de pas moins d'1Go et réalisé avec de la DRAM, faut pas trop s'attendre à trouver un truc vraiment sérieux.

Je sais pas si j'ai bien tout compris, mais les chiffres donnés semblent correspondre à une implémentation type FPGA en activant ou non la gestion dynamique des partitions de caches, dont la hiérarchie ne serait d'ailleurs même pas figée (même SRAM pour L1 et L2), autant dire que ça ne rime à rien.
par Nicolas D., le Lundi 24 Juillet 2017 à 09h15  
par Un #ragoteur déconnecté de Provence-Alpes-Cote d'Azur le Lundi 24 Juillet 2017 à 05h57
Bah oui, je vois même pas l'intérêt de raisonner là-dessus quand on connaît la solution depuis un bail.
Non non, le SMT consiste à partager efficacement les ressources d'un coeur physique pour permettre l'execution de plusieurs processus quasi simultanément afin d'optimiser l'utilisation des ressources. Ici c'est l'inverse, on optimise à plusieurs coeurs l'utilisation de ressources qui était auparavant "propre". Par exemple, c'est hors de question qu'un coeur d'un i5 vienne taper dans le L2 de son voisin, alors que c'est l'idée ici. Les gains proviennent du fait qu'aller taper dans ce cache est moins couteux en temps et énergie qu'aller bêtement voir en RAM.
par Un #ragoteur déconnecté de Provence-Alpes-Cote d'Azur, le Lundi 24 Juillet 2017 à 05h57  
par Nicolas D. le Dimanche 23 Juillet 2017 à 19h51
As-tu lu l'article ? Tout l'intérêt est ici dans le coeur physique et la gestion de la répartition physique de la mémoire sur les coeurs plus ou moins lointains :-).
Bah oui, je vois même pas l'intérêt de raisonner là-dessus quand on connaît la solution depuis un bail.

C'est d'ailleurs 4x256Mo de DRAM autour, présentée dans le papier comme similaire à de la HBM (empilée), ça pose la question de "mais d'où sortent les gains annoncés?"...
par Un ragoteur du Centre, le Dimanche 23 Juillet 2017 à 22h04  
Proposition de titre alternatif : CPU à cache adaptatif : Moore:0 / Darwin:1

par Nicolas D., le Dimanche 23 Juillet 2017 à 19h51  
par Un #ragoteur déconnecté de Provence-Alpes-Cote d'Azur le Dimanche 23 Juillet 2017 à 10h48
Z'êtes sûrs que ça vient bien du MIT un tel ramassis d'absurdités?

Si tu veux faire ça, t'as tout intérêt à employer le SMT qui fera ce partage de façon totalement dynamique et transparente, tout en permettant d'avoir plus de ressources "actives" pour chaque core logique pris isolément...
As-tu lu l'article ? Tout l'intérêt est ici dans le coeur physique et la gestion de la répartition physique de la mémoire sur les coeurs plus ou moins lointains :-).
par Ideal, le Dimanche 23 Juillet 2017 à 16h38  
par Practiq de Western Austra d'Ile-de-France le Samedi 22 Juillet 2017 à 22h55
45/14 = 3.21
donc non, pas 10x plus de transistor
refais tes calculs ( ou commence par en faire de bons, tu verra que tu te trompes )

Tu tentais vainement un troll
J'espère
Sinon bah lol pour ton calcul c'était tout choupinou