Discussion :

[bolhrak]

Bonsoir à tous,

Juste une petite question concernant le choix entre l'utilisation du passage de paramètres par référence et celui par copie. Pour les objets de grande taille, aucun problème, la réponse est évidente. Par contre pour ceux de petite taille, c'est plus délicat. D'après ce que j'ai pu lire, le passage par copie est préférable pour les types de base tels int ou double, car le proc peut utiliser un registre pour stocker cette valeur plutôt que de l'allouer sur la stack.

Maintenant qu'en est-il des objets genre complex (deux doubles) ? A priori cet objet sera alloué sur la pile s'il est copié, donc une référence semble plus apropriée. Pourtant l'implémentation du type complex de la librairie standard préfère le passage de complex par copie (pour les opértateurs arithméthiques par exemple). Y'a-t-il une raison à ce choix et une réelle modification des performances ?

[Sergejack]

Il y a un juste équilibre à trouver entre la sécurisation des données et les performances, puisque passer les paramètre par copie offre la sécurité de ne pas rallonger la portée des données outre mesure (sécurité face à l'erreur de programmation donc).

L'équilibre a été estimé en faveur du passage par recopie en ce qui concerne les complexes.

[Luc Hermitte]

La "sécurité" dont tu parles n'a de sens que dans un environnement multithréadé si la donnée passée est une entité pouvant évoluer. Ou que l'on ne trouve rien de mieux que de stocker une référence vers cette dernière. Dans ce dernier cas, il faut juste réfléchir aux dépendances. C'est exactement pareil que de garder des pointeurs.

C'est au nouveau du double double (sic) que je commence à faire un coup d'une façon, un coup de l'autre. Probablement parce que je ne me suis pas amusé à faire des mesures de perfs.

[Jean-Marc.Bourguet]

Il y a aussi des désavantages d'un point de vue performance à utiliser le passage par référence: les accès ont une indirection supplémentaire; donc le choix optimal peut être dépendant de l'implémentation de la fonction.

A mon avis, c'est typiquement le genre de choix qui devrait être laissé au compilateur (comme en Ada où le compilateur peut passer les paramètre in par valeur ou référence comme il veut -- sauf quelques exceptions comme les types limités où le passage par référence est obligatoire) et à ceux qui définissent l'ABI, car ils sont les seuls qui disposent réellement de l'information nécessaire pour choisir.

A noter en ce qui concerne l'utilisation des registres pour le passage des paramètres que rien n'interdit au compilateur d'implémenter:

Code :

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

1
2
3
void f(C obj) {
   ...
}

comme

Code :

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

1
2
3
4
void f(C& _obj) {
C obj(_obj);
   ...
}

Ce qui a au moins l'avantage de pouvoir diminuer la taille du code généré (et donc la pression sur les caches).

[Charlemagne]

Je vois encore d'autres critères qui peuvent influencer sur le choix d'un passage par référence ou par valeur:

-Si le paramètre est un template (99% des cas dans mes programmes), il vaut mieux faire un passage par référence étant donné qu'on ne connait pas (a priori) la taille du paramètre

-Si le temps d'appel de la fonction n'est pas négligeable par rapport à son temps d'exécution, alors c'est probablement une fonction qui pourrait/devrait être inlinée. J'ai déjà visualisé le code généré par mon compilo (Intel Compiler) pour les 2 types de passages sur des fonctions inlines: il ne fait aucune différence car tout est géré dans les registres.


Dans l'ensemble, je dirais qu'il faut passer:
- les types simples par valeur
- tout le reste par référence

Mais si tu veux en avoir le coeur net sur ton programme, rien ne remplacera une mesure des temps d'exécution

[Matthieu Brucher]

A ce sujet, pour les types simple, je crois que Boost propose un type templaté adapté - si le compilo le supporte -, ce qui permet d'activer le passage par référence ou pas selon le paramètre, justement

[Laurent Gomila]

Oui, a priori boost::call_traits<T>::param_type serait une bonne solution dans la plupart des cas. En tout cas c'est fait pour.

[Matthieu Brucher]

Tiens, j'avais même vu ça, y'a vraiment trop de truc dans Boost

[Charlemagne]

Ca devient quand même un peu lourd comme syntaxe avec boost. Ca va finir, on ne va plus du tout utiliser les éléments du C++.
Il peut y avoir pas mal de fonctions dans un programme.

Je me disais également que les itérateurs sont transférés par valeur dans les divers algorithmes de la STL (STLport en tout cas). Les itérateurs sont effectivement de bon candidats pour les appels par valeurs:
-en général de petite taille
-fréquemment utilisés (dans les boucles 'for')

[Matthieu Brucher]

Effectivement, dans la STL, on passe par valeur.

[bolhrak]

De mémoire il me semble que parameter_traits passe tous les types primitifs par copie et les types définis par l'utilisateur par référence, et là il s'agissait justement d'un type défini par l'utilisateur mais tellement petit (et dont le passage se fait par copie au niveau de la STL) que du coup je me posais la question.

En tout cas merci pour vos réponses

[Luc Hermitte]

Tiens, j'avais même vu ça, y'a vraiment trop de trucs dans Boost

Et c'est sans compter tous les trucs qui sont planqués : p.ex., atomic_count (dans les détails des smart-pointers), code convertion facet pour l'UTF-8 (détails de program-options ou de serialize, je ne sais plus), et je ne doute pas qu'il y ait d'autres trucs dans le genre si on creuse un peu.

Autrement, je ne suis pas sûr qu'il s'agisse d'une distinction primitif <-> custom. Il me semblait plutôt qu'ils utilisaient le SFINAE pour embrayer sur une définition ou l'autre en fonction de la taille du type. C'est à vérifier.