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.
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
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.
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
On Jun 12, 10:09 am, "J-F Portala" wrote:
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
On Jun 12, 10:09 am, "J-F Portala" <jfport...@free.fr> wrote:
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:james.kanze@gmail.com
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
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
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
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.
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
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.
On Thu, 12 Jun 2008 14:40:24 +0200, "J-F Portala" <jfportala@free.fr>:
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.
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
"J-F Portala" writes:
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__
"J-F Portala" <jfportala@free.fr> writes:
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.
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
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.
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.
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
"J-F Portala" a écrit dans le message de news: 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
"J-F Portala" <jfportala@free.fr> a écrit dans le message de news:
4851193d$0$19724$426a74cc@news.free.fr...
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.
"J-F Portala" a écrit dans le message de news: 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
On Jun 12, 2:40 pm, "J-F Portala" wrote:
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
On Jun 12, 2:40 pm, "J-F Portala" <jfport...@free.fr> wrote:
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:james.kanze@gmail.com
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
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
Merci à 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 à 50%.<br /> Si je rajoute un second thread, j'arrive à 100%.<br /> <br /> Il me semble que l'OS, ici XP est capable de répartir les threads sur les<br /> différents noyaux et ainsi optimiser les processeurs.<br /> Il suffit donc de travailler en multithread pour profiter des différents<br /> noyaux.<br /> Le compilateur n'est pas en cause.<br /> <br /> Ce niveau de répartition n'est peut pas optimum en comparaison des outils<br /> que vous avez cités, mais permet déjà de ne pas<br /> être trop frustré dans l'utilisation CPU.<br /> <br /> Jeff<br />
Merci à 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 à 50%.<br />
Si je rajoute un second thread, j'arrive à 100%.<br />
<br />
Il me semble que l'OS, ici XP est capable de répartir les threads sur les<br />
différents noyaux et ainsi optimiser les processeurs.<br />
Il suffit donc de travailler en multithread pour profiter des différents<br />
noyaux.<br />
Le compilateur n'est pas en cause.<br />
<br />
Ce niveau de répartition n'est peut pas optimum en comparaison des outils<br />
que vous avez cités, mais permet déjà de ne pas<br />
être trop frustré dans l'utilisation CPU.<br />
<br />
Jeff<br />
Merci à 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 à 50%.<br /> Si je rajoute un second thread, j'arrive à 100%.<br /> <br /> Il me semble que l'OS, ici XP est capable de répartir les threads sur les<br /> différents noyaux et ainsi optimiser les processeurs.<br /> Il suffit donc de travailler en multithread pour profiter des différents<br /> noyaux.<br /> Le compilateur n'est pas en cause.<br /> <br /> Ce niveau de répartition n'est peut pas optimum en comparaison des outils<br /> que vous avez cités, mais permet déjà de ne pas<br /> être trop frustré dans l'utilisation CPU.<br /> <br /> Jeff<br />
Michael DOUBEZ
<blockquote class="block0"><br /> Dans une appli avec un thread, le processeur arrive à 50%.<br /> Si je rajoute un second thread, j'arrive à 100%.<br /> [snip]<br /> Ce niveau de répartition n'est peut pas optimum en comparaison des outils<br /> que vous avez cités, mais permet déjà de ne pas<br /> être trop frustré dans l'utilisation CPU.<br /> <br /> </blockquote><br /> Il y a un pattern qui pourrait t'intéresser pour le calcul numérique<br /> multi-threadé, c'est la notion de valeur future. Le principe est qu'une<br /> valeur est calculée dans un thread (d'une pool de thread pour éviter<br /> l'overhead de création) et peut être retournée quand le calcul est terminé.<br /> <br /> L'attente de la fin du calcul n'est réalisée qu'au moment de<br /> l'utilisation de la valeur. Si tu est en milieu temps réel, c'est un<br /> peut plus lourd à gérer parce qu'il faut intégrer des timeouts dans<br /> l'interface.<br /> <br /> Il doit y avoir des lib qui implémentent ce pattern. Ca te permet en<br /> particulier d'utiliser le multi threading (et donc le multi coeur) de<br /> façon transparente.<br /> <br /> Typiquement, c'est quelque chose du genre:<br /> future<double> value1; //valeur future double<br /> future<double> 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 />
<blockquote class="block0"><br />
Dans une appli avec un thread, le processeur arrive à 50%.<br />
Si je rajoute un second thread, j'arrive à 100%.<br />
[snip]<br />
Ce niveau de répartition n'est peut pas optimum en comparaison des outils<br />
que vous avez cités, mais permet déjà de ne pas<br />
être trop frustré dans l'utilisation CPU.<br />
<br />
</blockquote><br />
Il y a un pattern qui pourrait t'intéresser pour le calcul numérique<br />
multi-threadé, c'est la notion de valeur future. Le principe est qu'une<br />
valeur est calculée dans un thread (d'une pool de thread pour éviter<br />
l'overhead de création) et peut être retournée quand le calcul est terminé.<br />
<br />
L'attente de la fin du calcul n'est réalisée qu'au moment de<br />
l'utilisation de la valeur. Si tu est en milieu temps réel, c'est un<br />
peut plus lourd à gérer parce qu'il faut intégrer des timeouts dans<br />
l'interface.<br />
<br />
Il doit y avoir des lib qui implémentent ce pattern. Ca te permet en<br />
particulier d'utiliser le multi threading (et donc le multi coeur) de<br />
façon transparente.<br />
<br />
Typiquement, c'est quelque chose du genre:<br />
future<double> value1; //valeur future double<br />
future<double> 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 />
<blockquote class="block0"><br /> Dans une appli avec un thread, le processeur arrive à 50%.<br /> Si je rajoute un second thread, j'arrive à 100%.<br /> [snip]<br /> Ce niveau de répartition n'est peut pas optimum en comparaison des outils<br /> que vous avez cités, mais permet déjà de ne pas<br /> être trop frustré dans l'utilisation CPU.<br /> <br /> </blockquote><br /> Il y a un pattern qui pourrait t'intéresser pour le calcul numérique<br /> multi-threadé, c'est la notion de valeur future. Le principe est qu'une<br /> valeur est calculée dans un thread (d'une pool de thread pour éviter<br /> l'overhead de création) et peut être retournée quand le calcul est terminé.<br /> <br /> L'attente de la fin du calcul n'est réalisée qu'au moment de<br /> l'utilisation de la valeur. Si tu est en milieu temps réel, c'est un<br /> peut plus lourd à gérer parce qu'il faut intégrer des timeouts dans<br /> l'interface.<br /> <br /> Il doit y avoir des lib qui implémentent ce pattern. Ca te permet en<br /> particulier d'utiliser le multi threading (et donc le multi coeur) de<br /> façon transparente.<br /> <br /> Typiquement, c'est quelque chose du genre:<br /> future<double> value1; //valeur future double<br /> future<double> 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 />
