[C++] Techniques à éviter?

[Dragohn]

Bonjour,

Voilà, il s'avère que je dois effectuer un projet en C/C++, j'ai eut des cours en C++, mais à aucun momnet n'est abordé la partie "optimisation mémoire ".

Pour faire court, mon projet consiste à implémenter certains algos, et à comparer leur efficacité.

Ce que je voudrais éviter, c'est de fausser les résultats à cause de techniques de programmation propres au C++ qui viendraient alourdir les choses pour la machine, et donc dont je voudrais me passer.

Sauriez vous ce qui est à éviter pour "économiser" la machine, ou pourriez vous me conseiller une doc traitant de ce sujet? Je cherche de mon côté sans réel résultat.

Merci d'avance

[Galdor]

Avant d'optimiser en fonction du langage, commence par optimiser le principe de tes algorithmes, c'est le plus important.

Après, il faut juste éviter certaines bêtises comme déclarer toutes ses variables en début de routine comme en C, penser au décalage de bits ( a * 2 ^ n == a << n ), remplacer ses multiples booléens par des chaînes de bits (et hop, 32 booléen par dword), éviter de dériver à mort des classes très utilisées pour limiter les évaluations de constructeur, mettre un frein sur les tableaux non-dynamiques.......etc.

[Irgoff]

Tu peux trouver qq techniques elementaires sur ce sitesur ce site.

[Dragohn]

Avant d'optimiser en fonction du langage, commence par optimiser le principe de tes algorithmes, c'est le plus important.

En fait je n'ai pas vraiment d'algo a construire, à la base le but est de comparer thériquement la vitesse d'un algo donné pour différentes structures de données, puis de comparer les temps en pratique via implémentation. Le seul truc à plancher est une méthode de génération automatique de graphes de grande taille, le reste c'est de l'implémentation de structures/algo connus dès le départ.

Merci pour vos conseils.

Irgoff > Le site que tu m'as donné m'éclaircit déjà pas mal.

Merci à vous deux

[theocrite]

penser au décalage de bits ( a * 2 ^ n == a << n ),

C'est inutile. Les compilos intelligents le font automatiquement.

theo@fermat:~$ cat decalage_bits.c; cat multi.c
#include <stdio.h>

int main(void)
{
       int a=5;
       a = a>>7;
}
#include <stdio.h>

int main(void)
{
       int a=5;
       a = a*128;
}

theo@fermat:~/tests$ gcc -S *.c; cat *.s
       .file   "decalage_bits.c"
       .text
.globl main
       .type   main, @function
main:
       pushl   %ebp
       movl    %esp, %ebp
       subl    $8, %esp
       andl    $-16, %esp
       movl    $0, %eax
       subl    %eax, %esp
       movl    $5, -4(%ebp)
       leal    -4(%ebp), %eax
       sarl    $7, (%eax)
       leave
       ret
       .size   main, .-main
       .section        .note.GNU-stack,"",@progbits
       .ident  "GCC: (GNU) 3.3.4 (Debian 1:3.3.4-13)"
       .file   "multi.c"
       .text
.globl main
       .type   main, @function
main:
       pushl   %ebp
       movl    %esp, %ebp
       subl    $8, %esp
       andl    $-16, %esp
       movl    $0, %eax
       subl    %eax, %esp
       movl    $5, -4(%ebp)
       movl    -4(%ebp), %eax
       sall    $7, %eax
       movl    %eax, -4(%ebp)
       leave
       ret
       .size   main, .-main
       .section        .note.GNU-stack,"",@progbits
       .ident  "GCC: (GNU) 3.3.4 (Debian 1:3.3.4-13)"

[Galdor]

Mouai, mais le jour où tu tombe sur un compilo à la c** qui ne le fait pas, bah c'est pas une perte de les avoir utilisés.

Exemple, à la fa, je ne suis pas sûr de tomber sur un bon compilo, donc...

[theocrite]

1/ Trouve un compilateur d'aujourd'hui qui ne fait pas ça.

2/ Retrouve ses programmeurs

3/ Jette leurs des pierres dans la rue

[Irgoff]

3/ Jette leurs des pierres dans la rue

he he he

sympa ta signature theocrite

[theocrite]

[jromang]

Tu peux trouver qq techniques elementaires sur ce sitesur ce site.

Super le lien Je vais de ce pas appliquer ca a mon jeu

[Irgoff]

Il faut aussi faire le distingo entre 'optimisation memoire' et 'optimisation rapidite' (ou autres optimisations...)

Pour debuter, quelques points sur lesquels s'interesser :

- connaitre le cout de son algo (en n ? n carre ? grand tau de n ? valeur du grand tau ?)

- savoir le cout des operations simples en connaissant son compilateur (pourquoi vaut-il mieux ecrire ++i que i++ par exemple). Un peu d'assembleur de fait pas ne mal et aide a comprendre comment reagit la machine.

- de meme s'interesser a ce que font les librairies qu'on utilise. Example : a partir de quand l'utilisation d'un type string est-il plus interessant qu'utiliser des char/char* avec des bibliotheques maison ? Est-ce valable pour mon systeme d'exploitation ?

Bref, le tout est de se poser des questions sur chaque lignes de code ecrites. Si on a une idee du code genere, on peut facilement optimiser 'a la volee' des portions de code simples.

[theocrite]

- connaitre le cout de son algo (en n ? n carre ? grand tau de n ? valeur du grand tau ?)

C'est pas un grand tau, mais un grand 'o' noté O(n), O(n²)... (grand o de n, grand o de n carré...)

Sinon, je suis parfaitement d'accord avec toi.

J'ajouterais que pour optimiser la vitesse, il existe des logiciels qui permettent de voir le nombre d'appels de tes fonctions et le temps qu'elles prennent. Ainsi, tu peut te concentrer sur les plus couteuse/plus appellées. Mais je n'en connasi pas sous windows.

[Dragohn]

Merci bien pour vos conseils. Ca me fait réfléchir un peu différement, ce qui ne peut être que bien

Theocrite, les logiciels dont tu parles, en connaitrais tu sous Linux (les projets chez nous sont à faire sous Linux)

Encore merci

[Irgoff]

C'est pas un grand tau, mais un grand 'o' noté O(n), O(n²)... (grand o de n, grand o de n carré...)

Oui bien sur ! Je ne sais pas pourquoi j'ai ecrit 'tau'... sans doute a cause de ma femme grecque.

[jromang]

Theocrite, les logiciels dont tu parles, en connaitrais tu sous Linux (les projets chez nous sont à faire sous Linux)

Encore merci 

Ces logiciels sont des profilers ; sous linux j'utilise gprof.

[theocrite]

L'équivalent sous KDE : kprof et ccmalloc est pas mal, mais pas pour le même usage.