Discussion :

[loufoque]

Si tu est à la recherche de registres pourquoi ne pas essayer le 64 bits ?
Le nombre de registres SSE 128 bits sont doublés et passent à 16. Les généraux passent aussi à 16 et sont sur 64 bits (of course).

Normalement si on est pas trop bête on exprime la vectorisation via les built-ins du compilateur, qui se charge alors d'utiliser autant de registres que possible en fonction de la plate-forme cible.

[mchk0123]

Question: les programmes compilés sous IA32 sont-ils compatibles sous 64 bits?
Si c'était le cas, j'imagine que la moitié des registre n'est pas utilisée.

La compatibilité doit être à 2 niveau :
- compatibilité hardware du processeur (IA64 et AMD64 sont compatibles IA32, ce qui n'était pas le cas de l'Itanium).
- compatibilité software de l'OS : Windows XP 64 et Vista 64 ont une couche d'émulation x86 qui s'appelles SysWOW64 (Windows On Windows)
- pour Linux je ne sais pas si Linux 64 et compatible Linux 32

Les corrolaires étants que :
- en mode compatibilité 32 bits, le processeur accèpte exactement le même jeu d'instruction et utilise le même nombre de registres que les processeurs 32 bits
- un programme compilé 32 bits tournant sur Windows 64 bits sera plus lent à cause de la couche d'émulation (mais cela reste quand même trés rapide)

- pour ce qui est des gardes-fous :

1. le linker doit normalement sélectionner le sous-système en fonction du code assembleur généré (ex: sous-système Win64 pour du code AMD64 généré)

2. ce qui fait qu'un programme 64 bits exécuté sur un OS 32 bits affichera une boîte de message d'erreur indiquant que le programme ne peut pas se lancer sur la version actuelle de Windows

3. enfin, un programme "broken" ayant une version de sous-système (information située dans l'entête PE de l'exécutable) contredisant le code généré lévera une exception hardware (du même style qu'une division par 0) et fera planter l'exécutable

Si ta bibliothèque est écrite uniquement en C/C++, pas d'autre choix que d'attendre gcc 64 bits. Par contre si certaines fonctions sont en ASM, là le choix est plus large (nasm, yasm, ...).

[Charlemagne]

Voilà, j'ai 2 nouveaux benchmarks à vous faire exécuter.
(J'ai effacé les benchs précédents qui ne sont donc plus téléchargeables)

1) Benchmark de référence single-threaded
http://www.ient.rwth-aachen.de/team/...FT_64_SSE2.zip
2) Benchmark multi-threadé, paramétré grâce à vos mesures précédentes pour tirer le meilleur parti du multithreading.
http://www.ient.rwth-aachen.de/team/...64_SSE2_MT.zip

Je vous passe les détails, mais ça n'a pas été facile de réussir à faire en sorte que le bench multi-threadé soit aussi rapide sur un système mono-processeur que le bench single-threadé.

Si ça marche comme je l'espère, je généraliserai le multi-threading aux FFT de matrices réelles, et je posterai un dernier Bench.

Quelques impressions basées sur les diverses mesures effectuées, pour l'achat d'un processeur muti-noyau:
- privilégier la fréquence d'accès mémoire du BUS à la fréquence du CPU (j'avais déjà fais cette constatation sur du single-thread)
- privilégier une grande mémoire cache. La synchronisation et l'initialisation de processus représentent un temps de calcul non négligeable (c'est la raison pour laquelle les mesures sur les petites matrices étaient - comme prévu- catastrophiques). Il faut donc prévoir des processus consommant pas mal de mémoire. Si l'on ne veut pas que les performances s'effondrent et rendent le multi-threading contre-performant, alors il vaut mieux une bonne mémoire cache.
- privilégier une mémoire cache commune aux noyaux pour faciliter les échanges de données d'un thread à l'autre, car sinon le multi-threading n'a surtout de sens que pour des processus indépendants.

[Laurent Gomila]

Voilà mes résultats pour le dernier bench (Athlon DualCore 3800+).

[Charlemagne]

Merci Laurent.
Y'a malheureusement 2 problèmes avec tes derniers benchs:
- les mesures single-thread sont nettement moins bonnes qu'auparavant: ça vient peut-être d'une option de compilation que j'ai changée entre temps
- Les résultats single- et multi-threads sont identiques! Là je comprends pas à moins que l'identification automatique du nombre de cores, que j'ai intégrée au dernier bench, soit défectueuse sur ton Athlon.
Je rajoute donc provisoirement un 3ème bench pour en juger.

Récapitulation des 3 benchmarks à effectuer:
http://www.ient.rwth-aachen.de/team/...FT_64_SSE2.zip
http://www.ient.rwth-aachen.de/team/...64_SSE2_MT.zip
http://www.ient.rwth-aachen.de/team/...4_SSE2_MTx.zip

[Laurent Gomila]

J'ai fait le dernier bench, ainsi que les deux premiers pour être sûr qu'il n'y avait pas de mauvaise manip de ma part (j'avais laissé tourner quelques applications en arrière plan).

[Charlemagne]

