Discussion :

[gronaze]

je cherche à optimiser mon code au maximum, est ce qu'il existe une "table"
qui definie le nombre d'operation machine par instruction, ou un truc dans le genre pour que je connaisse les instructions les plus gourmandes en temps...

[Emmanuel Delahaye]

je cherche à optimiser mon code au maximum, est ce qu'il existe une "table"
qui definie le nombre d'operation machine par instruction, ou un truc dans le genre pour que je connaisse les instructions les plus gourmandes en temps...

Ca dépend de tellement de choses plus ou moins complexes, que c'est quasiment imprévisible. Il faut faire des mesures. Un profiler (gprof, par exemple) peut aider.

[Gruik]

Du temps des 186 à 386, yavait des instructions machine qui prenaient plus d'un cycle (comme la multiplication)
Mais je crois qu'aujourd'hui toute instruction machine, sur PC, fait 1 cycle. En tout cas l'affectation et l'addition c'est sur.
Apres faut savoir que les variables doivent etre mises dans des registres avant operation (ce qui coute une affectation). Il faut savoir aussi que le compilateur est tres intelligent et qu'il cherche à mettre dans les registres des contenus de variable qu'un minimum de fois (pour eviter au maximum le transfert à la memoire vive qui est lente).
C'est typiquement le cas d'un i dans une boucle for...
Apres, toute indexation (tab[i]) ou acces à un champ (objet.champ) coute une addition supplementaire, evidemment. Et les indirections (*ptr ou ptr->champ) coutent une affectation supplementaire, evidemment.

Si tu veux te prendre la tete, je crois qu'une option du compilateur permet de generer le code assembleur correspondant au code machine créé et ainsi voir ce qu'a fait exactement le compilateur

Apres, un truc important à savoir, c'est qu'un appel à une fonction coute pas mal d'operations, entre l'enregistrement de l'adresse de retour, l'empilage des parametres, le deplacement du pointeur de pile et du pointeur de code.

[Emmanuel Delahaye]

Si tu veux te prendre la tete, je crois qu'une option du compilateur permet de generer le code assembleur correspondant au code machine créé et ainsi voir ce qu'a fait exactement le compilateur

Avec les caches mémoire et instruction, les pipe-lines, la prédiction... tu ne vas rien voir du tout. Détails dans la doc Intel...

Le Pentium 4 , c'est pas le 386...
De même, pour les Maceux, le Power PC, c'est pas le 68000...

[gronaze]

Ok merci pour le gprof ça correspond assez bien a ce que je cherchais

[Gruik]

Avec les caches mémoire et instruction, les pipe-lines, la prédiction... tu ne vas rien voir du tout. Détails dans la doc Intel...

Le Pentium 4 , c'est pas le 386...
De même, pour les Maceux, le Power PC, c'est pas le 68000...

Tu m'as cassé


Oui ce sont des choses qui nous depassent completement
Comme il a dit, la seule solution pour savoir ce qui est plus rapide c'est le bench et le profiler (que je connaissais pas)