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
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
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 )
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
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??
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
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
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 )
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
(fais attention qu'il peut aussi y avoir des différences entre les versions debug et release )
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager