Discussion :

[Space23]

Bonjour,

Voila je viens de finir une petite appli en c++ sur dev c++ qui réalise de la reconnaissance d'image. Ce type d'appli est assez lourde.

Je voudrais donc l'optimiser et qu'il mette moins de temps à s'exécuter. Quand je regarde la charge sur mon cpu il stagne à 13%... J'ai un core I7 (4 coeurs avec 8 threads), ça sert bien d'avoir un proco de fou s'il ne passe pas la barre des 13%.

1) Tout d'abord, j'ai remarqué que mon appli n'était pas multi-threadé car le 2e thread de chaque coeur est à 0% de charge. Est-ce qu'il y a une config à mettre dans mon compilo (dev c++) pour qu'il execute mes applis en multi thread?

2) Sinon je tourne à 30% du coup en monoThread, pourquoi pas 100%? Encore une fois il y t-il une configuration spéciale pour que l'appli utilise toutes mes ressources processeurs?

[jabbounet]

13% c'est a peu pres egal a 1/8 donc effectivement ton appli n'utilise qu'un seul des 8 threads possible du coeur.

1) Tout d'abord, j'ai remarqué que mon appli n'était pas multi-threadé car le 2e thread de chaque coeur est à 0% de charge. Est-ce qu'il y a une config à mettre dans mon compilo (dev c++) pour qu'il execute mes applis en multi thread?

C'est n'est pas une option de compilation mais plus l'architecture de ton soft a modifier en utilisant une lib de thread (pthread/boost/...), le but et d'essayer de paralléliser les traitement qui peuvent l'être.

2) Sinon je tourne à 30% du coup en monoThread, pourquoi pas 100%? Encore une fois il y t-il une configuration spéciale pour que l'appli utilise toutes mes ressources processeurs?

plutôt 25%, non?, si 1 seul des 4 coeurs est utilisé.

même conseil qu'en haut, il faut essayer de paralléliser certains traitements en les déléguant a des threads dédiés.

[Space23]

Je ne sais pas si ça utilise un seul coeur à fond ou simplement un petit pourcentage de chacun de mes coeurs. J'ai du mal à déchiffrer les diagrammes sur le gestionnaire de ressources (voir piece jointe).

Je vais regarder pThread voir ce que je peux faire mais je ne suis pas très optimiste sur le fait de pouvoir paralléliser des branches de mon code.


Autre question de noob, mon proc est 64bits. Est-ce qu'il me faudrait pas dev c++ 64 bits pour optimiser mes perfs?

Edit : Je corrige avant de me faire reprendre . Si j'ai bien compris devC++ est mon IDE donc le mettre en 64 bits n'a aucune importance. J'utilise MinGW comme compilateur il faudrait que je le passe donc en 64 bits. Ca se fait?

[jabbounet]

Ca dépend de ton compilo et de de ce qu'il est capable de générer, s'il peux faire des exécutable 64 bits et que ta plate forme/OS sont 64 bits, il est préférable de le lui demander.

ton os vois ton quad-core comme huit processeurs, chacune des huit cases en haut à droite "historique de l'utilisation cpu" représente l'activité de l'un d'eux au cours du temps.

dans ta capture d'écran on vois que c'est surtout le CPU numéro 3 ainsi que le numéro 1 (mais moitié moins) qui bossent.

sur le graphe en dessous "mémoire" on vois que l'utilisation de cette dernière augmente régulièrement au cours du temps, cela est peu être normal si ton application est en phase d'initialisation, mais cela peux aussi indiquer une fuite mémoire et donc un crash potentiel dans un avenir proche.

[koala01]

Salut,

Autre question de noob, mon proc est 64bits. Est-ce qu'il me faudrait pas dev c++ 64 bits pour optimiser mes perfs?

Edit : Je corrige avant de me faire reprendre . Si j'ai bien compris devC++ est mon IDE donc le mettre en 64 bits n'a aucune importance. J'utilise MinGW comme compilateur il faudrait que je le passe donc en 64 bits. Ca se fait?

Déjà, il faut bien être conscient que devC++ n'est plus vraiment maintenu, et qu'il serait peut être intéressant de passer à un autre EDI (Code::Blocks est pas mal et fort semblable ).

Ensuite, effectivement, il est possible d'obtenir une version 64 bits de MinGW.

Il s'agit en réalité d'un projet "parallèle" à MinGW qui s'appelle... MinGW-w64 (pour windows 64)

