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

Version imprimable

Voir 40 message(s) de cette discussion en une page

23/07/2007, 12h45
Charlemagne

Citation:

Envoyé par epsilon68

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

Je ne sais pas. Je ne pense pas, sinon la question sur les "Posix Threads" (la question qui suit celle sur l'architecture avec ATLAS 3.6.0) n'aurait pas de sens.
Pour en être sûr il faudrait que tu compares les perfs des 2 configurations différentes d'ATLAS. Il suffit de changer le chemin d'accès aux librairies d'ATLAS dans la ligne de commande de GCC.

Je viens de faire d'autres benchs sur mon ordi concernant la proposition 3 un peu plus haut pour résoudre la 'segmentation fault', mais y'a une petite baisse de perfs. Donc si la proposition 2 (allouer un peu plus de mémoire que strictement nécessaire) marche su ton ordi, c'est celle que j'adopterai.
J'ai bien trouvé une instruction assembleur plus rapide, mais ça ne suffit pas non plus pour avoir les mêmes perfs.

PS: Tiens, y'a maintenant le symbole [MT] dans le titre du topic. C'est un admin qui l'a rajouté?
23/07/2007, 13h07
epsilon68

Citation:

Envoyé par Charlemagne

Je ne sais pas. Je ne pense pas, sinon la question sur les "Posix Threads" (la question qui suit celle sur l'architecture avec ATLAS 3.6.0) n'aurait pas de sens.
Pour en être sûr il faudrait que tu compares les perfs des 2 configurations différentes d'ATLAS. Il suffit de changer le chemin d'accès aux librairies d'ATLAS dans la ligne de commande de GCC.

je n'ai pas la 3.6 mais la dernière ... je n'ai pas xconfigure et il fait une auto-configuration... j'ai aussi recompilé avec gcc 4.2.1 sans aucune amelioration du bench.

Citation:

Envoyé par Charlemagne

Je viens de faire d'autres benchs sur mon ordi concernant la proposition 3 un peu plus haut pour résoudre la 'segmentation fault', mais y'a une petite baisse de perfs. Donc si la proposition 2 (allouer un peu plus de mémoire que strictement nécessaire) marche su ton ordi, c'est celle que j'adopterai.
J'ai bien trouvé une instruction assembleur plus rapide, mais ça ne suffit pas non plus pour avoir les mêmes perfs.

ok je le fais ce soir.

Citation:

Envoyé par Charlemagne

PS: Tiens, y'a maintenant le symbole [MT] dans le titre du topic. C'est un admin qui l'a rajouté?

bonne question, oui ca doit etre un admin...

voila j'ai fait la modification 2 (qui alloue un peu plus de memoire)
et ca marche.
Je pense qu'il faut appliquer cette modif à toutes les plateformes, vu que c'est interdit de tapper dans de la memoire non allouée, qu'en penses-tu ?

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       41.9218 42.6312
(8x8)   0       255.65  249.518
(16x16) 0       822.739 728.629
(32x32) 0       1834.68 1132.33
(64x64) 0       1453.85 2718.43
(100x100)       0       1892    2430
(128x128)       0       2076.18 2277.51
(144x144)       0       2239.49 2323.1
(160x160)       0       2187.26 2891.78
(176x176)       0       2333.36 2082.58
(192x192)       0       2364.01 3779.59
(200x200)       0       2288    3744
(256x256)       0       2348.81 4060.09
(400x400)       0       2461.54 4224
(500x500)       0       2500    4368.93
(512x512)       0       2508.74 4346.1
(600x600)       0       2566.34 4483.02
(700x700)       0       2494.55 4530.19
(800x800)       0       2560    4452.17
(900x900)       0       2603.57 4520.93
(1000x1000)     0       2564.1  4511.28
(1024x1024)     0       2541.4  4505.21
(1500x1500)     0       2626.46 4591.84
(2000x2000)     0       2622.95 4610.95
(2048x2048)     0       2618.88 4593.55

si d'autres pouvaient faire tourner le benchmark sur le meme processor que moi, je serais assez curieux de voir les resultats.

23/07/2007, 20h19
Charlemagne

Citation:

Envoyé par epsilon68

voila j'ai fait la modification 2 (qui alloue un peu plus de memoire)
et ca marche.
Je pense qu'il faut appliquer cette modif à toutes les plateformes, vu que c'est interdit de tapper dans de la memoire non allouée, qu'en penses-tu ?

Merci! Cool que ça marche.
De toute évidence sous Mac, il est effectivement interdit de lire dans de la mémoire non allouée (même un tout petit peu...). Il se trouve que quand mon algo met à jour la fin d'une matrice, très rarement il lit un bloc SSE de 16 octets à l'extrémité de la mémoire réservée en débordant. Normalement ça n'aurait pas dû être grâve puisque l'opération d'écriture qui suit utilise une instruction assembleur qui ne déborde pas.

Ta suggestion d'étendre la modif aux autres plateforme est tentante, mais je vais encore y réfléchir. Ca n'urge pas pour le moment. Il se trouve que je m'étais donné vraiment beaucoup de mal pour que certaines variantes de la FFT ne déborde pas en écriture (certes, c'est plus grave qu'en lecture). C'est un comble de devoir probablement faire marche arrière en allouant à nouveau un peu plus que nécessaire. C'est pour ça que je vais me laisser un peu de temps de réflexion...

Sinon, t'es sûr qu'ATLAS utilise les 2 noyaux de ton processeur? Y'a surement moyen d'imposer une configuration mono-processeur.
Si vraiment il utilise les 2 noyaux, ça m'arrange parce que ça veut dire que j'ai encore de la marge sur les perfs.
Je vais te transmettre sous peu les fichiers qui te permettront de compiler mon produit matriciel multi-threadé.

Et si t'as encore un peu de temps, ça serait cool que tu essayes de voir si t'arrives à améliorer la gestion du cache.
Il suffit pour cela de modifier en tâtonnant les paramètres BLAS_M, BLAS_N, BLAS_K,BLAS_K,BLAS_K2 qui définissent les tailles de blocs de matrices:
Tu peux les déclarer:
-soit dans le fichier 'genial_config.h'
-soit tout en haut du fichier principal (avant tout autre 'include'), à condition de bien déclarer toutes les 4.

Ces paramètres valent actuellement 48,48,15,15
- BLAS_M et BLAS_N doivent être des multiples de 12.
- BLAS_K2 n'est pas vraiment importante pour les grandes matrices, laisse la à 15.
Fais des benchs sur quelques grandes matrices 500 à 2000 par exemple (modifie la variable statique 'sizes' du programme principal) , pas la peine de tester les petites matrices.
Commence par exemple à incrémenter plusieurs fois de +1 la valeur BLAS_K pour voir si il y'a un effet positif sur les perfs.
Tu pourras après essayer (BLAS_M=60 BLAS_N=48) (BLAS_M=48 BLAS_N=60) (BLAS_M=60 BLAS_N=60)...
23/07/2007, 21h20
epsilon68

tu voudrais pas faire un ptit programme de recherche des meilleurs valeurs ?
on pourrait aussi comparer ces valeurs pour les differents processors...
qu'en penses-tu ?
23/07/2007, 21h42
Charlemagne

Citation:

Envoyé par epsilon68

tu voudrais pas faire un ptit programme de recherche des meilleurs valeurs ?

Franchement je ne vois pas comment faire, et c'est sûrement un travail de longue haleine. Certes ATLAS a forcément un truc dans le genre dans son programme de configuration qui analyse la machine...

Citation:

Envoyé par epsilon68

on pourrait aussi comparer ces valeurs pour les differents processors...
qu'en penses-tu ?

Tous les processeurs que tu désires...
-Sur mon Pentium 4 HT 2.6GHz, c'est le paramétrage extrême (132,132,100,25) qui donne les meilleurs résultats mais c'est pas le genre de paramétrage que je conseillerais. Le paramétrage (48,48,15,15) marche bien aussi.
-Sur les Pentium 4E Prescott c'est le paramétrage (48,48,15,15) qui marche le mieux.
Pour toute les machines avec la même taille de cache L1 que les Pentiums 4 (16Ko je crois), c'est la configuration qui a de fortes chances de marcher le mieux.

Sinon je vais voir pour installer la dernière version "instable" 3.7.43 d'ATLAS. Je ne pense pas que ça fasse une grande différence par rapport à la version 3.6.0 sur mon ordi vieillissant.

PS: un détail ATLAS 3.7.34 et pas 3.7.43
23/07/2007, 21h52
epsilon68

Citation:

Envoyé par Charlemagne

Franchement je ne vois pas comment faire, et c'est sûrement un travail de longue haleine. Certes ATLAS a forcément un truc dans le genre dans son programme de configuration qui analyse la machine...

comme tes constantes sont en define, alors on pourrait imaginer une sorte de manager qui change un fichier .h et recompile, le lance, lis la sortie et compare par rapport au precedent...

bon c'est peut-etre trop compliqué juste pour ca ...
laisse tomber, j'essaierai a l'occasion de faire varier les valeurs....

je me reserve aussi du temps pour tester ton multi-thread :D
24/07/2007, 08h01
Charlemagne

Je viens d'essayer la toute dernière version "instable" 3.7.34 d'Atlas, et le moins qu'on puisse dire c'est qu'elle est vraiment instable sur mon ordi.
Les performances du produit matriciel fluctuent fortement d'une matrice à l'autre et sont nettement en dessous des perfs que j'obtiens avec la version "stable" 3.6.0.
Les perfs sont plus constantes sur ton ordi mais je crois que ça serait une bonne idée pour toi d'essayer la 3.6.0.

La procédure d'installation a beaucoup changé entre les version 3.6.0 et 3.7.34. La configuration est entièrement automatique avec 3.7.34 et je vois pas comment la paramétrer. Avec la version 3.6.0 c'est un peu plus manuel mais on peut mieux contrôler le paramétrage et ça reste très simple.
1)make xconfig
2)./xconfig.exe
-choisir l'architecture: un peu délicat dans ton cas: processeur inconnu? ou Pentium4 (SSE2)/Pentium4E (SSE3)?
-choisir si on veut utiliser les 'Posix threads', nombre de threads
-choisir par défaut pour le reste (en tout cas ça marche bien sur mon ordi)
3)make install arch=Nom de l'architecture
24/07/2007, 08h25
Charlemagne
Voici 2 fichiers que tu peux remplacer dans ma bibliothèque pour compiler la version multi-thread du produit matriciel ('genial/threads.h' et 'genial/blas/gemm.h').

