Calcul FP et SSE

**Fanche** · 22/08/2007, 13h10

pour le 64 bits, je pense que ça doit accélérer un peu les calculs en double précision (voir les calculs se font directement en double précision), mais ça c'est pas spécifique à vista. donc là où les calculs étaient nécessaires en double précision, c'est un plus. Après y a bien sûr la quantité de ram adressable qui apporte indéniablement un plus sur les calculs très gourmants en mémoire (structure simulables plus grosses et nb de points de calculs plus élevé).
Enfin tout ça c'est du théorique pour moi vu que j'ai pas pu tester, mais au dire de certains avec xp 64 ou linux, ça peut être bien utile parfois. (ça sera pas aussi flagrant que le passage du 16 au 32 bits.

**Yasko** · 22/08/2007, 13h23

Envoyé par Fanche

pour le 64 bits, je pense que ça doit accélérer un peu les calculs en double précision

Je ne crois pas que la largeur des unités de calcul ait été augmentée par le passage en 64 bits (de l'espace d'adressage).
Que tes adresses et tes registres internes soient en 32 ou 64 bits, il faut toujours 2 cycles pour faire un add de 2 long int sur une ALU de 32 bits.

Les gains peuvent par contre être observés du fait de la présence de registres supplémentaires, qui permettent de ne pas utiliser la pile qui est plus lente.

Enfin, c'est ce dont je me rappelle, j'aimerai bien une confirmation d'un master of x86.

**jihef** · 22/08/2007, 13h30

Envoyé par Yasko

Je ne crois pas que la largeur des unités de calcul ait été augmentée par le passage en 64 bits (de l'espace d'adressage).
Que tes adresses et tes registres internes soient en 32 ou 64 bits, il faut toujours 2 cycles pour faire un add de 2 long int sur une ALU de 32 bits.

Les gains peuvent par contre être observés du fait de la présence de registres supplémentaires, qui permettent de ne pas utiliser la pile qui est plus lente.

Enfin, c'est ce dont je me rappelle, j'aimerai bien une confirmation d'un master of x86.

+1

La FPU d'un x86 32-bits travaille d'ailleurs sur 80-bits en interne.

**Fanche** · 22/08/2007, 13h37

à j'pensai que les fpu avaient passées de 32 à 64 bits...
d'un point de vue OS, les calculs flottants sont fait en 32, 64 ou 80 bits? si y a pas de différence, l'augmentation de perf ne se ferai pas là (moi je pense qu'elle est surtout liée à la quantité de ram adressable dans les calculs que j'ai l'habitude de voir)

**Lissyx** · 22/08/2007, 13h49

Envoyé par jihef

+1

La FPU d'un x86 32-bits travaille d'ailleurs sur 80-bits en interne.

De mémoire, le K10 passe sa FPU en 128 Bits.

Et le plus intéressant en 64 bits, hormis pour les softs qui font des gros calculs, c'est le passage de 8 à 16 GPRs.

**fefe** · 22/08/2007, 14h17

hum,
la FPU des x86 est sur 80 bits depuis 35 ans... (meme quand le mode d'adressage etait 16 bits...)
Personne ne fait du FP 128 sur du x86, pas meme le K10 aujourd'hui autrement qu'en emulation soft.

La confusion vient du fait que en SSE les flottants sont stockes effectivement sur 32 ou 64 bits pour les simples et double precision contrairement au x87 ou ca a toujours etendu dans des extended precision de 80 bits.
Les registres SSE font 128 bits (contiennent 2x64 ou 4x32 flottants) donc les unites flottantes capables de traiter un registre SSE a un rythme de 1/clock ont souvent ete qualifiees de 128 bits.
En pratique personne en fait des calculs flottants sur une precision de 128 bits en full hardware (le multiplier demande 4x plus de hardware qu un multiplieur double precision et vu le nombre d'utilisateurs personne n'y mettra les transistors).

**Neo_13** · 22/08/2007, 14h26

pourquoi sur les registres font 128bits et que les unités aussi,, on ne peut pas faire une somme de deux nombre 128bits par le SSE (mais on peut faire 2 somme de 2 nombres 64bits) ?

**fefe** · 22/08/2007, 15h02

Envoyé par Neo_13

pourquoi sur les registres font 128bits et que les unités aussi,, on ne peut pas faire une somme de deux nombre 128bits par le SSE (mais on peut faire 2 somme de 2 nombres 64bits) ?

Jette un oeil ici pour comprendre la suite:
http://en.wikipedia.org/wiki/IEEE_fl...point_standard

En gros chaque flottant 64 bits est separe en mantisse exposant signe. Si tu veux faire une addition, il va falloir que tu shift les 2 mantisses par la difference d'exposant, les additionne, eventuellement +1 l'exposant max.

Donc pour faire une addition flottante 64 bits tu as besoin d'un additionneur 53 bits en pratique, un shifteur, et un peu de logique pour arrondir, et renormaliser. Pour en faire 2 en parallele tu as besoin de 2 additionneurs 53 bits.

Maintenant la question est si j'avais un additionneur 106 bits je pourrais facilement bloquer la retenue au milieu et le transformer en additioneur 53 bits (c'est comme ca que MMX a ete implemente sur P55C).
Le probleme c'est que la latence de la propagation de la retenue sur 106 bits vs 53 bits est tres differente, donc la latence de ton additionneur sera tres differente, et en pratique tu emploieras probablement meme des algorithmes differents pour le calcul de la retenue.

Donc 2 additionneurs 53 bits sont au final plus petits et plus rapides qu'un additionneur 106 bits.

Je ne ferai pas la demonstration pour un multiplieur mais c'est encore pire. Donc toutes les implementations "128bits" de SSE contre les implementations "64 bits" (celles ou on occupe les unites pendant 2 cycles) emploient une replication de hardware existant plutot qu'un redesign d'unites plus larges.

Le vrai flottant 128 bits a une mantisse dans les 110 bits dans mes souvenirs (la flemme de verifier) donc il faudrait ajouter qq bits en plus ce qui n'arrangerait rien.

Ai-je ete un peu plus clair ?

(N'hesitez pas a le dire, je fais ca depuis tellement longtemps que des fois je saute des etapes)

**Lissyx** · 22/08/2007, 15h47

Hmm, avec les bases d'électronique numérique qu'on a eu, j'ai pas trop mal compris

Mais alors, faudrait corriger l'article de XbitLabs, il me semble bien qu'il affirme que la FPU travaille à 128 Bits, et que donc les registres le sont aussi - ou alors j'ai mal compris - .

**Foudge** · 22/08/2007, 15h49

Envoyé par Yasko

Je ne crois pas que la largeur des unités de calcul ait été augmentée par le passage en 64 bits (de l'espace d'adressage).
Que tes adresses et tes registres internes soient en 32 ou 64 bits, il faut toujours 2 cycles pour faire un add de 2 long int sur une ALU de 32 bits.

Les gains peuvent par contre être observés du fait de la présence de registres supplémentaires, qui permettent de ne pas utiliser la pile qui est plus lente.

Enfin, c'est ce dont je me rappelle, j'aimerai bien une confirmation d'un master of x86.

La FPU (X87) n'a pas changé, mais avec le passage au x86-64, les CPU en ont profité pour avoir des ALU de 64bit, non ?

**Neo_13** · 22/08/2007, 15h57

Envoyé par fefe

Jette un oeil ici pour comprendre la suite:
http://en.wikipedia.org/wiki/IEEE_fl...point_standard

En gros chaque flottant 64 bits est separe en mantisse exposant signe. Si tu veux faire une addition, il va falloir que tu shift les 2 mantisses par la difference d'exposant, les additionne, eventuellement +1 l'exposant max.

Donc pour faire une addition flottante 64 bits tu as besoin d'un additionneur 53 bits en pratique, un shifteur, et un peu de logique pour arrondir, et renormaliser. Pour en faire 2 en parallele tu as besoin de 2 additionneurs 53 bits.

Maintenant la question est si j'avais un additionneur 106 bits je pourrais facilement bloquer la retenue au milieu et le transformer en additioneur 53 bits (c'est comme ca que MMX a ete implemente sur P55C).
Le probleme c'est que la latence de la propagation de la retenue sur 106 bits vs 53 bits est tres differente, donc la latence de ton additionneur sera tres differente, et en pratique tu emploieras probablement meme des algorithmes differents pour le calcul de la retenue.

Donc 2 additionneurs 53 bits sont au final plus petits et plus rapides qu'un additionneur 106 bits.

Je ne ferai pas la demonstration pour un multiplieur mais c'est encore pire. Donc toutes les implementations "128bits" de SSE contre les implementations "64 bits" (celles ou on occupe les unites pendant 2 cycles) emploient une replication de hardware existant plutot qu'un redesign d'unites plus larges.

Le vrai flottant 128 bits a une mantisse dans les 110 bits dans mes souvenirs (la flemme de verifier) donc il faudrait ajouter qq bits en plus ce qui n'arrangerait rien.

Ai-je ete un peu plus clair ?

(N'hesitez pas a le dire, je fais ca depuis tellement longtemps que des fois je saute des etapes)

merci, c'est limpide...

**fefe** · 22/08/2007, 16h31

Envoyé par Foudge

La FPU (X87) n'a pas changé, mais avec le passage au x86-64, les CPU en ont profité pour avoir des ALU de 64bit, non ?

Oui le passage au x86-64 a introduit des ALU 64 bits, les implementations hardware AMD et Intel different (et changent entre par exemple prescott et merom) mais au final il y a effectivement des ALU 64bits dans les CPU x86-64, alors que dans les precedentes generation il n'y avait que des ALU 32 bits.

Les changements FP abordes dans ce thread sont hortogonaux au passage a x86-64.

**fefe** · 22/08/2007, 16h46

Envoyé par Lissyx

Mais alors, faudrait corriger l'article de XbitLabs, il me semble bien qu'il affirme que la FPU travaille à 128 Bits, et que donc les registres le sont aussi - ou alors j'ai mal compris - .

Il y a pas mal de confusion sur le net dans ce domaine aujourd'hui, et c'est principalement lie a un probleme de terminologie.

Les registres SSE font 128 bits depuis l'introduction de SSE. Il y a eu diverses implementations hardware, par exemple le P4 avait des registres 128 bits, alors que le K8 et les P6 (jusqu'a Yonah) groupaient 2 registres de 64 bits pour (donc au final si on fait tourner un code avec 50% SSE 50% x86, on se retrouve avec effectivement 25% moins de registres physiques disponibles).
Le K10 comme Merom abandonne le groupement de 2 registres pour stocker les 128 bits dans 1 registre (comme P4).

Ensuite il y a la largeur des unites, le chemin de donnees faisait 128 bits sur P4 (normal pour lire un registre de 128 bits), mais les unites d'execution etaient 64 bits, donc les donnees etaient "staggered" pour passer dans les unites de calcul en 2 coups d'horloge.
Le P6 jusqu'a Yonah et le K8 avaient un chemin de donnees 64 bits et des unites 64 bits donc chaque instruction SSE resultait dans la lecture de 2 registres differents qui etaient envoyes a 2 cycles differents (generalement consecutifs) vers des unites de calcul (il y a eu des implementations qui splittaient une instruction SSE en 2 sous instructions pour faire ca et d'autres qui le faisaient avec une instruction qui envoyait ses donnees en 2 coups).

Maintenant, le K10 et Merom, ont des registres 128 bits, un datapath de 128 bits et 2 unites de calcul de 64 bits de chaque et envoient les calculs pour 128 bits de donnees SSE a chaque cycle. Certains ont appele ca FP128 c'est leur droit mais ca a lance la confusion.

En effet certaines personnes n'ont pas hesite a faire le pas et a partir du principe que les calculs FP qui en x87 etaient fait sur 80 bits, et en 32 ou 64 bits sur SSE etaient passe a 128 bits. C'est faux, et il n'y a aucun rapport entre la norme de calcul en floating point sur une precision de 128 bits et le hardware employe dans ces machines. Ou si il y en avait il faudrait introduire tout un jeu de nouvelles instructions SSE travaillant sur un type de donnee 128 bits afin d'exploiter ce hardware, et je n'ai vu personne en parler.

Il est possible que pour augmenter la confusion ces implementations plus larges de SSE permettent de faire les calculs utilisant une precision de 128 bits (faits par emulation soft aujourd'hui) plus rapidement et je pourrais vous sortir une phrase dans le genre "Le FP128 du K10 a triple les performance de notrew code FP128" mais bien sur je ne le ferai pas (oups

)

mmmm ca y'est je suis lance...

**Franck@x86** · 22/08/2007, 23h13

avec Marc on avait clarifié tout ça dans l'article sur l'archi Core :
http://www.hardware.fr/articles/623-...o-dossier.html

Une des améliorations les plus notables des unités de calcul de Core consiste en la présence de trois unités SSE dédiées aux opérations SIMD entières et flottantes. Alliée aux unités arithmétiques concernées, chacune d’elles est capable d’effectuer en un seul cycle des opérations paquées 128 bits (c’est-à-dire agissant simultanément sur quatre données 32 bits ou deux données 64 bits), là où Netburst, Mobile et K8 nécessitent deux cycles. Sont concernées notamment les opérations arithmétiques courantes telles que la multiplication et l’addition.

Core possède deux unités de calcul flottant, une dédié aux additions et l’autre aux multiplications et aux divisions. La capacité de calcul théorique atteint donc deux instructions x87 par cycle, et deux instructions flottantes SSE 128 bits par cycle (soit 8 opérations sur des flottants simple précision 32 bits, ou 4 opérations sur flottants double précision 64 bits). Core se montre ainsi en théorie deux fois plus rapide sur ce type d’instructions que Mobile, Netburst et K8.

K10 n'a fait que se mettre au niveau de Core pour les calculs SSE flottants.

**claneys** · 23/08/2007, 09h44

Envoyé par fefe

Jette un oeil ici pour comprendre la suite:
http://en.wikipedia.org/wiki/IEEE_fl...point_standard

En gros chaque flottant 64 bits est separe en mantisse exposant signe. Si tu veux faire une addition, il va falloir que tu shift les 2 mantisses par la difference d'exposant, les additionne, eventuellement +1 l'exposant max.

Donc pour faire une addition flottante 64 bits tu as besoin d'un additionneur 53 bits en pratique, un shifteur, et un peu de logique pour arrondir, et renormaliser. Pour en faire 2 en parallele tu as besoin de 2 additionneurs 53 bits.

Maintenant la question est si j'avais un additionneur 106 bits je pourrais facilement bloquer la retenue au milieu et le transformer en additioneur 53 bits (c'est comme ca que MMX a ete implemente sur P55C).
Le probleme c'est que la latence de la propagation de la retenue sur 106 bits vs 53 bits est tres differente, donc la latence de ton additionneur sera tres differente, et en pratique tu emploieras probablement meme des algorithmes differents pour le calcul de la retenue.

