Est-ce que quelqu'un connait les cycles machines approximatifs que coûtent les opérations de base du C++? Et les fonctions?
 
Y'a t'il un site web avec un récapitulatif?
 
Merci de votre réponse
Elsener

Ben ca depend du compilateur et du processeur... tu peux pas controler ce genre de choses...
Si vraiment tu dois ecrire une routine qui fonctionne en un nombre donne de cycles machines (comme aux temps valeureux des demomakers sur 68000), utilise l'assembleur...

Je voudrais juste savoir si un appel de fonction est quelque chose de très lourd pour le CPU  
 
En fait j'ai une classe avec des variables, et j'ai fait des méthodes pour changer ces variables. Donc je me demande si c'est beaucoup plus lourd que de faire des variables publiques et laisser l'utilisateur les modifier comme il le souhaite (sans passer par aucune fonction)? C'est juste pour avoir un ordre de grandeur quoi...

Tu peux utiliser l'inlining pour les méthodes simples.

Un exemple :
 
class Arf
{
  int valeur;
public:
  void setValeur(int tvaleur) { valeur= tvaleur; }
  void compute();
};
 
Les fonctions definies dans la declaration de la classe (dans le .h) sont automatiquement transformees en inline. Ca veut dire que ton compilo optimisera lors de la compilation, en ne faisant pas d'appel de fonction, mais en transcrivant telle quelle la fonction au sein meme du programme.
 
Arf arf;
arf.setValeur(2);
 
sera transforme en :
Arf arf;
arf::valeur=2;
 
Et si tu veux que d'autres fonctions soient integrees en inline, il suffit de le preciser.
 
inline void Arf::compute() {}
 
Auquel cas l'appel a compute() ne fera pas l'objet d'un appel de fonction, mais le compilo fera un copier coller de sa definition au sein meme du code source.
 
Voila voila.
Et donc pour resumer, c'est aussi rapide de faire des inline que des variables globales. Donc variables globales a eviter...

[edit]--Message édité par tgrx--[/edit]

Comme l'indique tgrx, la directive INLINE permet d'inclure le code s'il n'est pas trop long.
 
Toutefois, avec les prédicteurs de branchements qu'il y a intégré dans les processeurs modernes, le cout d'un appel de fonction peut être faible par rapport au cout des paramètres à pusher sur la stack.

C'est meme ce qu'il faut faire...
1- en debug tu genere un appel facilite de debugage
2- en release ca va plus vite
 
Dans mon cas environ 30% de gagne grace a l'inline et 10 % grace aux optimisations du compilo...

Merciiii
 
Je vais faire des essais comparatifs!
On verra ce que ça donne...
 
Merci encore à tous, @ bientôt    
 
Elsener

Il faut faire gaffe aux parametres que tu fournis aux fonctions non-inlinees.
 
Ex: void fonction(Arf arf);
 
Surtout pas ! Car a chaque appel de la fonction, le C++ va creer une copie de la classe Arf, et l'empiler, etc... ca prend enormement de temps.
-> Preferer les references et/ou les pointeurs qui ne prennent que 4 octets chacun, et c'est vite empile.
void function(Arf& arf);
void function(Arf* arf);
 
Et dans ce cas, comme l'a precise n0mad, ca devient rapide, la pile n'est pas trop surchargee.

Donc passer une variable int à une fonction est plus rapide par l'intermédiaire d'un pointeur?

[edit]--Message édité par Elsener--[/edit]

 
non, les 2 sont codés sur 32 bits, c'est pareil

Non, pour les types simples ca va. C'est seulement tout ce qui est plus gros que la taille de tes registres (32 bits sur PC par ex).
 
En général, les class et les struct c'est mieux. Le reste c'est selon (éviter au max les pointeurs).

Oky alors je fais juste pour l'instant
Tout ce qui n'est pas un type de base je le passe par référence ou par pointeur, donc pas trop de probs de ce côté là! Merci les gars pour ces précieuses infos!

Bon j'ai une page html très bien faite pour le pentium et+
Le problème est que je n'ai pas le nom du site sous les yeux, alors il faudra chercher.
L'auteur est "Agner Fog" le titre de la page est
"How to optimize for the Pentium family of microprocessors"

Je ne suis pas d'accord, et je le dis...
1- premierement, il faudrait utiliser le mot cle const pour eviter de modifier la valeur (dans un passge par valeur c'est impossible, alors que la...)
 
2- void function(Arf arf) n'est pas equivalent a void function(const Arf& arf) ou a void function (const Arf *arf)...
si on passe une classe derivee de Arf a la fonction, celle-ci recois une copie de type Arf dans le premier cas, et la classe d'un type derive dans le second. d'ou difference de comportement si il y a des methodes surchargees...
 
Les modifications sont a faire en connaissance de cause.
(Bon en general c'est (const Arf& arf) que l'on souhaite)

BENB> OUI. Tu as tout a fait raison.
 
Je decrivais juste de maniere tres basique comment faire pour optimiser du code source, et eviter de perdre betement des cycles machines... (sic)
 
Maintenant si on rentre dans le detail... evidemment & != *
Mais je ne crois pas que c'etait le but du topic.

Une petite remarque sur le post:
 
L'optimisation de ton code, fais la a la fin du developpement.
Si t'as mis les pieds dans l'objet, c'est pas la peine de tout saloper a vouloir optimiser le code des le debut. Il faut surtout respecter d'abord la clarte du code et le modele objet. Ensuite seulement doivent venir les questions existentielles sur l'optimisation du code. Tu utilise pour ca des outils de monitoring. En general, moins de 10% du code utilise 90% du temps CPU. C'est donc pas la peine de compliquer inutilement le reste.  
 
L'argument qui consiste par exemple a dire que toute recopie est proscrite est a prendre avec des pincettes (des fois, la recopie d'un objet est indispensable et vouloir ruser a tout prix pour grapiller ca et la un cycle d'horloge donne du code inutilisable par la suite.)

tgrx a écrit a écrit : BENB> OUI. Tu as tout a fait raison.   ....   Maintenant si on rentre dans le detail... evidemment & != * Mais je ne crois pas que c'etait le but du topic.

 
La difference entre * et & est philosophique mais importante
Par contre la difference entre (Arf) et (const Arf &) lors d'un passge d'argument est suffisement importante pour etre signalee a quelqu'un qui on conseille de changer l'un pour l'autre !
Le comprtement du proramme peut en etre affecte...

wpk>   C'est très juste, et malheureusement trop souvent oublié ou ignoré.