J'ai d'ailleurs déjà fournis une version 64 bits de MinGW capable de compiler aussi bien des applications 32 bits que des applications 64 bits (on parle de "support multilib" ).

Par défaut (ou en ajoutant l'option "-m64" qui est tout à fait inutile), les applications sont donc compilées en 64 bits, mais, si tu ajoute l'option "-m32" à ton instruction de compilation, l'application est générée en 32 bits

Tu le trouvera par exemple sur la page dédiée aux binaire Qt (car j'ai également fournis un version des binaires de Qt en 64 bits utilisant ce compilateur).
Quant à savoir s'il est ou non intéressant de compiler ton application en 64 bits, il faut savoir qu'il y a "a boire et à manger"

En effet, la différence la plus marquante entre une architecture 32 bits et une architecture 64 bits tient au fait que les adresses mémoires (tout ce qui utilise les pointeurs) sont... deux fois plus grandes en 64 bits qu'en 32 bits.

Tu auras compris que cela multiplie énormément la plage mémoire accessible

Dés lors, s'il est possible d'utiliser une application 32 bits sur une architecture 64 bits, ce n'est que parce que le système fournit une espèce de "wrapper" d'adresses qui converti l'adresse codée sur 32 bits en une adresse codée sur 64 bits (bon, avant que d'autres ne crient, ce n'est ni tout à fait complet ni tout à fait juste, mais cela te permettra de comprendre le principe )

Cette conversion a, malgré tout, un cout au niveau de l'exécution

D'un autre coté, il semble bien clair qu'il devient impossible à une architecture 32 bits d'utiliser une application prévue pour fonctionner en... 64 bits

De plus, en fonction des ressources nécessaires à ton application, il peut devenir intéressant de pouvoir disposer... d'une plage mémoire plus importante.

Au final, j'aurais tendance à te dire de réfléchir à l'utilisation qui sera faite de ton application.

Si destines ton application à être déployée sur des architectures aussi bien 32 bits que 64 bits (du moins si les ressources qu'elle utilise supporte le mode 32 bits), tu as donc le choix entre la laisser en 32 bits (merci le système de compatibilité ) ou la fournir... dans les deux versions.

Si tu te dis que cette application ne sera jamais déployée sur des machines 32 bits, ou qu'elle nécessite tellement de mémoire qu'il devient impossible d'envisager de la fournir dans une version 32 bits, le choix devient facile: vive le 64 bits

[Space23]

Salut koala,

Tout d'abord, merci de ta réponse ça m'a permis d'éclaircir pas mal de trucs . Mon application est a destination seulement de mon pc en fait donc je pourrait tout à fait passer gcc en 64 bits.

Possèder une plage mémoire plus importante ne va pas vraiment m'aider pour mon implémentation perso. Par contre cela va pouvoir améliorer les perfs de mon appli car je vais utiliser des fonctions de base, qui elles, utilisent maintenant des plage mémoire plus longue c'est ça?

On parle d'une amélioration du temps d'exécution importante ou pas?

[koala01]

En terme de temps d'exécution, on peut estimer qu'il y a un léger gain lorsque l'on dispose d'une application adaptée à l'architecture, parce que l'on évite cette manoeuvre de conversion, mais ce n'est très certainement pas aussi sensible que le gain que tu peux espérer en multitheadant correctement ton application.

Le tout reste toujours... de ne pas en arriver à une situation dans laquelle deux threads font la même chose à peu près au même moment

[JolyLoic]

C'est n'est pas une option de compilation mais plus l'architecture de ton soft a modifier en utilisant une lib de thread (pthread/boost/...), le but et d'essayer de paralléliser les traitement qui peuvent l'être.

Ces bibliothèque ne sont pas destinées au multithread pour les performances, il y a des alternatives plus adaptées (Intel TBB (open source), Microsoft PPL)

[jabbounet]

Ces bibliothèque ne sont pas destinées au multithread pour les performances, il y a des alternatives plus adaptées (Intel TBB (open source), Microsoft PPL)

quelque soit la lib utilisé s'il réussi a répartir correctement ses traitements sur ses CPU il devrait gagner un temps de traitement non négligeable.

Les libs dont tu parle sont peu etre plus performante, mais au vu de leur nom je ne sais pas si elle seront portable sur d'autres os/archi, et comme je ne connais pas la contrainte space23 j'ai préféré indiquer les standards.

[Joel F]

vu le type d'appli, un petit coup d'openMP serait peut etre largement suffisant.
2e point: a voir la qté de calcul aussi, ca sert a rien de paralleliser si y a peanuts à travailler.

J'aurais aussi tendance à dire qu'avant de se jeter sur le multithread, optimisez son cache, utilisez des trucs genre SSE2 et bien vérifiez l'optimalité de l'algo me semble de bon aloi

[jabbounet]

vu le type d'appli, un petit coup d'openMP serait peut etre largement suffisant.
2e point: a voir la qté de calcul aussi, ca sert a rien de paralleliser si y a peanuts à travailler.

J'aurais aussi tendance à dire qu'avant de se jeter sur le multithread, optimisez son cache, utilisez des trucs genre SSE2 et bien vérifiez l'optimalité de l'algo me semble de bon aloi

tout à fait exact, si la mémoire est bien organisée ça marche beaucoup mieux....

passer des outils de profiling peux aussi aider.

[Space23]

tout à fait exact, si la mémoire est bien organisée ça marche beaucoup mieux....

passer des outils de profiling peux aussi aider.

En fait mon appli est un mixte entre du java et du c++. La partie reconnaissance d'image pur se fait en c++ et l'algo est réalisé en Java.

C/C++ c'est imbattable question performance mais je me prends 10 fois plus la tete pour ecrire 3 lignes de code (je parle pour moi). C'est pour ça que j'ai fait ce choix.

Le temps d'exécution de cette appli est vraiment primordiale et pour l'instant je ne suis pas arrivé à mon objectif. A part le multithreading j'ai déjà optimisé ce que je pouvais.

J'ai donc implémenté pthread sur mon code mais ça ne marche pas et j'ai aucun message d'erreur. Je ne comprends pas où j'ai pu faire une erreur. Voici mon code (seulement la partie relatif aux threads) :

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
 
//Ma fonction appelé par des threads
void * reconnaissanceImage(void * srcPatternVoid) {
     char * srcPattern = (char *) srcPatternVoid;
     ****
}
 
//Fonction main
int main(int argc, char *argv[])
{
   //Définition de mes threads
   pthread_t * thread1;
   pthread_t * thread2;
   int ret = 0;
***
   system("pause");
 
   ret = pthread_create(thread1, NULL, reconnaissanceImage, (void *) "capture/image.jpg");
   pthread_join(*thread1,NULL);
 
***
   system("pause");
}

Edit : Je ne m'arrête jamais sur mes system("pause");

Autre chose bizarre, le package pthread c++ que j'ai trouvé pour windows contient plusieurs dll :
_ pthreadGC2.dll
_ pthreadGCE2.dll
_ pthreadVC2.dll
_ pthreadVCE2.dll
_ pthreadVSE2.dll

Je n'ai aucune idée de l'utilité de chacun, j'ai juste mis le 1er dans l'éditeur de liens de mon compilo ça vous semble correct?

[JolyLoic]

Les libs dont tu parle sont peu etre plus performante, mais au vu de leur nom je ne sais pas si elle seront portable sur d'autres os/archi, et comme je ne connais pas la contrainte space23 j'ai préféré indiquer les standards.

En terme de parallélisation pour les performances, je pense que TBB est le standard de fait aujourd'hui. Et elle est portable sur moult architectures. Voir http://software.intel.com/sites/prod...ease_notes.txt pour plus d'infos.

[Space23]

D'après ce que j'ai pu lire TBB n'a pas l'air très trivial à utiliser contrairement à pthread.

Même si ça n'a n'optimisera pas à fond, si j'arrive à paralleliser sur 8 threads (destiné à une archi quadri-coeur); quelque soit la librairie utiliseé les optimisations de performances risquent d'être énorme .

[Joel F]

je répété au risque de me répéter: quid du cache et du vectoriel avant de sortir les threads ?

[JolyLoic]

D'après ce que j'ai pu lire TBB n'a pas l'air très trivial à utiliser contrairement à pthread.

Oui et non... Elle fourni des concepts plus haut niveau, et donc demande plus de temps à être découverte et comprise. Une fois cette étape franchie, elle fourni des concepts plus haut niveau, et permet donc d'écrire du code plus simple, avec moins d'effort. Sans elle, tu risques par exemple de devoir réinventer des conteneurs thread-safe, ce que tu feras moins bien qu'eux (en terme de perfs, mais aussi d'erreurs).

je répété au risque de me répéter: quid du cache et du vectoriel avant de sortir les threads ?

Utiliser tous les threads peut être un argument marketing, alors qu'une mauvaise utilisation du SSE est moins aisément visible par l'utilisateur final...

A ce sujet (je connais mal le SSE), pour utiliser correctement SSE, comment fais-tu ? Utilises-tu une bibliothèque spécifique, ou bien écris-tu directement des instructions spécifiques à l'architecture ?

Et pour quelle(s) raison(s) places-tu le SSE avant le multithread ? J'ai l'impression qu'en terme de difficulté, c'est du même ordre, qu'en terme de gain attendu, aussi (c'est pour ces raisons qu'une bibliothèque comme Ct qui est sensée gérer les deux d'un bloc me semble intéressante).

[Joel F]

Utiliser tous les threads peut être un argument marketing, alors qu'une mauvaise utilisation du SSE est moins aisément visible par l'utilisateur final...

Moi le marketing ^^ j'ai des gens qui s'en charge :o

A ce sujet (je connais mal le SSE), pour utiliser correctement SSE, comment fais-tu ? Utilises-tu une bibliothèque spécifique, ou bien écris-tu directement des instructions spécifiques à l'architecture ?

*J'ai* écrit une bibliothèque qui encapsule tous les SIMD existants sous forme de fonctions façon cmath etc... qui travaille sur des objets genre simd::register_<T,N> qui représentent des paquets de N valeurs de types T. Si (T,N) correspondent à un register simd sur une archi donnée, la vectorisatione st automatique. Sinon, on découpe et on utilsie boost::array si besoin. Ca fait bien 5-6 que j'ai pas ecrit d'intrinsic directement autrement que pour ajouter une fonction dans ce machin.

Et pour quelle(s) raison(s) places-tu le SSE avant le multithread ? J'ai l'impression qu'en terme de difficulté, c'est du même ordre, qu'en terme de gain attendu, aussi (c'est pour ces raisons qu'une bibliothèque comme Ct qui est sensée gérer les deux d'un bloc me semble intéressante).

parce que avant de changer le moteur de ma voiture, j'utilise une bonne huile et un bon carburant Les extensiosn SIMD xont la, c'ets guère le drame a utilisé conceptuellement (pas d'histoire de mutex, de dead race etc) et c'ets un gain de 4 à 16 AVANT MEME de threader. Pour tout dire, SIMD+Thread, en général, sur pas mal d'applis ca suffit à briser la barrière du temps réel ou à rendre utilisable un algo. Ca relativise aussi la nécessité de faire des trucs chelou avec des GPU vu que le gain GPU vs SIMD+Thread depasse rarement 4 ou 6

[zeeboub]

*J'ai* écrit une bibliothèque qui encapsule tous les SIMD existants sous forme de fonctions façon cmath etc... qui travaille sur des objets genre simd::register_<T,N> qui représentent des paquets de N valeurs de types T. Si (T,N) correspondent à un register simd sur une archi donnée, la vectorisatione st automatique. Sinon, on découpe et on utilsie boost::array si besoin. Ca fait bien 5-6 que j'ai pas ecrit d'intrinsic directement autrement que pour ajouter une fonction dans ce machin.

Ta lib est dispo quelque part ???

[Joel F]

Y a une release de prévue quand le reste de la lib sera propre

[stardeath]

parce que avant de changer le moteur de ma voiture, j'utilise une bonne huile et un bon carburant Les extensiosn SIMD xont la, c'ets guère le drame a utilisé conceptuellement (pas d'histoire de mutex, de dead race etc) et c'ets un gain de 4 à 16 AVANT MEME de threader. Pour tout dire, SIMD+Thread, en général, sur pas mal d'applis ca suffit à briser la barrière du temps réel ou à rendre utilisable un algo. Ca relativise aussi la nécessité de faire des trucs chelou avec des GPU vu que le gain GPU vs SIMD+Thread depasse rarement 4 ou 6

en même temps si ta voiture a 8 cylindres, tu ne vas pas t'amuser à en utiliser qu'un seul même si tu utilises de la bonne essence.

le problème de l'optimisation, c'est que le résultat peut être très convaincant sur une machine, risque d'être pire qu'autre chose sur une autre machine. il y a un vieil adage qui dit "moins de 20% du code doit être optimiser".
autant peut être se concentrer à avoir une appli qui utilise tous les cores d'une machine que d'essayer d'avoir le maximum de perf d'un seul core et risquer de ne plus pouvoir utiliser d'autre core efficacement.

de plus s'amuser à étudier les défauts de cache est très loin d'être évident comparé à mettre un #pragma parallel for.

par contre ça m'intéresse de savoir d'où sort ce chiffre que le ratio gain gpu vs simd+thread dépasse rarement 4 ou 6.