Lenteur de la commande printf

Version imprimable

Bonjour à tous et à toutes (ben oui quoi y a aussi des femmes et ce pour notre plus grand plaisir donc ne les oublions pas ;) !),

Pour ne pas rentrer dans les détails sur mon souci je le contourne par le code suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #include <iostream> using namespace std; int main() { printf("Patientez calcul en cours !!!\n"); int nb=0; while (nb<1000000000) { sprintf (stdout,"%d",nb ); nb++; } printf("Termine !!!\n"); return 0; }
Comment faire pour que l'affichage à l'écran soit le plus rapide possible ? en effet que ce soit en c ou c++ les "printf", "cout" et autre "sprintf" ne sont pas des plus rapides... la même boucle sans le "sprintf (stdout,"%d",nb );" dure 1 seconde et celle avec le "sprintf (stdout,"%d",nb );" allonge considérablement les délais.

Et ne me dites pas "mais pourquoi tu veux afficher l'info à l'écran !!! je veux bien toute les valeurs, ici ce n'est qu'un exemple simplifié !!!! :?

Merci d'avance pour votre aide à tous !

08/04/2010, 14h21
nikko34

Afficher sur un écran ça prend du temps. Je crois que tu n'as pas vraiment de choix possibles.
08/04/2010, 14h32
akorx

Citation:

Envoyé par nikko34

Afficher sur un écran ça prend du temps. Je crois que tu n'as pas vraiment de choix possibles.

Tout d'abord merci Nokko34 pour ta réponse...

En fait y a il tout de même une instruction plus rapide ?

Et pourquoi est ce si lent ? la commande printf "attendrait" elle que le message soit afficher à l'écran avant de continuer ? dans ce cas y a t il un moyen de "bufferiser" ou éviter d'attendre ce retour ?

Et juste pour ma gouverne car je n'ai n'en ai pas la maitrise un passage par l'assembleur améliorerait il les temps de réponses ?

Salut,

Une question sans doute idiote, mais... là, tu va provoquer... 10 milliards d'affichages :P

Pourquoi ne pas réduire le nombre d'affichage, pour par exemple, marquer chaque tranche de 100 ou de 1000 (voire des tranches plus grandes :D) ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
int main()
{
    printf("Patientez calcul en cours !!!\n");
    int nb=0;
    while (nb<1000000000)
    {
        /* le calcul réel */
        if(nb%10000==0) // on rappelle à l'utilisateur que ca fonctionne...
                      // tous les 10 000 calculs
            std::cout<<nb<<" calculs effectués"<<std::endl;
        /* nous pourrions même afficher l'avance sous la forme d'un
         * pourcentage
         if(nb%10000==0)
             std::cout<<nb/1000000000.0*100 
                      <<" % effectués... Merci de votre patience"<<std::endl;
         */
    nb++;
    }
    printf("Termine !!!\n");
    return 0;
}

Bonjour,

A mon avis c'est surtout dépendant du programme qui affiche ton texte (le terminal sans doute)

j'ai testé en mettant tout les chiffre dans un string afin de tout affiché a la fin et sa n'est pas plus efficace :?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 #include <iostream> #include <QtCore/QString> using namespace std; int main(int argc, char** argv) { QString str; cout << "Patientez calcul en cours !!!" << endl; int nb=0; while (nb<1000000) { str.append(QString::number(nb) + "\n"); nb++; } cout << str.toStdString(); cout << "Termine !!!" << endl; return 0; }

08/04/2010, 15h10
koala01

@ atttchoum>> Salut, et bienvenue sur le forum.

Soit cependant attentif à ce que tu utilise...

De toute évidence, tu te repose sur la bibliothèque Qt.

Ce n'est pas un mal, loin de là, mais... c'est une bibliothèque qui n'a strictement rien à voir avec le standard, et qui impose des dépendances importantes pour utiliser quelque chose "d'aussi simple" que sa chaine de caractères :aie:

Il est un peu dommage d'imposer ces dépendances quand on sait que le standard C++ fournit plusieurs classes (std::string et les *stringstream pour les conversions éventuelles) qui s'en sortiront très bien :D
08/04/2010, 15h20
akorx

