Discussion :

[Charlemagne]

Cette version semble bien marcher

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
class semaphore
{
  public:
    typedef semaphore self;
    typedef scoped_lock<self> scoped_lock;
 
    typedef condition_mutex mutex_type;
 
  private:
    int count;
    int waiting;
    mutex_type cond;
 
    semaphore(const self &);
    const self &operator=(const self &);
 
  public:
    inline semaphore(     ) { count=0; waiting=0; }
    inline semaphore(int n) { count=n; waiting=0; }
    inline ~semaphore() {}
 
    inline void release() 
    {
      mutex_type::scoped_lock lock(cond);
      ++count;
      if (waiting>0) cond.signal();
    }
 
    inline void release(int n) { for (int i=0; i<n; ++i) release(); }
 
    inline void acquire()      
    { 
      mutex_type::scoped_lock lock(cond); 
      ++waiting;  
      while (count==0) cond.wait(); 
      --waiting;  
      --count;  
    }
    inline void acquire(int n) 
    {
      mutex_type::scoped_lock lock(cond); 
      waiting+=n; 
      while (count< n) cond.wait(); 
      waiting-=n; 
      count-=n; 
    }
 
    inline int try_acquire()      
    { 
      mutex_type::scoped_lock lock(cond); 
      if (count>0) { --count; return 1; } else return 0;
    }
    inline int  try_acquire(int n) 
    {
      mutex_type::scoped_lock lock(cond); 
      if (count>=n) count-=n; else { n=count; count=0; }
      return n;
    }
};

[epsilon68]

J'ai vu encore un truc dans ton implémentation:
Tu initialises dans le constructeur le compteur avec 1, et non 0 comme moi.

pourquoi tu l'initialises avec 0 resource ?
tu es donc obligé de faire un release alors avant de travailler dessus ?

... bizarre ...

[epsilon68]

Cette version semble bien marcher

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
class semaphore
{
  public:
    typedef semaphore self;
    typedef scoped_lock<self> scoped_lock;
 
    typedef condition_mutex mutex_type;
 
  private:
    int count;
    int waiting;
    mutex_type cond;
 
    semaphore(const self &);
    const self &operator=(const self &);
 
  public:
    inline semaphore(     ) { count=0; waiting=0; }
    inline semaphore(int n) { count=n; waiting=0; }
    inline ~semaphore() {}
 
    inline void release() 
    {
      mutex_type::scoped_lock lock(cond);
      ++count;
      if (waiting>0) cond.signal();
    }
 
    inline void release(int n) { for (int i=0; i<n; ++i) release(); }
 
    inline void acquire()      
    { 
      mutex_type::scoped_lock lock(cond); 
      ++waiting;  
      while (count==0) cond.wait(); 
      --waiting;  
      --count;  
    }
    inline void acquire(int n) 
    {
      mutex_type::scoped_lock lock(cond); 
      waiting+=n; 
      while (count< n) cond.wait(); 
      waiting-=n; 
      count-=n; 
    }
 
    inline int try_acquire()      
    { 
      mutex_type::scoped_lock lock(cond); 
      if (count>0) { --count; return 1; } else return 0;
    }
    inline int  try_acquire(int n) 
    {
      mutex_type::scoped_lock lock(cond); 
      if (count>=n) count-=n; else { n=count; count=0; }
      return n;
    }
};

je vois un probleme, quand on release une resource, on reveille un thread,
mais ce thread est en attente sur plus de resources que disponible et donc se remet en attente, ne peut-on pas avoir de blocage ?

excuse pour le try acquire, hier je ne voyais plus clair, ca coule de sens.
Ca venait de cela en fait ?

a+

[Charlemagne]

je vois un probleme, quand on release une resource, on reveille un thread,
mais ce thread est en attente sur plus de resources que disponible et donc se remet en attente, ne peut-on pas avoir de blocage ?

Le processus n'a qu'a attendre que le sémaphore libère plusieurs ressources. Si y'a un dead-lock quelque part, c'est de la faute à l'utilisateur du sémaphore.

Je vais aussi enlever la boucle dans la fonction 'release(n)'. La boucle n'était là parce que pthread ne permet pas de libérer plusieurs ressources à la fois.

[epsilon68]

Je n'arrive pas à trouver un exemple contradictoire, mais j'ai le sentiment qu'il peut y avoir un probleme...

Sinon waiters_count servait à savoir le nombre de thread en attente, et je ne suis pas sur qu'il serve ...

