Bulldozer et innovations

[newbie06]

Qui plus est charger un grand nombre d'instruction en parallele est beaucoup plus simple quand on n'a pas a les decoder.

Les op dans la trace ont une taille constante ? Ou bien il y a un mecanisme qui permet de tres rapidement recuperer les boundaries des ops ?

Finalement les branchements sont deja predits et les traces arrangees de maniere a ce qu'il n'y ait aucune bulle (un peu comme si les branchements n'avaient jamais existe) ce qui accelere aussi l'execution.

Ma question de newbie qui ne connait rien au P4 : il se passe quoi quand une prediction de branchement embarquee dans une trace se revele fausse ? Flush de cette trace ?

Ca me fait penser au mecanisme de trace de certains JIT, mais je me mefie, l'effet Canada Dry peut etre trompeur

[EPIC]

Les op dans la trace ont une taille constante ? Ou bien il y a un mecanisme qui permet de tres rapidement recuperer les boundaries des ops ?

Ma question de newbie qui ne connait rien au P4 : il se passe quoi quand une prediction de branchement embarquee dans une trace se revele fausse ? Flush de cette trace ?

Ca me fait penser au mecanisme de trace de certains JIT, mais je me mefie, l'effet Canada Dry peut etre trompeur

d'après l'article fait à l'époque par Sam & Franck l'intéret du trace cache c'est qu'il ne contient que des prédictions justes...

Quant aux µops je crois qu'elles sont de type "RISC" donc je dirais de taille constante, si je ne fait pas d'erreur, je crois que c'est AMD qui à introduit cette techno dans l'archi K5 (génération du pentium) j'avais lu ça dans l'une des docs d'architecture d'AMD sur ce sujet. Mais bon je pense que féfé va vite confirmer ou infirmer tou ça

[newbie06]

d'après l'article fait à l'époque par Sam & Franck l'intéret du trace cache c'est qu'il ne contient que des prédictions justes...

Hu ? Ca limiterait le trace cache aux branch non conditionnels Ou aux boucles infinies...

Quant aux µops je crois qu'elles sont de type "RISC" donc je dirais de taille constante, si je ne fait pas d'erreur, je crois que c'est AMD qui à introduit cette techno dans l'archi K5 (génération du pentium) j'avais lu ça dans l'une des docs d'architecture d'AMD sur ce sujet. Mais bon je pense que féfé va vite confirmer ou infirmer tou ça

Hum si elles sont RISC ça veut dire qu'elles font minimum 5 octets chaque à cause des constantes 32-bit (ou bien les constantes sont aussi découpées). Du coup ça fait exploser la taille de manière non négligeable (pour info sur un run de SPEC2k gcc, j'ai une moyenne dynamique de 3.67 octets/instruction sur du code x86_64).

Mais comme tu dis on attend Fefe

[Neo_13]

Hu ? Ca limiterait le trace cache aux branch non conditionnels Ou aux boucles infinies...

Euh, perso, je vois pas le problème : les instructions décodées sont stockées décodées... Ca veut pas dire qu'on va s'en resservir, ça veut juste dire que si elles se représentent au décodeur, elles seront bypassées. Il me semble que la prédiction est avant le décodeur, du coup, n'arrive au décodeur que les instructions prédites.

Je ne crois pas que le trace cahce contienne une gloubiboulga data + µops agglomérés tout sale.

Enfin voilà, je vois pas le problème.

[newbie06]

