Libérer le processeur

[brossden]

Bonjour à tous !
Comment libéré le processeur durant une temporisation assez longue.

Tu dois logiquement exécuter ta procédure longue dans un thread ou ajouter un delay dans ta boucle..
Sans plus de code on peut pas trop être précis dans la réponse.

[brossden]

J'ai testé cela mais 12% du processeur est occupé !
sous Windev par exemple il suffit de mettre :
multitache(-3600) // pour libérer le processeur pendant 36 secondes ! Le signe négatif est là pour ne pas bloquer l'attente!

[Marc56]

Comment libéré le processeur durant une temporisation assez longue.

Penser à utiliser WaitWindowEvent() et pas WindowEvent()
Ajouter quelques ms dans WaitWindowEvent(10) suffit aussi à relacher le système.
Parfois un Delay(100) dans la boucle principale est nécessaire.
Mais si tu veux que ton application "dorme" pendant un certain temps, le mieux est de mettre un timer
Voir: AddWindowTimer()
Si tu ne dis pas ce que fait ton programme, difficile de te conseiller une solution.

[brossden]

Je vais tester cela et merci pour l'aide !

[Ollivier]

Salut Denis,

c'est un peu la rencontre du 3ième type, le départ de ton sujet ! Mais la question mérite encore et toujours d'être posée.

Car, justement un des atouts de PB c'est d'avoir un excellent contrôle du processeur assez facilement.

On a donc Delay(xEnMillisecondes) qui vient théoriquement "libérer" le processeur, c'est-à-dire rendre la main à l'OS (Windows, Linux, ou Mac).

Qu'est-ce que ça fait de libérer le CPU? Déjà, ça évite que le ventilo se déclenche, donc ça fait moins de bruit (le bruit du ventilo me parasite beaucoup, personnellement...). Ensuite, ça économise en batterie, si on est sur un ordinateur portable non branché. Enfin, ça permet à l'OS de triturer sa mémoire, activité qu'on ne peut absolument pas contrôler, et que, l'OS adore faire : trier son souc, virer des morceaux de mémoire préalablement déclarés supprimés, enregistrer sur disque (ou SSD) des blocs mémoire trop rarement utilisés pour rester occuper de la RAM, etc...

Voilà, et tout ça, on l' <<autorise>> grâce à l'instruction Delay(DuréeEnMillisecondes).

Quelques points importants :

1) il n'y a pas meilleur programmeur (et ce n'est pas mon cas !) que celui qui teste et mesure les différentes réactions possibles de l'instruction Delay() selon le type d'OS en fonctionnement. En effet, Windows et Linux ne réagissent pas pareil : Windows, si nécessaire, dès lors qu'on lui offre une milliseconde de répis, avec un Delay(1), peut très bien s'octroyer le CPU par paquet de 16 millisecondes. C'est son truc. Du moins, ça l'a été pendant longtemps, si ça ne l'est plus ! À côté de Windows, Linux, si tu lui offre une milliseconde, il semble qu'il te prend cette millisecondes, si besoin, et pas plus.

Conséquence : Windows et Linux vont avoir deux comportements différents, sauf si on contraint Linux à la même sauce que Windows avec des Delay() calibrés sur des multiples de 15 à 16 millisecondes. (15, 33, 45, etc...)


2) Mais ça, c'est sur les bécanes qui n'ont qu'un CPU donc les anciennes bécanes. Linux a pris de l'avance sur Windows (qui s'est peut-être rattrapé à ce sujet, je l'ignore...) en redonnant la main immédiatement au programme si un CPU est libre. On lui offre une millisecondes (avec Delay(1) ) et Linux refuse cette offre s'il voit un ou plusieurs CPU de libre : la milliseconde c'était pour le CPU saturé. Donc, on se retrouve théoriquement à devoir compter les CPUs et devoir exécuter autant de Delay(1) qu'il n'y a de CPU libres. (Je fais un peu l'amalgame CPU et coeur...) pour voir sa milliseconde de repos CPU réellement reposer l'électronique. Donc, une vraie boucle d'attente est possiblement nécessaire :

Code : Tout sélectionner

t0 = ElapsedMilliseconds()
Repeat
 Delay(1)
Until ElapsedMilliseconds() > t0 + 1 ; <<< 1 = la vraie milliseconde de repos

3) Enfin, ça rejoint Marc : WaitWindowEvent() agit comme cette boucle, si aucun évènement n'arrive.

4) Pour finir, en mode graphique, FlipBuffers() contient , il me semble, aussi en interne, depuis plusieurs années une telle boucle pour exécuter réellement cette attente.

Voilà les grandes lignes des subtilités pour reposer son processeur central...




Bon courage et excellente prog.


PS : perso, j'ai un mono-processeur mono-core acheté 170 euros chez Aldi en 2020. C'est un portable 12V, donc se branche sur un allume-cigare. Il est tactile comme les Android mais avec un X64 d'Intel et son écran est pliable à 360 degrés, donc j'ai une sorte de grosse tablette tactile, quand il est complètement déplié, et un ordinateur portable, quand l'écran est déplié comme les ordinateurs portables. Effectivement, le temps processeur reste une donnée importante à traiter. Et la démo de pureBasic y défonce les performances calamiteuses de javaScript sur Android. Je suis d'ailleurs très étonné aussi par la vitesse efficace du CPU : c'est 1.1GHz mono-core, et il dégomme par 4 fois un quad core 2.6GHz. Sans parler des chutes de boulet qu'il subit sans broncher : 1m50 sur carrelage ne lui a pas faire peur du tout.