Merci pour toutes vos réponses... bien évidemment koala01 j'avais pensé à utilisé ce "filtrage" pour éviter d'afficher toutes les valeurs... mais si je veux ou dois les afficher que puis je faire ?
08/04/2010, 15h21
koala01

Je vais quand même réagir à

Citation:

Envoyé par akorx

Tout d'abord merci Nokko34 pour ta réponse...

En fait y a il tout de même une instruction plus rapide ?

La réponse est simple: non...

Citation:

Et pourquoi est ce si lent ? la commande printf "attendrait" elle que le message soit afficher à l'écran avant de continuer ? dans ce cas y a t il un moyen de "bufferiser" ou éviter d'attendre ce retour ?

C'est parce que, en fin de compte, les fonctions *printf vont invoquer des fonctions systèmes (propres au système d'exploitation) qui devront (sans doute) lancer une IRQ sur le périphérique d'affichage, attendre d'obtenir cette interruption, envoyer l'information, etc, etc...

Citation:

Et juste pour ma gouverne car je n'ai n'en ai pas la maitrise un passage par l'assembleur améliorerait il les temps de réponses ?

A l'heure actuelle, tu te casserais surement énormément la tête pour pas grand chose: les compilateurs seront très certainement en mesure d'optimiser bien mieux l'appel que tout ce que tu pourrais arriver à faire, surtout si tu n'es pas un "crack" de l'assembleur.

Il y a de fortes chances pour que tu n'obtienne au mieux que des performances similaires à celle d'un code C (ou C++) si tu mettais les doigts dans l'assembleur ;)
08/04/2010, 15h25
koala01

Citation:

Envoyé par akorx

Merci pour toutes vos réponses... bien évidemment koala01 j'avais pensé à utilisé ce "filtrage" pour éviter d'afficher toutes les valeurs... mais si je veux ou dois les afficher que puis je faire ?

prendre ton mal en patience...

L'affichage ou l'écriture dans un fichier prennent énormément de temps, simplement parce que les temps d'accès sont très largement supérieurs à ceux que l'on obtient lorsque l'on travaille sur la mémoire.

On ne sait rien y faire... On doit faire avec ;)

Ceci dit, si tu affiche toutes les valeurs, il faut te dire que tu n'auras très certainement pas le temps de toutes les lire.

Dés lors, on peut réellement se demander si ca en vaut la peine :D

Evidemment, si l'idée est de créer un fichier qui doit être complet, tu n'as sans doute pas le choix ;)
[EDIT](Et encore, tu auras sans doute meilleur temps de garder les résultat "quelque part" en mémoire, et de les écrire, si pas tous à la fois (pour des problème de disponibilité de mémoire, par exemple), au moins par "tranches" dans le fichier ;))
08/04/2010, 20h37
Lavock

Citation:

Envoyé par akorx

dans ce cas y a t il un moyen de "bufferiser" ou éviter d'attendre ce retour ?

Les affichages sont "nativement bufferisé", /n flush printf et endl flush cout.
08/04/2010, 23h05
akorx

Donc pour résumer : nos machines, malgré leurs puissances démultipliées années après années, se retrouvent "bêtement" bridés lorsqu'elles doivent afficher le résultat de leur calcul... c'est tout de même un peu frustrant ça quand même, je pensais sincèrement qu'il y avait une solution...

Merci à chacun d'entre vous pour la richesse de vos réponse en tout cas.
08/04/2010, 23h35
koala01

Citation:

Envoyé par akorx

Donc pour résumer : nos machines, malgré leurs puissances démultipliées années après années, se retrouvent "bêtement" bridés lorsqu'elles doivent afficher le résultat de leur calcul... c'est tout de même un peu frustrant ça quand même, je pensais sincèrement qu'il y avait une solution...

Merci à chacun d'entre vous pour la richesse de vos réponse en tout cas.

A vrai dire, il y aurait effectivement une solution pour éviter au moins en partie le problème en utilisant deux tableaux de résultat et deux thread: Le premier thread effectuerait le calcul et remplirait l'un des tableau pendant que le second thread afficherait les résultat contenu dans le deuxième tableau, avec échange des tableaux en temps opportun...

Mais...