Donc 2 additionneurs 53 bits sont au final plus petits et plus rapides qu'un additionneur 106 bits.

Je ne ferai pas la demonstration pour un multiplieur mais c'est encore pire. Donc toutes les implementations "128bits" de SSE contre les implementations "64 bits" (celles ou on occupe les unites pendant 2 cycles) emploient une replication de hardware existant plutot qu'un redesign d'unites plus larges.

Le vrai flottant 128 bits a une mantisse dans les 110 bits dans mes souvenirs (la flemme de verifier) donc il faudrait ajouter qq bits en plus ce qui n'arrangerait rien.

Ai-je ete un peu plus clair ?

(N'hesitez pas a le dire, je fais ca depuis tellement longtemps que des fois je saute des etapes)

1/ Prendre wikipedia naviguer de lien en lien.

2/ prendre une aspirine

3/ revenir sur le post

4/ prendre une aspirine

5/ revenir sur wikipedia

6/ prendre une aspirine

Là comme ça de bon matin... j'ai un peu de mal à comprendre la notation scientifique des flottants. Bon de base une nombre scientifique est mis sous la forme x = s *m * b(e), s le signe, b la base, m la mantisse, e l'exposant. En informatique on décale l'exposant, ça donne x = s * m* b(e-1)-1 (les trucs entre parenthèses sont en exposant des fois que y'en a aussi bien réveillé que moi).

