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

Version imprimable

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

22/08/2007, 13h11
epsilon68

je vais debugger pour te donner autant d'infos que possible ...
c'est en effet assez difficile a comprendre, je ne pense pas qu'il y ait une difference pour pthreads entre les plateformes ...
mais bon le debugger nous le dira :aie:

sinon je ne sais pas pour le suivi du topic ...
y-a-t-il un administrateur dans les parages ?

ca aide ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
(gdb) run
Starting program: /Users/xxx/Desktop/genial-2.0.2/samples/gcc-genial 
Reading symbols for shared libraries ....+ done
../genial/threads.h:372: failed assertion `r==0'
 
Program received signal SIGABRT, Aborted.
0x9003d66c in kill ()
(gdb) where
#0  0x9003d66c in kill ()
#1  0x9010e8cf in raise ()
#2  0x9010d422 in abort ()
#3  0x00041d73 in __eprintf (string=0x41e54 "%s:%u: failed assertion `%s'\n", expression=0x41e90 "../genial/threads.h", line=372, filename=0x41e88 "r==0") at ../.././gcc/libgcc2.c:1975
#4  0x00080872 in gmt::managed_thread_group<gmt::thread_manager>::managed_thread_group ()
#5  0x0001ff70 in __static_initialization_and_destruction_0 ()
#6  0x0002005c in global constructors keyed to _ZplRK4m64cS1_ ()
#7  0x8fe0fcc4 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#8  0x8fe0a1c6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
#9  0x8fe0c646 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#10 0x8fe03070 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#11 0x0000273e in _start ()
#12 0x000026a9 in start ()
(gdb)

un peu plus detaillé

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
29
30
31
32
 
(gdb) bt full
#0  0x9003d66c in kill ()
No symbol table info available.
#1  0x9010e8cf in raise ()
No symbol table info available.
#2  0x9010d422 in abort ()
No symbol table info available.
#3  0x00041d73 in __eprintf (string=0x41e54 "%s:%u: failed assertion `%s'\n", expression=0x41e90 "../genial/threads.h", line=372, filename=0x41e88 "r==0") at ../.././gcc/libgcc2.c:1975
        string = 0x0
        expression = 0x0
        line = 0
        filename = 0x0
#4  0x00080872 in gmt::managed_thread_group<gmt::thread_manager>::managed_thread_group (this=0x230040, n=2) at ../genial/threads.h:372
        i = 19028681
        i = 19028681
#5  0x0001ff70 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at ../genial/threads.h:893
No locals.
#6  0x0002005c in global constructors keyed to _ZplRK4m64cS1_ () at main.cpp:214
No locals.
#7  0x8fe0fcc4 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
No symbol table info available.
#8  0x8fe0a1c6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
No symbol table info available.
#9  0x8fe0c646 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
No symbol table info available.
#10 0x8fe03070 in __dyld__ZN4dyld24initializeMainExecutableEv ()
No symbol table info available.
#11 0x0000273e in _start ()
No symbol table info available.
#12 0x000026a9 in start ()
No symbol table info available.

Je ne suis pas sûr, mais j'ai l'impression que la chaîne d'appels n'est pas complète, c'est peut-être parce que tu forces les 'inline' en mode debug.
Tu peux peut-être essayer de faire un '#ifdef NDEBUG' autour de ce paramétrage dans 'genial_config.h' comme ceci:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 #ifdef NDEBUG #if defined(__ICL) || defined(_MSC_VER) #define inline __forceinline #elif defined(__ICC) //#define inline __forceinline //#define inline __inline #define inline __attribute__((__always_inline__)) // Has obviously no effect on ICC #elif defined(__GNUC__) //#define inline __inline #define inline __attribute__((__always_inline__)) // GCC4.2 seems to respect this attribute, unlike former version... #endif #endif
Tu connais la valeur du paramètre 'r' qui est alors passée à la fonction 'assert_thread'?

mince autant pour moi, merci pour le NDEBUG

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
29
30
31
32
33
34
35
36
37
(gdb) bt full
#0  0x9003d66c in kill ()
No symbol table info available.
#1  0x9010e8cf in raise ()
No symbol table info available.
#2  0x9010d422 in abort ()
No symbol table info available.
#3  0x00002ce3 in __eprintf (string=0x2da0 "%s:%u: failed assertion `%s'\n", expression=0x2d8c "../genial/threads.h", line=372, filename=0x2d84 "r==0") at ../.././gcc/libgcc2.c:1975
        string = 0x0
        expression = 0x0
        line = 0
        filename = 0x0
