Discussion :

[Ashin]

Bonjour,
suite a la mise a jour d'un logiciel, je dois quantifier les gains de temps entre l'ancienne et la nouvelle version. Jusqu a présent, j ai toujours utilisé la commande time qui me donne le temps réel, le temps user et le temps système.
Mon problème est le suivant, les temps user et système ne sont pas toujours cohérente et varie énormément entre deux exécutions similaires.
Je voudrais savoir si le fait qu il y ait 2,4 8 ou meme 16 processeurs sur la machine pouvait poser des problèmes sur les résultats de cette commande.
Et s il existait une alternative a la commande time.

Merci de vos réponses.

[souviron34]

si tu as accès aux sources, oui il y a une alternative.

(voir la rubrique sources C => date => GetClock qui donne la valeur réelle du temps passé (absolue)).

En ce qui concerne la commande time, le temps user est le temps "elapsed", donc peut énormément varier suivant la charge, le temps système est le temps machine, comptabilisé uniquement en temps où le programme est chargé (impliquant que s'il il est déchargé par swap, ça ne compte pas). D'où effectivement une variation là encore en fonction de la charge, et vraisemblablement du nombre de CPUs.

[Ashin]

oui la charge je suis conscient que cela influe sur les résultats mais cela n est pas gênant, on peut toujours s arranger pour faire les mesures a charge quasi égale.

mais pour ce qui est du temps système, est ce possible qu il soit faussé a cause des multi processeurs (qu il calcule par exemple que le temps ou il est chargé dans le 1er processeur et pas dans les autres ...)

[bizulk]

Ton programme est-il multi-tâche ? Fais-tu des accès disques ou vers d'autre périphériques ? Ceux-ci ont-ils changés ?

Juste pour indication tu peux aussi lancer le soft via un script avec un appel à 'date' avant et après (mais c sur les infos sont moins précises et moins complètes).

[Ashin]

le temps réel est bon, c est le temps système qui me pose problème


Pour le programme c est deux processus qui communiquent par ipc

D après ce que j ai compris le temps systeme c est le temps passé dans l espace noyau et le temps user c est le temps passé dans l espace utilisateur.
La somme des deux est le temps passé dans le processeur

[bizulk]

Théoriquement je penserais que Linux attribue un processus/une tâche au processeur qui est le moins chargé, mais ...

• D'après ici les processus user ne sont pas répartis entre les processeurs ce que je ne crois pas car make gère le smp. De plus la doc linux "cpusets.txt" montre que l'on peut attribuer des tâches a des cpus.
• Le support SMP Linux est inégal suivant les architectures PC (PowerPC, ...) et
• Il faut que le SMP soit activé dans le noyau et par le chargeur d'amorçage

.

Si ce qu'il se passe correspond à la "thérorie" alors je dirais : les perfomances dépendent de surtout ton application. Tu as en effet des tâches en attente sur des queues de messages, donc l'une d'elle peut être en attente de msg, ou en attente d'emission.
Tu peux le vérifier avec strace.

Enfin l'ordonnanceur Linux peut modifier la priorité de tes applications et recevoir moins de temps processeur.

[souviron34]

D après ce que j ai compris le temps systeme c est le temps passé dans l espace noyau et le temps user c est le temps passé dans l espace utilisateur.
La somme des deux est le temps passé dans le processeur

me trompe-je ou le temps utilisateur est simplement le delta entre le moment où le programme est lancé et celui`où il se termine ?

Le temps passé dans le processeur serait donc plutôt la différence des 2 temps.. Et encore.. Comme dit plus haut, il y a le swap, l'attente passive (sleep ou wait d'une ressource, etc etc)..

[Ashin]

me trompe-je ou le temps utilisateur est simplement le delta entre le moment où le programme est lancé et celui`où il se termine ?

il y a le temps réel, entre le moment ou la commande est lancée et le moment ou elle se termine
le temps système qui est le temps passé dans le noyau
le temps user le temps passé dans l espace utilisateur

le manuel dit ceci :
%E Elapsed real time
%S Total number of CPU-seconds that the process spent in kernel mode
%U Total number of CPU-seconds that the process spent in user mode





Sinon je pense que les variations viennent du fait que les appels système sont différents d un OS a un autre. Qu'un même programme pourrait passer plus de temps dans le noyau du fait qu il soit sous Linux ou sous Solaris par exemple, non ?

[bizulk]

Finalement que souhaites-tu ?
Comparer des performances d'exécutions de soft sur deux OS différents ? ou deux versions de soft sur le meme systèmes ? Ou deux architectures matérielle différentes ?
Si ton besoin c'est : récupérer un temps 'absolu' avant et après l'exécution d'un programme je te suggère d'utiliser un shell et d'utiliser GetTimeOfDay() qui donne une horloge précise.

[Ashin]

j étais pas très clair au début, je ne voulais pas en dire trop étant donné que c est dans le cadre de mon travail.

c est du portage de solaris vers linux, le code est sensiblement le meme a quelques différences près.
Le but étant de quantifier les gains de performances.

les gains en temps réels ce n est pas un problème, que ce soit time ou par l heure ou autre ...
Par contre pour quantifier les gains au niveau 'processeur' c est différent vu que les serveurs sont différents, des appels systèmes différents aussi d après ce que j ai vu.

[gangsoleil]

Bonjour,

c est du portage de solaris vers linux, le code est sensiblement le meme a quelques différences près.
Le but étant de quantifier les gains de performances.

Pour avoir fait ce genre de portage, il est nécessaire de passer par des outils beaucoup lpus précis que time().

Le plus simple est d'instrumenter le code pour y mettre des timers.
Le mieux est d'utiliser des logiciels de profiling de code, qui te diront combien de temps tu passes dans quelles méthodes, au maximum, minimum et en moyenne.

Attention : mesurer des temps sur des IPC nécessite une machine dédiée pour avoir des résultats probants. En effet, tu ne sais pas comment sont gérées les priorités par les différents systèmes, et un simple refus de communication une seule fois peut conduire à des temps processeurs très différents.

[souviron34]

Si ton besoin c'est : récupérer un temps 'absolu' avant et après l'exécution d'un programme je te suggère d'utiliser un shell et d'utiliser GetTimeOfDay() qui donne une horloge précise.

Pour avoir fait ce genre de portage, il est nécessaire de passer par des outils beaucoup lpus précis que time().

(voir la rubrique sources C => date => GetClock qui donne la valeur réelle du temps passé (absolue)).

http://c.developpez.com/sources/?pag...DATE_get_clock

(dernier source en bas de la page)

Le plus simple est d'instrumenter le code pour y mettre des timers.
Le mieux est d'utiliser des logiciels de profiling de code, qui te diront combien de temps tu passes dans quelles méthodes, au maximum, minimum et en moyenne.

Absolument d'accord

[bizulk]

Merci pour ces réponses, j'avais déjà vu passer clock_gettime sans réellement m'arrêter dessus (codé dans la gonction getclcok pour linux). Je la regarderai de plus près surtout qu'elle est compatible POSIX alors que gettimeofday non.
Cependant clock_gettime est sujet à une résolution temporelle que l'on ne peut modifier, je vais la vérifier pour voir si réellement cette fonction donne une horloge plus précise.

Mais je voudrais discuter certains points :

Envoyé par gangsoleil
Pour avoir fait ce genre de portage, il est nécessaire de passer par des outils beaucoup lpus précis que time().

==> La résolution de la mesure est dépendante de votre besoin sur l'application, je ne pense pas qu'il y ait de règle sur ces comparatif inter-OS.
Est-ce que l'on y gagne vraiment ici de passer de la mirco-seconde à la "pretendue" nano-seconde ?

Le plus simple est d'instrumenter le code pour y mettre des timers.

=> Il faut avoir le code, (le droit de le retoucher), tous les outils de compilation nécessaire + tous les fichiers d'entêtes des dépendances nécessaire à la recompilation.... et recompiler. Ce doit être le cas ici, mais non je ne suis pas d'accord ce n'est pas le plus simple à faire (cela reste d'appeler time). Par la suite il faudra recompiler pour ne pas avoir ces mesures.