Bon en le redisant je comprend mieux. Par contre les additionneurs dont tu parles, j'ai du mal. Pourquoi 53bits? ça représenterai la mantisse d'un flottant 64bits et le signe? :nuts: expliquer un peu plus "shifter les mantisses", surtout ça qui me pertube :loop: .

/me retourne sur son serveur RIS qui marche pô

**jihef** · 23/08/2007, 11h08

Envoyé par claneys

Bon en le redisant je comprend mieux. Par contre les additionneurs dont tu parles, j'ai du mal. Pourquoi 53bits? ça représenterai la mantisse d'un flottant 64bits et le signe? :nuts: expliquer un peu plus "shifter les mantisses", surtout ça qui me pertube :loop: .

Les mantisses des double flottants sont sur 52 bits mais il faut rajouter le premier 1 qui est implicite(mais peut-être nul dans certains cas particuliers).

Shifter les mantisses ca sert à aligner les mantisses pour les additionner simplement. Le principe c'est qu'il faut décaler vers la droite la mantisse du plus petit exposant pour aligner les chiffres de poids identiques.

ex 10101010*2^^2+11001*2^^0.

L'addition à faire est 10101010 + 110. La mantisse du nombre de plus petit exposant a du être décalée de (2-0) = 2 bits vers la droite. Le résultat donne 10110000*2^^2

