Le point sur Delay(), WindowEvent() et l'usage CPU à 100%

[crisot]

J'ouvre ce petit topic pour apporter des éclaircissements sur un problème de compréhension qui revient continuellement sur ce forum. L'occupation du CPU à 100%, et l'utilisation de Delay() avec les WindowEvent().

Le topic de SPH étant devenu assez "lourd", je vais prendre pour exemple le topic Attention à WindowEvent de notre ami MicroDevWeb.

Dans ce topic, on peut lire ceci:

Lorsque l'on développe un jeux par exemple, on évite le WaitWindowEvent() qui bloque la boucle jusqu'au retour d'un événement Window

Code : Tout sélectionner

OpenWindow(0,0,0,800,600,"tetes",#PB_Window_SystemMenu)
Repeat
      Repeat
            Event=WindowEvent()
            If Event=#PB_Event_CloseWindow
                  End
            EndIf
      Until Event=0
      ;Traitement du jeux
ForEver 

Si vous lancez ce code (qui ne fait absolument rien) et que vous ouvrer (CTRL+ALT+Delete) votre gestionnaire de tache (window) aller sur l'onglet Processus et chercher Purebasic_compilation.... vous verrez que dans "Processeur" votre processeur est occupé (chez moi du moins) à 25%.

Ce code occupe le CPU à 100% (un core à 100% = 25% d'un quad-core), ce qui semble un gouffre à CPU pour tout le monde, et anormal...

Pourtant... Occuper le CPU à 100%, c'est TRES EXACTEMENT ce que DEMANDE le programme tapé ci dessus. VOUS avez demandé à ce que l'ordinateur bloque le CPU à 100%. Pourquoi ça? Tout l'amalgame vient de la parenté de WindowsEvent() avec WaitWindowsEvent(). WaitWindowsEvent() ATTENDS qu'il se passe quelque chose pour continuer. Tant qu'il ne se passe rien, le programme attend, et le CPU reste à 0%. Mais comme le dit MicroDevWeb, ce n'est pas possible pour un jeu, on ne doit pas bloquer le code.

Ce code ne fait pas absolument rien. Au contraire, WindowEvent() regarde si il se passe quelque chose dans la fenêtre, en boucle, et le plus rapidement possible, des milliers de fois par seconde, si il se passe quelque chose. Ca veut par définition dire en bloquant le CPU à 100%.

Voici donc la solution proposée par notre ami:

Code : Tout sélectionner

OpenWindow(0,0,0,800,600,"tetes",#PB_Window_SystemMenu)
Repeat
      Delay(1)
      Repeat
            Event=WindowEvent()
            If Event=#PB_Event_CloseWindow
                  End
            EndIf
      Until Event=0
      ;Traitement du jeux
ForEver 

Et là, la magie opère, la charge CPU tombe à 0%. Le delay(1) est donc indispensable. Incroyable!

Maintenant, essayons de benchmarker ces 2 programmes. C'est vrai, Delay(1), c'est le plus petit Delay() qu'on puisse ajouter, ça ne doit pas être beaucoup plus lent. Voici un petit programme qui exécute chacun de ces 2 programmes 10 secondes, et compare leur rapidité.

Code : Tout sélectionner

OpenWindow(0,0,0,800,600,"tetes",#PB_Window_SystemMenu)

;boucle sans Delay()
count1=0
starttime=ElapsedMilliseconds()
While ElapsedMilliseconds()-starttime<10000
	Repeat
		Event=WindowEvent()
		If Event=#PB_Event_CloseWindow
        	End
		EndIf
	Until Event=0
	;Traitement du jeux
	count1+1      
Wend
	
;boucle avec Delay(1)
count2=0
starttime=ElapsedMilliseconds()
While ElapsedMilliseconds()-starttime<10000
	Delay(1)
	Repeat
		Event=WindowEvent()
		If Event=#PB_Event_CloseWindow
			End
		EndIf
	Until Event=0
	;Traitement du jeux
	count2+1      
Wend
	
MessageRequester("", "la première boucle s'est exécutée "+Str(count1)+" fois en 10 secondes")
MessageRequester("", "la deuxième boucle s'est exécutée "+Str(count2)+" fois en 10 secondes")
MessageRequester("", "la première boucle est "+Str(count1/count2)+" fois plus rapide que la deuxième")

A la fin, la vitesse des 2 boucles est comparée, et voici les messages que j'obtiens sur mon portable:

"la première boucle s'est exécutée 42495326 fois en 10 secondes"
"la deuxième boucle s'est exécutée 9983 fois en 10 secondes"
"la première boucle est 4256 fois plus rapide que la deuxième"

HEIN? 4256 fois pour un simple Delay(1) qui est le plus petit Delay() possible? Mais comment est-ce possible?

C'est simple. Delay(1) attends 1 milliseconde. A chaque fois que votre boucle principale recommence, votre ordinateur attendra 1/1000 de seconde, pendant lequel il ne fera RIEN.

Vous noterez un deuxième souci si vous lancez ce programme chez vous. Votre première valeur est sans doute très différente de la mienne, mais pour la seconde, vous aurez aussi à peine moins de 10.000. Que vous ayez un Pentium, un i3, un i7, vous aurez TOUS à peu prêt 10.000. Le Delay(1) rend notre programme incapable de tirer parti de la puissance de différents PC. C'est parce que le Delay(1), en attendant 1/1000 de seconde, limite l'exécution de la boucle à 1000 fois pas seconde.

Les plus incisif me feront remarquer que de toute façon, pour la boucle de notre ami MicroDevWeb, les résultats restent de toute façon bien assez rapide, et ils auront raison. Maintenant, puisque MicroDevWeb parle de jeu, prenons cet exemple:

Un jeu, c'est idéalement 60 images par seconde. Donc, on va partir du principe que notre boucle principale va s'exécuter 60 fois par seconde. La encore les gens incisifs me diront la chose suivante:

"Si le Delay(1) limite la boucle principale à un maximum de 1000 fois par seconde, alors ce n'est pas grave, car 1000 fois c'est bien assez pour un programme qui a besoin de 60 fois par seconde".

Oui. Mais non. Pour que votre jeu fonctionne à 60 images par seconde, il faut donc que votre ordinateur calcule chaque image en 1000/60 = 16.6 millisecondes. Sur ces 16.6ms disponibles, votre Delay(1) consomme déjà 1ms. Il ne reste à votre ordinateur que 15.6ms. Si vous avez un ordinateur très rapide, ce ne sera pas un problème.

Mais imaginons que votre ordinateur soit lent ou le jeu complexe. Imaginons que vous ayez un ordinateur qui a besoin de 16.5ms pour calculer une image, soit prêt de 100% de sa puissance! Que va t'il se passer? Après 16.5ms de calcul, Delay(1) va venir ajouter 1ms d'ATTENTE supplémentaire! Au final, votre boucle aura mis 17.5ms à s'exécuter! Que va t'on constater?:

-Le jeu ne fonctionnera plus à 60 images par secondes. Il va commencer à saccader.
-Paradoxalement, votre CPU ne montera pas à 100%!!! Car le Delay(1) va lui laisser du temps de repos!

Vous avez donc un ordinateur qui ne fonctionne pas à 100%, et un jeu qui pourtant saccade. Quel paradoxe...

Et encore! Dans l'exemple de notre ami MicroDevWeb, le Delay() n'est que de 1, et il est juste après le premier repeat. Sur d'autre topic, certains conseillent de mettre des Delay() supérieur, 2... 4... 16!!! et les mettent carrément dans la deuxième boucle! Voyons ça.

Dans le topic #WM_centreBUTTONDOWN ? notre ami Ollivier suggère d'utiliser ceci:

Code : Tout sélectionner

Repeat

   Repeat
      Ev = WindowEvent()
      If Ev
         Delay(16)
         ; Traitement évènement
      Endif
   Until Not Ev

Until Quit

Dois je vous expliquer le problème? Ce qui est particulièrement intéressant, c'est que notre ami met un Delay(16). Pile poil le temps nécessaire au calcul d'une image! Mieux encore, c'est un Delay(16) pour CHAQUE événement! Déplacez la souris, faites un clic et tournez la molette, et ce sont 48 ms que le processeur passe à dormir. 3 images! Et vous n'avez même pas encore commencé à calculer votre image....

Alors que faire pour n'être ni bloqué à 100%, ni perdre en performances?

La théorie est simple. La pratique encore plus grâce à PureBasic.

La théorie, c'est qu'on doit arrêter son CPU pour un temps variable et adapté à ses besoins. On ne doit surtout pas mettre un Delay(). Delay() est invariable! Il ralentira votre programme même si celui-ci est déjà trop lent! Et rassurez vous, pour celà, votre Os et PureBasic sont merveilleusement bien fichus!

Pour votre jeu, tout tiens dans FlipBuffers(). FlipBuffers() est une fonction extrêmement intelligente qui ne s'exécute pas plus de 60 fois par secondes, en se synchronisant avec votre écran. Ainsi donc, sans rentrer dans les détails techniques, FlipBuffers() s'adaptera au temps de calcul de votre image et fera en quelque sorte un "delay" automatiquement adapté!

Si votre image à pris 3ms à être calculée, FlipBuffers() fera virtuellement un "Delay(13.6)". Si votre image à nécessité 15.8 de calcul, alors FlipBuffers() remplira le rôle d'un "Delay(0. 8 )". Et votre jeu tournera TOUJOURS à 60 fps, et votre charge CPU ira parfaitement de 0% à 100% en fonction de la complexité de votre jeu.

Notre ami MicroDevWeb n'avait qu'à transformer son code ainsi pour régler efficacement son problème:

Code : Tout sélectionner

InitSprite()
OpenWindow(0,0,0,800,600,"tetes",#PB_Window_SystemMenu)
OpenWindowedScreen (WindowID(0) ,0 , 0, WindowWidth(0), WindowHeight(0),0, 0, 0, #PB_Screen_WaitSynchronization)
Repeat
      Repeat
            Event=WindowEvent()
            If Event=#PB_Event_CloseWindow
                  End
            EndIf
      Until Event=0
      ;Traitement du jeux
      FlipBuffers()
ForEver 

Car oui, un FlipBuffers() nécessite un Screen. Si vous souhaitez travailler dans une fenêtre, vous devrez tout de même créer un OpenWindowedScreen(). Ce genre de "contrainte" est directement lié aux fonctionnement des systèmes d'exploitation. Windows, Linux, AmigaOs...
Et de toute façon, dans 99% des jeux, vous aurez besoin d'un FlipBuffers()

Si votre application n'est pas un jeu, mais par exemple une interface graphique où rien ne se passe tant que vous ne faites rien, alors il faut sans hésiter revenir à WaitWindowEvent() qui se chargement de mettre votre programme en pause.

La règle générale

On ne Delay() JAMAIS, JAMAIS, JAMAIS un programme. On doit trouver le moyen de l'arrêter temporairement tout en pouvant le reprendre INSTANTANEMENT lorsqu'il le faut. Delay() ne répond pas à ce deuxième critère.

Si vous êtes confrontés à un programme qui vous semble charger votre CPU à 100% inutilement, il ne faut PAS mettre de Delay(), il vous faut trouver un moyen de mettre intelligement votre programme en attente. FlipBuffers() et WaitWindowsEvent() résoudront 99% des problèmes des gens, mais les Os disposent de très nombreuses fonctions vouées à ce but!

L'argument du Delay() pour le multitâche

On s'en fout, on s'en fout, et ON S'EN FOUT! C'est le problème de l'Os! Les Os sont suffisement évolués pour répartir à 50/50 deux tâches consommant 100% du CPU! On ne peut PAS limiter les performances de son application pour un éventuel multitâche alors qu'elle sera la plupart du temps la seule à fonctionner! Et de toute façon, sâchez que le Delay() n'aidera pas l'Os pour un sous, mais je n'ai ni l'envie ni le temps de vous expliquer pourquoi! Et c'est parce que vous n'avez pas envie de vous emmerder avec ces détails techniques que vous codez en Basic!

Pas de Delay() pour le multitâche! Point!

J'invite les derniers septiques à me mettre des exemples de code fonctionnels où un delay() seront parfaitement obligatoire, et nous verront ce qu'il y a à en dire...

Merci de m'avoir lu

[Fred]

Beau post, juste en plus

[MLD]

@ crisot

+10

[crisot]

ce qui fait que tes exemples marchent, c'est l'emploi de la double boucle Repeat
on en a deja parlé ici !

Je ne comprend pas le problème que pause le fait d'imbriquer deux repeat? C'est comme imbriquer 2 for, 2 if... Il n'y a aucune interdiction à ce sujet.

tu vides la liste des event ...
alors que si on emploi pas cette "artifice"

"Artifice"? C'est une "nécessité". Si tu retires la boucle, tu ne traites qu'un seul Event par boucle principale. Si sur ton jeu X event souris arrivent en même temps, ils seront traités en différés entre chaque image. Tu ne traitera jamais en même temps plusieurs events qui t'ont pourtant été envoyé en même temps par l'Os. A l'extrême, il deviendrait même possible que la liste grossisse plus vite que le programme ne la vide (même si c'est humainement très compliqué).

, l'emploi du Delay () est obligatoire, comme le pinard !

Je ne comprend pas pourquoi. Vire mon deuxième Repeat si cela te fait plaisir, ça ne provoquera que le mini défaut dont je parle ci dessus. Le programme fonctionnera toujours parfaitement bien.

il faudrai dans l'ideal avoir une fonction qui rend la mains au systeme (et vide la pile des events) et qui ne soit pas un Delay() .....

Hein??? Mais si une telle instruction existait, elle te passerait aussi à la trappe les Event dont tu as besoin. Alors tu va me dire que ça existe en VB, mais comment m'expliques tu le fait que ça n'existe pas en C/C++? Les Events, ce sont TES outils, à toi de les traiter... ou de les ignorer!

Il y a une très grosse lacune de compréhension pour le coup mon cher Spock.

[G-Rom]

Dobro, il faut TOUJOURS vidé les événements avant de faire autre chose , la façon que tu avait de faire n'étais PAS BONNE !
regarde ce qui ce fait ailleurs par exemple :

http://www.sfml-dev.org/tutorials/2.3/w ... nts-fr.php
https://wiki.libsdl.org/SDL_Event

on vois bien SYSTÉMATIQUEMENT while( event ... )
il ne sagit donc pas d'artifice , mais de réalité , la plupart des codes ici ne l'utilise pas par mauvaise habitude.

Code : Tout sélectionner

 l'emploi du Delay () est obligatoire, comme le pinard !

Je crois qu'il va falloir que l'on te donne une dérogation pour que t'arrête un peu le jaja...

[crisot]

non, encore une fois , "artifice" est la forme ! je trouve debile d'avoir a utiliser deux repeat imbriqué...

C'est parce que l'exemple est tout petit. Le premier repeat c'est la boucle principale de ton application, ça pourrait être un Do, un While, peu importe. L'autre repeat c'est juste une petite boucle, ici elle vide les events, mais on a tous dans nos code des petites boucles au milieu de grandes boucles.

Tu pourrais très bien avoir 80000 lignes de code entre les 2 repeats.

d'ailleurs, il me semble avoir démontrer qu'on pouvais se passer de 2 boucles en utilisant WaitWindowsEvent(TIMER) << tu ne traite pas de cette fonction, c'est bizarre
pour etre exhaustif , il faut expliquer pourquoi cette fonctionnalité existe !
elle represente au finale un WindowsEvent + un delay() ... mais alors ... mais alors , pourquoi donc avoir mis cette possibilité, si d'apres tes explications validées par le grand manitou , il n'en est point besoin ???

Ton WaitWindowsEvent(TIMER):

- Il ne VIDE PAS la totalité des Event, ce qui est une nécéssité! Bref, il ne remplace PAS la boucle.
- Il créé un Delay(), avec tous les défauts expliqué dans le premier post.

Et je suppose qu'il ne fait PAS l'équivalent d'un WindowEvent() suivi d'un Delay().

-WindowEvent() : Delay(10) regarde si il y a DEJA eu un -Event, puis attend 10.
-WaitWindowEvent(10) observent aussi les événements qui peuvent survenir PENDANT les 10ms.

si le Delay() n'as pas d'obligation .. alors la Doc se trompe !
encore une fois "Faudrai Savoir"

La doc est là pour expliquer l'utilisation d'une fonction. Ici le Delay() est le seul moyen de ne pas charger le CPU à 100% et limiter l'affichage, sans avoir à expliquer tout ce qui est nécessaire au retrait du Delay() dans cet exemple. La doc n'est pas un cours de programmation.

La doc d'un langage et l'apprentissage de la programmation sont 2 démarches distinctes.

-La doc t'apprend à utiliser WindowEvent(), ses entrée, ses sorties.
-Je (mais aussi plein de gens hyper doués sur internet!) t'explique humblement comment le mettre dans un programme propre et performant sans utiliser Delay().

2 démarches, en 2 temps!

Code : Tout sélectionner

ben non , car si tu utilises cette fonction "DOEVENT()" c'est parceque dans ton code, tu sais que tu peux le faire !
donc pas de Trappe dans cette histoire ...  :roll:

PureBasic est un langage de plus bas niveau et n'a pas de telle fonction. Les langages de très haut niveau ne font automatiquement que des choses que tu programmes toi même dans les langage bas niveau -> en l'occurrence, DoEvent() fait sans aucun doute cette boucle repeat qui fait débat.

Mais ce serait bien de s'en tenir à PB.

[Ollivier]

@Crisot

Code : Tout sélectionner

Delay(0) ; sale...perte de temps...jamais...interdit
InstructionInstantT
InstructionInstantTPlusDelta1
InstructionInstantTPlusDelta1PlusDelta2
Etc...

[falsam]

L'argument du Delay() pour le multitâche, On s'en fout, on s'en fout, et ON S'EN FOUT! C'est le problème de l'Os!

On en a parlé encore hier soir, et je ne peux que te rejoindre.

Je n'emploie jamais de Delay(). J'ai fait suffisamment de test avec des codes volontairement lourd pour le confirmer.

Dobro, il faut TOUJOURS vidé les événements avant de faire autre chose , la façon que tu avait de faire n'étais PAS BONNE !

Ca me rappelle de longues discussions sur ce sujet. Oui Dobro (Spock) tu as tord de procéder de cette maniere .... Nahhhhh pouet

PS: Oui je me la ramène telle la fouine doublée d'une hyènne rieuse

https://www.youtube.com/watch?v=fnAYxUqT8Uk

[Ollivier]

@Crisot

Je n'ai pas vérifié si FlipBuffers() permettait de faire l'équivalent à ce code plus haut.

Je te déroule le tapis rouge pour vérifier!

[blendman]

Je suis d'accord avec la généralité, mais il peut y avoir des cas de figures où on utilise un FlipBuffers() (mais pas à toutes les frames) avec un waitwindowevent(1).

Par exemple, sur Animatoon (mon soft 2D), j'utilise un screen que je n'update (FlipBuffers()) qu'après certaines actions (quand je dessine sur le screen) et sous une condition (update temps réel).
Je suis obligé d'avoir un waitwindowevent(1) plutôt qu'un windowevent(), sinon, j'ai le cpu à 50%, sauf lorsque le FlipBuffers() est utilisé.
Il est possible que mon code soit à revoir, mais malgré tous mes tests, c'est la méthode la plus rapide et la moins consommatrice de cpu que j'ai trouvée jusque maintenant ^^.

Par exemple, lorsque je dessine sur le screen sans l'effacer, c'est plus rapide que de dessiner sur un sprite et de mettre à jour le screen ensuite. C'est assez logique ^^.

[Ollivier]

@Blendman

Tu peux mettre

(a)
Delay(1)
Ev = WindowEvent()

ou

(b)
Ev = WindowEvent()
Delay(1)

(c)
à la place de WaitWindowEvent(1)

a) Attend 1ms, puis interroge la queue.
b) Interroge la queue, puis attend 1 ms.
c) Attend 1ms OU un évènement de la queue.

[crisot]

@Crisot

Je n'ai pas vérifié si FlipBuffers() permettait de faire l'équivalent à ce code plus haut.

Je te déroule le tapis rouge pour vérifier!

Je ne comprend pas bien le sens du code plus haut. ??? Eclaires moi?

[nico]

Je ne fais pas de jeux, voici une proposition, je ne sais pas si elle est viable; cela permet de maintenir un nombre de frames par seconde et de décider ce que l'on va faire si l'ordi n'est pas assez puissant.

Code : Tout sélectionner

Global ReferenceTemps.l = 33

If OpenWindow(0,0,0,800,600,"tetes",#PB_Window_SystemMenu)
  
  Repeat
    TempsDepart.l = ElapsedMilliseconds()
    
    Repeat
      Event=WindowEvent()
      If Event=#PB_Event_CloseWindow
        End
      EndIf
    Until Event=0
    
    
    ;Traitement du jeux
    
    
    ; --------- Maintient le nombre de frames ------------
    TempsEcoule.l = ElapsedMilliseconds()-TempsDepart
    temps.l = ReferenceTemps - TempsEcoule 
    
    If Temps >= ReferenceTemps
      ; Config machine insuffisante!
      ; ici on peut faire un traitement plus profond afin de déterminer
      ; si le jeu est encore jouable en fonction de la valeur de temps
      ; ou bien baisser la charge de travail si possible
      Delay(1)
    Else
      ; si on est là tout va bien
      Delay(ReferenceTemps - Temps)
    EndIf 
    ; ------------------------------------------------------
  ForEver
  
EndIf 

[crisot]

nico: C'est une solution pas con à laquelle j'avais pensé aussi effectivement. Définir un "temps de référence", et, en fonction du temps mesuré, mettre un delay adapté. Ca manque un peu de précision vu que Delay() travaille en millième de secondes, mais ça a le mérite d'être simple à mettre en place.

La seule différence avec ton exemple c'est que je n'hésiterais pas à aller jusqu'à la suppression totale du Delay(), plutot qu'un Delay(1) obligatoire.

[nico]

Je ne comprend pas trop ce que tu avances, les moniteurs actuels font 60 Hertz, soit 60 frames par secondes max au niveau de l'écran ce qui fait une image tous les 16.66 ms, alors où est le problème que le calcul se fasse au millième soit plus ou moins 1ms donne 15 ou 17.

Je ne sais pas ce que donnes les jeux créés avec PureBasic sur une machine de config de test de base, je ne pense pas qu'on atteigne un débit constant de 60fps, si c'est le cas, c'est vraiment cool.

Le delay(1) n'a été mis que pour éviter une surcharge du proc mais comme je l'ai écrit, le jeu devrait s'arrêter là ou alors si le jeu le permet descendre la résolution pour abaisser la charge de traitement afin d'être que très rarement dans cette zone de traitement, on pourrait rajouter des counts pour le vérifier car la charge du CPU ne sera jamais constante.