[Edit] Après de succintes recherches, mon petit ordi a quatre coeurs en fait, et sa fréquence d'horloge change selon les besoins demandés et l'alimentation fournie. Pour retomber sur la question du sujet, je me demande si, justement un Delay() n'est pas la seule instruction à utiliser. Exemple : si la temporisation est d'heure, mettre un délai de 3 600 000...

[brossden]

Dédolé mais aucune des solutions ne fonctionnent pas grave je vais faire mon programme en Windev. Merci quand même à tout le monde. Et bise au fétus Kwai chang caine

[Shadow]

Et bise au fétus Kwai chang caine

Heu ça veux dire quoi ça ?
Poste un code au moins !

[Ar-S]

@brossden tu veux faire quoi comme prog ?

[Ollivier]

Dédolé mais aucune des solutions ne fonctionnent pas grave je vais faire mon programme en Windev. Merci quand même à tout le monde. Et bise au fétus Kwai chang caine

Là, tu racontes un mytho de flemmingiteux ! Code qui attend une heure sans bouffer la moindre ressource CPU :

Code : Tout sélectionner

Delay(3600 * 1000)

Donc pose les bonnes questions pour avoir les bonnes réponses. Je me souviens d'un sujet nommé << Afficher l'heure a sonné >> où tu avais pondu une solution et puis tu t'es barré, victorieux. Et tout le monde, dans ce sujet avait validé, et mëme mis à jour ton code.

Pour ma part, je trouvais ton code court effectivement. Mais mon code, ma solution était celle qui bouffait le moins de ressources. C'était plus long, j'avais réinventé la roue, mais au moins le contrôle des ressources CPU était bien géré. De mémoire, j'avais même refait les requesters parce qu'ils n'étaient pas threadables.

Remate ce sujet. Cette mécanique du temps CPU y est explicite. Explique au moins qu'est-ce que tu compares en terme de critère avec Windev.

Pour info, dans le sujet sur les alarmes :
Message du 22/02/2009 22H51 = code
Message du 26/02/2009 00H14 = documentation du code

13 ans plus tard, à part quelques détails à mettre à jour, je peux dormir tranquille concernant le temps CPU utilisé.

J'attends (et je ne suis pas le seul) quelques précisions de ton problème actuel.

[microdevweb]

Voici une exemple : Et croi moi je connais WIndev, il est netement plus lent et grourmand que Pb

Code : Tout sélectionner

Global counter = 0
Global IdThread = 0
Procedure Exit()
  If IsThread(IdThread)
    KillThread(IdThread)
  EndIf
  MessageRequester("Test","Counter value "+Str(counter))
  End
EndProcedure
Procedure Open()
  OpenWindow(0,0,0,100,100,"Thread",#PB_Window_ScreenCentered)
  ButtonGadget(0,10,10,110,80,"Exit")
  BindGadgetEvent(0,@Exit())
EndProcedure

Procedure THR_Loop(*parameters)
  Repeat 
    counter +1;
    Delay(1)
  ForEver
EndProcedure

IdThread = CreateThread(@THR_Loop(),0)

Open()

Repeat : WaitWindowEvent() : ForEver

[Ollivier]

Forcément brossden est tombé sur un truc qui l'a fait hurler, et flipper.

Je me demande si ce n'est pas le DPI aware : il n'était pas là pendant la période où ça a été intégré.

[case]

Code : Tout sélectionner

multitache(-3600)

Ça ressemble pas mal a

Code : Tout sélectionner

waitwindowevent(3600)

le prog vas attendre 36 secondes a moins d'avoir un évenement sur sa fenêtre.
a condition d'utiliser une fenêtre et pas une console ni un screen bien sur...

normalement le processeur ne devrais pas s'exciter a lancer en mode debugger pour avoir la sortie text

Code : Tout sélectionner

main=OpenWindow(#PB_Any,0,0,640,480,"test waitwindowevent")
Repeat
  t=ElapsedMilliseconds()
  ev=WaitWindowEvent(3600)
  If ev
    Debug "un evenement a eu lieu apres "+Str(ElapsedMilliseconds()-t)
  Else
    Debug "pas d'evenements le programme a attendu "+Str(ElapsedMilliseconds()-t)
  EndIf
  
  
  
Until ev=#PB_Event_CloseWindow

  

[brossden]

Le processeur reste en 10 et 12% occupé.
Mais ce n'est pas grave j'ai développé mon code en Windev !

Merci beaucoup pour ton aide et le temps passé !

[brossden]

J'ai trouvé la solution

Mon programme contenait une procédure assez longue et je ne sais pas pourquoi je temps d'attente entre deux lancement de cette procédure maintenait le processeur en activité.
J'ai créer une DLL qui contient cette procédure et la tempo se trouve dans uns programme qui lance la DLL à chaque fin de tempo.
Cela marche parfaitement !
Processeur 0% pour un I7 huit cœurs 3.5 Ghz
Merci encore à tous ceux qui on essayé de me venir en aide !

Bonne journée à tous !