Discussion :

[Emmanuel Delahaye]

En meme temps le gars kia codé ce for avait envie de se prendre la tete, c'est quand meme plus simple de faire tourner un i de 0 a la taille de la chaine...[/code]

ou d'utiliser printf() avec "%s"... Sans doute trop simple...

[ggnore]

En meme temps le gars kia codé ce for avait envie de se prendre la tete, c'est quand meme plus simple de faire tourner un i de 0 a la taille de la chaine...[/code]

ou d'utiliser printf() avec "%s"... Sans doute trop simple...

en même temps, il y a un wait(20) entre chaque affichage de caractère.
J'ai pas bien compris ce que faisait le wait(20),
ça a l'air d'avoir à voir avec des threads et/ou des signaux.

[Emmanuel Delahaye]

Je ne vois pas pourquoi se priver d'un gain de temps .

On saura si on a gagné du temps le jour où on aura fait des mesures dans des conditions reproductibles... Se méfier des apparences.

Prendre aussi en compte le degré d'optimisation du compilateur qui peut très bien, après avoir compris l'intention du programmeur, choisir la stratégie de codage la plus efficace. Et je ne parle pas des pipelines et autres architectures complexes à prédiction...

Pour ces raisons, ce qu'on a pu écrire sur 'tableau vs pointeur' dans les années 80' à propos du langage C n'est plus si évident de nos jour avec les UC et compilateurs modernes...

Le seul critère objectif reste la mesure.

[Emmanuel Delahaye]

Sur toutes les implementations que j'ai rencontrees, la place prise en memoire pour un pointeur est celle d'un entier.

Tu n'as pas du faire beaucoup de x86 en mode réel!

[Emmanuel Delahaye]

En même temps l'espace mémoire occupé par une donnée est composée de son adresse et de sa valeur, non ?

L'adresse est une constante. Elle ne prend pas de place. C'est la valeur qui occupe une place en mémoire. Plus exactement, c'est la variable (l'objet). La valeur est le contenu de cette variable.

l'adresse d'un double long aura la même taille que celle d'un char,

Peut être...

mais au final la donnée double long prendra tout de même plus de place en mémoire, non ?

Oui, mais ça veut pas dire que le traitement d'une telle donnée sera plus lent ou plus rapide...

L'optimisation ne mène pas nulle part, j'en suis sûr.

Fait des mesures objectives avant de te prononcer...

D'ailleurs en voyant ce thread, je me suis dit que j'utiliserais peut être des unsigned char plutôt que des int, maintenant, pour les petites boucles qui nécessitent un indice.

Erreur. Il est recommandé d'utiliser toujours des int ou unsigned int (taille 'naturelle des objets vu du processeur) pour les travaux courants. Un char tout seul utilisé comme petit entier génère souvent plus de code, car il faut l'étendre en int pour le traiter dans les registres internes du processeur...

Idem pour les paramètres, on a jamais vu de paramètre de type [signed ]|[unsigned ]char dans la bibliothèque standard du C. Normal, tout paramètre 'char' est converti en 'int' automatiquement (idem pour 'short'). Cette conversion n'est pas gratuite.

[Emmanuel Delahaye]

En meme temps le gars kia codé ce for avait envie de se prendre la tete, c'est quand meme plus simple de faire tourner un i de 0 a la taille de la chaine...[/code]

ou d'utiliser printf() avec "%s"... Sans doute trop simple...

en même temps, il y a un wait(20) entre chaque affichage de caractère.
J'ai pas bien compris ce que faisait le wait(20),
ça a l'air d'avoir à voir avec des threads et/ou des signaux.

Ok, dans ce cas un putchar() aurait été plus léger...

[ggnore]

En même temps l'espace mémoire occupé par une donnée est composée de son adresse et de sa valeur, non ?

L'adresse est une constante. Elle ne prend pas de place. C'est la valeur qui occupe une place en mémoire. Plus exactement, c'est la variable (l'objet). La valeur est le contenu de cette variable.

l'adresse d'un double long aura la même taille que celle d'un char,

Peut être...
...
paramètre 'char' est converti en 'int' automatiquement (idem pour 'short'). Cette conversion n'est pas gratuite.

A quoi est ce qu'on peut se fier alors pour tenter d'optimiser du code ?

Si ça ne vaut rien d'essayer de mettre de types de variables le plus prêt possible du domaine de valeur d'une variable, je ne comprends plus rien.

Comment optimiser du code alors ?

A part tatonner et tester la vitesse d'éxécution ?
Faut il absolument connaître le fonctionnement interne du résultat compilé par le C ? Faut il comprendre comment ce résultat dialogue avec la machine ? Est ce que ça dépend beaucoup de la machine ?

[bball]

ok ok merci pour vos reponses elles m'ont été tres utiles encore merci

[fafounet]

Pour comparer deux codes C, il faut comparer la sortie ASM car les compilateurs optimisent beaucoup

[Emmanuel Delahaye]

En même temps l'espace mémoire occupé par une donnée est composée de son adresse et de sa valeur, non ?

L'adresse est une constante. Elle ne prend pas de place. C'est la valeur qui occupe une place en mémoire. Plus exactement, c'est la variable (l'objet). La valeur est le contenu de cette variable.

l'adresse d'un double long aura la même taille que celle d'un char,

Peut être...
...
paramètre 'char' est converti en 'int' automatiquement (idem pour 'short'). Cette conversion n'est pas gratuite.

A quoi est ce qu'on peut se fier alors pour tenter d'optimiser du code ?

