Bonjour,
 
Petite question bête mais sur lequel je ne sais pas répondre, comment savoir si un logiciel X utilise la gestion multi core d'un processeur (dual / quadri core)
 
Y-a-t-il un moyen fiable de le voir ? (un logiciel qui donnerait cette information par exemple)
L'idée est de savoir si pou tel ou tel application, il faut configurer le processeur en mono ou multi core.
 
Merci pour votre aide

Avec cela peut être :
http://neosting.net/logiciels/gest [...] se7en.html
 
http://www.bill2-software.com/processmanager/

Salut,
 
Je ne comprends pas trop bien ce que tu veux faire. Quelles "optimisations" voudrais tu appliquer pour les process qui ne sont pas multithreadés ?
 
Normalement tu n'as rien à faire, Windows s'occupe très bien de placer les différents process sur différents cores. Le placement manuel n'a pas d'intérêt particulier.

Je me disais justement que les applications mono soient définies sur un seul CPU. En fait dans le but de lancer plusieurs applications différentes mono et multi en même temps.

va plus loin dans ce que tu veux, je ne comprend pas
moi je lance des tonnes d'applis et je me fout de savoir si elles sont multi ou pas
et ton système en lance un sacre paquet aussi

Exemple : benchmark multi core Hyper Pi 0.99
 
Test de calcul 2M en priorité High :
 
Résultat test sur 1 processeur :

 
Résultat test sur 4 processeurs :

 
Pour moi, ça démontre clairement que basculer une application sur un seul processeur, c'est plus rapide que d'utiliser le multi core dans le cas ou l'application n'utilise pas les possibilités multi core évidemment.
 
Qu'en pensez-vous ?

 
CPU1 : APP1 et APP3
CPU2 : APP2 et APP4
CPU3 : APP2 et APP5 et APP4
CPU4 : APP4 et APP5 et APP6
 
un truc comme ça, qui comprend du mono et du multi.
Je sais pas si je suis bien clair

 
en 36sec il a fait les mêmes calculs qu’en 26 ou 4 fois plus ?

A la fois 4 fois plus car il a lancé le calcul sur le 1, le 2, le 3, le 4 mais même si 3 CPUs sont utilisés, mon appli sur le CPU1 devrait être aussi rapide que 26sec... Moi ça me parait logique.
Après ok, je sais qu'en multi processeur, y a de la gestion qui bouffe du CPU mais bon, pas dans le cas d'HyperPi...
 

 
Ton test est faussé, dans la mesure ou dans ton exemple, au premier test tu as effectué une seule fois le calcul, et dans le second test tu l'as effectué 4 fois. Si tu veux faire un vrai test, il te faut lancer SuperPi avec 4 threads, et la première fois laisser Windows placer les threads, la seconde forcer leur affinité sur certains CPU. Tu te rendras compte alors que le placement manuel aura très probablement dégradé les perfs.
 
Tu confonds deux choses : le fait qu'une application soit monothreadée ou multithreadée, ce qui est purement du choix du concepteur, tu n'as généralement pas la main dessus, et la deuxième chose qui est le placement des threads sur le CPU.
 
Si une application est monothread, tu n'as pas le choix, elle sera sur un seul CPU. Si une application est multithread, il sera dans 99,999% des cas plus rapide de laisser le kernel Windows placer les processus sur les différents cores, car il le fera de façon à optimiser le plus possible.
 
Quand au fait que 4 instances de SuperPi prennent plus de temps qu'une seule, c'est normal. Une appli multithreadée nécessite toujours un certain travail supplémentaire (il faut envoyer des données 4 fois au lieu d'une seule + la synchronisation des threads et toutes les tâches afférentes).

Bonjour,
 
les multi-coeurs ont été créés parce que les CPU ne pouvaient plus monter en fréquence. Donc sur le principe le multi est toujours moins efficace que le mono cœur.
Je viens d'essayer Hyperpi sur mon athlon 64 x2. C'est pratiquement le même temps sur un ou deux cœurs (1 seconde d'écart).
J'avais essayé sur mon Q6600 et je n'avais pas vu des différences comme chez vous.
Mais i est sur que quand 4 processus différents et exigeant comme Hyper Pi fonctionnement, les ressources partagés du CPU comme le cache 2 ou 3  sont embouteillées et donc ralentissent la machine.
 
Pour avoir une vrai idée de la différence de rendement, il faudrait un logiciel vraiment multicœur qu'on testerait en un et plusieurs coeurs.
 
J'ai lu que, chez Intel, si un processus ne nécessite pas vraiment l'utilisation de plusieurs coeurs, il limite si possible  son exécution à un coeur car c'est plus rapide que de partager la tache.
 C'est juste une amélioration parmi les autres de la gestion de la charge.

n'importe quel compresseur MP4 (H.264) est très bien optimisé pour le multithread