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?

[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.

[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 .

[jabbounet]

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.

dommage que les procésseurs sparc et PA-RISC ne soient pas supportées, sinon elle aurait bien pu m'intéresser, je vais donc rester sur du pthread.


Ensuite je ne serais pas si catégorique, d'expériences toutes les lib de thread on leurs avantage et leurs inconvénients. il y'aura forcément des use-case ou TBB sera moins bonne que pthread et vice et versa. les performances vont surtout beaucoup dépendre du design de ton application et des choix d'architectures logiciel.

http://www.drdobbs.com/go-parallel/b...PCKH4ATMY32JVN

[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.