(j'avais laissé tourner quelques applications en arrière plan)

Non c'était pas ça, les nouvelles mesures des 2 premiers benchs ont encore des valeurs faibles. Le 3ème revient à des valeurs cohérentes aux jours précédents, c'était donc bien mon changement d'option de compilation (Ob1 en Ob2). C'est dommage car sur mon système, les résultats étaient devenus légèrement plus rapide. Mais visiblement je vais revenir à Ob1 car la baisse de perfs est trop grande sur ton Athlon et probablement pour les autres AMD aussi. C'est dingue un tel changement de comportement d'un CPU à l'autre.

Je confirme également que mon programme ne détecte pas correctement le nombre de core sur ton Athlon (c'est bien 2 pas vrai?), et il n'en détecte qu'un seul. C'est bizarre car j'avais fais faire des tests sur divers CPU dans une autre discussion.
Veux-tu bien me copier-coller la sortie de ce minuscule programme (le même que celui testé plus haut par HanLee):
http://www.ient.rwth-aachen.de/team/...oads/cpuid.zip

[Laurent Gomila]

Je confirme également que mon programme ne détecte pas correctement le nombre de core sur ton Athlon (c'est bien 2 pas vrai?), et il n'en détecte qu'un seul. C'est bizarre car j'avais fais faire des tests sur divers CPU dans une autre discussion.

Oui c'est bizarre, j'avais fait ces tests et au final ça marchait très bien. D'ailleurs je te reconfirme ça :

Code X :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
name  	AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
vendor	AuthenticAMD
intel 	0
amd   	1
mmx   	1
sse   	1
sse2  	1
sse3  	1
3dnow 	1

physical core count    	1
logical processor count	2
L1 cache size          	1
L2 cache size          	1

[epsilon68]

et ca marcherait sur mon macbook pro dual core ?

[Charlemagne]

Ca s'explique (en partie).
Pour déterminer le nombre max de processus, j'utilise la donnée "physical core count" qui vaut 1 chez toi, alors que je m'attendais à 2 (tout comme HanLee sur son Core Duo).
La donnée "logical processor count" ne sert à ma connaissance (d'après les docs que j'ai lues) que pour les processeurs Hyper-Thread. Tout comme mon vieux P4 HT qui me retourne effectivement la valeur 2.

Je comprends pas pourquoi les processeurs AMD n'imitent visiblement pas le comportement des CPU Intel. L'Hyper-Threading n'existe pas chez AMD, mais ça n'explique pas la différence...
Je vois pas trop quoi faire si ce n'est utiliser l'une ou l'autre des valeur selon la marque détectée du processeur.

et ca marcherait sur mon macbook pro dual core ?

Si t'as Windows d'installer, alors normalement oui. Vérifie quand même que mon minuscule programme CPUID donne bien la valeur 2 pour "physical core".

En attendant je vais recompiler une version qui utilise la valeur "logical core" pour les AMD.

[epsilon68]

les sources du benchmarks sont-ils reservés uniquement pour windows ?

[Charlemagne]

les sources du benchmarks sont-ils reservés uniquement pour windows ?

Ce ne sont pas des sources mais des exécutables.
Je rendrai les sources disponibles en GPL quand ça marchera sans problème (bientôt!) sur mon site:
http://www.ient.rwth-aachen.de/team/...al/genial.html.
Pour l'instant les modules Multi-threads ne sont pas dispos.

[Charlemagne]

Les Benchmarks ont été modifié pour tenir compte du problème concernant la détection du nombre de noyaux sur les AMD.
Désolé pour ce contretemps bien involontaire.

C'est dommage et bizarre que les perfs soient nettement moins bonnes avec l'option de compilation Ob2 sur l'Athlon (alors que les perfs sur mon CPU Intel étaient légèrement meilleures), car l'exécutable était nettement moins volumineux qu'avec Ob1.

1)Benchmark de référence single-thread (Laurent en est dispensé!)
http://www.ient.rwth-aachen.de/team/...FT_64_SSE2.zip
2)Benchmark multi-thread
http://www.ient.rwth-aachen.de/team/...64_SSE2_MT.zip

[epsilon68]

Ce ne sont pas des sources mais des exécutables.
Je rendrai les sources disponibles en GPL quand ça marchera sans problème (bientôt!) sur mon site:
http://www.ient.rwth-aachen.de/team/...al/genial.html.
Pour l'instant les modules Multi-threads ne sont pas dispos.

Tu as utilisé OpenMP ? sinon ca me dirait bien une petite comparaison sur le meme programme de ta méthode puis avec OpenMP... j'ai GCC 4.2 sur mon mac je suis pret a tester (a t'aider pour OpenMP eventuellement)...

[Charlemagne]

Les problèmes:
-c'est que je connais pas OpenMP. C'est gratuit? Y'a une fonction du genre 'parallel_for / parallel_reduce' telle que je l'ai programmée?
-GCC n'est pas capable d'optimiser aussi bien la FFT que le compilo d'Intel ICL. (Certes j'ai pas encore eu la possibilité d'utiliser une version 4.X sous Windows)
-Mes algos multi-threadés fonctionnent uniquement sous Windows ou bien sur tout système avec la librairie 'pthreads' (Unix/Linux). Il est probable que GCC sous Mac connaisse 'pthreads' mais je connais pratiquement pas le monde Mac.

