Penryn et innovations

[Neo_13]

Je ne me rappelle pas d'un topic là dessus.

Penryn sera un die-shrink du Conroe. A prévoir :
- SSE4 qui permet des résultat améliorés en traitement vidéo
- division améliorée par passage en radix16 plutot qu'en radix4 (Quelles sont les opérations qui vont bénéficier de cette amélioration ? Uniquement idiv, ou d'autres opérations passent par le même tuyau et vont se retouver accélérer)
- 45nm
- 6Mo de cache L2 par dual core au maximum (4 sur Conroe)
- améliorations de design ?

[fefe]

Diviseur radix16:
-idiv
-fdiv x87 et SSE
-fsqrt x87 et SSE

J'ai poste pas mal de trucs la dessus dans d'autres threads mais j'ai la flemme de copier coller .

SSE4:
Ce qui ameliore massivement la compression video c'est l'instruction MPSAD (calcule plusieurs sommes de valeurs absolues de differences en parallele, l'element de base de l'estimation de mouvement).

[Foudge]

A noter qu'il s'agit du SSE4.1
Mais qu'en est-il du SSE4.2 ? Nehalem (ce qui serait donc à ajouter dans l'autre topic) ?

edit: a priori, ce serait bien sur le Nehalem

[Neo_13]

si les spécialiste de l'ASM veulent bien C/C la liste des instructions, avec éventuellement un pti commentaire

[Foudge]

Ce PDF est pas mal foutu. Par contre je laisse les spécialistes commenter l'utilité de tel ou tel (groupe d')instruction.
https://intel.wingateweb.com/publish...005_100Eng.pdf

[Møgluglu]

Je suis pas spécialiste, mais l'opérande implicite dans les BLENDV*, je trouve ça très moche. L'approche d'AMD avec 3 opérandes est nettement plus élégante (même si elle met plus de pression sur le cache d'instruction et le décodage).

Ça revient à avoir un registre de prédicats spécialisé, mais pas totalement...

Sinon pour le produit scalaire DPP, ils ne précisent pas les précisions intermédiaires, l'ordre d'évaluation, la compliance IEEE... C'est probablement équivalent à un MULP suivi de deux HADDP?

[claneys]

Un peu HS mais est il possible de mettre les topic "<processeur> et innovations" en post-it ?

ça fait un peu référence sur ces dit processeurs. Bon ok ils sont déjà en haut du forum mais pour éviter qu'ils descendent se serait bien.

[Lissyx]

Un peu HS mais est il possible de mettre les topic "<processeur> et innovations" en post-it ?

ça fait un peu référence sur ces dit processeurs. Bon ok ils sont déjà en haut du forum mais pour éviter qu'ils descendent se serait bien.

Elle est déjà notée "Importante" dans VBulletin, je trouve rien explicitement plus fort

[Neo_13]

Elle est déjà notée "Importante" dans VBulletin, je trouve rien explicitement plus fort

En fait, j'ai mis "Important" pour les 3 suite à cette remarque que j'ai trouvé judicieuse:P

[fefe]

Je m'y prendrai probablement en quelques coups et finirai surement pas, mais je vais essayer d'eclairer un peu sur l'utilite de certaines de ces instructions:

Encodage video
L'instruction qui change le plus de perf sur une appli donnee est tres certainement MPSADBW combinee avec PALIGNR et PHMINPOSUW, et comme dit dans les slides c'est la compression video. La base de la compression video post M-JPEG (donc depuis MPEG1) est l'estimation de mouvement et la combinaison de ces 3 instructions permet d'en faire l'essentiel.
M-JPEG consistait juste a coller des images JPEG les unes apres les autres donc on peut meme eviter de s'en souvenir. Il y a aussi d'autres formats que MPEG* typiquement H26* mais ils ont essentiellement suivi la meme evolution a quelques details pres.
Donc l'apport de MPEG par rapport a MJPEG etait que l'on decomposait l'image en sous blocs 16x16 (la taille d'un bloc JPEG) et on cherchait dans l'image precedente si on retrouvait un bloc similaire (pas exact, just suffisament proche). Si on en trouve un on encode ce bloc comme un vecteur de deplacement (X,Y) et une eventuelle compensation (la difference entre les 2 blocs, qui vu qu'elle est minime est tres compressible). Si on ne trouve pas de bloc correspondant on peut continuer a encoder le bloc en JPEG normal. Dans MPEG1 on alterne les trames predites par cet algorithme et des trames de reference. dans MPEG2 il y a des trames "B" pour bidirectionelles ou l'on recherche des blocs equivalents dans la trame precedente et la trame suivante.
Bref ca devient evident qu'on va devoir comparer enormement de blocs d'images pour arriver a ce resultat. Un des moyens d'y arriver est de soustraire les pixels de ces 2 blocs respectifs et de calculer la somme de la valeur absolue de ces differences. Si tous les pixels sont egaux, cette mesure vaut 0, si tous les pixels different de 1 ca vaut 256 etc... On ne le fait que sur la composante de luminance car c'est a celle la que l'oeil est le plus sensible.