#4  0x0000ed80 in gmt::assert_thread (r=-1) at ../genial/threads.h:372
No locals.
#5  0x0000edb1 in gmt::semaphore::semaphore (this=0x5c8c8) at ../genial/threads.h:480
No locals.
#6  0x0001656d in gmt::thread_manager::thread_manager (this=0x5c8c0) at ../genial/threads.h:777
No locals.
#7  0x000165c6 in gmt::managed_thread_group<gmt::thread_manager>::managed_thread_group (this=0x5c8c0, n=2) at ../genial/threads.h:869
        i = -1073743288
        i = -1073743288
#8  0x0000259c in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at ../genial/threads.h:893
No locals.
#9  0x00002672 in global constructors keyed to main () at main.cpp:214
No locals.
#10 0x8fe0fcc4 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
No symbol table info available.
#11 0x8fe0a1c6 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
No symbol table info available.
#12 0x8fe0c646 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
No symbol table info available.
#13 0x8fe03070 in __dyld__ZN4dyld24initializeMainExecutableEv ()
No symbol table info available.
#14 0x00001e6e in _start ()
No symbol table info available.
#15 0x00001dd9 in start ()
No symbol table info available.

22/08/2007, 19h53
epsilon68

mince, ca a tout l'air d'etre un probleme macosx sur les semaphores ...

Citation:

Darwin doesn't implement sem_init,
but does implement sem_open/sem_close.

voici le bench avec openmp en tous cas (nullisime compare a windows sous vmware :-/ )

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
float
(4x4)   0       36.9061 40.24
(8x8)   0       212.835 211.824
(16x16) 0       691.806 611.467
(32x32) 0       1541.54 940.311
(64x64) 0       1217.92 2300.05
(100x100)       0       1572    2032
(128x128)       0       1728.05 2529.17
(144x144)       0       1863.25 2579.89
(160x160)       0       1630.21 2375.68
(176x176)       0       1711.86 2071.67
(192x192)       0       1783.63 2788.69
(200x200)       0       1904    3040
(256x256)       0       1760.78 3053.45
(400x400)       0       1864.08 3200
(500x500)       0       1869.16 3301.89
(512x512)       0       1917.4  3292.13
(600x600)       0       1945.95 3355.34
(700x700)       0       1888.07 3362.75
(800x800)       0       1896.3  3413.33
(900x900)       0       1957.05 3417.19
(1000x1000)     0       1923.08 3418.8
(1024x1024)     0       1917.4  3381.86
(1500x1500)     0       1939.66 3443.88
(2000x2000)     0       2080.62 3463.2

22/08/2007, 21h00
Charlemagne

C'est quoi Darwin?
C'est quand même pas sympa de la part de GCC sous Mac de compiler et faire l'édition de lien comme si de rien n'était...

J'ai vérifié, sur Windows c'est le contraire: y'a bien sem_init mais pas sem_open ni sem_close !

Je n'ai pas de doc sur ces 2 dernières fonctions, mais je pourrai sûrement trouver qqch sur internet. Sinon, t'as peut-être une doc dispo sur ton mac que tu peux me copier. J'imagine qu'il y a moyen de se passer de 'sem_init' avec ces 2 fonctions.
22/08/2007, 21h11
Charlemagne

Effectivement le bench n'est vraiment pas bon sous MacOS comparativement à Windows. C'est d'autant plus surprenant que mon bench mono-processus compilé avec GCC4.2.1 sous Windows n'est que de l'ordre de 10% plus lent que celui compilé avec ICL.
Je ne pense pas que ce soit les quelques petites modifications que j'ai faites récemment qui expliquent le phénomène. Mystère...

Citation:

Envoyé par Charlemagne

C'est quoi Darwin?

c'est le systeme minimal de macosx en open-source

Citation:

Envoyé par Charlemagne

C'est quand même pas sympa de la part de GCC sous Mac de compiler et faire l'édition de lien comme si de rien n'était...

c'est clair c'est plutot nul !

Citation:

Envoyé par Charlemagne

J'ai vérifié, sur Windows c'est le contraire: y'a bien sem_init mais pas sem_open ni sem_close !

c'est cool ca :-/

Citation:

Envoyé par Charlemagne

Je n'ai pas de doc sur ces 2 dernières fonctions, mais je pourrai sûrement trouver qqch sur internet. Sinon, t'as peut-être une doc dispo sur ton mac que tu peux me copier. J'imagine qu'il y a moyen de se passer de 'sem_init' avec ces 2 fonctions.

en fait j'ai trouvé la definition sur le site apple:
http://developer.apple.com/macosx/mu...ogramming.html

attention je ne suis pas sûr mais ca devrait donner 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
29
30
31
32
33
34
35
36
37
class semaphore
{
  public:
 
    typedef semaphore self;
    typedef scoped_lock<self> scoped_lock;
 
  private:
    sem_t *sem;
 
    semaphore(const self &);
    const self &operator=(const self &);
 
  public:
 
