AMD annonce SSE5

[fefe]

http://developer.amd.com/sse5.jsp

Mmmm je ne savais pas qu ils avaient le droit d'introduire des nouvelles instructions sse et les appeler sse .

Sinon plein d'instructions a 3 operandes source, le bon vieux x86 est en train de mourir. Ca ressemble a un mouvement assez agressif de la part d'AMD .

[Neo_13]

et puis apparement, certaines instructions sont commune entre SSE4 et SSE5...

Un glissement vers l'intégration d'instruction GPU-like, annonciateur de fusion complète (meme jeu d'instruction) entre cpu et gpu ?

[Dandu]

y en a même à 4 opérandes

et on a aussi été étonné du nom, on a cru à un fake au départ :D

[Yasko]

3 opérandes sources + 1 destination (evite le store / load du résultat)

FMADDPS is an example of a four operand instruction:
FMADDPS dest, src1, src2, src3; dest = src1 * src2 + src3
The first operand is the destination operand and is an XMM register addressed by the 4-bit DREX.dest
field.

Et ils ont ajouté un 3ème octet pour l'opcode, sur 2, ca ne tenait plus du coup

Pour Franck :

Support for the new instructions is indicated by ECX bit 11 (SSE5) as returned by CPUID function 8000_0001h.

[Alexko]

Dans un sens, c'est logique. À chaque fois qu'Intel introduit un nouveau set, ça boost un peu leurs CPUs et AMD se retrouve avec un désavantage pendant 6 mois, le temps de rattraper. D'où cette contre-attaque : le feu par le feu...

Reste à voir ce que ça donnera en pratique.

[Franck@x86]

Pour Franck :

merci, j'avais même pas vu :jap:

[Møgluglu]

http://www.ddj.com/hpc-high-performa...ting/201803067

A floating-point matrix multiply using the new SSE5 extensions is 30 percent faster than a similar algorithm implemented with the existing SSE instructions.

Probablement grâce au FMA, et en plus on gagne en précision.

Discrete Cosine Transformations (DCT) [...] get a 20 percent performance improvement by using the new SSE5 extensions.

Toujours le FMA...

For example, the Advanced Encryption Standard (AES) algorithm gets a factor of 5 performance improvement by using the new SSE5 extension compared to an AES implementation that just uses the AMD64 instructions.

Là par contre, marketing bullshit inside?...
L'AES, c'est tout du calcul sur 8 bits il me semble? S'ils comparent du SSE[2+3+4+5] vectoriel à du code scalaire d'avant le P5 MMX, ça explique le facteur 5...

À la limite le FMA pourrait peut-être faire gagner un facteur 3 sur certains algos d'arithmétique flottante compensée (double-double)...

Sinon il y a aussi des instructions de conversion dans un format FP16, le même que celui des GPUs.

Mais ce que je retiens c'est le FMA : c'est probablement ce qu'il manque le plus actuellement en x86/x64 pour le calcul flottant, et ça serait une vraie évolution. Du fait que ça permet de faire des choses pas possibles/difficiles avant, plutôt que juste remplacer une séquence de 3 ou 4 instructions par une seule.

[Lissyx]

Nan nan, AES ce sont des blocs de 128 bits.

[Møgluglu]

J'y connais rien en crypto, mais en lisant l'entrée de Wikipédia ça m'a l'air parfait pour une implémentation SSE2 (les blocs de 128 bits sont divisés en 16 nombres d'un octet sur lesquels on calcule dans Z/256Z...)

Le SSE5 apporte bien le shift/rotate variable (PSHLD/PROTD) pour faire l'étape ShiftRows et les calculs sur les polynômes plus rapidement, mais de là à gagner un facteur 5...

[Franck@x86]

Huhu ...
http://www.theinquirer.net/?article=42484

Edit : tiens je viens de voir ceci, un petit schéma qui résume (si c'est possible) les interactions entre les versions de SSE :
http://www.xtremesystems.org/forums/...8&postcount=13

[Neo_13]

Huhu ...
http://www.theinquirer.net/?article=42484

Edit : tiens je viens de voir ceci, un petit schéma qui résume (si c'est possible) les interactions entre les versions de SSE :
http://www.xtremesystems.org/forums/...8&postcount=13

c'est dommage d'avoir mis le SSE4A en dehors du SSE4

[PeGGaaSuSS]

C'est peut-être relativement différent, mais ils disaient pareil avec l'AMD64... :D

[fefe]

C'est peut-être relativement différent, mais ils disaient pareil avec l'AMD64... :D

Oui mais AMD64 etait autrement moins specialise que SSE5.

SSE5 contient essentiellement toutes les instructions utiles qui manquaient a SSE a cause de l'absence d'une 3 eme source et qui etaient typiquement disponibles dans AltiVec. On ne peut que se rejouir de les voir arriver sur x86, mais il faut esperer que contrairement a 3Dnow (qui contenait un certain nombre de tres bonnes idees aussi) la compatibilite entre constructeurs sera atteinte ce qui permettra de transformer SSE5 en un standard employe par les applications.

[Alexko]

En même temps c'est logique qu'Intel prétende ne pas avoir l'intention d'adopter le SSE5. S'ils disaient le contraire, ça encouragerait les développeurs à s'y intéresser et à l'utiliser, ce qui ne serait pas à leur avantage puisqu'AMD devrait --- logiquement --- sortir un CPU SSE5 avant eux, donc profiter d'un certain avantage. Vaut mieux dire que c'est tout pourri pour essayer de le tuer dans l'œuf et éventuellement "changer d'avis" plus tard...

[fefe]

SSE5 comme jeu d'instruction et du point de vue software est quelque chose de tres bien. En revanche c'est beaucoup plus discutable du point de vue hardware. Le cout associe a l'ajout d'une 3 eme source en terme de developpement, de surface de silicone et de power est particulierement important (pour une implementation correcte non microcodee) et cela n'est pas forcement un mauvais choix de mettre ce budget sur d'autres features hardware.

[Alexko]

Ce coût est élevé de manière générale, ou ça peut varier significativement d'une architecture à une autre ?

[fefe]

Disons que pour x86 le cout par eleve, et apres certaines micro-architectures payent plus cher que d'autres. Le cout initial est dans le fetch et le decodage, ca fait une source de plus a decoder, des instructions plus longues, avec un escape code de plus. C'est vraiment pas la joie par rapport a un jeu d'instruction RISC comme le PPC ou les 3 sources etaient prevues a la base.

Typiquement une architecture avec des chedulers separes pour le flottant comme P4 ou le K8 payeront beaucoup moins cher leur implementation de la 3 eme source qu'une architecture de style P6 avec un scheduler centralise. Dans le cas de P6, ca force en effet a faire un gros scheduler avec une 3 eme source, alors que dans le cas de K8 il part beaucoup plus petit car beaucoup moins d'entrees et qu'il n'y a pas de dependances tous les cycles en flottant (toutes les instructions sont multi cycle).

[Alexko]

OK. Ça explique donc qu'Intel ne soit pas très chaud pour le moment... et peut-être aussi la décision d'AMD de passer à un instruction fetch de 32 octets.