Le principal problème, c'est que, pour qu'une information apparaissant à l'écran ait la moindre chance d'être saisie et correctement analysée par l'homme qui la regarde, il faut qu'elle soit fixe un bon dizième de seconde (peut être même plus... bien que je n'ai pas les chiffres sous le coude, je dirais volontiers plus proche de 0,25 sec... et je me baserai donc sur cette valeur "arbitraire" par la suite ;) :P).

Le temps nécessaire pour afficher quelque chose avec printf est très largement en deçà de ce délais, car même un dixième de seconde, qui nous parait pourtant si court (essaye de lance et d'arrêter un chrono le plus rapidement possible, généralement, tu y arrivera en un temps de 15 à 25 centièmes de secondes ;)) est une véritable éternité en terme de "temps ordinateur" au vu de leur puissance actuelle.

Si donc, pour que tu puisse "profiter" de l'affichage de chaque résultat, tu en viens à devoir ralentir la vitesse de l'affichage, le fait que printf prenne "si longtemps" en terme de "temps ordinateur" ne te pose plus de problème, et, inversement, si le calcul à effectuer est à ce point important que sa seule exécution prend déjà 0,25 seconde, tu as, très certainement des choses bien plus intelligentes à optimiser que cette seule instruction printf.

Dés lors, si l'on part du principe que, d'une manière ou d'une autre, tu ne pourra d'office pas "profiter" de l'affichage de tous les résultats, et que printf prend, effectivement, un temps très important par rapport au reste, la meilleure solution réside très certainement dans le fait... de ne pas afficher tous les résultat, mais de n'en afficher qu'un sur... un nombre qu'il te faudra déterminer en fonction du traitement effectué ;)

Au niveau de l'écriture sur disque dur, le problème est un peu différent et vient du fait qu'un disque dur, ca tourne à vitesse constante...

En considérant même que tu maintiens le fichier ouvert en permanence, il faut prendre en compte le fait que, alors que tu n'écris plus sur le disque pendant le délais nécessaire à ton traitement, le disque dur continue de tourner, et donc que la tête de lecture ne se trouve plus à la bonne position lorsqu'il s'agit de "continuer" l'écriture.

Le système est donc obligé... d'attendre que le disque dur ait fini son tour :P (je simplifie énormément, mais le principe est là ;))

De plus, chaque secteur du disque dur est capable de contenir... 512 byte, et tu risque donc, en voulant écrire les informations une à une d'être forcé d'attendre que le disque dur fasse deux tours au total pour l'écriture: le premier pour "relire" les bytes déjà écrits sur le secteur prévu à cet effet, le second pour "réécrire" les bytes déjà écrits et... ceux correspondant à la nouvelle valeur à écrire.

Là aussi, l'utilisation de threads est susceptible d'améliorer les choses, mais, là aussi, l'idéal est donc... de provoquer des écriture par lots plutôt que d'essayer d'écrire les données une à une ;)
09/04/2010, 00h14
Goten

Citation:

Envoyé par akorx

Donc pour résumer : nos machines, malgré leurs puissances démultipliées années après années, se retrouvent "bêtement" bridés lorsqu'elles doivent afficher le résultat de leur calcul... c'est tout de même un peu frustrant ça quand même, je pensais sincèrement qu'il y avait une solution...

Merci à chacun d'entre vous pour la richesse de vos réponse en tout cas.

Quel intérêt? C'est pas comme si l'oeil/le cerveau humain était capable de suivre. Donc on finit par tout sortir dans un fichier pour pouvoir le lire à notre vitesse...
09/04/2010, 07h16
3DArchi

Citation:

Envoyé par Goten

Quel intérêt? C'est pas comme si l'oeil/le cerveau humain était capable de suivre. Donc on finit par tout sortir dans un fichier pour pouvoir le lire à notre vitesse...

++. Si l'affichage est pénalisant par rapport au calcul, c'est probablement que la lecture par l'humain serait impossible.
Si l'objectif est d'avoir un calcul et quelque part savoir que ça n'est pas planté, alors il faut effectivement séparer ton code en 2 threads : un thread pour faire le calcul brut et un pour faire les sorties indiquant que l'appli tourne (avec éventuellement des infos d'avancement).