As-tu essayé avec cette version au niveau des perfs ?

EDIT: pour l'initialisation a 0, je comprends, c'est logique en fait.

[Charlemagne]

Sinon waiters_count servait à savoir le nombre de thread en attente, et je ne suis pas sur qu'il serve ...

Tu parles de la variable 'waiting'? Si, ça sert à savoir si il y a lieu d'envoyer un signal à un processus en attente.

As-tu essayé avec cette version au niveau des perfs ?

pas encore

PS: A la réflexion la variable 'waiting' n'est peut-être pas nécessaire, parce que d'après ma doc de pthread, la fonction 'pthread_cond_signal' ne fait rien si aucun processus n'est en attente. A tester...

[epsilon68]

ok
je suis vraiment curieux de voir l'impact sur les perfs...

EDIT: j'ai trop du mal a me concentrer sur autre chose

[epsilon68]

Mais honnêtement je crois que je préfère une solution que se base sur les sémaphores de MacOS, quitte à utiliser un nom...

il faudrait alors se tourner du coté de carbon ...

[Charlemagne]

ok
je suis vraiment curieux de voir l'impact sur les perfs...

Les perfs semblent équivalentes avec les 2 implémentations de sémaphores sur mon ordi. Mais ce n'est pas super représentatif sur mon P4 HT. Et puis le coût de synchronisation est négligeable face aux calculs.

il faudrait alors se tourner du coté de carbon ...

C'est quoi Carbon? Un environnement MacOS avec sa propre implémentation de pthread?

[epsilon68]

C'est quoi Carbon? Un environnement MacOS avec sa propre implémentation de pthread?

carbon c'est l'api apple pour C/C++
cocoa c'est l'api apple pour objective C

carbon est en perte de vitesse on dirait par rapport a cocoa.

[epsilon68]

Les perfs semblent équivalentes avec les 2 implémentations de sémaphores sur mon ordi. Mais ce n'est pas super représentatif sur mon P4 HT. Et puis le coût de synchronisation est négligeable face aux calculs.

si tu veux je peux tester la version sur mon dual-processor.

[Charlemagne]

si tu veux je peux tester la version sur mon dual-processor.

Ca n'en vaut pas la peine, les effets sur les perfs sont plutôt négligeables en comparaison avec le temps de calcul. Je vais garder cette version de sémaphore pour les mac.

Par contre 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 pour ton processeur.
Et modifie en tâtonnant les paramètres dans le fichier 'genial_config.h' BLAS_M, BLAS_N, BLAS_K,BLAS_K,BLAS_K2 qui définissent les tailles de blocs de matrices:

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)...

[epsilon68]

ce que je ne comprends pas c'est que la version windows (a travers VMWare va beaucoup plus vite), alors t'es sur que c'est une question de cache ?

[Charlemagne]

La version Windows est plus rapide parce que je l'ai compilée avec ICL. Les perfs de GCC 4.2 sont nettement plus lentes qu'ICL même si il y a eu de gros progrès depuis GCC3.4, principalement parce que GCC4.2 respecte dorénavant la consigne de forcer les inlines.

Paramétrer le cache permettra à ma bibliothèque éventuellement de gagner en perfs sur ton type de processeur (si le processeur réagit différemment que les Pentiums 4), indépendamment du compilateur utilisé.

[epsilon68]

tu pourrais m'envoyer la version windows compilées avec gcc ?
qui serait en fait la meme version que Mac (y compris les semaphores)
comme ca je pourrais exactement comparer ...

[Charlemagne]

tu pourrais m'envoyer la version windows compilées avec gcc ?
qui serait en fait la meme version que Mac (y compris les semaphores)
comme ca je pourrais exactement comparer ...

Tu trouveras dans ce fichier zip 4 versions de benchs pour windows selon le compilateur (GCC/ICL) et si c'est mono ou multi theadé.
http://www.ient.rwth-aachen.de/team/...gcc_vs_icl.zip

PS: les benchs compilés avec GCC ne mesurent pas les perfs d'Atlas (j'ai pas réussi à faire l'édition de lien)

[epsilon68]

salut !!! je viens d'avoir mon nouveau mac intel core 2 duo !!!

j'ai continué genial et la il y a une sacré difference !!!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
/usr/local/bin/g++ main.cpp -o gcc-genial -O2 -I../genial -msse3 -Winline -I/ATLAS/include/ -L/ATLAS/my_build_dir/lib/ -latlas -lcblas -I/ATLAS/my_build_dir/include/ -DNDEBUG
 