Envoyé par gangsoleil Voir le message
Le mieux est d'utiliser des logiciels de profiling de code, qui te diront combien de temps tu passes dans quelles méthodes, au maximum, minimum et en moyenne.

==> Le mieux pour quoi faire ? Pour moi c'est le mieux pour faire des optimisations, par pour faire de la mesure étant donné que ces logiciels de profiling de code détruisent la mesure (au même titre que time). Cela dit je m'en suis rarement servit donc libre à vous de me corriger sur la convergence des données de ces outils vers la réalité.

mesurer des temps sur des IPC nécessite une machine dédiée pour avoir des résultats probants. En effet, tu ne sais pas comment sont gérées les priorités par les différents systèmes, et un simple refus de communication une seule fois peut conduire à des temps processeurs très différents.

=> stp explique la première phrase. Pour moi le restant revient au problème de la politique d'ordonnancement, à la priorité (statique) assignée aux tâches, et enfin au flux IPC (donc aussi lié à l'applicatif).

Maintenant la question était je pense peut-on avoir des écarts de mesure importants mais fiables sur des exécutions successives sur une même machine Linux sachant que les applicatifs utilisent des queues de messages IPC et que l'on se trouve sur une architecture SMP ?
Je pense qu'il est difficile de te répondre sans connaître la nature des ces tâches et leur rapport consommatrice/productrice de message, ni leur ordonnancement/priorité, ainsi que le contexte d'éxécution (d'autres process en cours ?).

[Ashin]

ok merci pour toutes ces informations.
je me fierais au temps absolu dans ce cas, le temps système user n étant pas suffisament fiable.

[gangsoleil]

Bonjour,

Concernant l'insertion de timer dans le code au lieu de l'utilisation de time, il ne s'agit absolument pas de passer à la nano-seconde, mais simplement d'avoir des mesures plus précises du code en lui-même. Ainsi, on peut découvrir lors de ce genre de portage que la majeur partie du temps n'est pas passée dans les mêmes portions de code selon l'OS.
C'est d'ailleurs l'utilité des logiciels de profiling : avoir des mesures précises, en plus des mesures globales, avec une simple recompilation - donc sans devoir poser des timers dans tout le code juste pour mesurer les différents appels.

Enfin, concernant les IPC, l'intérêt d'une machine dédiée est le suivant : s'assurer de la fiabilité des résultats. En effet, la mesure des IPC risque d'être la partie la plus variable de la mesure, et ce sera encore plus vrai avec un système en charge (même si celle-ci est relativement faible), puisque l'on rentre dans des problématiques de schedulling OS, avec tous les aléas que cela engendre.

[bizulk]

C'est d'ailleurs l'utilité des logiciels de profiling ...avoir des mesures précises, en plus des mesures globales, avec une simple recompilation

Les logiciels de profiling détruisent forcément la mesure, au même titre que time.

La fiabilité des résultats n'est pas dépendant un environnement "vierge" dédié (à moins que l'on cherche à évaluer les mécanismes IPC), mais d'un environnement le plus proche des conditions de production.

[matafan]

Les logiciels de profiling détruisent forcément la mesure, au même titre que time.

Non, pas forcément. J'ai pas mal travaillé sur le "tprof" d'AIX, qui ne nécessite aucune instrumentation du code ni aucune modification de l'exécutable. Il fonctione en "sampling" : a chaque interruption d'horloge, l'adresse de l'instruction en cours est enregistrée par le système de trace, et tprof produit après coup un profile à partir de ces données. Il n'y a aucun impact (ou en tout cas absolument négligeable) sur le programme profilé.

[bizulk]

C'est plutôt intéressant comme méthode.

Maintenant en ce qui concerne la différence entre la mesure de temps avec clock_gettime et gettimeofday j'ai une réponse :
http://www.developpez.net/forums/d65...-gettimeofday/