k8 vs core2, analyse par performance counters

**newbie06** · 29/10/2008, 12h21

C'est du RWT, donc un minimum serieux : http://realworldtech.com/page.cfm?Ar...2808015436&p=1

J'avoue ne pas etre surpris qu'il ait des resultats parfois etranges, les performance counters sont devenus tres difficiles a implementer pour correspondre a un resultat humainement apprehendable, du fait de la speculation par exemple. (Petite ref a ce propos : http://www.csl.cornell.edu/~vince/papers/iiswc08/tr1051_08.pdf)

**fefe** · 29/10/2008, 12h43

Conclusions assez interressantes sur:
-Intel execute un peu plus d'uops qu'AMD, donc AMD a un jeu d'uop interne plus efficace
-Intel a un avantage significatif sur la prediction de branchement
-Des resultats etranges pour le nombre de fetch/instruction mais etant donne l'approche fondamentalement differente des 2 frontend ce n'est pas surprenant que les compteurs de perf ne comptent pas vraiment la meme chose.
-Meme pour le cache d'instruction, 2 way assoc c'est un peu leger vu que un cache moitie moins gros mais 8 way est souvent plus performant.
-Utiliser du code x87 n'est pas super compatible avec des acces alignes a la DCU
-L'assoc semble moins importante que la capacite pour la DCU dans leur tests (les differences observees me semblent bizarrement elevees par contre)
-Pour les miss rate L2 ils oublient que les politiques de remplacement sont differentes et surtout ils oublient la presence de prefetchers qui passent leur temps a generer des miss dans le L2 chez Intel.

Voila, sinon ils oublient de dire que toutes ces metriques peuvent varier d'un ordre de grandeur suivant les applications donc que toutes leurs tendances peuvent completement s'inverser en fonction du programme (en fait ils l'ont constate un peu mais l'ont attribue a des faiblesses du soft AMD).

**Tramb** · 29/10/2008, 12h47

Envoyé par fefe

-Utiliser du code x87 n'est pas super compatible avec des acces alignes a la DCU

Ca fait encore partie des benchs importants, le x87? (curiosité)

**fefe** · 29/10/2008, 12h51

Envoyé par Tramb

Ca fait encore partie des benchs importants, le x87? (curiosité)

Non en general mais la plupart de leurs tests s'executent en x87 quand l'archi = K8, et SSE sur Core et K10.

**newbie06** · 29/10/2008, 12h52

Envoyé par Tramb

Ca fait encore partie des benchs importants, le x87? (curiosité)

Le machin bidule Pi que tous les overclockers utilisent, il ne fait pas du x87 ?

**Tramb** · 29/10/2008, 12h58

Envoyé par newbie06

Le machin bidule Pi que tous les overclockers utilisent, il ne fait pas du x87 ?

Ca doit être du calcul entier vu que c'est de la précision arbitraire.

**newbie06** · 29/10/2008, 13h36

Envoyé par Tramb

Ca doit être du calcul entier vu que c'est de la précision arbitraire.

Ce n'est pas un critere. Quand tu fais des calculs en tres haute precision, tu utilises des FFT dont l'implementation est bien plus efficace en flottant qu'en entier, meme si tu passes par des conversions entier->flottant et vice versa, et que tu dois faire un controle d'erreur pousse.

Bien sur ca ne veut pas dire que machin Pi ne fait pas ses calculs en entier

**fefe** · 29/10/2008, 14h06

J'allais le dire que pour la precision arbitraire tu peux utiliser FP ou Int, pour SPI de toutes facons dans mes souvenirs les perfs sont plus liees a la taille du cache qu'a la capacite de calcul

.

**newbie06** · 29/10/2008, 14h23

Envoyé par fefe

J'allais le dire que pour la precision arbitraire tu peux utiliser FP ou Int, pour SPI de toutes facons dans mes souvenirs les perfs sont plus liees a la taille du cache qu'a la capacite de calcul

.

Bah meme prime95 (projet GIMPS) est limite par l'efficacite de l'architecture memoire. C'est inevitable sur ce genre de calcul (parce que le mec qui ecrit ca, le fait en assembleur, et sait ce que c'est que faire du preload et sait aussi menager les TLB ).