Donc c'est complètemet décorellé de la prédiction ? Et en fait une trace ne serait qu'un bloc de base (ou un morceau d'un bloc de base) ? Donc ça ne servirait qu'à réduire le power (au détriment d'une occupation moins efficace de la cache).

Marrant, pour moi le terme de trace recouvre un autre concept plus agressif (cf. trace scheduling).

[fefe]

Tu as des branchements deja predits dans le Trace Cache, ca ne veut pas dire que tu ne les reprediras jamais.

Si tu as des lignes de fetch qui ressemblent a ca

1: I..I..B3..X..
2:..............
3: I..I..I..I..

Avec un cache d'instruction traditionnel, si B3 est un branchement pris, tu perdras systematiquement la bande passante equivalente au nombre d'instructions restantes dans la ligne. Si le branchement etait la premiere instruction ca fait 75% de gachis. Dans un trace cache si B3 a ete predit pris la derniere fois que la trace a ete construite les instructions de la ligne 3 commenceront juste apres B3 d'ou aucune perte de bande passante.

Si le branchement est predit non pris, en general il y a des bulles d'inserees aussi pour X dues a la profondeur des etages de decodage et de fetch (ils sont pipelines donc le temps de realiser que le branchement est non pris il faut 1+ cycle pour continuer sur X quand meme au lieu de continuer dans le meme cycle. Pas de ca non plus avec un trace cache.

Bien entendu les branchements sont predits dans le trace cache, et la trace reconstruite a la volee en fonction des predictions. Tu peux avoir des branchements qui pointent vers d'autres traces, voire meme vers le milieu de traces existantes. Ca dependra de l'implementation.

Le trace cache de P4 n'etait nuke que dans le cas de code automodifiant dans mes souvenirs vu qu'il n'y avait pas moyen de retrouver quels traces etaient affectees par la modification de code.

Pour les immediats, le trace cache de P4 avait une structure separee qui cachait les immediats, et les instructions de longueur fixe (et d'un nombre de bit sans rapport avec aucun jeu d'instruction existant) contenaient des pointeurs vers cette structure. L'avantage des immediats est qu'ils sont generalement utilises suffisament tard dans le pipeline pour pouvoir les stocker dans une structure "lente".

Il y a beaucoup d'implementations differentes de trace cache dans la litterature, en general les noms varient de trace cache, a frame cache, basic block cache, predecode cache... Tous ont des variations sur la maniere dont sont construites les traces, leur support de branchements ou non au milieu de trace ou pointant vers l'interieur d'une trace.

Le trace cache du P4 etait clairement oriente vers la bande passante d'instruction sur des programmes ou la prediction marchait bien (a cause de la frequence les decodeurs classiques ne pouvaient pas suivre), et la reduction de la penalite de branchement dans les cas ou la reconstruction de trace n'etait pas trop couteuse. L'economie d'energie n'etait pas trop d'actualite alors.

[Oxygen3]

Suite et corrections des analyse de Anand:
http://www.anandtech.com/cpuchipsets...oc.aspx?i=3683

[Alexko]

AMD is also careful to mention that the integer throughput of one of these integer cores is greater than that of the Phenom II's integer units.

Bonne nouvelle, et ça va dans le sens de l'hypothèse selon laquelle les 4 pipelines seraient des ALU/AGU combinées.

According to AMD's roadmaps, Zambezi will use either 4 or 8 Bulldozer cores (that's 2 or 4 modules). The quad-core Zambezi should have roughly 10 - 35% better integer performance than a similarly clocked quad-core Phenom II. An eight-core Zambezi will be a threaded monster.

En comptant maximum 10 % pour un meilleur scaling et peut-être un plus gros cache, ça fait au moins 0~25 % de mieux en single-thread. Pas dégueu.

AMD did add that eventually, in a matter of 3 - 5 years, most floating point workloads would be moved off of the CPU and onto the GPU. At that point you could even argue against including any sort of FP logic on the "CPU" at all.

Et pour les calculs FP scalaires et non parallélisables, on fait comment ? Je pense qu'il faudra garder au moins une unité FP par module ; ou à la rigueur repenser le concept de module dans quelques années pour en faire un bloc de 4 clusters int + une paire d'unités FP.

[Møgluglu]

Et pour les calculs FP scalaires et non parallélisables, on fait comment ?

On les fait avec du flottant, mais pas forcément du flottant binaire...
Les calculs flottants scalaires, c'est typiquement des entrées-sorties et de la compta, qui marcherait bien mieux en arithmétique décimale.
IBM a commencé a en mettre en hard. Intel y est violemment opposé et propose du soft à la place. Jusqu'ici, AMD n'a pas pris position, mais ils ont quelques papiers sur des unités décimales...

Bien sûr ça demanderait de revenir sur des habitudes enracinées depuis 40 ans...
(En même temps même après 40 ans personne capte rien au flottant binaire alors...)

[fefe]

SMT: 5% de hard 10-30% de perf
AMD clustering: 50% de hard 60-80% de perf ? (je suppose que 80% est leur meilleur des cas...). Je suppose que ce 80% n'inclut aucune modification uarch proprea a ameliorer la performance a 1 thread sinon la comparaison n'est pas equitable.

Je suppose que leur solution doit etre efficace du point de vue power/performance (sinon je ne vois pas pourquoi ils sortiraient leur die).

Si en partant d'un core (de surface 1) en 45nm on veut ajouter des features et shrinker en 32nm, ca donne dans 1 de surface en 32nm:
- SMT: 1/(0.56*1.05)=1.7 cores / unite de surface = 2.04 perf / unite de surface (1.87-2.21)
- CLust: 1/0.56*1.5= 1.19 cores/ unite de surface = 1.90-2.1 perf/unite de surface.

Si on part du principe que les 30% de SMT se comparent a leurs 80% le clustering est un peu moins bon, si on considere que ca se compare aux 20%, le clustering est un peu meilleur. Au final je dirais que clustering apparait un peu moins efficace avec ces calculs, mais pas de beaucoup.

Donc en terme de perf/surface (ou plutot perf/$) la solution du clustering semble etre d'efficacite comparable a SMT.

La question maintenant va etre de savoir si un thread va ralentir l'autre comme ca arrive dans SMT: le 2 eme thread actif va utiliser des ressources du frontend. Si il y a partage dynamique des ressources, le premier thread actif en aura moins et potentiellement pourra perdre de la perf par rapport a si il avait ete seul. Bien entendu ils beneficieront des ameliorations de scheduling mises dans les OS pour SMT, a condition de ne pas traiter le 2 eme core de chaque cluster comme un core, mais comme un core SMT . (C'est pas grave ca passera inapercu ont promis les marketeux ). Bien entendu il est possible que ;e frontend ait ete concu pour eviter ces problemes, mais le cout me semble comparable a 2 frontends (sauf si ils ont 1 trace cache par thread et qu'ils ne partagent que les decodeurs mmm).

Ah les floating point binaires ou decimaux. Il n'y a guere que 3 programmeurs qui comprennent vraiment ce qu'ils font avec . On a beau essayer de leur enseigner, en general c'est la premiere chose oubliee .

[Møgluglu]

Bonne nouvelle, et ça va dans le sens de l'hypothèse selon laquelle les 4 pipelines seraient des ALU/AGU combinées.

Goto a creusé la question :
Sacrifier les performances en caclul entier? "Bulldozer" d'AMD.

Doutes : la largeur du décodeur (4 instructions) semble déséquilibrée par rapport à celle des unités d'exécution (8 int + 4 FP). Et les cores entiers ont-il chacun 2 LSU+2 ALU ou 4 LSU+4 ALU?

Réponses : les deux questions sont connectées. On sait déjà que chaque core entier accepte 4 micro-ops. "D'après AMD", les cores contiennent 2 pipes ALU et 2 pipes LSU, pour un total de 4.
Et faut pas mélanger macro-ops et micro-ops : 2 schedulers entiers recevant 4 macro-ops du décodeur partagé, et produisant 4 micro-ops chacun.
Du coup les débits matchent parfaitement et tout va bien (voir dessins).

[Alexko]

D'après AMD, chaque core de Bobcat contient 2 ALU + 2 LSU, mais je n'ai jamais vu AMD dire quoi que ce soit de semblable pour Bulldozer. D'ailleurs, s'ils le disent volontiers pour l'un et pas pour l'autre, c'est que ça ne doit pas être si simple pour l'autre.

D'ailleurs AMD a déjà dit qu'un quad-core basé sur Bulldozer serait plus performant qu'un Shanghai, et je vois mal comment ça pourrait être le cas si un "core" (i.e. un int-cluster) de Bulldozer était plus lent qu'un core Greyhound (celui de Shanghai). À vrai dire je pense même que sacrifier les performances single-thread serait suicidaire, même en 2011 : ça reste bien trop important.

Un petit résumé ici : http://blogs.amd.com/work/2009/12/11...10-and-beyond/

Passage intéressant :

The Bulldozer architecture can provide up to 80% greater expected throughput when running 2 threads simultaneously compared to a single thread running on a single integer core. Our engineers estimate that the amount of discrete circuitry that is added to each Bulldozer module in order to allow for a second integer thread to run only adds ~12% additional circuitry to each module, which translates into only ~5% of circuitry to the total Bulldozer die. We believe this is an excellent balance of greater performance with a very small silicon cost. The goal of the shared components is to help drive down power consumption. When you consider that our 16-core Interlagos is being designed to fit in the same power/thermal environment as a 12-core Magny Cours, it is clear that we’ve made some good choices around the power optimization – without sacrificing performance or features.

[Møgluglu]

Goto se serait planté? Arienai!

The Bulldozer architecture can provide up to 80% greater expected throughput when running 2 threads simultaneously compared to a single thread running on a single integer core.

Si le "single integer core" désigne un core de Bulldozer, cette phrase me semble aller plutôt dans le sens de Goto.

Dit dans l'autre sens, même quand on a qu'un seul thread sur le cluster, son débit d'exec n'est pas significativement supérieur à celui qu'il aurait avec un thread sur l'autre core.

S'il y a bien 4 LSU et 4 ALU par core, on pourrait s'attendre à ce qu'un seul thread puisse squatter toute la bande passante du décodeur à lui tout seul (4 macro-ops/cycle), et donc que la différence entre 1 thread et 2 thread soit plus grande...

[Møgluglu]

La suite : Goto persiste et signe, et développe son argumentation (avec les précautions oratoires d'usage, faut pas déconner).

http://pc.watch.impress.co.jp/docs/c...17_336298.html

Cite Chuck Moore (warning : traduction hasardeuse d'anglais en français par le japonais, si quelqu'un retrouve la VO je veux bien...) :

Ceci [image des 4 pipes des core integer] montre les pipelines d'exécution. Chacun des schedulers entiers est capable de traiter 4 instructions/cycle.
[...]
Chacun [des cores integer] peut effectuer 2 loads par cycle. Chacun [des core integer] est une machine out-of-order à 4 voies.

Interprétation : les 4 pipelines d'exécutions se divisent en deux paires ALU / load-store. On peut penser que les 2 loads/cycle signifient qu'on a pas des unités load et store séparées mais des unités combinées capables de faire des store ou des loads.
Du coup, tous les indices rassemblés jusqu'ici tendent à dire que l'organisation est la même que sur K7/K8/K10. Dixit Goto.

[Lionel33]

Il me semble que c'est ce qui est repris ici ... (qui n'était pas sur les slides de présentation)

- Each Bulldozer module is an optimized dual core
- Each Bulldozer "core" is capable of 2 loads/cycle; each is a 4-way out-of-order machine
- Bulldozer module is not bigger in area than Intel's hyperthreading design
- Bulldozer module can achieve ~80% speedup when running 2 threads (versus ~25% from hyperthreading)
- Multiple Bulldozer modules can share the L2 cache; and multiple of those (module? L2?) can share the L3 and NB
- Each INT scheduler can issue 4 inst./cycle; the FP scheduler can issue 4 inst./cycle
- "Over time" a Bulldozer "core" (INT only?) can be deployed in APU to work with GPGPU (for FP?)

[fefe]

Bulldozer module is not bigger in area than Intel's hyperthreading design

Marketing bullshit detector triggered !!! Leur core est beaucoup plus petit qu'un core Intel a la base, donc rajoute 50% de surface en plus et ils fininissent pas plus gros qu'un core Intel. Ca ne rend pas leur clustering aussi efficace d'un point de vue surface que Hyperthreading qui tend a faire grossir le core de seulement 5%...

[Lionel33]

Marketing bullshit detector triggered !!! Leur core est beaucoup plus petit qu'un core Intel a la base, donc rajoute 50% de surface en plus et ils fininissent pas plus gros qu'un core Intel. Ca ne rend pas leur clustering aussi efficace d'un point de vue surface que Hyperthreading qui tend a faire grossir le core de seulement 5%...

Daprès une citation dans un post d'Alexko plus haut :

"Our engineers estimate that the amount of discrete circuitry that is added to each Bulldozer module in order to allow for a second integer thread to run only adds ~12% additional circuitry to each module, which translates into only ~5% of circuitry to the total Bulldozer die."

donc il parle de seulement 5% sur toute la surface .


Et ici une discussion sur un forum AMD :

"The additional circuitry increases the total floor space of a module by about 12%.

Four incremental cores adds ~5% total real estate to the whole die.

Let's say for fun that the "other" components of the die = 60%. That is NB, mem controller, HT, cache, etc. Then you consider that the 4 modules = 40%, right?

Let's say that you doubled real estate of the modules. That is a 100% increase. Now you are at 140%.

So the 40%, under the new die size represents only 28% of the total die.

So, when you consider that you are dealing with only a portion of each of the modules, and there is things like a shared L2 cache in the module, it is clear that the total die space increase could easily be 5%."

Bon ,ce n'est que suposition aussi

[Oxygen3]

J'ai toujours du mal avec leurs saletés de "Cores" fluctuantes.

Le point qu'il faut voir:
16 core Interlagos = 16 ALU et 16 FPU
12 core Bulldozer = 24 ALU et 12 FPU

Tant qu'on mélange le terme de core (un core bulldozer, c'est un simple core ou un double core ? > c'est un simple core), on mélange tout dans les comparaisons faites par AMD je pense.

[Lionel33]

J'ai toujours du mal avec leurs saletés de "Cores" fluctuantes.

Le point qu'il faut voir:
16 core Interlagos = 16 ALU et 16 FPU
12 core Bulldozer = 24 ALU et 12 FPU

Tant qu'on mélange le terme de core (un core bulldozer, c'est un simple core ou un double core ? > c'est un simple core), on mélange tout dans les comparaisons faites par AMD je pense.

En fait le bulldozer est divisé en module ,et chaque module comprend 2 core (si j'ai tout suivi ,c'est un peu flou leur dénomination ).

[Alexko]

J'ai toujours du mal avec leurs saletés de "Cores" fluctuantes.

Le point qu'il faut voir:
16 core Interlagos = 16 ALU et 16 FPU
12 core Bulldozer = 24 ALU et 12 FPU

Tant qu'on mélange le terme de core (un core bulldozer, c'est un simple core ou un double core ? > c'est un simple core), on mélange tout dans les comparaisons faites par AMD je pense.

Interlagos c'est un MCM basé sur 2 dies de Bulldozer comprenant 4 modules (donc 8 "cores") chacun.

En fait le bulldozer est divisé en module ,et chaque module comprend 2 core (si j'ai tout suivi ,c'est un peu flou leur dénomination ).

Voilà c'est ça. Le message officiel d'AMD c'est 1 module = 2 cores, mais le terme "module" est provisoire, ils cherchent un truc plus kikoolol pour le marketing. Je pense qu'on devrait parler d'icores (int-core) et de modules pour plus de clarté, mais bon, la clarté et le marketing...

[fefe]

Daprès une citation dans un post d'Alexko plus haut :

"Our engineers estimate that the amount of discrete circuitry that is added to each Bulldozer module in order to allow for a second integer thread to run only adds ~12% additional circuitry to each module, which translates into only ~5% of circuitry to the total Bulldozer die."

donc il parle de seulement 5% sur toute la surface .


Et ici une discussion sur un forum AMD :

"The additional circuitry increases the total floor space of a module by about 12%.

Four incremental cores adds ~5% total real estate to the whole die.

Let's say for fun that the "other" components of the die = 60%. That is NB, mem controller, HT, cache, etc. Then you consider that the 4 modules = 40%, right?

Let's say that you doubled real estate of the modules. That is a 100% increase. Now you are at 140%.

So the 40%, under the new die size represents only 28% of the total die.

So, when you consider that you are dealing with only a portion of each of the modules, and there is things like a shared L2 cache in the module, it is clear that the total die space increase could easily be 5%."

Bon ,ce n'est que suposition aussi

Hyperthreading c'est 5% du core qui represente lui meme moins de la moitie de la surface du die... Ca ne s'aligne quand meme pas. De toutes facons il n'y a pas besoin de faire des calculs savants pour voir que c'est du BS. Prend une photo de die, regarde la taille du coeur entier et des L1 associes. Duplique et regarde la surface. Meme sans compter de surtaxe pour gerer les clusters ca ne peut pas faire 5% du core vu que ce que tu as duplique occupe plus de 5% de la surface du core au depart.

Il doit bien y avoir qq part un die de phenom ou meme de K8 avec des labels qui permet de faire ce genre d'exercice. Si ton L1 et tes unites entieres occupent moins de 5% de ton core, ton archi a un gros probleme d'efficacite a la base.
Il ne faut pas compter les L2, L3 et autres dans ce genre de calcul vu que cela ne fait qu'introduire du bruit.

Je ne dis pas que ce n'est pas rentable en terme de perf/unite de surface, juste que de dire que le cout est comparable a Hyperthreading est errone.

[newbie06]

http://chip-architect.com/news/2007_...us_Images.html

[Lionel33]

Hyperthreading c'est 5% du core qui represente lui meme moins de la moitie de la surface du die... Ca ne s'aligne quand meme pas. De toutes facons il n'y a pas besoin de faire des calculs savants pour voir que c'est du BS. Prend une photo de die, regarde la taille du coeur entier et des L1 associes. Duplique et regarde la surface. Meme sans compter de surtaxe pour gerer les clusters ca ne peut pas faire 5% du core vu que ce que tu as duplique occupe plus de 5% de la surface du core au depart.

Il doit bien y avoir qq part un die de phenom ou meme de K8 avec des labels qui permet de faire ce genre d'exercice. Si ton L1 et tes unites entieres occupent moins de 5% de ton core, ton archi a un gros probleme d'efficacite a la base.
Il ne faut pas compter les L2, L3 et autres dans ce genre de calcul vu que cela ne fait qu'introduire du bruit.

Je ne dis pas que ce n'est pas rentable en terme de perf/unite de surface, juste que de dire que le cout est comparable a Hyperthreading est errone.

Je comprend effectivement ,qu'en regardant les schémas c'est trop peu les 5 %.
L'explication vient du forum AMD ,ou forcément ils essaient d'enjoliver leur produit (le contraire aurait été étonnant ).
De toute façon ,sans avoir les détails complets de l'architecture ,on ne peut que faire des suppositions mais j'ai hâte quand même d'avoir plus de détails car le bulldozer me paraît prometteur (malgré quelque crainte sur l'équilibre de l'archi) .

J'ai lu quelque part que Magny-cours est prévu pour Q1/Q2 2010 ,est-ce que quelqu'un sait me confirmer (ou infirmer) cette info ?

[fefe]

http://chip-architect.com/news/2007_...us_Images.html

Parfait, la derniere image de la page illustre exactement mes pensees. Merci.

J'ai aussi hate d'en savoir plus car leur core semble etre bourre d'innovations interressantes. Innovations qu'ils sont de nouveau les premiers a amener dans le monde du x86 (bon encore une fois l'Alpha avait ca avant, mais tout le monde sait d'ou vient Dirk Meyer ).

[Neo_13]

Tu serais pas en train de dire que tout ce qu'AMD a amené, ils l'ont récupéré des cadavres chauds de Nexgen et celui, de moins en moins chaud d'Alpha, quand même ?

[fefe]

Ca reste mieux de trier les idees venant de cadavres (qui forcement avaient eu de mauvaises idees sinon ils ne seraient pas morts si vite) que d'attendre que ton competiteur direct les fasse pour voire si ca vaut le coup d'essayer de faire quelque chose non ?

Et puis ce n'est pas parce que l'alpha avait du clustering des unites entieres et pas du FP qu'ils l'utilisaient comme AMD a propose de le faire dans bulldozer: partitionner pour ameliorer le multi-thread, l'alpha utilisait les 2 cluster pour accelerer le meme thread.

[Neo_13]

Ca reste mieux de trier les idees venant de cadavres (qui forcement avaient eu de mauvaises idees sinon ils ne seraient pas morts si vite) que d'attendre que ton competiteur directe les fasse pour voire si ca vaut le coup d'essayer de faire quelque chose non ?

Et puis ce n'est pas parce que l'alpha avait du clustering des unites entieres et pas du FP qu'ils l'utilisaient comme AMD a propose de le faire dans bulldozer: partitionner pour ameliorer le multi-thread, l'alpha utilisait les 2 cluster pour accelerer le meme thread.

[Oxygen3]

Voilà c'est ça. Le message officiel d'AMD c'est 1 module = 2 cores, mais le terme "module" est provisoire, ils cherchent un truc plus kikoolol pour le marketing. Je pense qu'on devrait parler d'icores (int-core) et de modules pour plus de clarté, mais bon, la clarté et le marketing...

C'est ce que je comprends aussi. Reste que j'ai du mal avec leurs estimations de gains de 80% contre une surface de 15% si leur calcul final est fait sur le même nombre d'i-core ou pas :/

[Alexko]

C'est ce que je comprends aussi. Reste que j'ai du mal avec leurs estimations de gains de 80% contre une surface de 15% si leur calcul final est fait sur le même nombre d'i-core ou pas :/

Ils disent juste qu'en passant d'un icore à deux, on gagne 80 % et que ça coûte 12 % de surface en plus. Mais j'imagine qu'ils partent du principe qu'il y a déjà 2 FMAC de 128 bits et un gros L2. Sachant que c'est probablement ça qui bouffe le plus de surface, 12 % à l'échelle du module ça ne me semble pas complètement improbable.

[Alexko]

Commentaires de Dresden Boy sur les articles de Goto