[MT] Benchmark de produits matriciels sur processeurs multi-cores

ben justement:
j'ai recompiler avec icc en commentant les 3 lignes que tu avais ecrites:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

icpc main.cpp -o icc-genial -O2 -no-inline-max-size -msse3 -Winline -xP -I../genial -I/xxx/ATLAS/include/ -L/xxx/ATLAS/my_build_dir/lib/ -I/xxx/ATLAS/my_build_dir/include/ -latlas -lcblas   Benchmark GEMM 48 15 SSE2.txt float (4x4) 1760 42.7763 -1 (8x8) 12875 256.711 -1 (16x16) 82746 868.073 -1 (32x32) 654433 2043.41 -1 (64x64) 5.35583e+06 1671.43 -1 (100x100) 2.00907e+07 2290 -1 (128x128) 4.25664e+07 2524.97 -1 (144x144) 6.07443e+07 2729.19 -1 (160x160) 8.31146e+07 2686.98 -1 (176x176) 1.10521e+08 2867.63 -1 (192x192) 1.4366e+08 2859.47 -1 (200x200) 1.62499e+08 2832 -1 (256x256) 3.41608e+08 2885.68 -1 (400x400) 1.29629e+09 3072 -1 (500x500) 2.53153e+09 3125 -1 (512x512) 2.71749e+09 3158.06 -1 (600x600) 4.37573e+09 3229.91 -1 (700x700) 6.94451e+09 3118.18 -1 Segmentation fault

---

ca a l'air de venir de ton code donc ... à priori

je trouve ca bizarre ce segmentation fault, il ne le faisait pas avant, c'est depuis que tu m'as redonné le code avec ATLAS... ou alors ca vient des libs ATLAS...

Là ça m'inquiète.
Mais ça fonctionnait bien avant pourtant! Et ça marche bien sur mon ordi depuis des lustres. hum...

Rechange pour voir la ligne dans le programme principal
"mul(A,B,C1);" en "gemm(1,A,B,1,C1)". C'était l"instruction que je t'avais par erreur donnée dans le tout premier bench qui calcule en fait C+=A*B au lieu de C=A*B, mais ça n'influençait pas vraiment les perfs.

Citation:

---

Envoyé par epsilon68

ou alors ca vient des libs ATLAS...

---

tu peux toujours éviter l'édition de lien en enlevant '-lcblas' et '-latlas' mais je doute que ça fasse effet vu qu'aucune fonction d'ATLAS n'est appelée.

Citation:

---

Envoyé par Charlemagne

tu peux toujours éviter l'édition de lien en enlevant '-lcblas' et '-latlas' mais je doute que ça fasse effet vu qu'aucune fonction d'ATLAS n'est appelée.

---

justement je venais d'essayer, sans changement

avec le changement que tu m'as dit, plus de segmentation fault !

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Benchmark GEMM 48 15 SSE2.txt float (4x4) 5.05302e+08 36.6769 -1 (8x8) 2.48844e+09 197.927 -1 (16x16) 6.10461e+09 604.406 -1 (32x32) 1.40114e+10 1403.13 -1 (64x64) 1.37859e+10 1349.52 -1 (100x100) 1.88852e+10 1880 -1 (128x128) 2.1794e+10 2147.48 -1 (144x144) 2.38117e+10 2341.01 -1 (160x160) 2.3854e+10 2351.1 -1 (176x176) 2.54198e+10 2507.82 -1 (192x192) 2.58587e+10 2548.04 -1 (200x200) 2.535e+10 2496 -1 (256x256) 2.66455e+10 2617.25 -1 (400x400) 2.98145e+10 2886.27 -1 (500x500) 3.03785e+10 2941.18 -1 (512x512) 3.26096e+10 2982.62 -1 (600x600) 3.50058e+10 3085.71 -1 (700x700) 3.47222e+10 3035.4 -1 (800x800) 3.10437e+10 3072 -1 (900x900) 4.42105e+10 3124.29 -1