Si ça ne vaut rien d'essayer de mettre de types de variables le plus prêt possible du domaine de valeur d'une variable, je ne comprends plus rien.

Comment optimiser du code alors ?

A part tatonner et tester la vitesse d'éxécution ?
Faut il absolument connaître le fonctionnement interne du résultat compilé par le C ? Faut il comprendre comment ce résultat dialogue avec la machine ? Est ce que ça dépend beaucoup de la machine ?

Optimiser pourquoi faire ?

L'expérience montre que pour gagner en efficacité, il faut :

• Ecrire le code normalement sans astuces particulière, mais en veillant comme toujours à ce qu'il n'y ai ni bug (facile) ni comportement indéfini (difficile...)
• Passer le code au profiler pour voir quelles sont la ou les fonctions les plus utilisées.
• Faire des mesures sur ces fonctions (facile, suffit d'instrumenter le test unitaire...).
• Voir si on peut améliorer l'algorithme (éviter les redondances, les parcours de listes et de tableaux imbriqués etc.)
• Monter le niveau d'optimisation du compilateur
• En dernier seluement, faire les micro optimisations. En fait, c'est rarement utile.

[ggnore]

Optimiser pourquoi faire ?

L'expérience montre que pour gagner en efficacité, il faut :

• Ecrire le code normalement sans astuces particulière, mais en veillant comme toujours à ce qu'il n'y ai ni bug (facile) ni comportement indéfini (difficile...)
• Passer le code au profiler pour voir quelles sont la ou les fonctions les plus utilisées.
• Faire des mesures sur ces fonctions (facile, suffit d'instrumenter le test unitaire...).
• Voir si on peut améliorer l'algorithme (éviter les redondances, les parcours de listes et de tableaux imbriqués etc.)
• Monter le niveau d'optimisation du compilateur
• En dernier seluement, faire les micro optimisations. En fait, c'est rarement utile.

Ok.

Est ce que essayer d'économiser la déclaration de variable peut être un plus ? Est ce que par exemple, déclarer 2 char *, parcequ'on veut avoir deux noms de variable causant crée une réelle différence avec la déclaration d'un seul char * qu'on va utiliser pour 2 travaux différents ?

ça doit sûrement être inquantifiable, non ?

Par ailleurs, que penses tu de ce genre de code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
int main(){
int a,b,c;
 
b=12;
a = 1 +b;
c=3;
{
int d;
d=48;
}
 
}

le code en lui même est sans intérêt, mais est ce que mettre des accolades au milieu d'une plus grosse portion de code pour pouvoir rendre une variable 'volatile' a un intérêt ? (ce que je veux dire, c'est qu'une fois l'accolade fermante autour du

Code :

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

int d;

la variable d n'a plus d'existence.)

[Emmanuel Delahaye]

Est ce que essayer d'économiser la déclaration de variable peut être un plus ? Est ce que par exemple, déclarer 2 char *, parcequ'on veut avoir deux noms de variable causant crée une réelle différence avec la déclaration d'un seul char * qu'on va utiliser pour 2 travaux différents ?

ça doit sûrement être inquantifiable, non ?

La seule réponse sensée est "faire des mesures"...

Par ailleurs, que penses tu de ce genre de code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
int main(){
int a,b,c;
 
b=12;
a = 1 +b;
c=3;
{
int d;
d=48;
}
}

le code en lui même est sans intérêt, mais est ce que mettre des accolades au milieu d'une plus grosse portion de code pour pouvoir rendre une variable 'volatile'[1] a un intérêt ? (ce que je veux dire, c'est qu'une fois l'accolade fermante autour du

Code :

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

int d;

la variable d n'a plus d'existence.)

Je fais ça tout le temps parce que ça résout beaucoup de problèmes de conception.

http://emmanuel-delahaye.developpez....tes.htm#portee

Quand à l'effet sur la mémoire, il est variable. Certain compilateurs savent réutiliser la mémoire automatique libérée, d'autres ne se posent même pas la question et allouent toutes les variables sur la pile sans réflechir (MRI de Mentor Graphics, par exemple)...

--------------------------
[1] Attention, le terme 'volatile' a un sens précis en C (c'est même un mot clé) et il n'a rien à voir avec l'utilisation que tu en fais...

[moldavi]

Je pense qu'au niveau de l'optimisation, il est bon d'avoir certains réflexes. Je ne dis pas de programmer des portions de code en assembleur, mais de réfléchir à ses algorithmes dans les portions critiques du programme.

Je suis d'accord avec Emmanuel, faire des mesures peut parfois nous apprendre beaucoup de choses.

Juste un exemple: souvent dans mes premiers programmes, j'écrivais mes propres fonctions de concaténation ou de copie de chaîne de caractères.
Et puis un jour j'ai fait des mesures. Et bien quelle surprise lorsque je me suis aperçu que les fonctions strcat, strcpy, etc... étaient bien plus optimisées que ce que je ne pouvais faire.

Donc oui faire des tests, une fois que l'on a pris quelques habitudes, il devient moins nécessaire de s'inquiéter de l'optimisation.

Je pense que le programmeur qui s'inquiète de savoir si le code qu'il écrit est du bon code, est un bon état d'esprit. Je dirais que se poser des questions sur l'optimisation est presque un réflexe pour les programmeurs débutants. Quand on débute on veut savoir si notre code est efficace et optimisé.

Les programmeurs avancées se posent moins ce genre de question(sauf cas particulier, ex: jeux vidéos), parce qu'ils ont pris certaines habitudes et que leur code a pû être maintes fois éprouvé.