Micro-Architecture

[newbie06]

Le 45nm devrait faire en sorte qu'on atteigne des fréquences raisonnables en restant dans l'enveloppe des 2W... Il semble qu'il se place plutôt en face des processeurs ARM, avec la compatibilité x86 en plus.

Pour la conso on verra quand il sortira

Quant aux ARM qu'il aura en face, ce sera du OoO mis dans des SoC complets (le Silverthorne aura toujours besoin d'un controleur de memoire externe par exemple)... Si tu veux un exemple de SoC bases sur un ARM puissant (mais pas OoO) regarde ce que fait TI sur OMAP3430 et OMAP35x.

Si tu consideres que la compatibilite x86 est un plus, je ne discuterai pas, mais je note quand meme que depuis un moment les binaires sont compiles pour des x86 OoO, donc les perf seront mediocres en l'absence d'un scheduling adequat.

Pour le flush partiel, j'imagine que c'est par voies de cache. Donc la moitié du cache qui est flushée contenait à la fois des données utiles et moins utiles? (c'est-à-dire : on ne peut pas choisir la moitié qui nous arrange?)

Si ca se fait par voie de cache, et que tu veux garder certaines donnees en cache, il faut pouvoir pre-charger le cache dans les ways que tu souhaites conserver en utilisant du cache lock par way. Je ne sais pas si ca existera aussi...

D'un autre cote, peut-etre qu'on pourra faire du flush par adresse, ca existe sur d'autres architectures.

[Møgluglu]

Pour la conso on verra quand il sortira
Quant aux ARM qu'il aura en face, ce sera du OoO mis dans des SoC complets (le Silverthorne aura toujours besoin d'un controleur de memoire externe par exemple)... Si tu veux un exemple de SoC bases sur un ARM puissant (mais pas OoO) regarde ce que fait TI sur OMAP3430 et OMAP35x.

À terme, le Silverthorne devrait être intégré dans un SoC aussi (ça semble effectivement la seule solution raisonnable pour ce type de machine).
Roadmap : http://pc.watch.impress.co.jp/docs/2...gai419_01l.gif

Si tu consideres que la compatibilite x86 est un plus, je ne discuterai pas, mais je note quand meme que depuis un moment les binaires sont compiles pour des x86 OoO, donc les perf seront mediocres en l'absence d'un scheduling adequat.

Tout-à-fait d'accord, c'est d'ailleurs ce que je clame ici régulièrement à propos de Larrabee .

Si ca se fait par voie de cache, et que tu veux garder certaines donnees en cache, il faut pouvoir pre-charger le cache dans les ways que tu souhaites conserver en utilisant du cache lock par way. Je ne sais pas si ca existera aussi...

Par contre, s'il faut par exemple migrer toutes les données récemment utilisées sur une seule voie de cache avant d'éteindre les autres voies, ça doit réclamer une énergie non négligeable...

D'un autre cote, peut-etre qu'on pourra faire du flush par adresse, ca existe sur d'autres architectures.

Ce qui doit nécessiter une gestion très fine de la distribution de l'alimentation dans le CPU?

[Paul Verveine]

Le Silverthorne/Diamondville s'appelle maintenant officiellement Atom.
Alors que VIA se met à l'OoO "lourd", Intel fabrique donc des procos nains...

Le coeur in-order semble assez conventionnel, avec une ALU et une FPU à 2 voies chacune, et du SMT.
Des datapaths SIMD en 128-bits pour les entiers et 64-bits pour les flottants.

Pour l'économie d'énergie, on a :
- Cache L2 partiellement flushable
- FSB basculable en mode CMOS
- Pour le sommeil profond, possibilité de n'alimenter qu'une petite zone de SRAM basse conso contenant l'état du processeur (comme sur le Penryn?).

J'oublie certainement tout plein de choses...

sources en vrac :
http://arstechnica.com/news.ars/post...obile-cpu.html
http://www.anandtech.com/cpuchipsets...spx?i=3230&p=1
http://pc.watch.impress.co.jp/docs/2.../kaigai421.htm

Le 45nm devrait faire en sorte qu'on atteigne des fréquences raisonnables en restant dans l'enveloppe des 2W... Il semble qu'il se place plutôt en face des processeurs ARM, avec la compatibilité x86 en plus.

