La gamme Alder Lake ne provient pas du même die, comme chez les rouges

par Pyvesd d'Occitanie, le Samedi 30 Octobre 2021 à 21h24

justement j'ai cherché l'info pour les 65w et rien trouvé? un lien stp?

Ça y est, ça arrive
un grand lien tout pourri
Ça se confirme, les i5 n'auront pas de E-Cores, à l'exception des K/KF.
Mais le 12600 est un 6/12 P de 125W!

Publié ici il y a 5 jours.
Le Comptoir pourrait s'assurer que ce n'est pas un fake et en faire une brève. Je ne suis pas sûr qu'un site anglophone l'ai déjà déniché

Ahah, il y en a déjà un en circulation
Reste à déterminer la surface de tout ce petit monde (209mm² pour la total, MSI n'était pas très tombé loin)

edit: ok, donc pluôt dans les 11mm² pour un GC et 3.5mm² pour un Gr.

Très bonne remarque. Avec deux types de cœurs chacun optimisé dans son domaine, fini les compromis de design

Et tu donnes une nouvelle métrique intéressante à analyser: la performance par surface occupé.
Faudra attendre les dieshots pour affiner ça, mais si j'en crois l'image ci-dessus, les golden cove pourrait bien occuper dans les 20mm²? (difficile de dire combien retirer des bordures de la capsule et pour la partie IO....)
Si on peut mettre 4 Gracemont dans un GC (d'après les slides Intel, peut-être trompeur...), ça en ferait des cœurs de 5mm²?
Un Zen 2 en occuperait 8mm², tandis que Zen 3 ne serait que 15% plus gros (sur sa partie µArchi, mais surface L2/L3 probablement identiques).
Donc voilà le grand secret d'AMD: ses Zen sont en fait des cœurs LITTLE, mais avec toute la puissance d'un big
Du big.LITTLE tout en un

Si les CPU à 12 cœurs et plus sont sous utilisés par les jeux vidéos, c'est uniquement parce qu'ils sont minoritaires dans les configurations de gamers. Faut pas croire que les créateurs de jeux vidéos sont incapables de les mettre à profit

Pour la plupart des mortels, multiplier davantage les cores a effectivement un intérêt plus limité que pour quelqu'un qui doit compiler des gros projets, éditer des vidéos, ou qui bosse d'une manière générale. Pour ceux là ça ne sera pas toujours plus performant de multiplier les big cores que les efficient cores. Si on est limité par la surface et/ou le TDP, on voit que les E-cores débitent plus à surface ou puissance équivalente que les P-cores. Ca n'est pas qu'une question de plage de fonctionnement, certes on gagne déjà énormément en efficacité énergétique à undervolter/underclocker une puce, mais les choix architecturaux jouent aussi beaucoup.

On peut aussi se dire que l'existence de cores efficients permet de justifier d'aller plus loin dans la recherche de performances maximales pour les performance cores (au détriment de la conso). Un peu comme le SMT qui est un moyen de rentabiliser un back end d'exécution très large, qui serait cher payé pour accélérer modestement un thread, mais qui est bien mieux exploité avec deux (ou plus).

A voir dans ce cas ce que donneront leur 32 E-Cores dans le futur.
Mais je reste sceptique, on a déjà du mal à savoir quoi faire des 16 cœurs AMD, dont ont dit que c'est beaucoup trop pour les jeux, et le Comptoir avait sorti un édito démontrant qu'on allait vite atteindre un plafond de verre, niveau parallélisation. Que les CPU avaient beau gagner des cœurs d'années en années (merci AMD), nos logiciels ne sauront pas les exploiter pleinement, car pas disposé à être aussi massivement parallélisé (au contraire des appli pro, scientifique et cloud).

Et en attendant, si on est capable de multiplier les big (AMD), ça sera par définition toujours plus perfs que de multiplier les LITTLE.
Mais je suis parfaitement conscient qu'à trop multiplié les bigs, il va falloir diminuer la fréquence all-cores, pour tenir le TDP qu'on s'est fixé. Et qu'à un moment donnée, des petits cœurs tournant plus vites sans surchauffé (mais est-ce vraiment le cas de ces Gracemont? Je ne suis pas sûr qu'ils aient des vitesses de pointe plus élevé ), pourront surpasser des big-cores en quantité équivalente, mais tournant plus lentement

AMD n'a juste pas besoin de zieuté du côté de cette stratégie des LITTLE cores à la Intel/Apple, car ils l'ont redit encore récemment, ils vont encore être capable dans les années à venir d'améliorer leur cœurs Zen, tant en perf qu'en efficacité énergétique, et pouvoir ainsi continuer à le multiplier sans trop de soucis, grâce aux prochains nodes TSMC.

Pour le débat CISC vs RISC, la complexité de la puce dépend principalement de tout un tas de choses qui sont indépendantes du jeu d'instructions, la prédiction de branchement, l'exécution spéculative, le réordonnancement des instructions, les unités de calcul (vectorielles), tout ça sont communs aux deux courants philosophiques. Là où le x86 traine son boulet c'est le décodage des instructions, plus difficilement parallélisable que les jeux d'instructions RISC, c'est compensé par un cache de micro instructions de plus en plus large mais ça n'est pas gratuit. Ca doit rajouter un ou deux étages dans le pipe qui pénalisent un peu les mauvaises prédictions de branchement. Là où j'ai plus d'inconnues, c'est l'impact sur le parallélisme entre instructions (et donc l'IPC), vu le nombre réduit de registres exposés, et tous les effets de bords des instructions CISC, pas simples à paralléliser. Un argument toujours valable pour les jeux d'instructions RISC c'est qu'ils sont prévus dès le départ pour pouvoir facilement paralléliser les instructions dans le CPU plutôt que d'être pratiques à programmer pour un humain.

Pour ajouter mon grain de sel, le débat CISC/RISC qui est très intéressant ne me semble pas pertinent en ce qui concerne les P et les E cores. Tel que je le vois, c'est toujours important de pousser la perf par thread (problèmes latency bound, d'où l'existence des P cores), mais quand tu commences à vouloir pousser sur plus de 8 threads, en général c'est plutôt le throughput qui t'intéresse, donc des cores plus simples qui débitent un peu moins mais qui sont beaucoup plus économes en énergie et en surface sont bien plus adaptés pour ces tâches. C'est une sorte d'intermédiaire avant les tâches massivement parallèles que les GPU raffolent. Ca ne fait pas intervenir l'idée qu'Intel s'est retrouvé contraint de suivre cette voie pour être concurrentiel, c'est juste une bonne idée, qui a déjà fait ses preuves dans les smartphones. Rien que le fait que le M1 d'Apple fasse pareil devrait convaincre que c'est une bonne idée

Oui mais plus on en rajoute, plus on complexifie. Tout le défie est de garder les choses simples, mais ce n'est pas toujours évident.
Et si les cœurs Intel / AMD sont en fait composé de jeux réduit de µinstructions simples, à un moment donnée, les deux risquent de se croiser

A moins que la question soit uniquement les jeux d'instructions exposé au publique?
Mais dans ce cas tout le boulot en revient aux compilateurs, plus à l'architecture. Sont-ils plus à l'aise avec un jeu d'instruction CISC ou RISC? Il serait là le débat?
Soit c'est le compilateur qui converti en instructions simples, soit le décodeur x86.

par _m_, le Dimanche 31 Octobre 2021 à 10h06

Pas de mal, c'est toujours intéressant. Pas de nouvelles instructions sur les cœurs ARM eux-même, au fil des années?

Rien que pour le passage en 64 bits ils en ont pas mal rajouté / modifié.
Le R de RISC est pour réduite, le C dans CISC est pour complexe, ça n'implique pas une absence de jeux d'instruction pour l'un et la présence pour l'autre.

Un simple regard dans la documentation illustre la différence entre les 2 familles :

Pour ARM dans sa v8

Du coté de chez Intel

Pas de mal, c'est toujours intéressant.

Pas de nouvelles instructions sur les cœurs ARM eux-même, au fil des années?