SAD
Donc pour faire ca l'instruction PSAD a ete introduite il y a un moment, elle fait exactement la somme de la valeur absolue des differences de 2x(2x8) pixels (pourquoi 8: parce que MMX, etendu a 2x8 par SSE). Mais voila, ca accelere l'estimation de mouvement deja pas mal mais pas suffisament, la plupart des encodeurs utilisent des heuristiques pour reduire le nombre de blocs a comparer ("diamond search", "log search" pour ceux qui veulent googliser). Ces heuristiques marchent bien, mais il y a une perte de qualite associee a leur utilisation, la qualite maximum est obtenue en faisant un "full search" dans une fenetre importante afin de maximiser les chances de trouver le bloc le plus proche de celui recherche (particulierement utile lorsqu'il y a des mouvements de camera tres rapides et non axiaux).
L'avantage du full search c'est que son pattern est tres regulier et deterministe, on scanne a travers l'image. D'ou l'introduction de PALIGNR qui permet d'implementer une fenetre glissante sur des registres. Maintenant au lieu de recharger du cache les donnees a chaque comparaison de bloc on peut y acceder directement depuis les registres. Ca accelere le full search, mais pas suffisament pour le rendre attractif comme mode par defaut.

MPEG4
Et voila MPEG4 qui ramene ses gros sabots, afin d'ameliorer la qualite (qualite peut se traduire en ratio de compression en video) la decision est prise de decomposer les blocs 16x16 en sous blocs. Au lieu de chercher 1 bloc 16x16 dans les trames voisines on va chercher toutes les combinaisons de sous blocs 4x4 8x8 4x8 8x4 16x16 dans les trames precedentes et on encodera la meilleure option. Pas besoin de faire un dessin, ca casse un peu tout le concept du PSAD, donc on a le choix entre une qualite amelioree ou une estimation de mouvement qui recommence a prendre vraiment du temps (et exit le "full search").
Donc voila, la reponse c'est MPSAD, au lieu de faire le SAD sur des groupes de 8 pixels, on le fait sur des groupes de 4 pixels. Mais au lieu de s'arreter la il est possible d'utiliser l'idee du PALIGNR, et au lieu de faire le SAD pour 2 groupes de 4 pixels alignes, de les faire pour toutes les combinaisons disponibles dans les 2 registres source (un peu equivalent a shifter l'un des 2 registres par pas de 1 octet et calculer un SAD a chaque fois, le tout en 1 instruction).
Le resultat est qu'on a 8 SAD au lieu d'un avec une seule instruction, le PALIGNR facilite les scan de lignes et au final il faut quand meme calculer lequel est le meilleur de ces 8 SAD, auparavant on agregeait les resultats de plusieurs PSAD dans un registre pour utiliser PMIN, et a la fin on faisait une reduction en utilisant du x86. avec le MPSAD tu produits les SAD a un rythme accelere donc toutes ces operations pour calculer un minimum commence a devenir couteuse (loi de Amdhal, quand tu acceleres trop la partie parallele tu deviens domine par le temps sequentiel). D'ou introduction d'un MIN qui produit la valeur minimum d'un registre SSE (et pas n valeurs min de 2 registres).

Et voila, il y a pas mal de litterature et d'explications en ligne avec des dessins sur l'estimation de mouvement donc ca devrait etre a peu pres comprehensible.

[le_canz]

Intéressant ton post Fefe, merci

Moi qui aime assez bidouiller les encodeurs MPEG 2 / 4, ça m'a fait piger certaines choses.

[Neo_13]

pour une fois j'ai capté l'encodage... très clair fefe.

[fefe]

Bon, apres SSE4, un petit paragraphe sur le x86/x87 et la division, une longue histoire pleine de rebondissements, mais generalement incomprise (cela ne s'applique pas directement aux GPUS).

Je suggere un peu de lecture sur la representation en nombre flottants avant' ca peut aider: http://en.wikipedia.org/wiki/Floating_point et surtout http://en.wikipedia.org/wiki/IEEE_fl...point_standard

Tout d'abord il y a essentiellement 2 methodes concurentes pour calculer une division IEEE compliant de 2 nombres flottants. La methode dite SRT (a Radix) et la methode dite de Newton Raphson (j'y inclue Goldshmitt).
- La premiere revient a effectuer une division euclidienne en calculant pour chaque groupe de bits un quotient et un reste par iterations.
- La seconde revient a calculer une serie qui converge quadratiquement vers le resultat de la division (somme de produits).
Quelques details ici: http://en.wikipedia.org/wiki/Division_%28digital%29

SRT
C'est l'implementation generalement choisie par Intel pour le x87.
L'implementation hardware d'un diviseur Radix contient 3 etages, le premier ou pre-processing ou on aligne les nombres flottants en fonction de leur exposant, et une lookup table pour trouver le quotient de la premiere iteration. Le 2 eme etage calcule n-bits de quotient a chaque cycle et le reste a partir du quotient de l'iteration precedente et est iteratif. Le 3 eme etage ou post-processing s'occupe en general des arrondis et de la normalisation, il peut aussi avoir d'autres taches a effectuer lorsque le 2 eme etage travaille en arithmetique redondante (necessite une addition pour repasser en arithmetique normale). Le Radix est la base dans laquelle ce diviseur travaille donc 2^n. La version de base qui travaille sur 1bit/clock est le Radix 2, les processeurs Intel depuis le Pentium utilisent un Radix 4 (2 bits par clock) et le Penryn utilise un radix 16 (4 bits par clock).
L'avantage de Penryn est donc d'un facteur 2 sur une des 3 etapes du calcul par rapport aux generations precedentes, a cela il faut ajouter au moins 1 cycle pour chacune des etapes restantes (en pratique plus parce que le pre-processing pour un diviseur a haut radix est beaucoup plus complexe).

Newton Raphson
C'est l'implementation generalement choisie par AMD pour le x87. 3 etapes de calcul aussi, pendant le preprocessing on calcule n-bits de quotient a partir d'une lookup table, la boucle principale calcule la serie en utilisant le multiplieur et l'additionneur x87. La latence du diviseur est dependant du nombre de bits de la LUT (combien d'iterations elle permet d'eviter) et laboucle iterative est dependante de la latence du multiplieur (notez qu'AMD a toujours eu un multiplieur flottant avec une meilleure latence qu'Intel).

NR ou SRT ?
Chacune des approches a du pour et du contre.
-Pour NR il faut peu de hardware vu qu'on reutilise des operateurs classiques, il faut une LUT qui opere en general sur une 10 aines de bits (plus ca devient vite gros, moins ca ajoute des iterations). Pour SRT il faut un adder entier de la largeur des donnees ainsi qu'un multiplieur sur quelques bits pour calculer le reste, et une logique de selection du quotient dont la complexite s'accroit exponentiellement avec le Radix (le tout capable de fonctionner en 1 cycle). NR coute moins cher en hardware.
-Pour la validation, si on dispose d'un multiplieur et d'un additionneur deja valides, il ne reste qu'avalider une LUT d'une 10aine de bits, ce qui est assez simple. Pour SRT il faut simuler le tout...
-Pour la performance tout depend du nombre de bits que l'on veut calculer. Si on essaye d'obtenir juste une valeur approximee (comme certains operateurs SSE) un NR sera extremement rapide et probablement toujours la meilleure entre ces 2 solutions. Si on calcule plus de bits, la vitesse de NR va etre essentiellement limitee par la latence du multiplieur. Pour les tres grands nombres de bits la convergence quadratique lui assure une victoire certaine, mais dans les valeurs intermediaires (la taille des flottants IEEE) ce n'est pas assure parce qu'il est tres difficile de faire un multiplieur tres rapide et que chaque iteration prend ~8 cycles avec un multiplieur de 4 cycles. Un diviseur a haut Radix (raisonable) peut donc etre plus rapide sur des donnees de ~20-80bits.
-SRT utilise du hardware dedie donc mul et add peuvent calculer d'autres choses en parallele, cela peut augmenter la performance.
-Lorsque l'on a du SIMD NR necessite 2x plus de temps pour passer dans les mul/add existant, pour SRT il suffit de repliquer le hardware (beaucoup moins cher que de repliquer un multiplieur et un additionneur flottant).
-Le hardware du SRT peut etre modifie pour un cout presque nul et calculer des racines carrees, alors que l'equivalent de NR pour la racine carree converge juste lineairement (donc lentement). SRT a tendance a gagner systematiquement sur les SQRT, surtout les versions SIMD.
-Le hardware du SRT peut calculer des divisions entieres avec des modifications mineures (essentiellement dans la phase d'alignement et d'arrondi), pour NR il faut faire une conversion int->float puis float->int, ce qui resulte dans des divisions entieres generalement tres lentes.
-Le scheduling d'instructions a tres longue latence dans le cas de SRT (pis variable dans le cas de la division entiere) est un cauchemard pour l'Out Of Order et necessite des solutions complexes pour savoir quand les instructions dependantes pourront etre executees. Dans le cas de NR on n'execute que des instructions de latence classique et il n'y a rien de special a gerer (ou presque a cause des exceptions).

Jusqu'a Penryn Intel n'a jamais investi le hardware necessaire (ni sur P4 ni sur P6) pour etre plus rapide que l'approche d'AMD sur le K7/K8, mais Penryn inverse la situation. Les options d'AMD sont assez limitees car reduire la latence du multiplieur semble etre trop couteux, et de meme la taille de la LUT necessaire pour gagner une iteration semble l'etre aussi.

[edit]
PS: La raison pour laquelle j'ai dit que cela ne s'appliquait pas aux GPUs est (comme le rappele Mogluglu dans ce thread http://forum.x86-secret.com/showthre...?t=7524&page=2) que dans un GPU il faut beaucoup de bande passante aux diviseurs, sans vraiment de questions de latence et que les imperatifs de precision sont generalement moindre que pour les CPUs. Dans un CPU il y a generalement 1 seul instruction de division a traiter simultanement donc aucun besoin de pipeliner les operateurs, et seule la latence compte (jusqu au point ou l'OOO trouve assez d'operations pour recouvrir la latence du div).

A suivre...

[Neo_13]

C'est limpide désormais...

[Alexko]

"-Le scheduling d'instructions a tres longue latence dans le cas de SRT (pis variable dans le cas de la division entiere) est un cauchemard pour l'Out Of Order et necessite des solutions complexes pour savoir quand les instructions dependantes pourront etre executees. Dans le cas de NR on n'execute que des instructions de latence classique et il n'y a rien de special a gerer (ou presque a cause des exceptions)."

=> C'est toujours un problème sur Penryn et ses latences nettement plus courtes ?

[Møgluglu]

Quelques details ici: http://en.wikipedia.org/wiki/Division_%28digital%29

En français, il y a aussi le chapitre 5 du Muller rose (qui commence à dater un peu, mais ce n'est pas comme si ça avait tellement changé depuis).

-Pour la validation, si on dispose d'un multiplieur et d'un additionneur deja valides, il ne reste qu'avalider une LUT d'une 10aine de bits, ce qui est assez simple. Pour SRT il faut simuler le tout...

Voire prouver formellement, même, depuis le Pentium...
Pour NR il faut tout de même garantir l'arrondi correct à la fin, ça ne me semble pas trivial, surtout quand on n'a pas d'instruction FMA...

-Lorsque l'on a du SIMD NR necessite 2x plus de temps pour passer dans les mul/add existant, pour SRT il suffit de repliquer le hardware (beaucoup moins cher que de repliquer un multiplieur et un additionneur flottant).

Là je n'ai pas compris. Dans le cas de ton multiplieur à 4 cycles, si on suppose qu'il est pipeliné, il n'est utilisé qu'un cycle sur 4 (ou 2 cycles avec Goldschmidt). Donc avoir plusieurs divisions à faire en parallèle permet de remplir le pipeline sans matériel supplémentaire, non?

PS: La raison pour laquelle j'ai dit que cela ne s'appliquait pas aux GPUs est (comme le rappele Mogluglu dans ce thread http://forum.x86-secret.com/showthre...?t=7524&page=2) que dans un GPU il faut beaucoup de bande passante aux diviseurs, sans vraiment de questions de latence et que les imperatifs de precision sont generalement moindre que pour les CPUs.

Pour la précision, il semble que ça ne soit plus le cas : d'après les news d'aujourd'hui DirectX 10.1 requièrerait l'arrondi correct pour la division. Donc Oberman va devoir se mettre au SRT aussi
(enfin la précision reste toujours plus faible, vu qu'on est en simple précision)

[fefe]

Sur K8 DivSD prend 20 cycles et on peut en lancer 1 tous les 17 cycles, DivPD prend 37 cycles et on peut en lancer 1 tous les 34 cycles.

Il y a en general des problemes d'exceptions qui empechent l'execution de plusieurs flots microcodes FP en parallele efficacement et le hardware pour gerer l'execution en parallele de 2 flots supposes etre atomiques n'est pas necessairement des plus simples. Je n'ai pas regarde en detail des implementations de NR recement, mais il n'est pas certain que tu puisses en executer 2 en parallele pour des problemes d'occupations de ressources comme la ROM FP.

Oui l'arrondi n'est pas trivial quand on n'a pas de fused MAD. Mais une fois l'algo ecrit et valide une fois c'est fini, pas besoin de revalider tant que le microcode ne change pas.

[fefe]

=> C'est toujours un problème sur Penryn et ses latences nettement plus courtes ?

Ca doit dependre des applications, mais de maniere generale si ton appli a un IPC de 2 (1 mul et 1 add par cycle) et un divide de latence 12 il va te falloir trouver 24 instructions independantes de ton div, et reussir a les caser dans 15 registres (ton div en consomme 1 deja).
D'experience la plupart du code numerique que j'ai touche resiste assez bien a quelques instructions de 8-10 cycles de latence mais au dela l'impact commence a se sentir.

Donc net progres avec Penryn, mais il y a encore quelque chose a gagner a mon avis, surtout en double precision.

[Alexko]

Vu comme ça, ça a l'air bien chiant, effectivement... À ton avis, comment AMD est susceptible de réagir s'ils ne peuvent ni réduire la latence des multiplieurs ni augmenter la taille de la LUT ? En passant à la méthode SRT Radix 16 comme Intel ? Ou laisser tomber et se contenter de ce qu'ils ont...

[fefe]

Vu comme ça, ça a l'air bien chiant, effectivement... À ton avis, comment AMD est susceptible de réagir s'ils ne peuvent ni réduire la latence des multiplieurs ni augmenter la taille de la LUT ? En passant à la méthode SRT Radix 16 comme Intel ? Ou laisser tomber et se contenter de ce qu'ils ont...

Vu qu'ils ne developpent pas de nouvelles archi aussi souvent qu'Intel cela leur laisse pas mal de temps pour y penser.
En attendant ils ne perdent pas grand chose en moyenne (ils partaient avec un bel avantage), et je suppose que les packed divide et packed SQRT ont ete fixes sur K10 donc cela reduit les chances d'applis qui montreraient une grosse difference (genre une appli qui ferait des packed 1/SQRT a tout bout de champ en double precision).

[Alexko]

OK. En tout cas, après avoir lu les tests, le process 45 nm d'Intel est vraiment impressionnant... Matbe a mesuré 40% de consommation en moins sur le Quad à 3 GHz, sans compter le potentiel d'overclocking de bourrin.

[fefe]

C'est surtout sur les mobiles que ca va se sentir. Peu de desktop etant power limited.

[Lissyx]

Ou sur les serveurs, si y'a des Xeon déjà en 45nm ... Comme j'ai pas des masses suivi :D

[fefe]

Ou sur les serveurs, si y'a des Xeon déjà en 45nm ... Comme j'ai pas des masses suivi :D

Bof Tant que tu auras des FBDIMM a 10W la barette ca ne changera pas grand chose... Et je n'ai pas entendu parle de chipsets servers Intel sans FBD...

[Lissyx]

ça dépend si y'a beaucoup de barettes

[Alexko]

ça dépend si y'a beaucoup de barettes

Bah en général, dans un serveur...

[fefe]

Sinon j'aime bien les commentaires dans les tests qui se plaignent que DivX utilise un algorithme different (et plus lent) avec le SSE4 et eventuellement choisissent d'omettre le test. Oui c'est plus lent mais la qualite augmente de maniere non negligeable (un full search donnera toujours une video avec un meilleur PSNR qu'un diamond search ou un log search, employes a l'heure actuelle par DivX), et en video + de qualite ca peut aussi etre transforme en plus de compression. C'est un peu comme se plaindre qu'un setting "haute qualite" diminue les perfs d'un jeu et choisir de tester en "moyenne qualite". Je suis d'accord que ca serait bien que les instructions beneficient aux algos existants, mais a la base ce n'est pas pour ca qu'elles ont ete introduites (le MPSADBW force un redesign de l'algorithme d'estimation de mouvement et rend quasiment inutilisables tous les autres algos hors full search) donc il n'y a rien de surprenant...

Question idiote: qui encode des DivX autrement qu'en ciblant un bitrate (ou une taille de fichier c'est pareil) et en essayant de recuperer la qualite maximum au bout du compte ? Je suppose qu'il y en a, mais personellement ce qui compte pour moi c'est le temps d'encodage a la qualite maximum, je ne fais pas d'encodage DivX avec des contraintes temps reel.

Sinon au final les conclusions des articles que j'ai lus sont tres raisonables. Penryn est un shrink sans changements importants, a frequence egale la perf est donc marginalement amelioree face a Conroe (quelques % en general). Et la conso a ete amelioree de maniere significative grace a la transition de process vers 45nm. SSE4 comme la plupart des autres generations de SSE n'apporte guere des gains que dans les applis reecrites pour (hors SSE2 ou il n'etait pas rare de voir quelques % d'amelioration par simple recompilation, mais rien d'epoustouflant).

[Yasko]

OK. En tout cas, après avoir lu les tests, le process 45 nm d'Intel est vraiment impressionnant... Matbe a mesuré 40% de consommation en moins sur le Quad à 3 GHz, sans compter le potentiel d'overclocking de bourrin.

C'est clair.
Si Intel voulait gagner quelques dineros de plus, il pourrait mettre TSMC et consorts sur la paille...
Mais il doit préférer bénéficier de l'exclusivité de son process (en 45 nm, y a déja une petite file d'attente rien qu'avec Penryn apparemment).
Dommage, une petite 8800 GT en 45nm Intel, ca doit être pas mal.
Allez, 1 GHz ? (600 MHz en 65 nm par *MC ?)

[Childerik]

Dommage, une petite 8800 GT en 45nm Intel, ca doit être pas mal.
Allez, 1 GHz ? (600 MHz en 65 nm par *MC ?)

Déjà, en 65 nm, la 8800GT consomme beaucoup moins que la 8800GTS. Il est même question d'une version heatpipe. Mais c'est clair qu'en 45 nm, on devrait se retrouver avec un haut-de-gamme consommant autant qu'un bas-de-gamme actuel :D.

[Alexko]

Ouais... mais même si Intel le proposait, NVIDIA ne leur sous-traiterait jamais leur production.