**newbie06** · 29/10/2008, 15h22

Envoyé par fefe

-Des resultats etranges pour le nombre de fetch/instruction mais etant donne l'approche fondamentalement differente des 2 frontend ce n'est pas surprenant que les compteurs de perf ne comptent pas vraiment la meme chose.

Je pense la meme chose : le nombre d'acces Icache ne veut rien dire et est sans doute juste dans les deux cas ; mais si par exemple le k8 ne compte pas une eventuelle queue d'instructions entre la Icache et le coeur qui serait utilisee pour les boucles, du coup la comparaison est inutile.

Dans ce cas-la, je pense que seul le taux de miss peut etre pris en compte. Et encore, il n'est pas evident que les predicteurs pilotant le prefetch ne vont pas encore rendre la comparaison difficile

**Tramb** · 29/10/2008, 15h25

Envoyé par newbie06

Ce n'est pas un critere. Quand tu fais des calculs en tres haute precision, tu utilises des FFT dont l'implementation est bien plus efficace en flottant qu'en entier, meme si tu passes par des conversions entier->flottant et vice versa, et que tu dois faire un controle d'erreur pousse.

Tu m'étonnes, le contrôle d'erreur doit être ignoble.

Au fait quel est l'argument pour dire qu'une FFT flottante est bien plus performante qu'une FFT entière?

**fefe** · 29/10/2008, 15h35

A ma connaissance l'utilisation de FP ou int depend du type d'application visee. Je ne connais pas vraiment bien ce domaine a part que cela fait partie des applications qui aimaient bien les 80bits de precision de x87.

http://en.wikipedia.org/wiki/Arbitra...ion_arithmetic

**Tramb** · 29/10/2008, 15h40

Envoyé par fefe

A ma connaissance l'utilisation de FP ou int depend du type d'application visee. Je ne connais pas vraiment bien ce domaine a part que cela fait partie des applications qui aimaient bien les 80bits de precision de x87.

http://en.wikipedia.org/wiki/Arbitra...ion_arithmetic

Ouais les applications qui aiment bien les 80 bits, ça veut en général pas dire "contrôle d'erreur poussé", ça veut dire "on en fout le plus possible et on espère que ça passe"

Enfin bon, l'argument sur la FFT me semblait bizarre, parceque les DCT, MDCT des codecs et certaines FFT sont codées en entiers, et puis bon si tu te satisfais de 16 bits, tu as pas mal d'opérations 8-way au lieu de 4-way en float.

**newbie06** · 29/10/2008, 15h42

Envoyé par Tramb

Tu m'étonnes, le contrôle d'erreur doit être ignoble.

Pas tant que ca, mais ca necessite un minimum de math pour comprendre. Pour les details gore, voir par exemple : http://www.faginfamily.net/barry/Pap...Transforms.pdf

Au fait quel est l'argument pour dire qu'une FFT flottante est bien plus performante qu'une FFT entière?

Poula ca fait longtemps que je n'ai plus pratique ca. Il me semble me souvenir que si tu fais ta FFT sur des anneaux d'entier, la phase de reconstruction n'est pas triviale et necessite d'utiliser des modulos, donc des divisions. Attention, je ne me souviens ptet pas tout a fait juste avec mon age gnatruc

