IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

Optimisation de code


Sujet :

C

  1. #41
    Membre habitué
    Inscrit en
    Janvier 2005
    Messages
    491
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 491
    Points : 172
    Points
    172
    Par défaut
    Hello
    juste pr dire qu'il semblerait que memmove ne soit pas plus rapide qu'une simple boucle, du moins sur le pc sur lequel je bosse... Le programme suivant:
    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
     
    #include <stdio.h>
    #include <string.h>
    #include <time.h>
    int main(void){
    	int i ;
    	double *t = calloc(2000, sizeof(double)) ;
    	if(t == NULL) exit(0) ;
     
    	double t0 = 0., dt = 0.0001, tf = 500;
    	size_t taille =  1999*sizeof(double);
     
            clock_t start = clock();
    	while(t0 < tf) {
    		t0 += dt ;
    		for(i = 1999 ; i > 0 ; i--) t[i] = t[i-1];
    		//memmove(&(t[1]), &(t[0]), taille) ;
    	}
            clock_t end = clock();
     
            printf("\nEnd: %f\n",((double)end - start) / (CLOCKS_PER_SEC));
     
    	free(t);
    	return 0 ;
    }
    passe presque du simple (9secondes) au double (16 secondes) chez moi!

  2. #42
    Membre à l'essai
    Profil pro
    Inscrit en
    Juillet 2003
    Messages
    20
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2003
    Messages : 20
    Points : 17
    Points
    17
    Par défaut
    Memmove et Memcpy sont à utiliser suivant les cas. Si les zones de mémoire concernées se recouvrent, il faut obligatoirement utiliser memmove, sinon memcpy. Les deux sont censés être quasiment aussi efficace, mais ca doit varier suivant les implémentations.

    Voila une implementation qui se trouve dans string.c (il y a peu etre des versions plus recente):

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
    #ifndef __HAVE_ARCH_MEMCPY
    void * memcpy(void * dest,const void *src,size_t count)
    {
    	char *tmp = (char *) dest, *s = (char *) src;
     
    	while (count--)
    		*tmp++ = *s++;
     
    	return dest;
    }
    #endif
    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
     
    #ifndef __HAVE_ARCH_MEMMOVE
    void * memmove(void * dest,const void *src,size_t count)
    {
    	char *tmp, *s;
     
    	if (dest <= src) {
    		tmp = (char *) dest;
    		s = (char *) src;
    		while (count--)
    			*tmp++ = *s++;
    		}
    	else {
    		tmp = (char *) dest + count;
    		s = (char *) src + count;
    		while (count--)
    			*--tmp = *--s;
    		}
     
    	return dest;
    }
    #endif

  3. #43
    Membre éclairé Avatar de stephl
    Profil pro
    Développeur informatique
    Inscrit en
    Février 2007
    Messages
    643
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Février 2007
    Messages : 643
    Points : 771
    Points
    771
    Par défaut
    Citation Envoyé par vinzzzz
    Hello
    juste pr dire qu'il semblerait que memmove ne soit pas plus rapide qu'une simple boucle, du moins sur le pc sur lequel je bosse...
    Si memmove() est implémentée sur votre système comme la version de bl4d3, alors memmove() sera selon moi moins efficace que votre boucle, car memmove() utilise alors la même technique que vous mais requiert en plus le temps d'un appel de fonction. En revanche, il me semble qu'il existe des instructions assembleur pour déplacer un bloc de mémoire. Si memmove() utilise cette technique, elle peut être plus rapide que votre boucle. Chez moi, la version avec memmove() est plus rapide.

  4. #44
    Membre habitué
    Inscrit en
    Janvier 2005
    Messages
    491
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 491
    Points : 172
    Points
    172
    Par défaut
    Manifestement chez moi la fonction est bien plus lente qu'une simple boucle

  5. #45
    Membre éclairé Avatar de stephl
    Profil pro
    Développeur informatique
    Inscrit en
    Février 2007
    Messages
    643
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Février 2007
    Messages : 643
    Points : 771
    Points
    771
    Par défaut
    Citation Envoyé par vinzzzz
    Manifestement chez moi la fonction est bien plus lente qu'une simple boucle
    Selon moi, si votre implémentation de memmove() est une boucle semblable à ce que vous faites, alors utiliser memmove() prendra au moins autant de temps que la boucle que vous faites "à la main". A cela, il faudra ajouter le temps de l'appel à la fonction si le compilateur n'optimise pas et que la fonction n'est pas inlinée.

  6. #46
    Membre habitué
    Inscrit en
    Janvier 2005
    Messages
    491
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 491
    Points : 172
    Points
    172
    Par défaut
    Etonnament le temps que met le programme ci-dessus à se terminer est, comme je l'ai dit plus haut, beaucoup plus élevé, presque le double, quand j'utilise memmove au lieu d'une simple boucle... Pour un simple appel de fonction?

  7. #47
    Membre éclairé Avatar de stephl
    Profil pro
    Développeur informatique
    Inscrit en
    Février 2007
    Messages
    643
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Février 2007
    Messages : 643
    Points : 771
    Points
    771
    Par défaut
    Citation Envoyé par vinzzzz
    Etonnament le temps que met le programme ci-dessus à se terminer est, comme je l'ai dit plus haut, beaucoup plus élevé, presque le double, quand j'utilise memmove au lieu d'une simple boucle... Pour un simple appel de fonction?
    Sauf que ce n'est pas UN appel de fonction en plus, mais tf/dt appels. Et oui, l'appel est dans une boucle while.

  8. #48
    Débutant  
    Profil pro
    Bidouilleur
    Inscrit en
    Avril 2006
    Messages
    145
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Bidouilleur

    Informations forums :
    Inscription : Avril 2006
    Messages : 145
    Points : 103
    Points
    103
    Par défaut
    pour la division et la multiplication en assembleur c'est exactement la meme chose, l'un c'est une rotation a gauche et l'autre une rotation a droite, donc pas de reel difference du pt de vu temps de calcul.

  9. #49
    Membre éclairé Avatar de stephl
    Profil pro
    Développeur informatique
    Inscrit en
    Février 2007
    Messages
    643
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Février 2007
    Messages : 643
    Points : 771
    Points
    771
    Par défaut
    Citation Envoyé par kabil.cpp
    pour la division et la multiplication en assembleur c'est exactement la meme chose, l'un c'est une rotation a gauche et l'autre une rotation a droite, donc pas de reel difference du pt de vu temps de calcul.
    Il me semble que cette remarque n'est valable que pour les multiplications/divisions par des puissances de 2. D'ailleurs, c'est alors un décalage et non une rotation.

  10. #50
    Membre éclairé Avatar de mchk0123
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    816
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2007
    Messages : 816
    Points : 844
    Points
    844
    Par défaut
    Pour ce qui est de la fonction memove. On peut effectivement avoir des surprises.

    Elle peut trés bien être implémentée en code ASM (optimisé ou non) comme en code C. De trés nombreux paramètres rentrent en ligne de compte : choix de la version de la CRT.lib et/ou du CRT0 lors de l'édition de lien, architecture du processeur, flags de compilation (par ex. sélection de la libCRT en mode debug) choix du compilateur ... etc.

    Le seul moyen de savoir et de faire comme vinzz c'est à dire de benchmarker 2 versions d'un même programme.

    Donc ça ne m'étonnes pas plus que ça d'avoir le memmove plus long.

    Par simple curiostié, pendant que tu y est (et si cela s'y prête), tu peux essayer avec bcopy, memcpy ou _memcpy à la place de memmove.
    Avant de poster un message .
    Quand vous avez la réponse à votre question, n'oubliez pas de cliquer sur .

  11. #51
    Membre éclairé Avatar de stephl
    Profil pro
    Développeur informatique
    Inscrit en
    Février 2007
    Messages
    643
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Février 2007
    Messages : 643
    Points : 771
    Points
    771
    Par défaut
    Citation Envoyé par mchk0123
    Par simple curiostié, pendant que tu y est (et si cela s'y prête), tu peux essayer avec bcopy, memcpy ou _memcpy à la place de memmove.
    L'exemple ici n'est pas utilisable avec memcpy() car les blocs source et cible ne sont pas disjoints.

  12. #52
    Membre habitué
    Inscrit en
    Janvier 2005
    Messages
    491
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 491
    Points : 172
    Points
    172
    Par défaut
    En effet il s'agit de déplacer les N-1 premiers éléments d'un tableau d'une case vers la droite.

    Citation Envoyé par souviron34
    la division prend environ 2 fois plus de temps que la multiplication
    Citation Envoyé par kabil.cpp
    pour la division et la multiplication en assembleur c'est exactement la meme chose, l'un c'est une rotation a gauche et l'autre une rotation a droite, donc pas de reel difference du pt de vu temps de calcul.
    Citation Envoyé par stephl
    Il me semble que cette remarque n'est valable que pour les multiplications/divisions par des puissances de 2. D'ailleurs, c'est alors un décalage et non une rotation.
    Alors qui a raison ?
    Savez vous où l'on peut trouver des infos sur ce genre de chose ?

  13. #53
    Expert éminent

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    Par défaut
    Citation Envoyé par vinzzzz
    Alors qui a raison ?
    Les decalages ne peuvent effectivement servir que pour les multiplications et les divisions par une puissance de 2.

    Sur un processeur moderne, savoir ce que coute une operation est difficile. Parce que la plupart sont capables d'en executer plusieurs en meme temps, certains sont meme capable de les executer dans un ordre different que celui du programme. Donc ajouter une operation peut ne rien couter en pratique parce qu'elle est executee sur une unite qui est libre a ce moment la. Et meme des choses contre-intuitives -- transformer une addition d'entier en une addition de flottant -- peut etre benefique.

    Donc, la seule chose a faire, c'est mesurer. Et la difficulter, c'est de faire en sorte que la mesure soit significative.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  14. #54
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Bon excusez j'étais absent hier.

    Alors voilà :

    En ce qui concerne les diviisons/multiplications, il y a une opération de plus au moins (calcul du reste/alternativement calcul de la partie entière)

    En ce qui concerne le memmove, cela dépend effectivment de l'implémentation. Par rapport à la solution que j'avais donné dans le post #xxx (la boucle sur les pointeurs) dans la meilleure des implémentations ce devrait être équivalent (ce devrait être ce que ça fait).

    La seule vraie différence à ce niveau est la lisibilité : d'un côté la boucle est facilement portable avec un autre langage, et en lisant on comprend ce que ça fait. Le memmove est plus compact en écriture et , même si le nom est assez explicite, c'est pas forcément transposable dans un autre langage, mais on fait référence aux éléments directs du tableau (placer 0 en 1), alors que dans la boucle on fait référence à des pointeurs.

    Donc, à l'implémentation prêt, c'est question de choix.

    Au vu de tes mesures et du code que tu postes sur l'implémentation, je dirais qu'effectivement dans ton cas il vaut mieux la boucle sur les pointeurs.

    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  15. #55
    Membre habitué
    Inscrit en
    Janvier 2005
    Messages
    491
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 491
    Points : 172
    Points
    172
    Par défaut
    Citation Envoyé par Jean-Marc.Bourguet
    Donc, la seule chose a faire, c'est mesurer. Et la difficulter, c'est de faire en sorte que la mesure soit significative.
    J'ai fait quelques mesures pour la division et la multiplication, et j'observe des différence énormes de temps d'execution...
    Quand il s'agit de puissance de deux, il n'y a aucune différence en effet, mais lorsque j'utilise un double quelconque, la différence est flagrante: Par exemple 42 secondes pour 3 milliards de divisions, et 3,6 secondes seulement pour le même nombre de multiplications...

    J'ai utilisé ce genre de code pour la mesure, en changeant la valeur de mult et de la valeur à diviser:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    start = clock();
    for(i = 0 ; i < 1000000000 ; i++) {
    	res = 68.4586647112*mult;
    }
    end = clock();
     
    t = ((double)end - start) / CLOCKS_PER_SEC;
    printf("Mult: %.10f\n", t);
    Ce genre code vous parait-il valable afin de valider mes mesures?

  16. #56
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par vinzzzz
    Ce genre code vous parait-il valable afin de valider mes mesures?
    Absolument ...

    Et c'est ce que je disais ... re

    On peut être plus précis sur le timing, mais à ces différences-là, on s'en fiche un peu...

    Dans les optimisations, lorsqu'on manipule des réels, TOUJOURS préférer des multiplications à des divisions....
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  17. #57
    Expert éminent

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    Par défaut
    Citation Envoyé par vinzzzz
    Ce genre code vous parait-il valable afin de valider mes mesures?
    A condition de savoir ce que tu mesures exactement.

    La difference me semble importante, et je crains qu'il y ait un facteur dont tu n'as pas tenu compte qui soit intervenu.

    Pour se rendre compte de l'importance de mesurer en contexte:

    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
    #include <stdio.h>
    #include <time.h>
     
    int main() {
        int start, end;
        long i;
        double t, res, res2;
        start = clock();
        res = 1;
        res2 = 1;
        for(i = 0 ; i < 100000000 ; i++) {
    #if DIV        
            res = res/0.9999999;
    #endif
    #if MUL        
            res2 = res2*1.0000001;
    #endif                
        }
        end = clock();
     
        t = ((double)end - start) / CLOCKS_PER_SEC;
        printf("Temps: %.10f\nValeurs: %g %g\n", t, res, res2);
        return 0;
    }
    Code shell : 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
    ~/src 32> cc -O3 -DDIV mm.c
    ~/src 33> ./a.out 
    Temps: 2.0300000000
    Valeurs: 22026.5 1
    ~/src 34> ./a.out
    Temps: 2.0000000000
    Valeurs: 22026.5 1
    ~/src 35> ./a.out
    Temps: 2.0600000000
    Valeurs: 22026.5 1
    ~/src 36> cc -O3 -DMUL mm.c
    ~/src 37> ./a.out
    Temps: 0.9400000000
    Valeurs: 1 22026.5
    ~/src 38> ./a.out
    Temps: 0.9300000000
    Valeurs: 1 22026.5
    ~/src 39> ./a.out
    Temps: 0.9200000000
    Valeurs: 1 22026.5
    ~/src 40> cc -O3 -DMUL -DDIV mm.c
    ~/src 41> ./a.out
    Temps: 1.3900000000
    Valeurs: 22026.5 22026.5
    ~/src 42> ./a.out
    Temps: 1.4200000000
    Valeurs: 22026.5 22026.5
    ~/src 43> ./a.out
    Temps: 1.4100000000
    Valeurs: 22026.5 22026.5

    Oui, faire la division et la multiplication va plus vite que faire la division uniquement. Je n'ai pas d'explications a proposer. Le code assembleur genere pour les boucles n'a rien d'etrange.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  18. #58
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Jean-Marc.Bourguet
    Oui, faire la division et la multiplication va plus vite que faire la division uniquement. Je n'ai pas d'explications a proposer. Le code assembleur genere pour les boucles n'a rien d'etrange.
    une explication est celle de la fabrication, de l'algorithmie utilisée :

    http://perso.ens-lyon.fr/nathalie.re...ath-Info02.pdf


    J'avais je ne sais plus où l'algo. le plus utilisé, mais ce papier en résume un certain nombre. Il me semble que ça a à voir avec le fait que une division en réel c'est un peu une suite, mais mes souvenirs sont trop vagues.
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  19. #59
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Je viens de trouver 2 références intéressantes sur le sujet, sur le Web :

    http://en.wikipedia.org/wiki/Floatin...Multiplication

    En particulier notez le :

    Division is done similarly, but that is more complicated
    Et aussi (publié par IEEE, mais évidemment le papier complet est payant) :

    AMD5K86 Floating-Point Division Algorithm
    J Strother Moore <moore@cli.com>
    Fri, 19 Apr 96 14:28:31 CDT
    I would like to bring your attention to some recent joint work by Advanced
    Micro Devices, Inc., and Computational Logic, Inc., in which the ACL2
    theorem prover was used to prove the correctness of an algorithm of
    commercial interest. In particular we proved the correctness of the kernel
    of the floating-point division algorithm on the AMD5K86, the first
    Pentium-class processor produced by AMD. Roughly speaking, we proved that
    the algorithm implements division on the double extended precision normal
    and denormal numbers of the IEEE standard, in the sense that (under
    appropriate hypotheses) it returns the floating-point number obtained by
    rounding the ``infinitely precise'' quotient by the method and to the
    precision specified by a given rounding mode. The permitted rounding modes
    include round to 0, round away from 0, round to nearest, round to positive
    (or negative) infinity, and ``sticky'' rounding. The proof is quite
    interesting, involving as it does the formalization of a lot of
    floating-point ``folklore'' and classical numerical analysis.

    J Strother Moore

    The paper may be obtained via the URL:
    http://devil.ece.utexas.edu:80/~lync...de/divide.html

    The title and abstract are shown below.

    A Mechanically Checked Proof of the Correctness of the Kernel
    of the AMD5K86 (tm) Floating-point Division Algorithm

    J Strother Moore (Moore@cli.com)
    Tom Lynch (Tom.Lynch@amd.com)
    Matt Kaufmann (Matt_Kaufmann@email.mot.com)

    ABSTRACT:

    We describe a mechanically checked proof of the correctness of the kernel of
    the floating-point division algorithm used on the AMD5K86 microprocessor.
    The kernel is a non-restoring division algorithm that computes the
    floating-point quotient of two double extended precision floating-point
    numbers, p and d (d \= 0), with respect to a rounding mode, mode. The
    algorithm is defined in terms of floating-point addition and multiplication.
    First, two Newton-Raphson iterations are used to compute a floating-point
    approximation of the reciprocal of d. The result is used to compute four
    floating-point quotient digits in the 24,,17 format (24 bits of precision
    and 17 bit exponents) which are then summed using appropriate rounding
    modes. We prove that if p and d are 64,,15 (possibly denormal)
    floating-point numbers, d \= 0 and mode specifies one of six rounding
    procedures and a desired precision 0 < n <= 64, then the output of the
    algorithm is p/d rounded according to mode. We prove that every
    intermediate result is a floating-point number in the format required by the
    resources allocated to it. Our claims have been mechanically checked using
    the ACL2 theorem prover.
    Voili voilà....

    En tous cas, ça correspond à mes souvenirs, même si ils étaient lointains...

    Une multiplication est TOUJOURS moins coûteuse qu'une division avec des flottants.
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  20. #60
    Membre éprouvé

    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 116
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 116
    Points : 1 111
    Points
    1 111
    Par défaut
    Bonjour.

    J'aimerai savoir si la compression de l'écriture permet d'améliorer la vitesse du code, par exemple les exemples "programmeur expérimenté" que j'ai pu voir dans le livre langage C ANSI Ritchie et Kernighan (les incrémentations dans les expression conditionnelles et de test, mettre des fonctions à valeur de retour dans des expressions de test, du genre
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    if ( MonPointeur=malloc(128) )
    ).

    Dans quelle mesure le compilateur influence-t-il la vitesse d'exécution avec deux sources portables différentes et optimisées, ie un programme peut être "optimisé" pour un compilateur mais pas pour l'autre et inversement.

    N'est ce pas au compilateur de réaliser les optimisations au maximum dans la mesure du possible ?

    Citation Envoyé par souviron34
    Une multiplication est TOUJOURS moins coûteuse qu'une division avec des flottants.
    Les additions sont moins coûteuses que les multiplications je crois, cependant, le langage C est fait pour nous éviter d'avoir à replonger dans la conception de fonctions "opérateurs élémentaires".
    Ainsi, il serait ridicule je crois de bondir parce que l'on réalise une division sur long double avec les processeurs PC actuels. Tout dépend alors en fait (je crois) du compilateur et de la plateforme sur laquelle servira le code compilé.

    La typage fort du langage C est une des caractéristiques qui en font un langage compilé propre aux optimisations. L'optimisation réelle ne peut se faire qu'en ayant une connaissance intime des caractéristiques et des possibilités à la fois du microprocesseur, du compilateur et du langage C, ce qui forme pour quelqu'un comme moi (~débutant) un domaine d'exploration assez vaste.

Discussions similaires

  1. optimiser le code d'une fonction
    Par yanis97 dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 15/07/2005, 09h41
  2. Optimiser mon code ASP/HTML
    Par ahage4x4 dans le forum ASP
    Réponses: 7
    Dernier message: 30/05/2005, 11h29
  3. optimiser le code
    Par bibi2607 dans le forum ASP
    Réponses: 3
    Dernier message: 03/02/2005, 15h30
  4. syntaxe et optimisation de codes
    Par elitol dans le forum Langage SQL
    Réponses: 18
    Dernier message: 12/08/2004, 12h54
  5. optimisation du code et var globales
    Par tigrou2405 dans le forum ASP
    Réponses: 2
    Dernier message: 23/01/2004, 11h59

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo