processeur double coeur

Le
J-F Portala
Bonjour,
je ne sais pas si c'est le bon groupe, mais
je ne voyais pas où poster ma question.

Je développe en C++ (avec VC++6.0 sous XP) des applications où il y a
pas mal de calculs.
Dernierement j 'ai fait des benchs sur une application et j'ai vu que le
processeur etait utilisé à 50% alors
que je m'attendais à 100% d'occupation

La seule explication pour moi est que le PC etant un double coeur, les
calculs n'étaient faits que sur un des deux.

Mon application va aussi vite sur un PC récent que sur un P4 2,4GHz d'il y a
3 ans.

Comment fait on pour gérer ces nouveaux processeurs?
Est ce qu'il faut affecter des tâches à chaque processeur, (et quand le pc
en aura 4?)
Toutes les applications écrites pour un seul processeur vont donc tourner à
50% sur les nouveaux PC et à 25% sur les futurs quadro processeurs?

Cela me parait un sacré retour en arrière en terme de performances.

Peut être que je suis à côté de la plaque, n'hésitez pas à m'en faire part.

Merci

Jeff
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Michael DOUBEZ
Le #6971251
Bonjour,
je ne sais pas si c'est le bon groupe, mais
je ne voyais pas où poster ma question.

Je développe en C++ (avec VC++6.0 sous XP) des applications où il y a
pas mal de calculs.
Dernierement j 'ai fait des benchs sur une application et j'ai vu que le
processeur etait utilisé à 50% alors
que je m'attendais à 100% d'occupation

La seule explication pour moi est que le PC etant un double coeur, les
calculs n'étaient faits que sur un des deux.


Oui. Il y a plusieurs stratégies pour exploiter les processeurs
multicoeur et la plus courante est qu'un processus s'attache à un coeur.
La solution est d'utiliser une libraire multicoeur (comme propsée par
intel ou IBM). Je n'en sais guère plus.

Sinon, si changer de langage est une option, Erlang est le langage à la
mode. Je ne sais pas si il est possible de le linker avec du C++.

Enfin, je pense qu'il doit être possible d'avoir une architecture qui
tire partie de l'architecture multicoeur (par passage de message par
exemple) mais IMO c'est pas trivial.

--
Michael

James Kanze
Le #6971241
On Jun 12, 10:09 am, "J-F Portala"
Je développe en C++ (avec VC++6.0 sous XP) des applications où
il y a pas mal de calculs. Dernierement j 'ai fait des benchs
sur une application et j'ai vu que le processeur etait utilisé
à 50% alors que je m'attendais à 100% d'occupation

La seule explication pour moi est que le PC etant un double
coeur, les calculs n'étaient faits que sur un des deux.


Un thread ne peut s'exécuter que sur une CPU à la fois.

Mon application va aussi vite sur un PC récent que sur un P4
2,4GHz d'il y a 3 ans.


Si elle tourne tout seule, probablement.

Comment fait on pour gérer ces nouveaux processeurs?


Ça dépend de l'application. Pour des applications naturellement
multi-thread, ça se fait prèsque de façon automatique. Pour des
applications de calcul, il faut soit un compilateur qui sait
gérer la parallelisation lui-même (très difficile en C++, à
cause de l'aliasing), soit que tu le fais à la main toi-même.

Est ce qu'il faut affecter des tâches à chaque processeur, (et
quand le pc en aura 4?)... Toutes les applications écrites
pour un seul processeur vont donc tourner à 50% sur les
nouveaux PC et à 25% sur les futurs quadro processeurs?


Écrites, ça dépend du compilateur. Mais toutes celles compilées
avec des compilateurs assez anciens, c'est sûr.

Cela me parait un sacré retour en arrière en terme de
performances.

Peut être que je suis à côté de la plaque, n'hésitez pas à
m'en faire part.