Par ailleurs, IIRC (encore une fois...) les multiplications 64x64 entieres sont lentes sur les Core2 alors qu'en flottant tu fais du 53x53 tranquille. C'est pourquoi les Core2 se font exploser par les K8 et autres sur GMP (http://gmplib.org/gmpbench.html).

Envoyé par fefe

A ma connaissance l'utilisation de FP ou int depend du type d'application visee. Je ne connais pas vraiment bien ce domaine a part que cela fait partie des applications qui aimaient bien les 80bits de precision de x87.

http://en.wikipedia.org/wiki/Arbitra...ion_arithmetic

Lorsque la precision augmente, tu diminues les erreurs ( (c)Lapalisse) et donc tu peux reduire le nombre de points de ta FFT.

**fefe** · 29/10/2008, 15h55

Envoyé par Tramb

Enfin bon, l'argument sur la FFT me semblait bizarre, parceque les DCT, MDCT des codecs et certaines FFT sont codées en entiers, et puis bon si tu te satisfais de 16 bits, tu as pas mal d'opérations 8-way au lieu de 4-way en float.

Pour la DCT/iDCT il t'en faut 17 en pratique, et c'est chiant

**Tramb** · 29/10/2008, 15h58

Envoyé par fefe

Pour la DCT/iDCT il t'en faut 17 en pratique, et c'est chiant

Bof en salopant un peu les coefficients... si c'est pour de la texture filtrée...

**newbie06** · 30/10/2008, 08h38

Envoyé par newbie06

Le machin bidule Pi que tous les overclockers utilisent, il ne fait pas du x87 ?

Je confirme. J'ai lance un coup d'IDA sur le Super PI original (la version mod, que tout le monde utilise je crois, est packee, et ca me fatigue) : c'est plein de fld, fst, fmul et autres joyeuseries x87.

**Childerik** · 30/10/2008, 09h05

Envoyé par newbie06

Je confirme. J'ai lance un coup d'IDA sur le Super PI original (la version mod, que tout le monde utilise je crois, est packee, et ca me fatigue) : c'est plein de fld, fst, fmul et autres joyeuseries x87.

C'est normal : si le code original date bien de 95, alors c'est avant l'introduction du MMX. Or, qu'est ce qu'il y avait avant le MMX ?

**newbie06** · 30/10/2008, 09h17

Le but etait juste de montrer que le code x87 existait bel et bien encore dans certains benchmarks utilises

**fefe** · 30/10/2008, 10h28

Et je confirme, pas seulement dans les benchmarks, il y a beaucoup de code x87 qui tourne encore, beaucoup plus qu'on a tendance a l'imaginer.

**Foudge** · 30/10/2008, 11h31

Envoyé par newbie06

Le but etait juste de montrer que le code x87 existait bel et bien encore dans certains benchmarks utilises

Mais comme tu l'a dit, personne n'utilise la version originale. Ca veut pas dire que la version mod 1.5 utilise massivement du SSE, mais le doute persiste à ce sujet

**newbie06** · 30/10/2008, 11h49

Envoyé par Foudge

Mais comme tu l'a dit, personne n'utilise la version originale. Ca veut pas dire que la version mod 1.5 utilise massivement du SSE, mais le doute persiste à ce sujet

Vu qu'ils n'ont pas eu acces au source (a ma connaisssance), j'ai un doute. Ce mod est un gros hack. Remarque, y'a de tres bons hackers capables d'ajouter du SSE et autre. Si quelqu'un s'y connait, il m'envoie le binaire depacke et je compare avec l'original

**Yasko** · 30/10/2008, 11h54

Envoyé par newbie06

Si quelqu'un s'y connait, il m'envoie le binaire depacke et je compare avec l'original

Envoyé par newbie06

En tout cas, quand j'etais du cote des mechants, je peux t'assurer que l'absence de sources n'etait nullement un frein.

Fake !

**newbie06** · 30/10/2008, 12h05

Envoyé par Yasko

Fake !

Heu, comme le faisait remarquer Childerik, je suis un croulant. A l'epoque ou j'etais un vilain peu frequentable, les PC coutaient une fortune et etaient reserves aux entreprises. Je suis encore capable d'assembler et de desassembler du code Z80 de tete, ce qui est un veritable plus sur mon CV

**Childerik** · 30/10/2008, 12h08

Envoyé par newbie06

Heu, comme le faisait remarquer Childerik

...

**newbie06** · 30/10/2008, 13h18

Envoyé par Childerik

...

Fixed

**fefe** · 30/10/2008, 14h38

Envoyé par newbie06

Je suis encore capable d'assembler et de desassembler du code Z80 de tete, ce qui est un veritable plus sur mon CV

Ah toi aussi tu as un CV avec des items super utiles:
-Assembleur 6800 lu ecrit parle
-Assembleur x86 en hexa dans le texte
-Programmation en Scheme, APL, Forth...

**newbie06** · 30/10/2008, 14h46

Envoyé par fefe

Ah toi aussi tu as un CV avec des items super utiles:
-Assembleur 6800 lu ecrit parle
-Assembleur x86 en hexa dans le texte
-Programmation en Scheme, APL, Forth...

Mouai pas loin, sauf que j'ai CommonLISP en lieu et place d'APL, ainsi que z80 au lieu de x86. C'est dommage, il me manque COBOL et Java.

**Møgluglu** · 30/10/2008, 17h29

Envoyé par newbie06

Vu qu'ils n'ont pas eu acces au source (a ma connaisssance), j'ai un doute. Ce mod est un gros hack. Remarque, y'a de tres bons hackers capables d'ajouter du SSE et autre. Si quelqu'un s'y connait, il m'envoie le binaire depacke et je compare avec l'original

Pour SuperPi, j'imagine qu'il utilise une bibliothèque genre GMP et a été compilé avec un antique gcc, donc il suffirait "juste" de le relinker avec une version plus récente...

En passant, sur le FTP de Kanada, il n'y a que la version Windows qui date de 1995, toutes les autres plate-formes sont de 2003...
ftp://pi.super-computing.org/pub/

Pour une fois que les utilisateurs de Solaris et Tru64 sont les premiers servis...

Bon, là c'est clair :

Code:

 Version 2.0 of the super_pi for Linux OS
 Fortran source program was translated into C program with version 19981204 of
 f2c, then generated C source program was optimized manually.
 pgcc 3.2-3 with compile option of "-fast -tp px -Mbuiltin -Minline=size:1000 -Mnoframe -Mnobounds -Mcache_align -Mdalign -Mnoreentrant" was used for the
 compilation.

J'ose même pas imaginer avec quel compilo Fortran a été compilé la version 95

Edit:
super_pi 1M, fight :
- Alpha 21264 667 MHz : 80.433 s
- C2D E8400 3 GHz : 12.305 s
Rapporté à la fréquence, l'Alpha s'en sort effectivement pas si mal...

**newbie06** · 30/10/2008, 17h40

Envoyé par Møgluglu

Pour SuperPi, j'imagine qu'il utilise une bibliothèque genre GMP et a été compilé avec un antique gcc, donc il suffirait "juste" de le relinker avec une version plus récente...

Je ne pense pas. Puis si oui, ils sont en violation avec la LGPL, puiqu'aucun moyen n'est donne pour linker avec une nouvelle lib

Code:

 Version 2.0 of the super_pi for Linux OS
 Fortran source program was translated into C program with version 19981204 of
 f2c, then generated C source program was optimized manually.
 pgcc 3.2-3 with compile option of "-fast -tp px -Mbuiltin -Minline=size:1000 -Mnoframe -Mnobounds -Mcache_align -Mdalign -Mnoreentrant" was used for the
 compilation.

J'ose même pas imaginer avec quel compilo Fortran a été compilé la version 95

Nan mais deja rien que f2c c'est trop drole. Bon le portland group compiler n'etait pas mauvais, il me semble, c'est toujours ca

Discussion: k8 vs core2, analyse par performance counters

Outils de la discussion

Règles de messages