pertinence de std::this_thread::sleep_for(x)

**Katian** · 14/11/2018, 06h04

Bonjour !

Je me demande quelle valeur minimale est réellement pertinente à l'utilisation de std::this_thread::sleep_for(x)

au vu des délais lors des changements de contexte en multi-thread, (est-ce une constante, de quoi cela dépend t'il)

en bref, j'essaie de diminuer l’utilisation du CPU de façon empirique, est-ce que si x se rapproche de zero, l'utilisation du CPU se rapproche de 100 % ?

désolé si je ne suis pas clair.

dans mon cas d’expérimentation j'ai deux thread dont chacun dispose d'une boucle infinie avec aucune instruction mis à part ce std::this_thread::sleep_for(x)

**Matt_Houston** · 14/11/2018, 09h55

La documentation est claire (l'emphase n'est pas de moi) :

Blocks the execution of the current thread for at least the specified sleep_duration.

L'exécution reprendra donc après un laps de temps égal ou supérieur à la durée spécifiée par l'appelant, à savoir sleep_duration. Mais le noyau ne va pas immédiatement préempter le thread actif dès que le compte à rebours est terminé comme un réveil-matin, il faut encore attendre que le tour de ton thread arrive. Ce délai dépend de beaucoup de paramètres, principalement de la stratégie de préemption du noyau et de la charge qui sont effectives.

**JolyLoic** · 14/11/2018, 11h04

Je ne suis pas certain de ce que tu essayes d'obtenir, mais je partirais depuis le point de vue opposé : Quel est, fonctionnellement, la fréquence de travail nécessaire à ton application ?

**Katian** · 14/11/2018, 16h59

Envoyé par JolyLoic

Quel est, fonctionnellement, la fréquence de travail nécessaire à ton application ?

En fait j'essaie d'appréhender les concepts clés lors de la conception d'un jeu vidéo (boucle principale et délégation de taches)

**JolyLoic** · 15/11/2018, 16h48

Aux dernières nouvelles que j'ai eues, les développeurs de jeu tendent à éviter les threads, car le coût de synchronisation peut être prohibitif. Donc un sleep_for n'aura pas tant pour effet de permettre à un autre thread de tourner, mais plus de permettre au matériel de se reposer, et donc de ne pas trop chauffer, et donc de na pas bouffer trop de batterie (sur tablette, téléphone) ou de faire trop de bruit de ventilo (sur fixe ou laptop).

Généralement, pour les jeux, ce qu'on veut avoir de plus rapide à cadencer est l'affichage, avec souvent une cible à 60Hz (le moteur physique peut demander plus en interne, mais sans être vraiment cadencé). Ce qui fait des temps pour un sleep_for de quelques millisecondes, ce qu'un sleep_for n'a généralement pas de problème à gérer...

Est-ce que c'est le genre de réponse que tu attendais ?

**Katian** · 15/11/2018, 17h03

Vous répondez parfaitement à mes interrogations merci ^^

Envoyé par JolyLoic

Aux dernières nouvelles que j'ai eues, les développeurs de jeu tendent à éviter les threads, car le coût de synchronisation peut être prohibitif.

est-ce spécifique au développement sur smartphone ?

**Bktero** · 16/11/2018, 08h53

est-ce spécifique au développement sur smartphone ?

Non. C'est le cas dés que tu souhaites économiser du temps CPU ou éviter des latences. Toutefois, il faut avoir de sacrées contraintes pour s'interdire les threads (ça dépend quand même de l'OS, chacun ayant sa politique de cadencement).

**Matt_Houston** · 16/11/2018, 09h19

Envoyé par JolyLoic

Aux dernières nouvelles que j'ai eues, les développeurs de jeu tendent à éviter les threads, car le coût de synchronisation peut être prohibitif.

Dans le cas du jeu vidéo les relations entre les threads sont beaucoup plus complexes que dans le cas d'un programme de calcul scientifique, certes, mais ça ne veut pas dire que l'approche concurrente n'est jamais adaptée. Je pense surtout qu'on ne se donne pas la peine de paralléliser à grande échelle parce que les jeux sont en grande majorité GPU-bound. Le « coût prohibitif » est donc plutôt à chercher au niveau du rapport entre le coût de développement et de maintenance d'une telle conception en regard du maigre bénéfice procuré.

C'est aussi pourquoi l'emploi d'un moteur de jeu monothreadé (allô, Unreal Engine..

) pour autre chose qu'un jeu type peut s'avérer ~~un cauchemar~~ très contraignante.

**Katian** · 16/11/2018, 12h42

Envoyé par Bktero

(ça dépend quand même de l'OS, chacun ayant sa politique de cadencement).

ici je développe sous Linux

Envoyé par Matt_Houston

Dans le cas du jeu vidéo les relations entre les threads sont beaucoup plus complexes que dans le cas d'un programme de calcul scientifique, certes, mais ça ne veut pas dire que l'approche concurrente n'est jamais adaptée.

Je démarre sur une base où rendu et entrées sont gérées par le thread principal après éventuellement un pool de threads histoire d'éviter la création/destruction de threads trop fréquente

**bacelar** · 16/11/2018, 15h08

ici je développe sous Linux

Vu le nombre de variétés de Linux et la customisation possible de ces Kernels, c'est tout aussi flou que l'ensemble des OS existant.
Un RT-Linux ou un Linux "standard" n'ont pas grand-chose en commun sur cet aspect.

Je démarre sur une base où rendu et entrées sont gérées par le thread principal après éventuellement un pool de threads histoire d'éviter la création/destruction de threads trop fréquente

Sauf gestion explicite des économies d'énergie, on se fait pas trop chier à essayer de sauver les ours polaires ( => consommation de CPU sans limite).

Pour les jeux, il y a 2 stratégies habituelles.
Soit on se synchronise avec le rafraichissement vertical de l'écran (le 30 ou 60 Hz des consoles) en utilisant ou en réglant des API d'affichage qui attendent la "synchro verticale", bloquant ainsi le moteur, ou la partie rendu du moteur.
Soit on se synchronise pas et on n'y va à fond, laissant le Kernel faire les switch de contexte les plus pertinents.

Je ne vois donc pas d'utilité particulière de "std::this_thread::sleep_for(x)" dans un jeu (et dans une application en générale d'ailleurs).

**Bousk** · 16/11/2018, 15h20

Au contraire les engine les plus puissants sont très multithreadés et parallélisés pour profiter de tous les coeurs et cpu pour atteindre le fameux 60fps tant convoité par les joueurs (je crois qu'aujourd'hui ils ne s'en contentent plus mais jurent par le 122 ou 144 fps ?).
Mais tu as toujours des threads qui nécessitent moins de synchronisation et tournent dans leur coin, comme un thread de réception réseau, ou d'envoi de logs/stats par exemple, et il est important de ne pas les laisser tourner trop vite et prendre tout le CPU donc une petite pause de 1ms après chaque process, ça laisse l'OS gérer et souffler un peu, et ça évite d'avoir à ajouter des mécanismes de synchronisation ou priorisation complexes.

**bacelar** · 16/11/2018, 17h02

et ça évite d'avoir à ajouter des mécanismes de synchronisation ou priorisation complexes.

Heu, suffit de prendre des API bloquantes et d'utiliser les propriétés de priorisation des threads 1 fois par thread, à sa création.
On peut toujours faire une usine à gaz, mais on n'est pas obligé.

ça laisse l'OS gérer et souffler un peu,

Si le "x" de "std::this_thread::sleep_for(x)" est petit, il y a de bonnes chances qu'il soit implémenté avec un bon gros spin lock qui tâche, donc assez moyen pour "faire souffler le CPU".

**Katian** · 16/11/2018, 17h43

Envoyé par bacelar

ou la partie rendu du moteur.

pour l'instant je cap le rendu à 40 fps, le reste de ma boucle principale est rythmée à coup de std::this_thread::sleep_for(x)

Envoyé par bacelar

Heu, suffit de prendre des API bloquantes et d'utiliser les propriétés de priorisation des threads 1 fois par thread, à sa création.

Je ne maîtrise pas ce sujet bacelar tu aurais de quoi m'orienter ?

**Matt_Houston** · 16/11/2018, 18h37

Envoyé par Bousk

Au contraire les engine les plus puissants sont très multithreadés et parallélisés pour profiter de tous les coeurs et cpu pour atteindre le fameux 60fps tant convoité par les joueurs (je crois qu'aujourd'hui ils ne s'en contentent plus mais jurent par le 122 ou 144 fps ?).

Tu as des exemples ? Moi pas, mais je suis curieux d'en savoir plus. Je ne connais que très peu le développement sur console par exemple.

Créer des threads, ce n'est pas paralléliser. Ce n'est pas parce que le programme dispatche quarante tâches qu'il exploite plus d'un cœur pour autant. Ce sont plutôt les jeux eux-mêmes qui vont paralléliser leurs propres traitements, s'ils en ont l'usage, plus que le moteur.

**bacelar** · 16/11/2018, 19h21

pour l'instant je cap le rendu à 40 fps, le reste de ma boucle principale est rythmée à coup de std::this_thread::sleep_for(x)

OK, mais pourquoi "rythmée" votre boucle puisque vous vous foutez de l'effet de "sheering" qu'entraine la désynchronisation entre la vitesse de rafraichissement de l'écran et celle de votre programme ? (à moins que les 40fps viennent de votre fréquence d'écran, ce qui serait assez bizarre).
Moi, dans ce cas, je fais "rythmée" la boucle principal au taquet, sans "std::this_thread::sleep_for".
Pourquoi voulez-vous que votre thread principal s'arrête ???? (un temps indéterminé, borné inférieurement mais pas supérieurement, je le rappelle)

Je ne maîtrise pas ce sujet bacelar tu aurais de quoi m'orienter ?

C'est fonction des API graphiques, des OS, etc..., mais c'est le genre de détail que les concepteurs de moteur de jeu customisent au poil de cul (enfin normalement).

Souvent, dans les moteurs de jeux, le passage du mode synchro/désynchro sur la "V-Sync", c'est juste l'appel à une fonction globale ou équivalent.
Normalement, votre code ne doit pas dépendre de ce type de réglage.

**Katian** · 16/11/2018, 19h33

Envoyé par bacelar

OK, mais pourquoi "rythmée" votre boucle puisque vous vous foutez de l'effet de "sheering" qu'entraine la désynchronisation entre la vitesse de rafraichissement de l'écran et celle de votre programme ?

je comprends mieux maintenant je vais me préoccuper de ce point

Envoyé par bacelar

Pourquoi voulez-vous que votre thread principal s'arrête ???? (un temps indéterminé, borné inférieurement mais pas supérieurement, je le rappelle)

le but est de limiter l'utilisation CPU tant que possible dans le cas où j'utilise d'autres threads

Envoyé par bacelar

C'est fonction des API graphiques, des OS, etc..., mais c'est le genre de détail que les concepteurs de moteur de jeu customisent au poil de cul (enfin normalement).

j'en suis aux débuts donc ce sera un de mes prochains objectifs

Envoyé par bacelar

Souvent, dans les moteurs de jeux, le passage du mode synchro/désynchro sur la "V-Sync", c'est juste l'appel à une fonction globale ou équivalent.

J'en prends bonne note merci bacelar

**Bousk** · 16/11/2018, 19h48

Envoyé par Matt_Houston

Tu as des exemples ? Moi pas, mais je suis curieux d'en savoir plus. Je ne connais que très peu le développement sur console par exemple.

Créer des threads, ce n'est pas paralléliser. Ce n'est pas parce que le programme dispatche quarante tâches qu'il exploite plus d'un cœur pour autant. Ce sont plutôt les jeux eux-mêmes qui vont paralléliser leurs propres traitements, s'ils en ont l'usage, plus que le moteur.

Tous les jeux sur consoles exploitent la console au possible. Sauf peut-être les jeux moins gourmand ou ambitieux qui se contentent et tournent sur peu.
Tu as X coeurs (8 sur PS4 et 7 sur XOne je crois) qui ont chacun leur priorité et importance, quand tu crées des threads tu les assignes sur certains coeurs ou pas, tu ne laisses pas bêtement le système choisir pour toi (je sais même pas s'il en est capable sur consoles) sinon y'a (quasi) aucun intérêt

Et même si c'est le gameplay qui est le plus parallélisé, c'est grâce au moteur qui le permet.
Tu peux avoir des étapes de process qui sont parallélisées via le moteur et le gameplay/jeu ne fait que créer des entités/évènements qui vont agir à X ou Y étapes.
Sur PC c'est un peu plus complexe parce qu'il faut que le moteur s'adapte au CPU et aux coeurs existants, mais c'est possible (j'ignore les détails et le talk de mon ancien collègue semble avoir disparu du gdc vault https://software.intel.com/en-us/art...rated-graphics)

**Katian** · 16/11/2018, 19h51

Il faut peut-être distinguer console/PC j'ai pas l'ambition de toucher les consoles disons pour l'instant, je préfère voir petit ^^

**bacelar** · 19/11/2018, 11h33

le but est de limiter l'utilisation CPU tant que possible dans le cas où j'utilise d'autres threads

C'est là qu'intervient les priorités et les synchronisations de thread.
Si votre boucle principale a besoin d'attendre que d'autres threads aient terminé leur travail, utilisez des primitives de synchronisation.