---

Merde alors.
Je vais essayer de voir le problème, mais il n'y a en interne quasiment pas de différence entre les 2 calculs, et puis ça marche sans problème chez moi depuis des lustres.

:mouarf: ca n'arrive qu'a moi :mouarf

t'as une piste ? une supposition ? un doute ? anguille sous roche ?

J'ai vérifié le code et je ne vois pas de problème. De manière interne 'mul(A,B,C) <=> C=A*B', et 'gemm(1,A,B,1,C) <=> C+=A*B' utilisent les mêmes fonctions sauf une. Ces 2 variantes de fonctions ont beaucoup de code commun, la variante pour 'gemm' rajoute juste un peu de code pour faire l'addition de matrices. Bref c'est incompréhensible.

J'ai compilé avec GCC 3.4.4 sous cygwin et ça roule.

Je n'ai pas vraiment de pistes:

1)Peut-être qu'il y a un problème d'alignement mémoire mais je n'y crois pas beaucoup, car on aurait vu le problème probablement plus tôt.
Tu peux toujours essayer de modifier la fonction correspondante dans 'memory.h'.

Code:

---

1 2 3 4 5 6 7 8 9 10

#elif defined(__APPLE__) #include <stdlib.h> inline void* aligned_malloc (size_t size, size_t align=16) { void *p=malloc(size); if ((int)p%16) cout << "allocation memoire non alignee" << endl; return p; } inline void aligned_free (void *p) { return free(p); } #else

---

2) A part débugger je ne vois plus quoi faire. Et comme la "segmentation fault" se produit visiblement pour les tailles 800x800, si l'erreur est en plein milieu des calculs, je te souhaites bien du plaisir (je ne veux pas te forcer). Maintenant, si tu trouves ne serait-ce que l'instruction qui plante, ça me mettrait peut-être sur la piste.

j'ai fait la modif dans memory.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Benchmark GEMM 48 15 SSE2.txt float (4x4) 1760 42.5949 -1 (8x8) 12875 255.891 -1 (16x16) 82746 869.523 -1 (32x32) 654433 2038.82 -1 (64x64) 5.35583e+06 1620.57 -1 (100x100) 2.00907e+07 2240 -1 (128x128) 4.25664e+07 2407.53 -1 (144x144) 6.07443e+07 2663.5 -1 (160x160) 8.31146e+07 2572.29 -1 (176x176) 1.10521e+08 2791.31 -1 (192x192) 1.4366e+08 2760.38 -1 (200x200) 1.62499e+08 2736 -1 (256x256) 3.41608e+08 2751.46 -1 (400x400) 1.29629e+09 2953.85 -1 (500x500) 2.53153e+09 3000 -1 (512x512) 2.71749e+09 3010.49 -1 (600x600) 4.37573e+09 3113.51 -1 (700x700) 6.94451e+09 3008.77 -1 Segmentation fault

---

c'est pas ca...

le segmentation fault est encore la meme sans optimisation, bonne nouvelle je dirais .. :aie: pour gcc et icc :mrgreen:

avec gdb j'ai le message:

Code:

---

1 2 3 4

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x007f5000 0x002613ca in sse_real_matmul2<15, dot_function, sum_function, data_matrix_generator<Vector<tiny_vector_generator<4, float> > const>, data_matrix_generator<Vector<tiny_vector_generator<4, float> > const>, sub_array_generator<Matrix<data_matrix_generator<float> >, 0>, add_adaptor_function<id_adaptor_function> > (A=@0xbfffd3bc, B=@0xbfffd3ac, C=@0xbfffd614, adaptor=@0xbfffd3ab) at ../genial/simd/sse.h:72 72 inline m128f operator* (const m128f &x, const m128f &y) { return m128f(_mm_mul_ps(x.vec,y.vec)); }

---

et si j'enleve l'inline dans genial_config.h

Code:

---

