Version imprimable
Salut,
Quel est le temps d'exécution du programme en c sous C:B?
Il m'affiche s deux durée différentes pour le meme programme! La quelle qui correspond au CPU?
Merci
http://i85.servimg.com/u/f85/14/25/90/60/cpu10.jpg
http://i85.servimg.com/u/f85/14/25/90/60/cpu110.jpg
Salut,
Le temps "réel" de l'exécution du programme est donnée par le programme lui-même (c'est donc la valeur obtenue dans la console qui importe ici :D)
Le temps indiqué par code::blocks représente le temps pendant lequel console_runner a été actif, c'est à dire, jusqu'à l'appui sur une touche qui a provoqué sa fermeture.
Ainsi, si tu teste une application sous code::blocks et qu'elle s'effectue en deux secondes, mais que tu t'écarte de l'ordinateur pendant une demi-heure, tu verra un message de la console te demandant d'appuyer sur une touche pour terminer.
cet appui provoquera la fin du console_runner et le temps indiqué par C::B sera... d'une demi heure :D
Merci pour ces explications!
Ainsi, pourquoi à chaque fois, pour le meme programme, je clique sur l'onglet build and run, le temps d'exécution calculé par la fonction clock change?
Quel est le temps d'exécution à prendre dans ce cas?
Des explications??
33 lectures et personne pourrait me répondre!?
:pleure:
Le fait est que le temps réel d'exécution dépend d'une quantité impressionnantes de facteurs, dont l'utilisation du processeur qui est fait par les autres applications (les démons de linux ou les services de windows, par exemple), l'utilisation de la mémoire ou la capacité du système à les différentes données nécessaires à l'application dans une page mémoire unique, et j'en oublie surement.
Bref, tu te rend facilement compte que tu n'a finalement que peu de chances d'arriver à gérer toi-même l'ensemble de ces paramètres :aie:
De plus, la fonction clock() peut être relativement imprécise selon le système sur lequel tu travaille.
Enfin, windows et linux ne sont pas des systèmes dits "en temps réels" (que l'on devrait d'ailleurs nommer "en temps garantis").
Cependant, les temps d'exécutions successives sont relativement stables, à quelques décimales près ;)
L'idéal, si tu as le temps à y consacrer, et si tu veux avoir une estimation la plus précise possible, est donc peut-être de faire exécuter plusieurs fois l'application et de calculer la moyenne des différents temps d'exécution.
Si tu calcules également l'écart type, tu pourra même préciser que si l'application tourne en moins d'un temps donné, elle tournera exceptionnellement vite et que si elle tourne en plus d'un autre temps, elle tournera exceptionnellement lentement :D
Merci cher :roi: koala01 pour cette réponse!Citation:
Envoyé par koala01
Quel est le nombre de de test à faire pour calculer la moyenne des différents temps d'exécution?Citation:
peut-être de faire exécuter plusieurs fois l'application et de calculer la moyenne des différents temps d'exécution.
Par avance, merci.
Comme dans le sketch de je ne sais plus qui, la bonne réponse est "un certain nombre"... (dans le sketch en question, c'était "un certain temps"... mais bon :P)Citation:
Envoyé par laureat
Plus tu aura un nombre élevé de tests, plus tu augmentera la précision de ta moyenne ;)
Pour le reste, je dirais que tout dépend du temps que tu veux bien passer sur tes tests :D
(fais attention qu'il peut aussi y avoir des différences entre les versions debug et release ;))
Merci pour cette réponse!Citation:
Envoyé par koala01
Dans le cas des exercices en classe, est ce que je prends la version debug ou relaese?
Merci encore
Un benchmark se fait toujours en mode release.
La version débug va en effet régulièrement rajouter des information de débuggage, des assertions, des tests en pagaille, quand ce n'est pas purement et simplement supprimer certaines (voire toutes) les optimisations, et tout cela aura un impact très négatif sur les performances réelles :D