Le problème (dans ton cas), c'est qu'il n'y a pas beaucoup
d'argent dans le calcul numérique, et que donc, les évolutions
ne le prenent pas trop en compte (sauf au niveau des
super-ordinateurs, peut-être). Augmenter la vitesse d'un core
unique devient de plus en plus difficile, tandis que fournir
d'avantage de corps améliore la vitesse d'autres applications
considérablement. D'autres applications qui ont un impact
financiel important, comme des serveurs de Web ou de bases de
données. (Mes applications tournent sur une machine à 32 CPUs en
production, et je peux te dire qu'elles en gagne beaucoup. Mais
elles sont naturellement parallel, avec plusieurs centaines de
threads.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

J-F Portala
Le #6984621
Merci de vos reponses.

Tu évoquais le fait qu'un compilateur récent effectuerait la tâche tout
seul.
Cela n'a pas l'air d'être simple à vérifier.
J'ai passé un peu de temps sur le net pour avoir des informations sur les
compilateurs et leur capacité
à gérer plusieurs processeurs, mais sans succès.
Est ce que faire du multithreading veut dire automatiquement que les threads
seront affectés aux différents processeurs.
Est ce que cela dépend du compilateur (je travaille avec VC++6.0 plus trés
jeune), ou de l'OS.

Merci
Jeff
Fabien LE LEZ
Le #6984611
On Thu, 12 Jun 2008 14:40:24 +0200, "J-F Portala"
Tu évoquais le fait qu'un compilateur récent effectuerait la tâche tout
seul.


Je crois que tu as mal lu.
James évoquait la possibilité qu'un compilateur gère le multi-thread,
mais la trouvait douteuse, étant donné que c'est très difficile à
faire pour un compilateur C++.

Toutefois, un compilateur récent peut tirer parti d'autres
fonctionnalités des processeurs récents. Intel base la publicité pour
son compilateur C++ là-dessus.

Est ce que cela dépend du compilateur


Oui. Du moins, pour ton code.

(je travaille avec VC++6.0 plus trés jeune),


Gloups... Effectivement. Si tu as cinq minutes (et Windows XP), je te
conseille de tester Visual C++ 2008 Express, gratuit.
Je ne sais pas s'il améliorera beaucoup les performances, mais au
moins il te permettra de programmer en C++, c'est déjà ça.

pjb
Le #6989091
"J-F Portala"
Merci de vos reponses.

Tu évoquais le fait qu'un compilateur récent effectuerait la tâche tout
seul.
Cela n'a pas l'air d'être simple à vérifier.
J'ai passé un peu de temps sur le net pour avoir des informations sur les
compilateurs et leur capacité
à gérer plusieurs processeurs, mais sans succès.


Par exemple:
http://www.pgroup.com/products/workindex.htm

google: parallel fortran multicore


Est ce que faire du multithreading veut dire automatiquement que les threads
seront affectés aux différents processeurs.


Avec les vrai fils du noyau, oui. Les fils verts (Green Threads) sont
implémentés en mode non-privilégié, et donc ne bénéficient pas de
l'ordonanceur du noyau.


Est ce que cela dépend du compilateur (je travaille avec VC++6.0 plus trés
jeune), ou de l'OS.


Des deux.


--
__Pascal Bourguignon__

Benoit
Le #6990761
J-F Portala wrote:
Bonjour,
je ne sais pas si c'est le bon groupe, mais
je ne voyais pas où poster ma question.


Sous Windows, fr.comp.os.ms-windows.programmation
pour les apis gérant les processeurs.

Eric Pruneau
Le #6992271
"J-F Portala" 4851193d$0$19724$
Merci de vos reponses.

Tu évoquais le fait qu'un compilateur récent effectuerait la tâche tout
seul.
Cela n'a pas l'air d'être simple à vérifier.
J'ai passé un peu de temps sur le net pour avoir des informations sur les
compilateurs et leur capacité
à gérer plusieurs processeurs, mais sans succès.
Est ce que faire du multithreading veut dire automatiquement que les
threads seront affectés aux différents processeurs.
Est ce que cela dépend du compilateur (je travaille avec VC++6.0 plus trés
jeune), ou de l'OS.

Merci
Jeff



Je travaille avec le compilateur d'intel et il y a effectivement une option
d'optimisation qui permet de paraleliser le code automatiquement. Pour mon
cas il y a une légère amélioration, mais il faut noter que j'utilise aussi
plusieurs thread, donc je ne m'attendais pas à des gains spectaculaires.

La meilleur options pour des performances optimales serait probablement
d'utiliser "Intel® Threading Building Blocks". Je n'ai jamais utilisé mais
comme ils disent dans leur publicité: "Thread like an expert whitout being
one!". Ce qui est bien avec cet outil c'est qu'il s'adapte automatiquement
au nombre de coeur présent sur la machine.

--------------
Eric Pruneau

James Kanze
Le #6993001
On Jun 12, 2:40 pm, "J-F Portala"
Tu évoquais le fait qu'un compilateur récent effectuerait la
tâche tout seul.


Pas tout à fait. J'ai évoqué la possibilité qu'un compilateur la
fasse, en signalant même un aspect du C++ qui le rend difficile.
Je ne connais pas de compilateur actuellement qui le fait en
C++. (J'en connaissais un en Fortran, il y a bien vingt ans.)

Cela n'a pas l'air d'être simple à vérifier. J'ai passé un
peu de temps sur le net pour avoir des informations sur les
compilateurs et leur capacité à gérer plusieurs processeurs,
mais sans succès.


Ne t'en fais pas. Si un compilateur le fait, les auteurs en
parleraient.

Est ce que faire du multithreading veut dire automatiquement
que les threads seront affectés aux différents processeurs.


Oui et non. Ça dépend un peu de l'OS, mais sous Windows, les
pthread de Solaris (mais pas forcément les threads plus anciens)
et les versions les plus récentes de Linux, les threads sont
gérer pratiquement comme des processus : un thread qui veut
travailler serait affecté à la première CPU qui se libère.

Est ce que cela dépend du compilateur (je travaille avec
VC++6.0 plus trés jeune), ou de l'OS.


Plutôt que de l'OS.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

J-F Portala
Le #7018811
Merci &agrave; tous de votre aide.<br />
<br />
J'ai poursuivi mes recherches et j'ai fait quelques tests.<br />
<br />
Dans une appli avec un thread, le processeur arrive &agrave; 50%.<br />
Si je rajoute un second thread, j'arrive &agrave; 100%.<br />
<br />
Il me semble que l'OS, ici XP est capable de r&eacute;partir les threads sur les<br />
diff&eacute;rents noyaux et ainsi optimiser les processeurs.<br />
Il suffit donc de travailler en multithread pour profiter des diff&eacute;rents<br />
noyaux.<br />
Le compilateur n'est pas en cause.<br />
<br />
Ce niveau de r&eacute;partition n'est peut pas optimum en comparaison des outils<br />
que vous avez cit&eacute;s, mais permet d&eacute;j&agrave; de ne pas<br />
&ecirc;tre trop frustr&eacute; dans l'utilisation CPU.<br />
<br />
Jeff<br />
Michael DOUBEZ
Le #7024041
<blockquote class="block0"><br />
Dans une appli avec un thread, le processeur arrive &agrave; 50%.<br />
Si je rajoute un second thread, j'arrive &agrave; 100%.<br />
[snip]<br />
Ce niveau de r&eacute;partition n'est peut pas optimum en comparaison des outils<br />
que vous avez cit&eacute;s, mais permet d&eacute;j&agrave; de ne pas<br />
&ecirc;tre trop frustr&eacute; dans l'utilisation CPU.<br />
<br />
</blockquote><br />
Il y a un pattern qui pourrait t'int&eacute;resser pour le calcul num&eacute;rique<br />
multi-thread&eacute;, c'est la notion de valeur future. Le principe est qu'une<br />
valeur est calcul&eacute;e dans un thread (d'une pool de thread pour &eacute;viter<br />
l'overhead de cr&eacute;ation) et peut &ecirc;tre retourn&eacute;e quand le calcul est termin&eacute;.<br />
<br />
L'attente de la fin du calcul n'est r&eacute;alis&eacute;e qu'au moment de<br />
l'utilisation de la valeur. Si tu est en milieu temps r&eacute;el, c'est un<br />
peut plus lourd &agrave; g&eacute;rer parce qu'il faut int&eacute;grer des timeouts dans<br />
l'interface.<br />
<br />
Il doit y avoir des lib qui impl&eacute;mentent ce pattern. Ca te permet en<br />
particulier d'utiliser le multi threading (et donc le multi coeur) de<br />
fa&ccedil;on transparente.<br />
<br />
Typiquement, c'est quelque chose du genre:<br />
future&lt;double&gt; value1; //valeur future double<br />
future&lt;double&gt; value2;<br />
<br />
value.compute(bind(method1,1)); //lance le calcul<br />
value.compute(bind(method2,42));<br />
<br />
return value1+value2; //retourne l'addition quand les calculs sont finis<br />
<br />
--<br />
Michael<br />
<br />
Publicité
Poster une réponse
Anonyme