Pour le flush partiel, j'imagine que c'est par voies de cache. Donc la moitié du cache qui est flushée contenait à la fois des données utiles et moins utiles? (c'est-à-dire : on ne peut pas choisir la moitié qui nous arrange?)

tu regardes pas les news cpc de teraboule ?

[fefe]

Pour la conso on verra quand il sortira

Quant aux ARM qu'il aura en face, ce sera du OoO mis dans des SoC complets (le Silverthorne aura toujours besoin d'un controleur de memoire externe par exemple)... Si tu veux un exemple de SoC bases sur un ARM puissant (mais pas OoO) regarde ce que fait TI sur OMAP3430 et OMAP35x.

Oui, ce sera toujours une archi multi-chip, et la dessus les plateformes ARM garderont un avantage serieux.

Si tu consideres que la compatibilite x86 est un plus, je ne discuterai pas, mais je note quand meme que depuis un moment les binaires sont compiles pour des x86 OoO, donc les perf seront mediocres en l'absence d'un scheduling adequat.

Re /agree, ca fait 15 ans que les codes x86 ne sont plus optimises pour les in-order donc si on fait tourner du binaire existant ca va etre bien lent. En revanche les compilos optimisant pour pentium existent, et je suis certain qu'Intel ne va pas le sortir sans sortir une version d'ICC ni avoir travaille avec MS/gcc (a moins que resortir les options de compil p5 reglent la chose, mais j'ai un gros doute vu la profondeur du pipeline et les changements de latence)

Si ca se fait par voie de cache, et que tu veux garder certaines donnees en cache, il faut pouvoir pre-charger le cache dans les ways que tu souhaites conserver en utilisant du cache lock par way. Je ne sais pas si ca existera aussi...

Tu mets un masque qui est teste lors de l'ecriture du cache, et tu n'ecris que dans les voies qui match le mask, et tu eteints les voies qui sont a zero (apres avoir write-back toutes les donnees dans l'etat M). Il n'y a pas particulierement besoin de charger les donnees dans des voies specifiques, vu que c'est pour le power management les changements d'etat sont rares, et tu peux laisser le cache se recharger tout seul (si les donnees etaient dans les voies flushees). Tu perds un peu de perf mais c'est simplissime.


D'un autre cote, peut-etre qu'on pourra faire du flush par adresse, ca existe sur d'autres architectures.[/QUOTE]

tu regardes pas les news cpc de teraboule ?

Si et comme je pointe dans le thread de comment, la news est erronee .

Tout-à-fait d'accord, c'est d'ailleurs ce que je clame ici régulièrement à propos de Larrabee .

Sauf que Larrabee tu ressors ton vieux compilo P5 et les optims tiendront la route, contrairement au pipeline a 16 etages au SMT et aux latences ala P4 de Silverthorn.

[Paul Verveine]

Si et comme je pointe dans le thread de comment, la news est erronee .

en fait je répondais à mogluglu mais j'avais pas vu la page suivante

[Møgluglu]

tu regardes pas les news cpc de teraboule ?

Nan je lis que les news qui viennent de sources russes

'temps pour moi, je cherchais encore le RSS hardouère-only, enfin tant mieux dorénavant je me cultiverai sur les jeux vidéo...

Sauf que Larrabee tu ressors ton vieux compilo P5 et les optims tiendront la route, contrairement au pipeline a 16 etages au SMT et aux latences ala P4 de Silverthorn.

Pourtant je m'attendrais à ce que les latences et les pipelines soient beaucoup plus longs dans un GPU ou on peut masquer la latence avec plein de parallélisme de données que dans un CPU embarqué principalement mono-tâche...
Mon G86 il prend 18 cycles pour exécuter une addition .

[Paul Verveine]

'temps pour moi, je cherchais encore le RSS hardouère-only, enfin tant mieux dorénavant je me cultiverai sur les jeux vidéo...

bonne idée, je note et transmets à qui de droit

[fefe]

Mon G86 il prend 18 cycles pour exécuter une addition .

Ton G86 il maintient combien de threads en parallele pour recouvrir cette latence ?

[newbie06]

Pourtant je m'attendrais à ce que les latences et les pipelines soient beaucoup plus longs dans un GPU ou on peut masquer la latence avec plein de parallélisme de données que dans un CPU embarqué principalement mono-tâche...
Mon G86 il prend 18 cycles pour exécuter une addition .

Et ton pauvre GPU il a beaucoup de mal a executer efficacement ses sauts

[Møgluglu]

Ton G86 il maintient combien de threads en parallele pour recouvrir cette latence ?

Vu comme ça, d'accord, le compilateur n'en a rien à faire de la vraie latence...

Et ton pauvre GPU il a beaucoup de mal a executer efficacement ses sauts

Donc il a quand-même besoin d'un compilo plus malin que celui du P5
(surtout sur du x86!)

[newbie06]

Donc il a quand-même besoin d'un compilo plus malin que celui du P5
(surtout sur du x86!)

Pas sur, je ne pense pas que ton GPU ait une unite de prediction de branchement, alors que ton P5 si

EDIT: y'a des matins ou je reponds trop vite ; je laisse ma reponse pour montrer a quel point c'est vrai

[fefe]

Le P5 a une BPU et surtout un pipeline tres court, donc les penalites liees a du code spaghietti sont nettement plus limitees sur un P5 que sur un steam processor classique (a pipeline long).

[Franck@x86]

y'a eu des compilos P5 ?
je ne me rappelle que des heures à pairer les isntructions asm à la main pour occuper les deux pipes, si y'avait eu un outil il aurait été le bienvenu.

[fefe]

Dans mes souvenirs les premiers compilos sachant le faire correctement sont arrives avec le P55C, je deterrerai quelques archives pour verifier ca .

[newbie06]

Je me souviens de certains codes ecrits en C et qu'il ne fallait compiler qu'avec -O1 pour eviter que le compilo essaie de scheduler. Le mec mettait deux statements C par ligne pour bien montrer le pairing. C'etait une autre epoque ma bonne dame

[Neo_13]

Juste pour info : quand on parle de methode de codage ASM sur des CPU de 1993, on passe pour des vieillards

[Tramb]

Juste pour info : quand on parle de methode de codage ASM sur des CPU de 1993, on passe pour des vieillards

Quoi t'aimes pas tailler des u-pipe et des v-pipe?

[Neo_13]

Quoi t'aimes pas tailler des u-pipe et des v-pipe?

ce qui m'inquiète, c'est que j'ai compris cette phrase alors qu'en 1993, j'avais 12 ans...

Je suis un geek de naissance, apparement

[Tramb]

ce qui m'inquiète, c'est que j'ai compris cette phrase alors qu'en 1993, j'avais 12 ans...

Je suis un geek de naissance, apparement

Apparemment.
Mais c'est pas très grave hein!

[Neo_13]

ben ça dépend... si t'as une formation en info et/ou que c'est ton métier, c'est même plutot bon... mais je n'ai ni l'un ni l'autre... :D

[Foudge]

Oui enfin, ton métier n'est pas à 1000 lieux du domaine des processeurs.
T'es même en plein dedans si je ne me trompe

[newbie06]

ben ça dépend... si t'as une formation en info et/ou que c'est ton métier, c'est même plutot bon... mais je n'ai ni l'un ni l'autre... :D

Hu ? Tu te fais des illusions sur les formations infos et/ou les etudiants qui y participent...
J'ai donne plusieurs cours en maitrise d'info, orientes code gen et architecture.
Les premiers ont ete faits vers 1996 et les derniers vers 2001. Entre ces deux annees la maitrise d'info de Nice etait passee de numerus clausus a qui n'en veut vient. Ca fait une enorme difference. Il y a ptet eu aussi l'invention de Java au milieu.

Bref, j'en ai retire que les etudiants ils s'en tapent de comment ca marche, du moment qu'ils peuvent lancer leur IDE et foutre des boi-boites partout. Il y a toujours les furieux qui veulent tout comprendre (et c'est ceux-la qu'on aime quand on enseigne ), mais l'immense majorite va sortir de la sans savoir ce que veut dire optimiser.

[Neo_13]

c'est pour ça que je disais "c'est plutot bon" car ayant fait une grande ecole avec une filière info, j'ai bien observé qu'en très grosse majorité, ils ne savent rien des ordinateurs, et pas grand chose de tout ce qui est à un niveau inférieur au java (meme la jvm, c'est obscur)

Et je me souviens de :
- on peut rien faire avec ça, c'est pas assez puissant
- c'est ennuyeux, car on a pas le budget pour tout rénover, mais on va essayer. Et si on prend du neuf, vous ferez comment ?
- ben en java, avec la puissance disponible, on va pas se priver...

Ceci a conclu le projet, et deux autres mecs sont intervenus et ont fait du pur asm, et ça a roulé

[fefe]

Hu ? Tu te fais des illusions sur les formations infos et/ou les etudiants qui y participent...
J'ai donne plusieurs cours en maitrise d'info, orientes code gen et architecture.
Les premiers ont ete faits vers 1996 et les derniers vers 2001. Entre ces deux annees la maitrise d'info de Nice etait passee de numerus clausus a qui n'en veut vient. Ca fait une enorme difference. Il y a ptet eu aussi l'invention de Java au milieu.

Bref, j'en ai retire que les etudiants ils s'en tapent de comment ca marche, du moment qu'ils peuvent lancer leur IDE et foutre des boi-boites partout. Il y a toujours les furieux qui veulent tout comprendre (et c'est ceux-la qu'on aime quand on enseigne ), mais l'immense majorite va sortir de la sans savoir ce que veut dire optimiser.

Oui l'objectif des cours est en general qu'ils aient quelques vagues souvenirs quand ils codent plus tard, et que certains se posent des questions et fassent des recherches le moment donne. Les cours classiques avec cet objectif pour moi etaient sur les stack overflow et la stabilite numerique. Le comment ca marche, a part 3 geeks tout le monde faisait du bachotage. Et c'est marrant ma periode d'enseignement est exactement la meme, juste une autre uni .
C'est effectivement la periode java, mais aussi la transition pascal->caml dans l'enseignement de l'algo .

Bon sinon ISCA est le mois prochain je ferai peut etre un effort pour reveiller ce topic meme si je n'y serai pas.

[Oxygen3]

Oui l'objectif des cours est en general qu'ils aient quelques vagues souvenirs quand ils codent plus tard, et que certains se posent des questions et fassent des recherches le moment donne.

Gagné
C'est le but de 95% des cours d'école d'ingé.

Et apprendre à apprendre à chercher l'info aussi

[Yasko]

Petite question d'ordre général :
Pourquoi dans un CPU multiplier le nombre de cores plutôt que multiplier le nombre de voies (/issue) dans un core. Pourquoi accoler 2 cores 4 issues plutot qu'un seul 8 issues ?
Cela scale moins bien ? (limitation lié au cache, aux registres internes, ... Si oui, pourquoi ne pas les doubler aussi dans ce cas ?)

[newbie06]

En vrac : plus tu dois sortir d'instructions plus tu dois augmenter la bande passante de ton I cache, plus tu dois extraire de parallélisme, plus tu satures ta file de registres, plus tu satures ton unité de renommage, etc.

EDIT: un autre point : quand tu augmentes la taille d'une cache, tu augmentes son temps d'accès, idem pour les files de registres.

[Yasko]

plus tu dois extraire de parallélisme

Oui effectivement, j'avais zappé mais on est sur le même thread, contrairement au multicore...
Et même avec du SMT en plus, je suppose que ça reste moins efficace.

[fefe]

C'est une bonne question, je vais essayer d'y repondre en details.

Il y a pas mal de problemes, le premier est de rester efficace dans ta depense de hardware. En effet l'equilibre aujourd'hui est atteint avec 2-3 unites entieres un Fadd un Fmul 1 ou 2 load et 1 store sachant que suivant que tu es en entier ou en flottant tu auras tendance a en utiliser entre 3 et 4 en parallele quand tout va bien mais pas plus.
Donc pour conserver le meme equilibre effectivement tu dois doubler tes unites, il n'y a pas vraiment d'intermediaire efficace.

Jusque la ca va c'est juste une replication de hardware. Maintenant il faut delivrer les donnees de tes registres a ces unites et consommer les resultats, ca te fait un reseau d'interconnection d'une complexite telle si tu veux assurer tous les bypass direct que rien que son cout et la difficulte de le mettre en oeuvre justifient de ne pas faire une telle machine.

Pour resoudre ce probleme des architectes ont invente des methodes de clustering, il n'y a plus tous les bypass, et on se debrouille pour lancer les instructions ayant besoin de bypass vers le meme cluster. On perd un peu de performance lorsque l'on doit envoyer les resultats d'un cluster a l'autre donc on perd en scaling.

Ensuite l'acces aux registres, a supposer que tu supportes 4 acces simultane a ton ban de registre cela fait 8 ports en lecture 4 en encriture, si tu doubles ca la complexite de ton ban de registre explose et tu n'arriveras pas a maintenir la meme frequence, ou si tu y arrives la surface aura eteprobablement multipliee par 4. Solution, cluster aussi les registres, maintenant quand on a besoin d'instructions qui ne sont pas dans ton ban de registre il faut dynamiquement emettre une instruction pour la copier depuis un autre ban de registre. Ca coute encore un peu de performance et ce n'est pas super simple.

Maintenant l'OOO, si tu dois alimenter 2x plus d'unites fonctionnelles il te faut extraire 2x plus d'ILP, donc on double l'OOO ? Non, pour doubler l'ILP des machines actuelles il faut probablement faire plus de 8x sur la profondeur de l'OOO. Ca devient difficile de maintenir la meme frequence en faisant x8 sur ces structures, donc tu es oblige de faire des schedulers a plusieurs niveaux, qui sont gros, complexes, et... perdent de la performance vu qu'ils allongent le pipeline.

L'allocation (tu remarques que je remonte les etages de pipeline), maintenant en plus du renommage de registre qui doit etre fait sur 2x plus de registres en meme temps (nettement plus de 2x plus dur) il te faut predire dans quel cluster tu veux tes registres et vers quel cluster envoyer tes instructions, un algorithme stupide est implementable sans ajouter d'etage de pipeline, mais un algo qui ne perd pas trop de performance est oblige d'essayer d'analyser l'arbre de dependances et tu perds directement au moins un cycle a le faire, donc tu rajoutes encore un etage de pipeline.

Le frontend, ahahah ! Maintenant au lieu de decoder 4 instructions il t'en faut 8, facile tu doubles tout ? Oui et non, maintenant il va te falloir charger 2x plus de donnees du cache d'instruction, et predire 2x plus de branchements par cycle, sinon la deuxieme moitie de tes decodeurs risque d'etre peu occupee par manque de capacite a predire des branchements. Faire plusieurs predictions en meme temps en plus de demander plus de ports d'acces sur des structures complexes, correspond aussi a predire plus loin dans le futur, donc plus dur. Si tu veux garder le meme taux de succes - en pratique tu veux l'augmenter vu que ton pipeline s'allonge - il va falloir serieusement ameliorer le predicteur, et au niveau actuel des predicteurs, il faut des investissements massifs non seulement en hard mais aussi en recherche...

Apres, si tu as reussi a faire tout ca, il reste le sous systeme memoire. Il va te falloir 2x plus de bande passante vers tes caches prives, alors qu'en multi cpu tu repliques juste les caches. Si tu ajoutes simplement des ports de lecture/ecriture, la complexite de tes structures explose et les timings aussi, donc tu utilises des techniques de "banking", mais lorsqu'il y a des conflits de bancs tu perds de la performance.

Tu es super heureux tu vient de creer un coeur d'execution qui a un IPC 2x superieur a son predecesseur, hourra ! Ah non dommage, il faut encore acceder a la memoire... Et sa latence n'a pas change et elle conditionne une part non negligeable de ta performance, donc ton IPC est plutot 1.6x plus rapide. Pour atteindre 2 il va falloir reduire la latence de ta memoire de maniere significative (et avoir la bande passante mais ce n'est pas le plus dur cela coute juste cher sur la carte mere). Pour reduire la latence typique de la memoire, on peut soit augmenter la taille des caches, soit ameliorer les prefetchers, soit arreter d'utiliser de la DRAM pour de la SRAM mais on va dire que ce n'est pas une option.

A priori il te faut les 2, caches et prefetchers. Augmenter la taille des caches tend a augmenter un peu leur latence, donc il faut les augmenter encore un peu plus pour compenser ca (cercle un peu vicieux), ce n'est pas trop dur mais ca consomme beaucoup de transistors. Les prefetchers maintenant, ca ne consomme pas beaucoup de surface et c'est super efficace, mais un peu comme les predicteurs de branchements, il n'y a plus beaucoup de marge de progression pour les ameliorer, a part peut etre les techniques de speculative multithreading.

Tu peux essayer d'employer les cycles inactifs de ton cpu (qui en a de plus en plus vu sa largeur actuelle) pour executer speculativement au dela des retours d'appels de fonctions en predisant que le code qui suit l'appel de fonction est independant de celle-ci. Cela ne marche pas trop mal, mieux que l'on pense en tout cas pour lancer les acces memoire en avance, pas formidable par contre pour calculer les resultats en avance il ne faut pas rever. Bien sur il faut toute la logique pour gerer ce thread speculatif, annuler ce qu'il aurait pu charger dans les caches avant que ca ne soit utilise si la speculation etait erronee, vider le pipeline de ces instructions separement, s'assurer qu'il n'a pas pollue des predicteurs (donc lui en ajouter)...

Voila, on vient de faire un super CPU pour les applis single threads, il tient probablement pas loin de l'espace de 4 cpus actuels. Si notre appli n'est pas multithreadable c'est la meilleur option d'un facteur 2, si elle l'est, on perd un facteur 2 en perf.

En plus de tout ca, l'equipe pour designer ce CPU est probablement 3x plus grosse que l'equipe pour designer le quad core etant donne la complexite du design. Donc le projet est nettement plus couteux, lent et sujet a problemes.

Le choix pour les fabriquants de cpus a ete assez simple quand ils ont reussi a se convaincre que les gens du soft allaient ecrire des threads.

La vache ... sacre pave...

[Alexko]

Sacré pavé, mais très intéressant ! ;-)