Discussion :

[Katian]

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]

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]

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]

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]

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]

Vous répondez parfaitement à mes interrogations merci ^^

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 ?

[Matt_Houston]

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.