robinHood (./106) :
yield ? quant je lis la def ca ressemble comme deux gouttes d'eau à un Sleep(0); sauf qu'il met le processus en dernier de la liste
Oui, ça ressemble, mais ça n'a rien à voir. La description que tu donnais toi dans ton post est celle de "yield" et non de "sleep". "Donner du boulot aux autres" c'est yield, sleep c'est "dormir".
en plus, il ne stoppe pas le processus si il n'y en à pas d'autre
Et donc ?
vive le 100% de cpu pour rien ... :- /
Gné ?
et d’ailleurs, je ne sait ce que ça vaut
Rien.
mais magnifique implémentation de yield en utilisant Sleep http://lists.puremagic.com/pipermail/phobos/2010-September/002284.html
C'est pas parce que t'as un effet similaire que c'est la même chose. yield > sleep.
Sinon, sous Windows, yield s'apelle SwitchToThread…
GoldenCrystal (./96) :
Ouais, d'autres programmes "tournent". Ça ne veut en aucun cas dire qu'ils sont actifs, ni qu'ils utilisent une quelconque quantité non strictement nulle de temps CPU.
Ouais sur l'autoroute d'autre voitures "roulent". Ca ne veut en aucun cas dire quelle ne sont pas sur l'aire de repos, ou ne roulent pas à deux à l'heure sur la voie de droite.
Je veux bien croire que mon truc (bien que exact) ait été maladroitement dit, mais ta déformation est foireuse. Une voiture qui est à l'arrêt ne roule pas. Par contre tu ne me feras pas gober que dans ton esprit la fenêtre explorer minimisée qui en réalité est totalement inactive, ne "tourne" pas
Bref, c'est juste pour dire qu'on est pas obligé de consommer du cpu pour "tourner".
donc roulons à fond ?
J'ai absolument pas dit ça…
GoldenCrystal (./96) :
Fort heureusement, non.
donc si tes jeux utilisent le max de puissance possible, je n'en lancerais jamais aucun, cpu 100% => poubelle
Tu ne devrais jouerà aucun jeu moderne alors.
Personnellement, la plupart des jeux auxquels je joue, utilisent toute la puissance nécessaire sur le PC… Quel est l'intérêt d'avoir un bon CPU si c'est pour ne jamais l'utiliser hein ?
L'intérêt c'est de t'en servir quand t'en as besoin. Si tu résumes tout à un % d'utilisation CPU, c'est une vision assez triste des choses. T'as peut être du mal à concevoir qu'on puisse utiliser légitimement 100% du CPU ?
(Hint : Suffit de concevoir son application correctement
)
GoldenCrystal (./96) :
Ou pas ?
en tout cas c'est très propre tout de même :- ) et je comprend la joie qu'à du avoir folco en utilisant cela, j'ai fait la même
il y 7 jours (ok, rien à voir avec du C
), et j'ai trouvé ça super utile simple et propre comme système !
GoldenCrystal (./96) :
ça reste tout à fait dans le contrat de sleep pourtant, et ça collerait malgré tout très bien à la plupart des cas où tu attends un truc qui va se produire bientôt. (PS: Quand tu utilises sleep(>0), tu indiques nécessairement que tu n'est pas trop regardant sur le temps réel qui s'écoulera pendant le sommeil)
si sdl étais fait habilement tout serais par callback pour les event, sauf que ce n'est pas le cas, bref faut lire régulièrement (ou alors dis moi quoi utiliser) sauf qu'avoir 1000000 test/seconde et 100% de cpu ben je te le laisse, très peu pour moi et mes programmes, un test de sourie ou touche n'est pas un arrêt d'urgence que je sache
GoldenCrystal (./96) :
Car bien évidemment SDL fait un sleep avant de récupérer les messages c'es évident 
Heureusement ça n'est pas aussi pourri que ça.
c'est une hypothèse, sait on jamais, tu as écrit sdl ?
C'est pas une hypothèse, banane, le code est dans ton propre post… C'est pas la peine de poster du code si tu n'es pas capable de le lire -_-
robinHood (./84) :
int SDL_WaitEvent (SDL_Event *event)
{
while ( 1 ) {
SDL_PumpEvents();
switch(SDL_PeepEvents(event, 1, SDL_GETEVENT, SDL_ALLEVENTS)) {
case -1: return 0;
case 1: return 1;
case 0: SDL_Delay(10);
}
}
}
le fait de se reposer sur cette fonction pour dispatcher un par un les event pose des risques intérogations et connaitre son fonctionnement et éventuellement la shunter est pertinent.
Par défaut quand tu utilises une fonction, suppose qu'elle fonctionne bien… i.e. qu'elle utilise la bonne implémentation (ou bien une des meilleures s'il y a plusieurs façons de faire).
en tout cas grace à cette fonction les dev de sdl nous montre comment faire une boucle avec sdl, un while 1 et un sdl delay
Parce que t'as pas fait la même chose ?
sdl_delay implémenté sous windows comme cela :
void SDL_Delay(Uint32 ms)
{
Sleep(ms);
} \o/
hérésie ! !call sdlTeam
Quel problème as tu en particulier avec cette implémentation ?
À part que c'est moins efficace que #define SDL_Delay(ms) Sleep(ms), c'est bien la correspondance idéale…
GoldenCrystal (./96) :
de plus les procs sont rapides, mais Folco aime optimiser non ? lancer un wait qui va se while un pumpilup c'est vraiment moche et surtout inutile
Oui, mais il cherche (aussi (surtout)) à faire les choses correctement. Enfin je vais le laisser répondre pour lui-même.
GoldenCrystal (./96) :
Il mésestime que dalle. Il y a certainement très peu d'OS où sleep n'est pas implémenté avec un appel système.
mésestime == sous estime, tu as mal compris,
Non, j'avais parfaitement compris… C'est ta réponse là que je comprends pas.
Zerosquare te dit sleep = context switch, tu dis qu'il sous-estime le système, je te dis qu'il sous-estime que dalle.
et si justement sleep ne fait pas des nop et appelle le système
Rassures-moi, tu n'en as jamais douté ?
fasse tourner le code moins vite
"lol"
Tu attribuais du crédit aux boucles for vides pour assurer le timing des très vieux jeux aussi ?
en donnant du temps à d'autre processus éventuellement plus critique
Les processus plus critiques ont une priorité plus haute, ils ont pas besoin de ça
GoldenCrystal (./96) :
Enfin, soyons clair, si tu fais tourner en arrière plan un programme à base de sleep() sur ton iPhone ou tel Android, tu vas ruiner la batterie en deux temps trois mouvements.
Il y a des primitives de synchronisation bien plus efficaces (mais nécessairement plus couteuses en mémoire… par rapport au cout "zéro" du sleep) qui te permettent réellement de ne rien exécuter quand tu as besoin de ne rien exécuter 
J'espère que tu comprends la différence entre "attendre jusqu'à ce que x se produise" et "vérifier si x s'est produit; si non, attendre minimum x millisecondes puis recommencer" Dans le premier cas, ton thread est inactif et ne consomme pas de CPU, alors que dans l'autre il est (fréquemment) actif et consomme du cpu.
pourquoi un sleep boufferais la batterie ? le proc tombe à 0% si ca bouffe la batterie, c'est vers windows qu'il faut se tourner pour des explications
Pourquoi "pourquoi
un sleep" ?
Serait-on passé des boucles d'attente basées sur sleep à uniquement la fonction sleep ? Essaye de rester un peu sérieux stp.
La fonction sleep est très bien, elle fait boulot. Comme son boulot c'est de faire à peu près son boulot, de la manière la plus efficace possible, y'a aucune explication à demander à Windows où je ne sais quoi, parce que Sleep fait très bien son boulot.
Le fait est que Sleep, comme te l'explique Zerosquare en
./107, implique deux context switch.
On context switch, ce sont des cycles CPU perdus. Par nécessité, mais perdus quand même, c'est pour ça qu'on essaye de n'avoir recours à ces context switch que par réelle nécessité.
Si tu fais plein de Sleep(1) en boucle, ton code va idéalement (en pratique, pas forcément) cramer plein de cycles 1000 fois par seconde. Tu vas sciemment cramer des cycles pour… économiser des cycles.
Alors que tu aurais pu juste économiser des cycles.
ici aussi, nous parlons de code mono thread, pas de sémaphore ou autre, si tu connais un moyen de réduire la vitesse de manière simple ça m'intéresse
Il est bien évident que le système d'évènements de SDL est tout sauf single-threaded. D'ailleurs, tout système de passage de message est tout sauf-single threaded. L'intérêt même du passage de messages est de synchroniser et/ou coordonner différents threads entre eux. (NB : pas forcément des threads du même processus)
Comme tu l'as fait remarquer, d'autres programmes "tournent" sur le PC. Multithread ou pas, eux ont trouvé un moyen de ne rien faire du tout de manière plus efficace qu'avec un sleep. Pourquoi ne pourrais-tu pas en faire de même ?
Typiquement, s'il existe un truc que tu peux attendre, alors attend ce truc (pas avec un sleep !), sinon c'est que tu ne dois pas attendre. Si tu veux malgré tout temporiser, alors "temporise" (avec un sleep)…
Dans un jeu y'a bien un truc que tu peux attendre, c'est la synchronisation verticale… DirectX te le propose par exemple. SDL le fait (à priori) tout seul dans ton dos s'il le peut.
Sinon, typiquement, dans l'implémentation de SDL_WaitEvent, qui est
le vrai problème dont on parle à la base, ce qu'il est sensé faire c'est attendre l'arrivée d'un message. Protocole qu'il respecte à peu près extérieurement, mais pas réellement quand on regarde le code utilisé.
Et pour attendre un message, il suffit d'attendre qu'un message soit inséré, ce qui ne consomme pas de CPU. Dans Windows, y'a des objets "Event" qui permettent ça pour toi.
Quand tu attends un message, tu attends sur l'objet évent.
Quand tu insères un message, tu signales l'évènement. Ce qui a pour condition de débloquer celui qui attendait. Et paf…
Dans SDL, l'équivalent a l'air d'être géré par SDL_cond, en espérant que ce ne soit pas implémenté avec Sleep sous Windows, mais quoi qu'il en soit, SQL_WaitEvent aurait pu s'en servir.
peut être veut tu parler sous windows de la fonctionLRESULT CALLBACK WndProc(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam) ?
Non, pas du tout
quant ma lib n'utilise pas sdl elle à son point d'entrée la dedans pour la vérification des messages, les traites et éventuellement si ceux si sont définis lance les callbacks vers les fonctions onClick onMove etcc'est très puissant et évite une vérification perpétuelle, d’ailleurs je ne comprend pas que sdl ne propose pas d'office la même chose :- /
Je comprends pas que tu ne comprennes pas que SDL te propose (conceptuellement) la même chose avec son système d'évènements… C'est juste que Windows est un peu plus complet / complexe à ce niveau. (Heureusement, d'un autre côté)
Si tu veux déplacer le code de gestion d'un évènement SDL (le switch) dans sa fonction propre (ce qui serait très sage) alors rien ne t'empêche de le faire
Godzil (./110) :
Heu "tu n'en fait pas tant qu'il ne se passe rien" ? Heu si, si tu pars en attente d'un evenement du kernel, il va mettre ton process/thread dans la liste des taches inactive et donner la main a une autre tache, donc un joli context switch.
Je vais préciser ce que disait Zerosquare : À part les context switch initial et final, tu ne fais pas de context switch vers ou à partir de ton programme tant qu'il ne se passe rien, contrairement au sleep où tu va faire potentiellement plein de context switch alors qu'il ne se passe rien dans ton programme.
C'est mieux ?
Apres si ton programme doit fonctionner a une fréquence précise (prendre le cas d'un émulateur par exemple) tu n'a pas 36 méthodes pour fixer la fréquence, a pars des sleep ou des boucles, autant prendre un sleep qui sera un peu moins méchant sur le CPU.
Yep, j'avais fait ça aussi
Un petit Sleep à durée variable + attente active de ~1ms pour complémenter le tout et synchroniser à 60 FPS
), et essayer de traiter les évènements quand on a le temps ?
), m'enfin dans la boucle principale du programme, ça pue un peu, quoi...) 
ça reste tout à fait dans le contrat de sleep pourtant, et ça collerait malgré tout très bien à la plupart des cas où tu attends un truc qui va se produire bientôt.
Mais avant ça, ton clavier risque de se péter 
Folco 
)