**claneys** · 23/08/2007, 11h46

Ok merci jihef. Tout est clair et limpide maintenant.

( fefe aussi hein c'était clair, me manquait juste ça c'est parfait )

**Franck@x86** · 23/08/2007, 11h50

Voici un inverseur IEEE software. Vous noterez que le nouvel exposant est calculé, alors que pour la mantisse une table est utilisée.
C'est généralisable pour toutes les puissances de flottant, y compris 1/2 (racine carrée) et -1/2 (inverse de racine carrée, très utile pour la normalisation des vecteurs).

Code:

// Inverse
// Entrée : float f
// Sortie : 1/f
// Attention : à utiliser après initialisation de InvertTable (fonction CreateInvertTable)
inline
float IEEE_Invert(float f)
{
    unsigned long mf = *(long *)&f;
    unsigned long sign = mf&0x80000000;
    unsigned long new_exp = 0x7E800000 - (mf&0x7F800000);   // 253-exposant = 2*127-1-exposant
    unsigned long new_m = InvertTable[(mf&0x7FFFFF)>>13];
    float fret;

    mf = sign+new_exp+new_m;
    fret = *(float *)&mf;

    return fret;
}

// Tableaux contenant les premiers bits des
// mantisses des inverses
unsigned long InvertTable[1024];	// 4Ko