    inline semaphore(     ) { sem = sem_open( "", O_CREAT, S_IRUSR | S_IWUSR, 1 ); }//assert_thread(sem_init(&sem,0,0)); };
 
    inline semaphore(int n) { sem = sem_open( "", O_CREAT, S_IRUSR | S_IWUSR, n ); }//assert_thread(sem_init(&sem,0,n)); };
 
    inline ~semaphore() { sem_close(sem); } //assert_thread(sem_destroy(&sem)); }
 
    inline void release()      { assert_thread(sem_post(sem)); }
 
#if !defined(__ICL) && !defined(_MSC_VER)
    inline void release(int n) { for (int i=0; i<n; ++i) release(); }
#else
    inline void release(int n) { assert_thread(sem_post_multiple(sem,n)); }
#endif
 
    inline void acquire()      { assert_thread(sem_wait(sem)); }
    inline void acquire(int n) { for (int i=0; i<n; ++i) acquire(); }
 
    inline bool try_acquire()      { return sem_trywait(sem)!=-1; }
    inline int  try_acquire(int n) { for (int i=0; i<n; ++i) if (!try_acquire()) return i; return n; }
 
    inline unsigned int value() { int sval; assert_thread(sem_getvalue(sem, &sval)); return sval; }
};

le truc dont je ne suis pas sur c'est le nom du semaphore a donner...
parce que en fait c'est pour synchroniser deux processus, ce sont des primitives systemes... c'est vraiment lent comparé à une optimisation pour un seul processus (je crois que Qt le fait ainsi que Windows avec CriticalSection)

et sinon il faut rajouter le header:

Code:

#include <sys/stat.h>

et ca marche, mais c'est pas terrible... comme openmp finalement

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
(4x4)   0       40.2573 42.5641
(8x8)   0       245.923 246.704
(16x16) 0       810.525 729.924
(32x32) 0       1832.65 1127.81
(64x64) 0       1453.85 2722.1
(100x100)       0       1360    2434
(128x128)       0       1514.14 2252.34
(144x144)       0       2209.63 3057.65
(160x160)       0       2146.3  2924.54
(176x176)       0       2278.84 2769.5
(192x192)       0       2335.7  3708.81
(200x200)       0       2272    3664
(256x256)       0       2315.26 4026.53
(400x400)       0       2461.54 4141.18
(500x500)       0       2500    4326.92
(512x512)       0       2508.74 4305.1
(600x600)       0       2541.18 4441.12
(700x700)       0       2472.07 4446.3
(800x800)       0       2497.56 4491.23
(900x900)       0       2557.89 4486.15
(1000x1000)     0       2531.65 4477.61
(1024x1024)     0       2511.68 4443.07
(1500x1500)     0       2586.21 4530.2
(2000x2000)     0       2580.65 4584.53
(2048x2048)     0       2575.69 4581.3

Qu'en penses-tu ?

22/08/2007, 21h42
epsilon68

ho super je suis tombé sur ca:

Citation:

MacOS X does not support unnamed semaphores.

vive Qt !
22/08/2007, 22h01
epsilon68

ok la meilleure solution je pense serait de reimplementer le semaphore avec un mutex...

c'est aussi ce que Qt fait ...

Citation:

A semaphore is a generalization of a mutex. While a mutex can
only be locked once, it's possible to acquire a semaphore
multiple times. Semaphores are typically used to protect a
certain number of identical resources.

J'ai rajouté un #ifdef, et un destructeur.
Code:

1 2 3 4 5 6 7 8 9 #if (defined(__MACOSX__) || defined(__APPLE__)) inline semaphore( ) { sem = *sem_open( "", O_CREAT, S_IRUSR | S_IWUSR, 1 ); } inline semaphore(int n) { sem = *sem_open( "", O_CREAT, S_IRUSR | S_IWUSR, n ); } inline ~semaphore() { assert_thread(sem_close(&sem)); } #else inline semaphore( ) { assert_thread(sem_init(&sem,0,0)); }; inline semaphore(int n) { assert_thread(sem_init(&sem,0,n)); }; inline ~semaphore() { assert_thread(sem_destroy(&sem)); } #endif
J'ai pas vraiment compris l'utilité du 3ème paramètre 'mode' de sem_open.

Par contre j'ai également rajouté un "*" parce que 'sem_open' renvoit un pointeur. J'espère que l'affectation marchera comme ça. Je ne comprends pas que GCC ne n'ait pas donné une erreur de compilation.

Citation:

MacOS X does not support unnamed semaphores.

J'espère que ça marchera quand même sans nom, comme tu l'as fait. Sinon il faudra passer un autre paramètre au constructeur de sémaphore, ce qui ne plaît vraiment pas.

Citation:

Envoyé par epsilon68

