Discussion :

[JolyLoic]

ATLAS reconnait normalement automatiquement la configuration de l'ordi.
J'espère qu'il reconnait les récents processeurs du genre Core2Quad

Pas certain. Lors du configure, j'ai eu un message :

Architecture configured as Core2Duo (15)

Ce n'était que le début des ennuis... J'ai eu à la suivi un message (toujours dans le configure) :

Code :

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

Unable to find usable compiler for ICC; abortingMake sure compilers are in your path

Je précise :

Code :

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

1
2
3
4
5
$ g++ --version
g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

J'ai quand même tenté le make

Code :

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

1
2
3
4
5
6
7
$ make
make -f Make.top build
make[1]: Entering directory `/cygdrive/d/temp/ATLAS/mon_architecture'
make[1]: Make.top: No such file or directory
make[1]: *** No rule to make target `Make.top'.  Stop.
make[1]: Leaving directory `/cygdrive/d/temp/ATLAS/mon_architecture'
make: *** [build] Error 2

[Charlemagne]

Désolé. C'est pas fortiche de la part d'ATLAS...

Essaye la version 3.6.0:
- C'est moins automatique: il suffit de répondre à quelques questions. Arrange toi pour lui dire d'utiliser 4 threads, SSE3 (ou du moins SSE2, je ne crois pas que les instructions SSE3 soient vraiment utilisées)
- Mes bench donnent la version 3.6.0 nettement plus rapide que la 3.8.1 sur mon Pentium4.
-tu peux peut-être compiler ATLAS en version mon--thread puis une autre en version 4 threads pour comparer

Voici les quelques commandes à rentrer dans le shell de cygwin pour la version 3.6.0

Code :

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

1
2
3
4
Placer atlas dans un répretoire dont le chemin est sans espaces
> make xconfig
> ./xconfig.exe 
> make install arch=Nom_de_ton_Architecture

Je te filerai les source du bench.

PS: d'ici 2-3 jours je te filerai qqs benchs rapides de FFT pour tenter de voir ce qui ne tourne pas rond avec 4 threads.

[epsilon68]

Salut Charlemagne,

je voulais savoir si tu pensais utiliser TBB pour savoir si TBB est bien par rapport a ton implementation et/ou OpenMP ^^?

a+

[Charlemagne]

je voulais savoir si tu pensais utiliser TBB pour savoir si TBB est bien par rapport a ton implementation et/ou OpenMP ^^?

J'y avais pas vraiment pensé.
Mais y'a plusieurs éléments qui me donnent pas vraiment envie d'essayer.
- Je ne pense pas que les mauvais résultats des benchs de FFT sur un Core2Quad soient dus à une hypothétique mauvaise performance de mon implémentation du multi-threading puisque ça marche bien avec les multiplications matricielles.
- même si je me suis inspiré de TBB, ma syntaxe est quand même sérieusement différente et il faudrait que je programme des wrappers à TBB.
- J'essaye d'éviter autant que possible les dépenses de ma bibliothèque à d'autres librairies. C'est une des raison pour laquelle j'ai reprogrammé les fonctions de TBB qui m'intéressaient.


J'y ai réfléchis, mais je n'ai toujours pas vraiment d'explication pour les mauvais benchs à 4 threads sur le Quad.
Je ne connais pas la structure des Code2Duo ni des Core2Quad, mais je sais que le cache L2 est commun pour les divers noyaux. Et donc je présume que le problème vient de là: la vitesse des échanges avec ce cache pour les 4 noyaux serait le goulot d'étranglement.
Le problème ne se manifeste pas pour la multiplication matricielle si, comme je le suppose, chaque noyau possède un cache L1 propre. En effet la FFT ne peut pas vraiment optimiser le cache L1 à cause des accès non consécutifs en mémoire.

@Loïc: Je n'ai pas eu le courage le week-end dernier de faire des benchs particuliers pour ton Quad. Ca va venir...

[nicroman]

Juste comme ça un truc tout bete auquel on ne pense pas forcément....
Tu ne switcherai pas régulièrement entre simple et double précision ?
Ou une conversion float->int ?
Le genre de truc qui "stall" le CPU histoire de reseter les flags....

[Charlemagne]

Juste comme ça un truc tout bete auquel on ne pense pas forcément....
Tu ne switcherai pas régulièrement entre simple et double précision ?
Ou une conversion float->int ?
Le genre de truc qui "stall" le CPU histoire de reseter les flags....

Non, non, je fais rien de tout ça.
Mais tu as raison: les conversions sont à proscrire car elles sont horriblement lentes. On s'en rend très vite compte quand on programme avec les instructions SIMD.

[epsilon68]

je pense me mettre tout doucement a TBB
il n'y a finalement pas d'alternative a cette lib, meme OpenMP me parait beaucoup trop dependant des compilateurs et trop C :-(

[Charlemagne]

Avec un peu de retard, désolé, voici des benchs spécialement prévus pour tester le Core 2 Quad.

http://www.ient.rwth-aachen.de/team/...ads/benchs.zip

Il y a en fait 9 benchs différents, dont plusieurs vont me servir de référence.
Un fichier "BAT" évite d'avoir à les exécuter tous les 9 manuellement?
Ils sont très rapides à exécuter. (J'ai désactivé la comparaison avec FFTW).
Il faut me rendre les 9 fichiers textes résultant (par exemple dans un zip)

Merci d'avance.

J'espère que ça va me permettre d'expliquer en partie pourquoi 4 threads ne sont pas plus rapide que 2.
En fonction des résultats de ce bench, je pense vous faire au moins une autre série de benchs.
Le problème est certainement a rechercher dans la saturation du cache L2, dû aux appels aléatoires. Et donc a priori, y'a pas grand chose a faire a cause de la nature de la FFT, j'ai une petite idée quand-même à voir...

[JolyLoic]

Voilà mes résultats de bench

benchs result.zip

[Charlemagne]

Merci Loïc

C'est ce que je craignais. Les FFTs sur les colonnes sont plus lentes que sur les lignes. Y'a toute les chances que la raison vienne du trafic de données trop élevé avec le cache L2.
Je ne vois pas comment améliorer ça. C'est dû à la nature de la FFT qui nécessite des accès aléatoires. Le phénomène est accru sur les colonnes.
Le phénomène n'apparait pas dans mes benchs de produits matriciels, car dans ce cas y'a moyen d'optimiser le cache L1.

C'est dommage, mais ça montre les limites de processeurs avec de plus en plus de cœurs. Il va falloir qu'Intel améliore les performances de la mémoire cache, sinon ça n'a pas de sens d'accroitre indéfiniment le nombre de cœurs...

Je n'ai plus de benchs à vous faire faire (dans l'immédiat).

Je compte afficher diverses courbes sur mon site d'ici peu.
( http://www.ient.rwth-aachen.de/team/...al/genial.html )
J'écrirai une petite phrase de remerciements avec vos pseudos. Si vous ne voulez pas y être mentionné, ou si vous préférez que j'y inscrive vos vrais noms/prénoms, alors dites le moi.
Merci