Ta propre compilation avec GCC sous MacOS est assez plus rapide que la mienne avec GCC sous Windows...
Version imprimable
Ta propre compilation avec GCC sous MacOS est assez plus rapide que la mienne avec GCC sous Windows...
n'oublie pas que j'execute tes programmes sous une machine virtuelle.
sinon tu as raison, le windows sur VMware ne prend pas en compte le 2ieme core, ce qui n'est pas normale, mais celui-ci est une image de mon ancien PC ce qui peut expliquer pourquoi ... mais je suis en train de chercher ...
C'est quoi exactement une machine virtuelle? C'est un programme sous MacOS qui "boote" sur Windows? Y'a plusieurs années j'avais fait une 2ème partition pour Linux, mais vu le peu d'utilisation que j'en faisais, je l'ai supprimé...
Si le problème n'est pas dû à mon programme, ça me rassure d'un certain coté. Désolé que tu doivent plancher sur VMware.
Est-ce comme si t'avais 2 machines différentes, un core pour chaque? Comment tu t'en rends compte que VMware ne reconnaît pas le 2ème core? Dans le gestionnaire de tâche?
C'est quand même bizarre que mon programme ne reconnaisse pas le 2ème coeur parce que je n'appelle pas de fonctions de l'API Windows, mais uniquement l'instruction CPUID du processeur. On dirait que la machine virtuelle modifie le comportement propre du processeur.
en fait j'utilise une image de l'ordi que j'avais avant, un centrino.
et en fait d'apres le lien : http://support.microsoft.com/kb/315341/
je suis foutu :-/ windows detecte cela ä l'installation donc je suis obligé de reinstaller une machine virtuelle si je veux exploiter mes deux cores :-/
VMware permet de faire tourner windows (ou linux ou ...) en paralle de macosx. C'est un virtualiseur... donc ce n'est pas aussi rapide que l'installation en natif mais c'est beaucoup plus user-friendly de ne pas rebooter pour passer de l'un a l'autre, et la vitesse est tres acceptable. Un gros avantage est de pouvoir faire des snapshots dans des cas risqués et de pouvoir faire un rollback si cela ne va pas....
mais par contre ton programme le detecte bien :-)
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Visiblement y'avait donc un double problème:Citation:
Envoyé par epsilon68
- VMWare ne reconnaissant qu'un seul core
- Paramétrage de mon prog faisant, contrairement à ce que j'ai dit un peu plus haut, bien un appel à l'API Windows.
Tu trouveras les nouveaux exécutables qui ce basent sur l'instruction CPUID là:
http://www.ient.rwth-aachen.de/team/...gcc_vs_icl.zip
J'ignore si le multi-threading marchera pleinement sous VMware.
A la vue des résultats du bench que tu as compilé toi-même, je pense que tu as mal paramétré le multi-threading puisque les perfs correspondent à celles que j'attendrais de la part seul core.
Il y a 2 choses à définir dans 'genial_config.h':
- #define MAX_THREADS 0 (ou bien 2 pour éviter la détection automatique)
- #define BLAS_THREADING
Je pense que que tu as oublié la 2ème.
ci-joint le genial_config.h
tout est bien defini de mon point de vue ...
tu pourrais confirmer ?
a+
Ajoute ceci dans 'genial_config.h'
Visiblement je n'avais pas permis ce paramètre quand je t'ai fait faire la mise à jour pour le multi-threading de la multiplication matricielle.Code:
2
3
Et sinon, les 2 cores marchent-ils sous VMware?
il y est déjà dans genial_config.h donc je pense que le resultat est bien avec 2 threads ... donc ca cloche pour le multi-thread ???
sinon pour VMWare mon windows ne reconnait pas les deux cores puisque j'ai fait une image d'une installation sur un PC ayant un centrino.
Pour achever les tests, il faut que j'installe une version sur mon mac pour que windows reconnaise et installe un kernel pour dual-cores.
J'ai relancer genial sur mon mac intel core duo, les resultats sont catastrophiques par rapport au core 2 duo...
alors je pense que ca vient de gcc car sous VMWare ton programme s'execute tellement plus vite. Ca me fait aussi penser que ce n'est pas une question de cache.
Code:
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
ok j'ai testé ton bench sur un windows qui reconnait le dual-core, toujours avec VMWare ... ben y a pas photo :aie:
GCC Benchmark GEMM 48 15 SSE2 MT2
ICC Benchmark GEMM 48 15 SSE2 MT2Code:
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
Code:
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
et comment je fais sur Mac alors pour activer le multi-threads ?
peut-etre redonne moi les derniers sources avec toutes les options d'activées ... ?
Pourtant ça devrait marcher. :-/Citation:
Envoyé par epsilon68
Voici mes sources actuelles, tu peux écraser tous les fichiers.
Ainsi que la source du bench correspondant, à remplacer également car certains appels ont changé.
sinon c'est pas mal les perfs multi-thread sur le Core2Duo, pas mal du tout...
C'est vraiment un peu plus lent avec ICL qu'avec GCC, t'as pas interverti les résultats?
non je n'ai pas interverti ...
je viens de retester ...
mais ca colle pas du tout, c'est completement incoherent !!!
il y a forcement un probleme quelque part, ca peut pas s'executer plus lentement que sous une VM avec VMWare !!!!Code:
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
si ca se trouve il ne cree qu'un seul thread ...
Je reconnais que c'est bizarre...Citation:
Envoyé par epsilon68
Je t'assure que tu as reçu les sources telles que je les aie compilées...
Mon programme semble bien créer 2 processus comme l'indique normalement le titre du fichier (MT2)
Essaye OpenMP pour voir en définissant la macro correspondante dans 'genial_config.h'. (ou en ligne de commande)
Essaye aussi la version mono-thread en ne définissant pas 'BLAS_THREADING'.
La comparaison des perfs permettra surement de voir si le multi-threading crée rellement 2 processus.
Branche éventuellement ATLAS en décommentant les trois lignes 182-184 du fichier main. Ca résoudra pas le problème mais ça donnera une référence mono-thread. (visiblement ta compilation d'ATLAS n'est pas multi-threadé malgré le paramétrage automatique de la dernière version "instable", contrairement à la version 3.6.0 qui, elle, semble obéir au doigt et à l'oeil...)
PS: Ta ligne de commande me parait correcte.
Pourtant on dirait vraiment que ton programme compilé est en mono-thread...
PS2: Je comprends pas: Les perfs de ton bench dans le message 197 étaient bonnes! J'ai rien dit... c'était déjà multi-threadé...
Juste un détail, les Core Duo ne bénéficient pas de l'architecture Core des Core 2 Duo, c'est l'architecture Centrino (Pentium Pro) des Dothan améliorée, c'est tout, il y a une sacré différence entre les 2 architecture (Conroe vs Yonah).
effectivement j'obtiens le meme temps en single thread ...
bon bah c'est pas normal :-/Code:
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
comment je pourrais savoir si 2 threads sont bien actifs en meme temps ?
Y compris avec OpenMP?Citation:
Envoyé par epsilon68
Je vois pas trop comment...Citation:
Envoyé par epsilon68
Peut-être:
-un bug dans l'implémentation du sémaphore pour Apple (et pourtant ça semble bien marcher...). Je te file une version Windows compilée avec GCC et le sémaphore prévu pour MacOS à essayer
-un autre problème dû à l'implémentation pthread de MacOS...
PS: Ca se passe aussi un peu comme si BLAS_THREADING n'était pas définie. Je n'y crois pas trop mais, essaye de le définir dans le fichier 'genial_config.h' au lieu de la ligne de commande.
oui y compris avec openmp
non definitivement le probleme est ailleurs, toutes les constantes sont bien definies donc...
comment pourrait-on faire pour voir le nombre de threads créés ? et voir qu'ils tournent bien en parallele ?
a+
EDIT: la version que tu as attachée marche parfaitement sur windows. Ca doit etre un truc vicieux qui se trame pour macosx ....