Version imprimable
Bonjour.
Y-a-t-il un moyen simple d'afficher le temps d'exécution d'un code en millisecondes :
1) qui soit portable sur les différents OS
2) qui ne produise pas de bug pour une application multithreadée
Si je ne peux pas avoir les 2, quelles est la meilleure façon de procéder en gardant la condition 2 mais pour Windows et Linux (toutes les distribs, pas seulement Ubuntu) séparément ?
Merci beaucoup :ccool:
Je viens de faire un portage, et je peux te dire que non (ou alors je l'ai pas trouvé). Sauf peut-être si sous windows tu te décides à utiliser Cygwin, et sous Linux wine.Citation:
Envoyé par Kaluza
Il me semble qu'il y a des fonctions qui marchent sur les deux OS, mais elles ne font pas la différence entre le temps kernel et le temps utilisateur (et donc renvoient systématiquement la somme des deux).
Salut,
j'avais fait une classe qui fait cela il y a quelques années, je suis au boulot là je posterai le code en fin d'après-midi.
NeoKript
Sinon je peux aussi faire un directive pour le préprocesseur suivant le système d'exploitation...
Dans ce cas, quelle est la méthode Windows et la méthode Linux (qui fonctionne sur toutes les distribs) la plus simple ?
Personnellement j'utilise l'implémentation de la bibliothèque Ogre qui marche très bien et est très précise -- et tu pourras voir quelles fonctions ils utilisent par OS :
- l'interface : https://bitbucket.org/sinbad/ogre/sr...de/OgreTimer.h
- l'implémentation sous Windows : https://bitbucket.org/sinbad/ogre/sr.../OgreTimer.cpp
- l'implémentation sous OSX : https://bitbucket.org/sinbad/ogre/sr.../OgreTimer.cpp
Le code tiens compte des problèmes de synchro multi-core pour la version windows (qui est toujours une horreur a faire correctement, c'estpour ça que j'utilise ce code).
Sinon, officiellement il y a std::chrono qui est dans un future standard (C++2011? je sais plus) et qui sera l'interface standard pour avoir un temps précis.
Il y a une implémentation dans boost (boost::chrono) mais je ne sais pas à quel point elle est complète. Il se peut que tu sois interéssé pour l'implémenter.
Complément d'information : boost::chrono a été accepté dans boost (source : http://lists.boost.org/boost-announce/2011/01/0280.php ).
J'imagine que si les performances sont au rdv, ça sera pas mal. Je le met dans la liste des libs a tester dans mon jeu tiens.
edit> La doc actuelle : http://svn.boost.org/svn/boost/sandb...tml/index.html
Re,
Si tu ne veux pas utiliser de librairie, il faut regarder du côté des structures timeval et __timeb64 avec les fonctions gettimeofday (Unix) et _ftime64_s (Windows)
Voici une implémentation :
www.megaupload.com/?d=XPNYW9W4
Utilisation :
NeoKriptCode:
2
3
4
5
6
7
8
9
leur implémentation ne tient pas un peu du bricolage?Citation:
Envoyé par Klaim
non, tout std::chrono est bien la, y compris les types pour les sous unités de temps.
pardon je parlais de la version de Ogre.
Leur implémentation est très imprécise dans un sens; a chaque fois que tu appelles le chrono il peut rescheduler ton thread sur le core 0 (qui pourrait bien être occuppé). Sachant que le scheduler accorde sous windows un temps de l'ordre de la milliseconde (10s ou 30ms?) la résolution du timer devient carrément pourrie, a moins d'être déjà sur le CPU 0.
A ce niveau la il y a des mesures de temps plus performantes integrées a l'OS.....
ou alors j'ai pas compris le principe?
screetch> C'est le résultat d'une longue experimentation pragmatique qui est la seule stable qu'ils aient pu mettre en place.
Le souci est que contrairement à ce qui est dit, les multicore d'intel (entre autre) vont bien faire sauter le thread d'un coeur à un autre de manière intempestive sur certaines machine, notemment les laptops, et cela va pourrir le calcul du temps parcequ'il est indépendant pour chaque coeur.
Sous windows, pour avior un temps assez précis, il faut utiliser donc QueryPerformanceCounter en combinaisona vec l'autre fonction, et comme il dépends du coeur local, pour éviter d'avoir des sauts dans le temps, il faut impérativement se baser sur un unique coeur.
Cela dit, le code a été mis en place il y a quelques années, quand les bicores se sont démoncratisés et que le code précédent donnait des variations bizarres de performances, voir des blockaques bizarres et longs.
Donc peut être qu'il y a mieu, mais j'avoue que je fais beaucoup confiance aux mecs d'Ogre tout simplement parceque :
1. Ils sont très pragmatiques
2. Si ce code ne marchait pas correctement (perfs vs correctness) ils le verraient rapidement.
Cela dit, une solution à la boost::chrono me semble plus adaptée dans le cas général. L'horloge de performance étant basée sur QueryPerformanceCounter aussi sous winddows, il se peut que le même genre de code soit mis en place dans l'implémentation.
Ca serait cool de comparer, mais j'avoue que je ne connais pas tous les détails et trucs àà savoir poru confoutrner les problèmes des fonctions de Windows...
de un leur code est copié collé pour les millisecondes et les microsecondes et ca c'est bof bof (je vois bien un
)Code:inline unsigned long Timer::getMilliseconds() { return getMicroseconds() / 1000; }
et je dirais "comme quoi tout ce qui sort de ogre n'est pas béni", dans un code aussi grand il y a forcément du code caca.
(le time slice sous windows est de 30 millisecondes quad même, autat utiliser une méthode dont la résolution est de l'ordre de lam illisecondes si c'est pour avoir cette imprécision)
Je ne saurais pas te répondre, il faudrait retrouver le thread de discussion qui a amené à cette implémentation et peut être aussi en parler sur leur forum, voir si ils n'ont pas rencontré des problèmes avec des variantes de ce code ou encore si ils l'ont laissé comme ça parceque ça marche suffisamment bien ;)
Personnellement je n'ai jamais eu besoin de mieu, alors jusqu'a ce que je me mettes a boost::chrono, je préfère utiliser ce code qui marche.
sur un programmem onothread ca n'aura pas beaucoup d'influence et je suppose que c'est ce sur quoi ils se basent.
sur un programme task-based (i.e. un jeu récent, voire du futur) cette implémentation va être trop intrusive pour pouvoir fonctionner si elle reschedule les threads a chaque fois.
J'ai bien compris, mais je dis que visiblement ça les a pas empêché d'implémenter des tas de trucs a coup de threads (notemment le chargement en tache de fond) et donc si tu penses qu'ya moyen de faire mieu ça serait cool de leur en parler. Moi je suis pas sufisament compétent dans le suket :aie:
De mon point de vue tant que c'est stable et largement assez rapide pour ce que je fais ça va.
Ou alors y'a tellement de cores que tu peux en dédier un à la gestion de l'horloge ! :PCitation:
Envoyé par screetch
MAT.