Discussion :

[Pocus]

Bonjour,

Question basique certainement...

Si j'exécute plusieurs threads dans un programme Delphi:

- D7
- BDS 2007

et suivant différents OS:

- XP
- Vista
- Seven

Est ce que Windows va de façon optimale répartir les threads sur chaque coeur, ou il y a des précautions à prendre suivant les combinaisons sus citées?

Merci par avançe
Philippe/Pocus.

[Paul TOTH]

Bonjour,

Question basique certainement...

Si j'exécute plusieurs threads dans un programme Delphi:

- D7
- BDS 2007

et suivant différents OS:

- XP
- Vista
- Seven

Est ce que Windows va de façon optimale répartir les threads sur chaque coeur, ou il y a des précautions à prendre suivant les combinaisons sus citées?

Merci par avançe
Philippe/Pocus.

ce qu'il faut regarder c'est surtout le nombre de thread et le nombre de coeurs, pour le reste l'OS fait ce qu'il peut

[Pocus]

ce qu'il faut regarder c'est surtout le nombre de thread et le nombre de coeurs, pour le reste l'OS fait ce qu'il peut

Oh ca sera simple, au plus 1 thread par coeur... ce qui m'inquiète c'est le "l'OS fera ce qu'il peut " ...

[Franck SORIANO]

Oh ca sera simple, au plus 1 thread par coeur... ce qui m'inquiète c'est le "l'OS fera ce qu'il peut " ...

Qu'est-ce qui t'inquiête la dedans ? Windows fait un très bon travail à ce sujet.
Maintenant si vraiment ça t'inquiête, tu peux définir l'affinité de chaque thread avec les CPU disponibles, grâce à la fonction :
SetThreadAffinityMask
Elle te permet de restreindre les CPU que chaque thread peut utilisé, et ainsi affecter un thread à un CPU donné.

Cependant, c'est rarement une bonne idée (à moins de vouloir définir des quotas CPU, ou de vouloir réserver un CPU pour une tâche donnée). Car si le CPU affecté est utilisé, le thread ne pourra pas s'exécuter en utilisant un autre CPU disponible...

[Lung]

Qu'est-ce qui t'inquiête la dedans ? Windows fait un très bon travail à ce sujet.

Ah bon !
Moi, mon quad core : le premier travaille, le deuxième un peu, et les deux autres jamais. Et quand le premier est à fond, les deux derniers n'aident jamais.

Cependant, c'est rarement une bonne idée (à moins de vouloir définir des quotas CPU, ou de vouloir réserver un CPU pour une tâche donnée).

C'est justement ce qu'il serait bien que le système permette de faire.

Car si le CPU affecté est utilisé, le thread ne pourra pas s'exécuter en utilisant un autre CPU disponible...

Certes. Mais dans mon cas, comme j'ai deux coeurs qui ne travaillent pas, autant les occuper.

[Pocus]

Justement c'est de cela dont je voulais parler. Certains disent "laissent Win se débrouiller", d'autres pensent qu'il est mieux de lui baliser le chemin (SetThreadAffinityMask entre autre).

C'est vrai que comme cela, j'aurai tendance à être du 2e avis (même si ce n'est pas un avis trés éclairé), parce que si justement je regarde l'utilisation des 4 coeurs de mon PC pendant qu'il fait tourner un jeu AAA (du genre avec un moteur Unreal 3 et un moteur physique, donc certainement pas du monothread) et bien je ne peux pas dire que les charges soient vraiment réparties, ce serait plutôt coeur 1 = 100%, le 2e à 25% et les 3 et 4 qui se tournent les pouces.

Aprés, sans preuve, je ne peux dire si c'est l'optimum, mais ca n'y ressemble pas...

[Franck SORIANO]

Ah bon !
Moi, mon quad core : le premier travaille, le deuxième un peu, et les deux autres jamais. Et quand le premier est à fond, les deux derniers n'aident jamais.

C'est vrai que comme cela, j'aurai tendance à être du 2e avis (même si ce n'est pas un avis trés éclairé), parce que si justement je regarde l'utilisation des 4 coeurs de mon PC pendant qu'il fait tourner un jeu AAA (du genre avec un moteur Unreal 3 et un moteur physique, donc certainement pas du monothread) et bien je ne peux pas dire que les charges soient vraiment réparties, ce serait plutôt coeur 1 = 100%, le 2e à 25% et les 3 et 4 qui se tournent les pouces.

Le problème ne vient pas de windows, mais de la conception même des applis.
Déjà, il n'y a pas de miracles. Pour que les 4 coeurs tournent au maximum de leur capacité, il faut qu'il y ait en permanence 4 threads activable prêt à consommer du CPU. Or dans la pratique, un thread passe son temps à attendre quelque chose. Soit une E/S, soit le résutlat d'un calcul précédent effectué par un autre thread.

Prenons l'exemple du jeu si tu veux : Le moteur physique est une chose, mais il ne va pas avoir grand chose à faire tant que le joueur n'a pas fait quelque chose qui nécessite de recalculer la scène.
Le rendu des images est effectué par la carte 3D, l'ensentiel des calculs se passe dans les shaders.
De même, pour le son, ce n'est pas la gestion des sons à jouer qui va écrouler le processeur. Ensuite, c'est la carte son qui travaille...
Au final, même si le jeu est multi-threadé (et encore, il n'y a que les jeux récents qui le sont réellement), ça ne veut pas dire qu'il y a de quoi occuper les 4 CPU.

[GoustiFruit]

C'est bien ce qu'il me semblait, le multi-core, c'est de l'arnaque !

[Franck SORIANO]

C'est la même chose qu'une machine multi-processeurs.
Il faut en avoir l'utilité, avoir des applis qui savent le gérer, ou vouloir faire tourner plusieurs applis en même temps, ou mettre plusieurs utilisateurs sur la même machine en TSE...

Lorsque je recompresse mes enregistrements de la TNT, je peux te dire que j'apprécie de voir les 4 coeurs tourner !