Discussion :

[sebaaas]

Bonjour,

J'ai un petit programme qui lit un fichier image PGM de 720 x 560 que je met dans un tableau de 9 x 8.
Voici le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[])
{
    FILE* fichier = NULL;
    int tableau9x8[9][8];
    int i = 0;
    int j = 0;
    int k = 0;
    int l = 0;
 
    fichier = fopen("1.pgm", "r");//ouverture du fichier
    fseek(fichier, 15, SEEK_SET); // placement du curseur après l'entête du fichier PGM
 
    if (fichier != NULL)
    {
      //remplir le PGM dans un tableau
       for (j = 0; j < 560 ; j++)
       {
           for (i = 0; i < 720 ; i++)
           {
            k=i/80;
            l=j/70;
              tableau9x8[k][l]=tableau9x8[k][l]+ fgetc(fichier);
 
           }
       }
      // fermeture du fichier
        fclose(fichier);
 
    }
 
    return 0;
}

Or je trouve le programme assez lent. Est-ce du fait que je lise les caractère 1 par 1 (fgetc)?
Voyez vous un moyen d'accélérer la manœuvre ?

Merci

[Médinoc]

As-tu activé les optimisations sur ton compilateur?

[Kannagi]

optimisation ou pas du compilateur , la lecture du disque dur est très très lente.
Tu peux augmenter un peu la lecture en faisant une lecture avec fread et donc de faire ta boucle sur le buffer de ton image.

[Médinoc]

Mais de mémoire, fgetc() est déjà bufferisée.
Personnellement je commencerais par sortir le calcul de l de la boucle intérieure, mais n'importe quel optimiseur doit déjà en être capable, pour peu qu'il soit activé.

[Bousk]

Ton tableau n'est pas initialisé, tu vas avoir des résultats différents à chaque appel.
Ensuite, qu'entends-tu par lent ? La lecture depuis disque est lente, la seule façon de l'améliorer est de posséder un SSD.

[dalfab]

Le résultat obtenu n'est qu'un tableau aléatoire car non initialisé.
Avant d'optimiser, il est préférable de faire quelque chose qui ait un sens.
Tel que tu le lis, le fichier serait un fichier texte d'au moins 430215 caractères est-ce bien le cas? Lire au delà de la taille max d'un fichier peut peut-être ajouter les longueurs, mais version debug ou optimisé, ça ne devrait être sous la milliseconde.
Qu'entends-tu par lent ?

[Sve@r]

Bonjour

Mais de mémoire, fgetc() est déjà bufferisée.

C'est vrai que la lecture disque est toujours bufferisée. Mais même bufferisée, lire n fois 1 caractère sera toujours plus lent que lire 1 fois n caractères. Dans le premier cas, il y a n fois appel de fonction avec n fois tout ce qui va avec et ça, même si c'est invisible et transparent, ce n'est pas gratuit.
De fait j'avais fait il y a quelques années des tests benchmark de ce type et globalement les fonctions style fgets ou fread donnaient de meilleurs résultats que fgetc. Bien sûr il y a aussi des effets liés à la taille de la zone lue qui peuvent parfois être contre intuitifs (par exemple ce n'est pas parce qu'on multiplie la taille de la zone à lire par 10 que ça va améliorer les performances x10 et parfois ça peut même les baisser) mais malgré tout ça reste préférable.

Personnellement je commencerais par sortir le calcul de l de la boucle intérieure, mais n'importe quel optimiseur doit déjà en être capable, pour peu qu'il soit activé.

Personnellement je pense qu'aucun optimiseur ne peut remplacer la réflexion et l'analyse personnelle. Il vaut mieux d'abord réfléchir et (comme tu le dis) sortir les traitements lourds des boucles si le fait de calculer dans la boucle n'apporte rien au résultat.
Une fois ce travail fait, si ensuite l'optimiseur peut faire des trucs en plus c'est cadeau.

[wistiti1234]

Les buffers utilisé par les fichiers sont contrôlé (activation, taille) par les commandes setbuf() / setvbuf().

Après, si la mémoire n'est pas un problème dans le programme, moi je lirais tous le fichier d'un seul coup dans un buffer temporaire et je travaillerait directement dessus. En plus de supprimer le morcellement des accès disque, ça éviterait également les quelques 720 x 560 appels/retour de fonctions de lecture (avec gestion de contexte, etc...).
Et puis, suivant l'algorithme qu'on va écrire derrière, ça faciliterait les accès non séquentielle à ces données (vs les multiples "seek()", si on voulait faire la même chose directement sur le fichier).

Par ailleur, il n'y a pas que le "l=j/70;" qui est redondant. On se rend bien compte que le "k=i/80;" aussi, aboutit 80% du temps au même résultat. Et celui-là, je suis pas certain que les optimiseurs savent en faire quelque chose.
Or, parmi les opérateurs de bases sur les entiers, la division est de très loin la plus coûteuse. Ca va dépendre des architectures, et je ne suis pas sûr de ce qu'il en est sur x86, mais '+', '-', '*' se règles généralement en un seul cycle d'horloge, tandis que la division peut en demander une bonne vingtaine ou quarantaine, suivant la plateforme.


Bon bien-sûr, sur PC, on n'a généralement pas besoin de se préoccuper de ce genre de détails et il est préférable de privilégier d'autres considération (réutilisation du code, lisibilité, maintenance, ...). Mais si un goulot d'étranglement critique a réellement été identifié, et en restant sur des boucles for, moi j'aurai proposé quelque chose comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
char buf[720*560];
int tableau9x8[9][8] = {{0}};
 
 
size_t ret = fread(buf, 1, 720*560, fichier);
 
if( ret == (720*560) ){
    char *bufPtr = buf;
    for(int row=0; row!=8; row++){
        for(int r=70; r!=0; r--){
            for(int col=0; col!=9; col++){
                for(int c=80; c!=0; c--){
                    tableau9x8[col][row] += *bufPtr++;
                }
            }
        }
    }
}