1 2 3 4

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00705000 0x000030ab in loadu (x=@0xbfffdb60, p=0x704ff8) at ../genial/simd/sse.h:105 105 inline void loadu(m128f &x, const float *p) { x.vec = _mm_loadu_ps((float *)p); }

---

ca t'aide ?

C'est encore plus bizarre.

La 'segmentation fault' ne semble pas se produire au même endroit dans les 2 cas.
Dans un cas c'est dans une surcharge de la multiplication (pour des registres SSE), dans l'autre c'est pour le chargement de mémoire non alignée (loadu, u comme unaligned).
De plus l'algo s'impose de multiplier des données alignées en mémoire (condition indispensable pour la vitesse). L'algo ne fait des accès non alignés uniquement pour stocker des résultats définifs.


"Could not access memory" laisse penser que l'algo veut accéder à des zones mémoire ne lui appartenant pas, mais comme mon programme marche bien sous d'autres systèmes et d'autres compilos, ça rend sceptique.

Et puis bizarre qu'il veuille charger 16 octets à l'adresse 0x704ff8 mais que l'ordi se plaigne de ne pouvoir accéder à la mémoire 8 octets plus hauts. Y'a des contraintes de "page mémoire" sous Mac ou quoi?

Je pense avoir compris pourquoi la variante C+=A*B marche par rapport à 'C=A*B'. En fait les multiplications matricielles par bloc sont écrites dans une matrice temporaire alignée (avant d'être additionnées à la matrice C), alors que la variante 'C=A*B' écrit les multiplications partielles directement dans C.
Mais ça ne m'explique toujours "la segmentation fault"

Je n'ai pas vraiment d'idées.
Je vais encore y réfléchir, mais si t'as d'autres indices entre temps...

J'ai une piste sérieuse.
Dans le fichier 'vector.h' (vers la ligne 680), remplace

Code:

---

1 2 3

inline void load (Vector<tiny_vector_generator<2,float> > &X, const float *p) { load (X.generator().data, p); } inline void loadu (Vector<tiny_vector_generator<2,float> > &X, const float *p) { loadu (X.generator().data, p); }

---

par

Code:

---

1 2	inline void load (Vector<tiny_vector_generator<2,float> > &X, const float *p) { loadl (X.generator().data, p); } inline void loadu (Vector<tiny_vector_generator<2,float> > &X, const float *p) { loadl (X.generator().data, p); }

---

Si c'est bien ça, ça voudrait dire qu'il y a une sécurité de plus sur Mac par rapport à d'autres systèmes, du genre pas le droit de lire dans de la mémoire non allouée.
J'avais utilisé une certaine instruction SSE plutôt qu'une autre à l'époque pour optimiser un peu plus. J'espère que ça ne va pas avoir de grosses influence sur les perfs sous XP, ou je vais peut-être mettre à cet endroit une directive de compilation '#ifdef __APPLE__' si c'est bien l'origine de la 'segmentation fault'

touché coulé !
t'as vu juste, c'est ca !

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

(gdb) run Starting program: genial-2.0.2/samples/gcc-genial Reading symbols for shared libraries .. done Benchmark GEMM 48 15 SSE2.txt float (4x4) 1760 5.87494 -1 (8x8) 12875 17.8432 -1 (16x16) 82746 26.5912 -1 (32x32) 654433 38.7973 -1 (64x64) 5.35583e+06 37.7487 -1 (100x100) 2.00907e+07 42.3077 -1 (128x128) 4.25664e+07 42.7198 -1 (144x144) 6.07443e+07 44.6502 -1 (160x160) 8.31146e+07 43.4973 -1 (176x176) 1.10521e+08 45.056 -1 (192x192) 1.4366e+08 44.5851 -1 (200x200) 1.62499e+08 44.4444 -1 (256x256) 3.41608e+08 44.1506 -1 (400x400) 1.29629e+09 45.3901 -1 (500x500) 2.53153e+09 45.8716 -1 (512x512) 2.71749e+09 45.965 -1 (600x600) 4.37573e+09 46.4017 -1 (700x700) 6.94451e+09 46.0403 -1 (800x800) 1.0348e+10 46.0846 -1 (900x900) 1.47385e+10 46.4183 -1   Program exited normally.

---

franchement chapeau !

je n'arrive pas à inliner avec icc
mais ca donne une idée sur ATLAS

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Benchmark GEMM 48 15 SSE2.txt float (4x4) 0 41.8003 43.146 (8x8) 0 170.122 252.171 (16x16) 0 339.296 731.021 (32x32) 0 419.103 1127.15 (64x64) 0 403.177 2760.38 (100x100) 0 434 2410 (128x128) 0 432.013 2541.75 (144x144) 0 437.55 2346.98 (160x160) 0 442.368 2924.54 (176x176) 0 442.619 2791.31 (192x192) 0 438.829 3737.12 (200x200) 0 434.951 3728 (256x256) 0 443.172 4026.53 (400x400) 0 445.217 4141.18 (500x500) 0 450.45 4285.71 (512x512) 0 447.392 4294.97 (600x600) 0 445.361 4441.12 (700x700) 0 445.455 4487.85 (800x800) 0 445.217 4452.17 (900x900) 0 447.239 4486.15 (1000x1000) 0 447.427 4477.61 (1024x1024) 0 445.536 4473.92 (1500x1500) 0 447.316 4560.81 (2000x2000) 0 447.427 4597.7

---

Sans tes indices, j'aurais jamais trouvé. Et puis je connais un peu mon programme ;)

Le problème, c'est que ça m'arrange pas du tout. A vu de nez, les benchs sont 15% plus lent maintenant sur mon ordi, ça fait beaucoup pour un si petit changement. Surtout que si j'ai bien compris, je crois bien que le bug n'apparaît au plus qu'une fois par produit matriciel, et pour quelques dimensions seulement.

Je vois 3 possibilités:
1)faire une directive de compilation spéciale pour Mac à cet endroit (et à 1 ou 2 autres similaires). Mais j'imagine que ce sera également plus lent sur les Macs.

2)Faire en sorte qu'une allocation mémoire alloue un peu plus que strictement nécessaire.
- Rechange les 2 fonctions dans 'vector.h' comme elles étaient initialement

Code:

---

1 2	inline void load (Vector<tiny_vector_generator<2,float> > &X, const float *p) { load (X.generator().data, p); } inline void loadu (Vector<tiny_vector_generator<2,float> > &X, const float *p) { loadu (X.generator().data, p); }

---

- modifie l'allocation mémoire dans 'memory.h' pour allouer 16 octets de plus

Code:

---

1 2 3 4 5

#elif defined(__APPLE__) #include <stdlib.h> inline void* aligned_malloc (size_t size, size_t align=16) { return malloc(size+16); } inline void aligned_free (void *p) { return free(p); } #else

---

3) Modifier l'ordre d'appel de fonctions
-garde les fonctions d'origine dans 'vector.h' et dans 'memory.h'
-change dans le fichier 'gemm.h' dans les DEUX fonctions 'sse_real_matmul' et 'sse_real_matmul2'

Code:

---

1 2	adapt(j ,func(s0,s1,s2,s3)); adapt(j+4,func(s4,s5));

---

par

Code:

---

1 2	adapt(j ,func(s0,s1)); adapt(j+2,func(s2,s3,s4,s5));

---

Cette 3ème possibilité (si elle marche) a pour l'instant ma préférence.


Sinon je vais également essayer de trouver une meilleure instruction assembleur pour charger la mémoire dans ce cas de figure, mais j'avais déjà cherché un peu à l'époque.

Citation:

---

Envoyé par epsilon68

je n'arrive pas à inliner avec icc
mais ca donne une idée sur ATLAS

---

Dommage pour ICC.