et ca marche, mais c'est pas terrible... comme openmp finalement

Je te passerai mes nouvelles sources à l'occasion, même si je doute fort que les quelques modifications que j'ai faites expliquent les disfférences de perfs entre GCC Windows et GCC Mac.
Faudra voir les options de compilations mais je n'utilise rien de particulier (-s -O2 -Winline -DNDEBUG).
Il me semble qu'il m'a fallu rajouté manuellement cette définition de NDEBUG dans ma ligne de commande, car NDEBUG n'était bizarrement pas définit automatiquement avec O2 (contrairement à ICL ou VC). Si tel est le cas, ça peut avoir une forte influence sur les perfs, car ma bibliothèque réorganise pas mal les calculs avec des spécialisations de templates qui sont masquées en mode debug.

22/08/2007, 22h23
epsilon68

je suis vraiment désolé, mon code avec sem_open ne marche pas... :-(
il faut reimplementer le semaphore avec un mutex, c'est la seule solution...

je vais de suite essayer le ndebug, c'est clair tu as raison
22/08/2007, 22h25
Charlemagne

Citation:

Envoyé par epsilon68

il faut reimplementer le semaphore avec un mutex, c'est la seule solution...

Ca ne me plaît pas du tout non plus...

avec le -DNDEBUG c'est beaucoup mieux (openmp)

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 OpenMP1.txt
float
(4x4)   0       45.7998 43.4323
(8x8)   0       304.017 251.956
(16x16) 0       1337.69 724.107
(32x32) 0       2909.6  1140
(64x64) 0       2200.96 2727.87
(100x100)       0       2848    2412
(128x128)       0       3099.59 2998.3
(144x144)       0       3230.83 3093.48
(160x160)       0       3235.84 2277.38
(176x176)       0       3358.29 2769.5
(192x192)       0       3397.39 3737.12
(200x200)       0       3376    3728
(256x256)       0       3456.11 4026.53
(400x400)       0       3513.73 4182.18
(500x500)       0       3537.74 4368.93
(512x512)       0       3579.14 4294.97
(600x600)       0       3600    4400
(700x700)       0       3548.28 4405.5
(800x800)       0       3531.03 4530.97
(900x900)       0       3585.25 4486.15
(1000x1000)     0       3571.43 4511.28
(1024x1024)     0       3549.56 4473.92
(1500x1500)     0       3648.65 4560.81
(2000x2000)     0       3644.65 4584.53
(2048x2048)     0       3639.8  4581.3

ca devrait ressembler a ca un semaphore implémenté avec un mutex non ?

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
29
30
31
32
33
34
35
36
class semaphore
{
  public:
    typedef semaphore self;
    typedef scoped_lock<self> scoped_lock;
 
  private:
    int resource_count;
    mutex mut;
 
    semaphore(const self &);
    const self &operator=(const self &);
 
  public:
 
    inline semaphore(     ) { resource_count = 1;  }
 
    inline semaphore(int n) { resource_count = n; }
 
    inline ~semaphore() {}
 
    inline void release()      { mutex::scoped_lock lock(mut); resource_count += 1; }
 
    inline void release(int n) { mutex::scoped_lock lock(mut); resource_count += n; }
 
    inline void acquire()      { mutex::scoped_lock lock(mut); resource_count -= 1; }
 
    inline void acquire(int n) { mutex::scoped_lock lock(mut); resource_count -= n; }
 
    inline bool try_acquire()      { mutex::scoped_lock lock(mut); return resource_count > 0; }
 
    inline int  try_acquire(int n) { mutex::scoped_lock lock(mut); return resource_count > n ? n : resource_count; }
 
    inline unsigned int value() { mutex::scoped_lock lock(mut); return resource_count; }
 
};

mais ca marche pas ...

EDIT OK c'est normal puisque ca ne s'implemente pas comme ca :aie:

22/08/2007, 22h44
epsilon68

aussi je ne pense pas que

Code:

inline void acquire(int n) { for (int i=0; i<n; ++i) acquire(); }

soit bon, puisque ce n'est pas thread safe du coup a cause de la boucle for ...

non ?
22/08/2007, 22h49
epsilon68

que je suis bete, un semaphore avec un mutex est bien plus compliqué...
mince :-( je peux effacer mes post d'avant ? :aie:
22/08/2007, 22h50
Charlemagne

C'est mieux pour les perfs, mais je pense que la différence avec ATLAS était encore moindre sur mon ordi. Je referai un bench demain.

Citation:

Envoyé par epsilon68

ca devrait ressembler a ca un semaphore implémenté avec un mutex non ?

A priori si, mais je n'y ai pas encore réfléchit.
Et je pense qu'il vaut mieux y réfléchir tranquillement avant de remplacer les sémaphores par une implémentation perso

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