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

**Charlemagne** · 07/07/2007, 15h26

Salut

J'avais déjà ouvert un topic pour des benchs de FFT multi-threadées.
http://www.developpez.net/forums/sho...d.php?t=357175

C'est au tour d'un produit matriciel optimisé. Ca serait sympa si autant de personnes que possible voulaient bien faire tourner ces benchs sur Windows avec un système multi-processeur ou multi-core.
Vous pouvez le télécharger sur mon site:
http://www.ient.rwth-aachen.de/team/...ads/benchs.zip
-un bench de référence single-threadé
-un bench de test multi-threadé.

Ca ne vous prendra qu'une ou 2 minutes. Il suffit d'exécuter le fichier '.bat' et de me poster les 2 fichiers textes résultants.
Attendez vous à d'autres benchmarks pour faire des réglages.

Merci d'avance

PS: Désolé. Y'a un bug, je remets les benchs à plus tard, dès que je l'aurai corrigé...

**Charlemagne** · 08/07/2007, 19h32

Voilà, le bug est corrigé (une erreur grossière mais pas facile à déloger).

Vous pouvez faire les benchs:
http://www.ient.rwth-aachen.de/team/...ads/benchs.zip

Les résultats contenus dans les tableaux résultants sont des MFlops et sont calculés comme ceci:
MFlops=K*m*n*k/dt
-m,n,k: dimensions des matrices (m-k) x (k-n)
-dt: temps de calcul moyen en micro secondes
-K: constante valant 2 pour des matrices de réels (float/double), valant 8 pour des matrices de complexes.

A titre d'exemple voilà ce que j'obtiens sur mon vieux Pentium 4 HT 2.6GHz en mode single-thread (le multi-threading n'apporte aucun gain).
Le paramétrage de la mémoire cache est optimisé pour mon PC alors que les benchs ci-dessus sont optimisés pour un Pentium 4 de 3.4GHz. Il se peut que ce paramétrage ne soit pas optimum pour tous vos processeurs.
Les courbes en gras sont les résultats de ma bibliothèques, les autres courbes sont celles obtenues par la librairie ATLAS.
Le premier graphe concerne les matrices réelles, le 2ème est pour des matices complexes.

**epsilon68** · 09/07/2007, 09h24

et voila

**Charlemagne** · 09/07/2007, 10h30

Whawwww,c'est intéressant!!

La vitesse du bench multi-threadé a pratiquement doublé sur ton 2x Xeon.
Sur un bi-processeur, ça marche mieux que pour la FFT parce que les blocs calculés sont plus indépendants les uns des autres.
On dirait même que les perfs augmenteraient encore pour des matrices plus grandes. La prochaine fois je vais rajouter des tailles plus grandes.

ATLAS est nettement moins bon que ma bibliothèque sur ce coup, mais ça vient probablement du fait qu'ATLAS n'a pas été compilé sur ton Xeon. (ATLAS modifie les paramètres en fonction de la machine ciblée). Ceci dit ma bibliothèque n'était pas non plus compilée spécialement pour les caractéristiques de la mémoire cache du Xéon (qui me sont inconnues).

Y'a des sauts brusques de la performance en multi-threading (144,192) que je ne m'explique pas vraiment.

Je serais ravi si d'autres personnes pouvaient faire ces benchmarks sur d'autres multi-processeurs. Merci d'avance.

Je trouve intéressant de vous montrer vos courbes.

Single-thread Xeon:

Multi-thread 2x Xeon:
-ATLAS n'est pas multi-threadé (j'ai pas regardé comment faire)
-Attention au changement d'échelle par rapport aux graphiques précédents.

**mchk0123** · 09/07/2007, 10h39

Ce qui est remarquable, c'est qu'en multithreadé sur x2, la pente à l'infini de ta bibliothèque est supérieure à celle d'ATLAS (2 derniers graphes).

Autrement dit, plus le calul est intensif, plus ta bibliothèque est performante proportionnellement à ATLAS. On n'est pas encore dans une optimisation algorithmique d'ordre polynomiale supérieure (cubique vs. linéaire), mais on tu t'en rapproches.

**Charlemagne** · 09/07/2007, 10h50

Envoyé par mchk0123

Ce qui est remarquable, c'est qu'en multithreadé sur x2, la pente à l'infini de ta bibliothèque est supérieure à celle d'ATLAS (2 derniers graphes).