Une comparaison avec d'autres bibliothèque m'intéresse. Si ça t'intéresse également tu peux t'amuser à les comparer.
Tu peux comparer des algorithmes simples.

Voici par exemple un algo faisant la somme des éléments d'un vecteur. (Y'a moyen de faire beaucoup plus rapide avec les instructions vectorielles SSE mais ce n'est qu'un petit exemple)
Il suffit d'inclure le fichier d'en-tête 'threads.h' ci-joint.

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
#include <vector>
#include <numeric>
#include <ctime>
 
#define MAX_THREADS 2
#include "threads.h"
 
using namespace std;
 
inline double get_time() { return double(clock())/CLOCKS_PER_SEC; }
 
template<class V>
struct fill_function
{
  V val;
  fill_function(const V &v) : val(v) {}
  template<class RanIt> void operator()(RanIt begin, RanIt end) const { fill(begin,end,val); }
};
 
template<class V>
struct accumulate_function
{
  mutable V val;
  accumulate_function() : val(0) {}
  void join(const accumulate_function &x) const { val+=x.val; }
  template<class It> void operator()(It begin, It end) const { val=accumulate(begin,end,val); }
};
 
template<class RanIt,class T>
T parallel_accumulate(RanIt begin, RanIt end, const T &val)
{
  accumulate_function<T> func;
  gmt::parallel_reduce(begin,end,func,10000);
  return val+func.val;
}
 
int main()
{
  typedef int value_type;
  vector<value_type> X(10000000,1);
 
  //fill(X.begin(),X.end(),1);
  //gmt::parallel_for(X.begin(),X.end(), fill_function<value_type>(1), 100);
 
  double t0=0;
  value_type *psum = new value_type; //variable allouée dynamiquement pour bluffer l'optimisation d'ICL qui peut sinon carrément zapper les itérations des boucles
 
  //t0=get_time();
  //for (int i=0; i<500; ++i)
  //  *psum=accumulate(X.begin(),X.end(),0);
  //cout << *psum << " " << get_time()-t0 << "s" << endl;
 
  t0=get_time();
  for (int i=0; i<500; ++i)
    *psum=parallel_accumulate(X.begin(),X.end(),0);
  cout << *psum << " " << get_time()-t0 << "s" << endl;
}

[epsilon68]

je dirais que OpenMP c'est vraiment adapté a du calcul numerique.
www.openmp.org

je te fais aussi quelques exemples, mais aussi de memoire on ne peut faire de reduction ou sum que sur des types primitifs...

je (re)teste et je poste :-)

ps: ce qu'il y a de bien avec OpenMP c'est que c'est le meme code pour le parallel ou non ... pas plusieurs sources a maintenir

[mchk0123]

D'après mes connaissances OpenMP est gratuit à partir du moment ou la librairie est incluse avec le compilateur.

Une liste (pas à jour) est accéssible ici.
Nottament, VC++ 2007 (hors EE) dispose de OpenMP.

Sur la disponibilité, je n'en sais pas plus.

Pour son usage c'est trés simple : 2 directives de compilation encadrant une boucle "for()" suffit pour paralleliser la boucle sur le bon nombre de Cores / Procs.

Tutoriel French ici

[Charlemagne]

OpenMP mérite un coup d'oeil. Je vais voir ça.
A première vue c'est une "surcouche" sur le compilo, non?
GCC semble être un absent notoire de la liste. Et puis je ne vois aucune trace d'OpenMP dans la doc de VC2003, c'est normal? Ca me chagrine car je souhaite une solution 100% C++ portable sous divers compilos.

A part ça, mchk0123, t'as réparé ton Windows Vista? STP, tu peux faire les 2 derniers benchs postés un peu plus haut?

[mchk0123]

OpenMP mérite un coup d'oeil. Je vais voir ça.
A première vue c'est une "surcouche" sur le compilo, non?

Pour ce que j'ai compris, il y a 2 parties :
- directives natives du compilateur (genre #pragma)
- librairie statique à linker

Il y a aussi un projet de développement OpenMP en libre pour gcc, mais ça semble être tout récent.

A part ça, mchk0123, t'as réparé ton Windows Vista? STP, tu peux faire les 2 derniers benchs postés un peu plus haut?

Nan Vista démarre toujours pas. Et ça sera pas pour tout de suite vu le temps que j'ai perdu dessus dernièrement.
Par contre j'ai un Athlon bicore au travail, je lancerai les tests la semaine prochaine. A voir aussi si un bench sur AMD Sempron 3400+ t'intéresse, c'est un monocore, mais ça pourrait permettre d'identifier des différences entre CPU & constructeurs.

[epsilon68]

openmp c'est effectivement des directives (pragma) donné au compilateur pour generer du code qui va bien. Une librairie est necessaire ensuite pour que ca marche.

gcc 4.2 (que j'ai longtemps attendu) le gere,
icc,
vs 2005

bref openmp c'est un standard ...