Ya pas à dire, ATLAS est fort...
Il confirme aussi que le Core Duo sur portable est moins performant qu'un Pentium 4 de bureau. J'ai l'impression que les ordinateurs portables sont systématiquement plus lents que leur équivalent de bureau.

Tu as bien un core en réserve sur le Core Duo? (c'est le même processeur qu'un Core 2 Duo? Je m'y perds avec la nomenclature...)

Si tu veux tester le multi-threading d'ATLAS je pense qu'il te suffit de compiler une autre configuration d'ATLAS en répondant oui à la question des "pthreads".

Citation:

---

Envoyé par Charlemagne

Dommage pour ICC.

Ya pas à dire, ATLAS est fort...
Il confirme aussi que le Core Duo sur portable est moins performant qu'un Pentium 4 de bureau. J'ai l'impression que les ordinateurs portables sont systématiquement plus lents que leur équivalent de bureau.

Tu as bien un core en réserve sur le Core Duo? (c'est le même processeur qu'un Core 2 Duo? Je m'y perds avec la nomenclature...)

Si tu veux tester le multi-threading d'ATLAS je pense qu'il te suffit de compiler une autre configuration d'ATLAS en répondant oui à la question des "pthreads".

---

je n'arrive plus a inliner ni avec gcc 4.01 ni avec icc ...
EDIT je n'arrive pas à inliner ni avec gcc 4.01 ni avec icc 10, seul gcc 4.2 s'en sort bien ...
le core duo a bien deux cores mais c'etait le premier processor dual cores de chez Intel. A priori l'architecture du Core 2 duo est totalement differente et offrirait 40% en plus... Chose que je testerai bien sûr prochainement héhéhé

Pour ATLAS, il ne m'a jamais posé de question ... ou est-ce que
je le configure ?

le dernier bench avec GENIAL et ATLAS sur gcc 4.2 -O3

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

Benchmark GEMM 48 15 SSE2.txt float (4x4) 0 34.3997 30.6175 (8x8) 0 204.302 201.084 (16x16) 0 565.109 549.806 (32x32) 0 1830.81 1106.12 (64x64) 0 1417.67 2719.48 (100x100) 0 1860 2402 (128x128) 0 2042.63 2269.12 (144x144) 0 2215.6 2293.24 (160x160) 0 2121.73 2637.82 (176x176) 0 2246.13 2736.79 (192x192) 0 2307.39 3531.94 (200x200) 0 2240 3600 (256x256) 0 2248.15 3925.87 (400x400) 0 2407.92 4096 (500x500) 0 2427.18 4285.71 (512x512) 0 2440.32 4294.97 (600x600) 0 2541.18 4400 (700x700) 0 2472.07 4446.3 (800x800) 0 2518.03 4413.79 (900x900) 0 2557.89 4486.15 (1000x1000) 0 2531.65 4511.28 (1024x1024) 0 2511.68 4443.07 (1500x1500) 0 2586.21 4530.2 (2000x2000) 0 2593.19 4571.43 (2048x2048) 0 2591.23 4569.11

---

Citation:

---

Envoyé par epsilon68

Pour ATLAS, il ne m'a jamais posé de question ... ou est-ce que je le configure ?

---

Quand tu exécutes './xconfig.exe', il te pose plusieurs questions dont ton architecture. Pour toutes les autres je pense qu'il vaut mieux répondre par défaut (taper entrée) sauf peut-être dans ton cas à l'une d'elles où il est question de "pthreads".

Sinon, as tu eu le temps d'essayer les 2 propositions plus haut, et de voir si la "segmentation fault" disparaissait?

non pas encore, je suis en train de recompiler ATLAS avec gcc4.2 et je suis en train de downloader gcc 4.2.1 ...
je ferais un retour sur GENIAL juste apres ...

ATLAS doit etre par default multi-thread...
a la compil il a detecté mon archi et 2 threads

cela expliquerait peut-etre pourquoi il est presque 2 fois plus rapide ?