Autrement dit, plus le calul est intensif, plus ta bibliothèque est performante proportionnellement à ATLAS. On n'est pas encore dans une optimisation algorithmique d'ordre polynomiale supérieure (cubique vs. linéaire), mais on tu t'en rapproches.

En "théorie" ça devrait se stabiliser. Tu penses bien que ça va pas augmenter indéfiniment (dommage). Je suis surpris que ça ne se soit pas stabilisé plus tôt comme en single-thread, mais y'a des phénomènes qui m'échappent sûrement en multi-threading. Ca veut dire aussi qu'il y a probablement moyen de gagner des méga-flops sur les tailles intermédiaires. J'ai fais une version multi-thread à la va vite. J'entrevois une autre possibilité mais je ne sais pas si ça vaut vraiment le coût de chambouler le programme actuel. Des benchs sur d'autres machines me le diront peut-être...

**Charlemagne** · 09/07/2007, 11h15

Visiblement le multi-threading n'est pas le fort d'ATLAS. Voici les benchs d'Intel:
http://www.intel.com/cd/software/pro...eng/266858.htm
Je voudrais bien tester sur les mêmes machines...

**Laurent Gomila** · 11/07/2007, 11h55

Voilà mes résultats.

**Charlemagne** · 11/07/2007, 12h27

Merci Laurent.
(Il ne manque plus HanLee, t'es là? Sinon j'accepte aussi les benchs de toute autre personne).

Il faut reconnaître que l'Athlon est ici nettement plus lent que les Pentium ou Xeon. Certes je ne connais pas les caractéristiques du cache de l'Athlon, mais ça n'explique pas tout.
En tout cas la version multi-threading à un gain proche de 2.
Y'a toujours cette baisse de performance pour la taille 192. (Je vais essayer de comprendre le phénomène)

Voici les courbes (je ne mets pas les matrices de nombres complexes qui n'apportent rien vraiment de différent)

Single-Thread:

Multi-thread:

Je vous ferais faire un autre bench dans les jours à venir.

**mchk0123** · 12/07/2007, 11h46

Charmelagne, peut être un début de piste à explorer pour expliquer les chutes de performance sur l'Athlon.

Si on regarde bien la courbe en MT, elle chute (un peu ou trés fortement) pour les tailles de matrices de 64, 128, 192 et 256, soit un multiple de 64 (car pour 32 elle ne chute pas).

Peut-être est-ce dut, comme tu le disais, aux caches de l'Athlon.
Pour mémoire, sur ces processeurs, les lignes du data cache sont d'une taille de 64 Ko, et les lignes du code cache sont de 64 octets.

L'idéal serait de lancer le benchmark en profilant le code sur des matrices de tailles 176 et 192 ; et de vérifier si, sur une taille de 192, il n'y a pas une fonction qui explose en temps d'exécution, alors que sur une taille de 176, elle prend beaucoup moins de temps.

**Charlemagne** · 13/07/2007, 11h44

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

A priori la baisse de perfs sur certaines dimensions n'est pas un problème de cache.

Je crois plutôt que les charges se sont pas toujours bien réparties sur les divers processeurs. Je pense que ce bench fera mieux, car j'ai réduit la granularité.

J'ai rajouté les dimensions (2000x2000) et (2048x2048), pour avoir 2 mesures supplémentaires, mais j'ose pas trop aller jusqu'à (3000x3000) parce que le temps de calcul risque d'augmenter fortement.

3 tests dans ce bench, donc 3 fichiers textes à me retourner:
-ST de référence
-MT
-MT avec OpenMP

Merci

**epsilon68** · 13/07/2007, 22h49

et voila

**Charlemagne** · 13/07/2007, 23h34

Merci. Les résultats sont déjà plus conformes à ce que j'attends.

Il y a un gain de 2x pour les grandes matrices. Je ne vois plus trop comment améliorer le gain pour les tailles intermédiaires.

La taille 64 est moins bonne sur tes Xeon en multi-thread qu'en single-thread. C'est parce que j'ai pour l'instant réglé le multi-threading pour qu'il s'enclenche à partir de cette taille, mais le coût de synchronisation y est encore trop important par rapport au temps de calcul. De plus il est fort vraisemblable que l'hyper-threading (qui diminue en fait les perfs sur mon ordi) ne vienne parasiter le bench.

De toute évidence y'a un bug dans le bench qui utilise OpenMP, je comprends pas pourquoi parce qu'en fait j'utilise la même fonction parallel_for que tu connais déjà et qui marche bien avec la FFT. Je vais essayer de comprendre le mystère au cours du week-end. Je posterai alors un nouveau bench.

**epsilon68** · 14/07/2007, 09h47

Envoyé par Charlemagne

De toute évidence y'a un bug dans le bench qui utilise OpenMP, je comprends pas pourquoi parce qu'en fait j'utilise la même fonction parallel_for que tu connais déjà et qui marche bien avec la FFT. Je vais essayer de comprendre le mystère au cours du week-end. Je posterai alors un nouveau bench.

OpenMP le sujet qui m'interesse

dis moi si je peux t'aider

**Charlemagne** · 14/07/2007, 10h02

Nouveau benchmark: probablement le dernier si tout va bien.
http://www.ient.rwth-aachen.de/team/...ads/benchs.zip

C'est la clause 'if' d'openMP qui cause problème, quand je l'ôte ça marche mais le temps de latence est beaucoup plus lent pour les petites boucles.
Le mystère du problème concernant OpenMP s'épaissit car :
-c'est sensé marcher (ça marchait avec la parallelisation de la FFT)
-ça plante sur une instruction assembleur
-le problème n'apparaît qu'avec des matrices de doubles (avec des floats ça marche bien)
-le programme compilé en mode débug marche bien...
Bref je ne vois pas d'explication à moins qu'ICL 8.1 ait un bug. Jusqu'à présent ICL ne m'avait jamais causé de problèmes.
J'ai donc fait un test 'if' moi même avant l'appel de la boucle OpenMP...

J'ai réglé le multi-threading pour qu'il s'enclenche plus tard, et donc la perf de (64x64) devrait rester constante.

OpenMP le sujet qui m'interesse
dis moi si je peux t'aider

Merci. Je ne vois pas trop comment. A la limite tu pourrais compiler toi même le benchmark sous VC2005. Si ça t'intéresses, je te donnerai des instructions et les sources pour le faire.

Et bonne Fête Nat !!

PS: les benchs multi-threadés ne testent pas les perfs d'ATLAS. (auparavant chaque bench testait ATLAS). Ca réduit donc le temps d'exécution du bench de plus d'un tiers par rapport aux précédents, mais il faut pas tenir compte des valeurs erronnées dans les tables.

**epsilon68** · 14/07/2007, 12h20

et voila

**Charlemagne** · 14/07/2007, 14h04

Ca roule. A priori c'était bien le dernier benchmark. Merci.

Si quelqu'un veut faire le même benchmark sur d'autres sytèmes, ça serait sympa, et puis vous pourriez comparer les perfs de vos ordis!
(pour rappel, bench téléchargeable là: http://www.ient.rwth-aachen.de/team/...ads/benchs.zip )

OpenMP donne des gains équivalents à mon implémentation multi-thread. C'est pas étonnant puisque les coûts de synchronisation sont globalement négligeables vis-à-vis du temps de calcul.
Maintenant que j'ai fais un branchement 'if' avant la boucle d'OpenMP plutôt qu'une clause 'if', il a les mêmes perfs pour les petites matrices. Preuve qu'OpenMP est améliorable.

Epsilon68, si tu veux compiler le bench sous VC2005 et voir si le "bug" d'OpenMP de la clause 'if' persiste, fais le moi savoir.
Je vais aussi à l'occasion mettre en ligne sur mon site le graphe de ton bench. Si tu veux un petit remerciement joint au graphe, je t'invite à me donner ton prénom et/ou nom si tu le désires. (par message privé éventuellement)

Si d'autres benchs d'autres systèmes sont plutôt bons pour ma bibliothèque, je les mettrai peut-être aussi en ligne.

J'ai mis le single-thread et le multi-thread sur un même graphe pour mieux comparer. (en gras le multi-threading).

**epsilon68** · 15/07/2007, 00h28

Envoyé par Charlemagne

Epsilon68, si tu veux compiler le bench sous VC2005 et voir si le "bug" d'OpenMP de la clause 'if' persiste, fais le moi savoir.
Je vais aussi à l'occasion mettre en ligne sur mon site le graphe de ton bench. Si tu veux un petit remerciement joint au graphe, je t'invite à me donner ton prénom et/ou nom si tu le désires. (par message privé éventuellement)

Je te remercie,
ce que tu peux faire c'est mettre mon pseudo et citer le forum developpez.com
epsilon68 / developpez.com (avec l'url de ton post)

c'est une bonne idée je trouve non ?