// Initialisation de la table des inverses
void CreateInvertTable()
{
    long i;
    float ft;

    for ( i=0; i<1024; i++ )
    {
        ft = 1.0f / (1.0f + (float)i/1024.0f);
        InvertTable[i] = *(long *)&ft;
        InvertTable[i] &= 0x7FFFFF;
    }
    InvertTable[0] = (1<<23);
}

**fefe** · 23/08/2007, 12h02

Les inverses et inverses approximes et inverse de square root approximes en SSE (celles specifiees avec seulement 11 bits exacts) utilisent une methode similaire avec une table precalculee afin d'accelerer le calcul, les versions completes sont faites par un radix chez Intel et par reciprocation chez AMD (Newton Raphson) en partant d'une table precalculee.

On sort du topic la, ca devient un topic FP

.

**Neo_13** · 23/08/2007, 12h07

Voilà, la discussion est déplacée

En fait pour le 128bits, je voulais tentre de faire du très grande précision à un moment pour voir... c'est ça qui m'avait amener à regarder si les registres XMM pouvait etre utilisé en 128bits... Et à part on peut pas parce qu'on peut pas, j'avais jamais eu de réponse... Merci fefe.

**fefe** · 23/08/2007, 12h34

Il y a des library de calcul en FP avec une precision arbitraire:
http://linux.die.net/man/n/bigfloat par ex

**Franck@x86** · 23/08/2007, 13h02

La manip des IEEE754 est assez intéressante.
Il existe également une grosse astuce qui consiste à additionner à un nombre flottant une constante qui va bien, ce qui permet un cast en entier pratiquement gratuit.
Eh oui, fut une époque où chaque cycle gagné représentait une mini-victoire

**jihef** · 23/08/2007, 13h09

Ca me rappelle la fois ou je faisais une petite FPU en soft. Enfin c'était juste pour comprendre le fonctionnement des IEE754.

**Lissyx** · 23/08/2007, 13h50

Envoyé par jihef

Ca me rappelle la fois ou je faisais une petite FPU en soft. Enfin c'était juste pour comprendre le fonctionnement des IEE754.

Tu as toujours les sources ?

**jihef** · 23/08/2007, 13h52

Surement. Ca t'interresse ?

Y'a rien de transcedant. De mémoire il doit juste y avoir addition ou multiplication avec des parties en assembleur pour le fun.

**fefe** · 23/08/2007, 13h52

Linux kernel, rechercher ce que l'option x87 emu active

**jihef** · 23/08/2007, 13h53

Déjà à l'époque Fefe m'avais aidé et conseillé.

**Lissyx** · 23/08/2007, 13h53

Envoyé par jihef

Surement. Ca t'interresse ?

Y'a rien de transcedant. De mémoire il doit juste y avoir addition ou multiplication avec des parties en assembleur pour le fun.

C'est plus le côté émulation CPU qui m'intéresse.

**Lissyx** · 23/08/2007, 13h54

Envoyé par fefe

Linux kernel, rechercher ce que l'option x87 emu active

D'ailleurs, tu saurais si c'est possible de "visualiser" ce qui se passe au niveau du CPU avec des émulateurs comme Bochs ?

**jihef** · 23/08/2007, 13h57

Si c'est juste les algo. un qui était utilisé par les Pentium et qui était mal implémenté (bug fdiv) était le SRT radix 4.

Discussion: Calcul FP et SSE

Outils de la discussion

Règles de messages