> Non. Je te donne le cas d'un processus unique qui pouvait aléatoirement être migré entre un coeur et l'autre.
Ce qui est normal. Et ce n'est pas vraiment aléatoire. Fais des setaffinity sur plusieurs programme et tu va voir que les performances vont dramatiquement chuter. Donc déplacer un thread est tout à fait normal. Et c'est peu coûteux. Si tu veux te convaincre que c'est peut couteux, fais un "make -j nb_cpu+2" et un "make -j nb_cpu". Les deux vont s'éxécuter quasiment aussi vite. Pourtant pour le premier il y aura beaucoup plus de "déplacement" de thread d'un cpu à un autre.
Considère ça :
cpu_1 : thread_A
cpu_2 : thread_B
Thread_A passe en sommeil et thread_C est lancé sur cpu_1 (puisqu'il est disponible)
cpu_1 : thread_C
cpu_2 : thread_B
Thread_B passe en sommeil.
Maintenant le thread_A doit être lancé. Que doit faire l'OS ? Arrêter thread_C, le passer sur cpu_2, le lancer, et lancer thread_A sur cpu_1 ? Ça c'est beaucoup plus coûteux que de lancer thread_A sur cpu_2.
> Il y a quelques générations du noyau de cela, c'était même un ping pong permanent (et très coûteux).
Ce n'est pas coûteux du côté OS. Ça bouffe quasiment autant de cycle. Le problème est qu'il peut y avoir une mauvaise utilisation du cache cpu. Le problème peut être "dramatique" pour certaine architecture. Mais pas sur PC.
S'il est possible qu'un thread s'éxécute sur le même cpu, tant mieux. Mais ne chercher que ça ferait chuter les performances (et gravement).
[^] # Re: Multicoeur ?
Posté par IsNotGood . En réponse à la dépêche Intel libère TBB. Évalué à 1.
Ce qui est normal. Et ce n'est pas vraiment aléatoire. Fais des setaffinity sur plusieurs programme et tu va voir que les performances vont dramatiquement chuter. Donc déplacer un thread est tout à fait normal. Et c'est peu coûteux. Si tu veux te convaincre que c'est peut couteux, fais un "make -j nb_cpu+2" et un "make -j nb_cpu". Les deux vont s'éxécuter quasiment aussi vite. Pourtant pour le premier il y aura beaucoup plus de "déplacement" de thread d'un cpu à un autre.
Considère ça :
cpu_1 : thread_A
cpu_2 : thread_B
Thread_A passe en sommeil et thread_C est lancé sur cpu_1 (puisqu'il est disponible)
cpu_1 : thread_C
cpu_2 : thread_B
Thread_B passe en sommeil.
Maintenant le thread_A doit être lancé. Que doit faire l'OS ? Arrêter thread_C, le passer sur cpu_2, le lancer, et lancer thread_A sur cpu_1 ? Ça c'est beaucoup plus coûteux que de lancer thread_A sur cpu_2.
> Il y a quelques générations du noyau de cela, c'était même un ping pong permanent (et très coûteux).
Ce n'est pas coûteux du côté OS. Ça bouffe quasiment autant de cycle. Le problème est qu'il peut y avoir une mauvaise utilisation du cache cpu. Le problème peut être "dramatique" pour certaine architecture. Mais pas sur PC.
S'il est possible qu'un thread s'éxécute sur le même cpu, tant mieux. Mais ne chercher que ça ferait chuter les performances (et gravement).