Dans 'genial_config.h' il faut que tu crées la macro suivante (si tu ne l'a pas déjà copiée-collée précédemment)
Code:

1 2 3 #ifndef BLAS_THREADING #define BLAS_THREADING #endif
Voilà, j'espère que je n'ai rien oublié.
26/07/2007, 21h08
epsilon68

Je ne t'oublie pas, c'est juste que je n'ai pas le temps ces temps-ci...
tu es dans ma to-do list :aie:
26/07/2007, 22h51
Charlemagne

OK, merci.

Au fait, toi qui t'intéresses au multi-threading, ceci peut t'intéresser également: La nouvelle version de la bibliothèque Intel Threading Building Blocks (TBB), dont je parlais dans le topic sur la FFT et dont je me suis inspiré pour ma gestion multi-thread, est open source depuis quelques jours.
Je trouve qu'elle est bien plus intéressante qu'OpenMP.
http://softwaredispatch.intel.com/?p...R&t=3&lid=1588
27/07/2007, 08h46
epsilon68

... mais j'aime beaucoup beaucoup OpenMP: pas compliqué, standard, multiplateforme (pas seulement linux,windows,mac), et vraiment integrable partout...

mais j'y jetterais quand meme un oeil :mouarf:
27/07/2007, 11h37
epsilon68

J'ai regardé TBB, et c'est vrai que c'est pas mal...
ca compile avec tous les compilateurs ?
et ca tourne avec les AMD ?
combien de plateformes ?

EDIT (FAQ)

The project is dedicated to supporting all compilers, all OSes and all processors as a cornerstone objective of the project. Up to date information on status is available on the web site.
27/07/2007, 13h38
Charlemagne

Citation:

Envoyé par epsilon68

J'ai regardé TBB, et c'est vrai que c'est pas mal...

Je trouve qu'OpenMP ressemble à du mauvais C.

TBB, c'est de la programmation générique "à la STL". Un point non négligeable, c'est leur bonne documentation (tutoriels, références...)
Je n'aime pas trop leur syntaxe, j'ai donc chercher à sérieusement la simplifier pour ma bibliothèque, même si elle est loin d'être aussi complète, mais pour l'instant ça me suffit.

Citation:

Envoyé par epsilon68

ca compile avec tous les compilateurs ?
et ca tourne avec les AMD ?
combien de plateformes ?

The project is dedicated to supporting all compilers, all OSes and all processors as a cornerstone objective of the project. Up to date information on status is available on the web site.

Je n'en sais pas plus. Donc a priori oui, ça marche sous toutes les plateformes. A fortiori pour les AMD compatibles x86.
19/08/2007, 21h54
epsilon68

j'ai recemment acheté VMWare fusion sur mon mac ...
ca tourne vraiment bien :P

voici les resultats de ton bench pour windows sur le mac avec VMWare:

et je reviens sur la compil mac pour le bench multi-thread:

Code:

1
2
3
4
5
 
/usr/local/bin/g++ main.cpp -o gcc-genial -O2 -I../genial -msse3 -Winline -I/xxx/ATLAS/include/ -L/xxx/ATLAS/my_build_dir/lib/ -latlas -lcblas -I/xxx/ATLAS/my_build_dir/include/
../genial/cpuid.h: In function 'gmt::cpuid_reg gmt::_cpuid(unsigned int, unsigned int)':
../genial/cpuid.h:50: error: can't find a register in class 'BREG' while reloading 'asm'
../genial/cpuid.h:50: error: 'asm' operand has impossible constraints

une idée ?

Content de te revoir.
J'espère que tu n'as pas acheté VMWare fusion uniquement pour mon bench!

Citation:

Envoyé par epsilon68

voici les resultats de ton bench pour windows sur le mac avec VMWare:

Le multi-threading marche pas trop mal.
Mais malheureusement les perfs de mon algo sont quelque peu inférieures à celle d'ATLAS.
Plus bizarre: les perfs de ta compilation mono-thread avec GCC (message 117) sont largement inférieures à ces dernières sous Windows XP. C'est d'autant plus bizarre que j'ai moi même entre temps essayé GCC 4.2.1 sous Windows, et les perfs de GCC étaient un peu inférieures à celles d'ICL pour la multiplication matricielle. (mais 4 fois plus lent pour la FFT).

Maintenent que GCC 4.2 peut forcer les 'inline', les perfs sont en sérieux progrès depuis GCC 3.4, mais ICL reste clairement meilleur. Seulement je ne comprends pas pourquoi les perfs de ta compilation avec GCC ne sont pas similaires aux miennes sous Windows.

Citation:

Envoyé par epsilon68

et je reviens sur la compil mac pour le bench multi-thread:
une idée ?

Bizarre car GCC sous Windows compile bien les quelques instructions assembleurs du fichier 'cpuid.h'. Je ne vois pas pourquoi ça ne marcherait pas sous d'autres systèmes avec des processeurs compatibles. Je ne voit pas quoi faire pour que l'analyse du processeur marche correctement avec ton GCC.

Pour désactiver cette analyse, tu peux changer la définition de MAX_THREADS dans le fichier 'genial_config.h' et ça devrait compiler. Pour un système à 2 noyaux:

Code:

#define MAX_THREADS 2

Si des erreurs de compilation subsistent, tu n'as qu'à carrément commenter les 7 lignes suivantes dans 'cpuid.h'
Code:

1 2 3 4 5 6 7 #elif defined(__GNUC__) && (defined(i386)||defined(__x86_64__)) inline cpuid_reg _cpuid(unsigned int a, unsigned int c=0) { cpuid_reg r; __asm__("cpuid":"=a"(r.eax),"=b"(r.ebx),"=c" (r.ecx),"=d"(r.edx):"a"(a),"c"(c)); return r; }

20/08/2007, 13h24
epsilon68

Citation:

Envoyé par Charlemagne

Content de te revoir.
J'espère que tu n'as pas acheté VMWare fusion uniquement pour mon bench!

moi aussi :P
rassures-toi j'ai acheté VMWare pour tester, valider certaines options possibles etc ... J'ai aussi profité de 50% de reduction en l'achetant en "pre-order"
il est vraiment cool, et il est vraiment rapide, confortable de travailler avec...

le resultat

Code:

1
2
3
$ ./gcc-genial 
../genial/threads.h:372: failed assertion `r==0'
Abort trap

une idée ?

22/08/2007, 11h13
Charlemagne

Pour ce bug aussi, c'est à ni rien comprendre.
Je n'arrive pas a reproduire cette assertion sous Windows, que ce soit avec les libraries pthread-w32 ou pthread de gcc. Y'a peut-être une différence d'implémentation de la librairie pthreads pour mac.

Tu peux temporairement utiliser OpenMP en definissant la macro 'OPENMP' dans 'genal_config.h', pour contourner le problème, mais il restera entier.

Pour avoir une chance de corriger le bug, il faudrait que je connaisse la fonction qui appelle la fonction 'check_thread' de la ligne 372. (regarde la chaîne d'appel des fonctions quand le bug se produit). Ca serait utile de connaître la valeur du paramètre 'r' (utilise un debugger ou 'cout << r;').
Et il faudrait regarder dans la doc de pthread pour mac (pour voir si les entrées/sorties sont différentes)

Au fait, j'ai fait en sorte que mon programme alloue par sécurité un peu plus de mémoire sous tout les autres systèmes, comme tu me l'avais proposé. Je n'ai pas trouvé mieux pour l'instant pour ne pas perdre en performance, même si c'est pas totalement satisfaisant.

Et un truc bizarre: je ne reçoit pas toujours un mail automatique m'avertissant d'un nouveau message dans le topic, même si je prends soin de toujours cliquer sur le lien des mails que je reçois...

Voir 40 message(s) de cette discussion en une page