Benchmark GEMM 48 15 SSE2 MT2.txt
float
(4x4)   0       53.9871 53.1675
(8x8)   0       372.788 344.923
(16x16) 0       2035.53 1234.98
(32x32) 0       6442.32 2267.02
(64x64) 0       4049.08 4622.65
(100x100)       0       4978    4760
(128x128)       0       6174.02 5578.42
(144x144)       0       7005.12 5858.5
(160x160)       0       7372.8  5906.43
(176x176)       0       7861.46 5626.23
(192x192)       0       8125.42 7757.37
(200x200)       0       7984    7680
(256x256)       0       8556.38 8704.22
(400x400)       0       9124.75 9600
(500x500)       0       9250    10250
(512x512)       0       9474.19 10200.5
(600x600)       0       9741.18 10904.9
(700x700)       0       9508.91 10656.3
(800x800)       0       9660.38 10935.9
(900x900)       0       9628.3  11324.3
(1000x1000)     0       9523.81 11111.1
(1024x1024)     0       9586.98 11012.7
(1500x1500)     0       9782.61 11440.7
(2000x2000)     0       10000   11347.5
(2048x2048)     0       9930.56 11302.5

alors qu'en penses-tu ?

il faudra que je ressaye sur mon ancien mac ...
serait-ce gcc qui ne serait pas génial pour les intel core duo premiere generation ?

[epsilon68]

et ci-dessous les resultats icc MT sur VMWare

"Benchmark GEMM 48 15 SSE2 MT1.txt"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
	GENIAL sgemm	ATLAS sgemm	GENIAL dgemm	ATLAS dgemm
4	150	281	264	352	
8	1363	1068	1282	1116	
16	3746	1558	2848	1626	
32	8571	1980	3982	1774	
64	7979	1448	4846	2077	
100	9532	6810	5371	3181	
128	9857	4654	5495	2796	
144	7280	3952	5584	4579	
160	10103	11196	5530	3901	
176	10904	9554	5696	3635	
192	9860	7432	5865	3505	
200	10400	6960	5714	3276	
256	9427	10226	4006	3196	
400	8915	10240	4655	3657	
500	9524	10000	4739	3571	
512	9395	9348	4881	3977	
600	9391	9818	4782	3927	
700	9800	9312	5081	3920	
800	9309	10240	5095	4452	
900	9720	10021	5028	4276	
1000	10000	10256	5263	3992	
1024	9717	10226	5113	4203	
1500	10060	10385	5229	4213	
2000	9994	10660	5207	4047	
2048	10160	10592	4988	4335

[epsilon68]

et ci-dessous les resultats pour gcc MT sur VMWare

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
	GENIAL sgemm	ATLAS sgemm	GENIAL dgemm	ATLAS dgemm
4	111	-1	242	-1	
8	1327	-1	1087	-1	
16	3438	-1	2627	-1	
32	7002	-1	3051	-1	
64	6751	-1	3798	-1	
100	5590	-1	143	-1	
128	8488	-1	3922	-1	
144	9555	-1	4550	-1	
160	8816	-1	4219	-1	
176	8842	-1	4611	-1	
192	7010	-1	4601	-1	
200	8686	-1	4419	-1	
256	9227	-1	3691	-1	
400	7680	-1	4267	-1	
500	8294	-1	4149	-1	
512	8541	-1	4130	-1	
600	8640	-1	4469	-1	
700	8575	-1	4558	-1	
800	8904	-1	4452	-1	
900	8576	-1	4418	-1	
1000	9050	-1	4444	-1	
1024	8948	-1	4286	-1	
1500	9362	-1	4527	-1	
2000	9401	-1	4309	-1	
2048	9129	-1	4424	-1

[Charlemagne]

Félicitation pour ton nouvel ordi.

il faudra que je ressaye sur mon ancien mac ...
serait-ce gcc qui ne serait pas génial pour les intel core duo premiere generation ?

Je crois plutôt que le core 2 duo est nettement meilleur que la 1ère génération.

Par contre je suis très surpris que mon programme ne détecte pas le 2ème coeur de ton nouveau processeur (alors que ça marchait sur ton core duo...)
STP, tu veux bien me retranscrire la sortie du minuscule programme suivant sur tes 2 ordis (surtout le nouveau):
http://www.ient.rwth-aachen.de/team/...oads/cpuid.zip