Re: const - C++ (French)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Re: const
Goto page 1, 2 Next

C++Talk.NET Forum Index -> C++ (French)

View previous topic :: View next topic

Author

Message

Marc Boyer
Guest

Posted: Wed Jul 30, 2003 12:57 pm Post subject: Re: const

In article <bg8en6$tmv$1 (AT) biggoron (DOT) nerim.net>, Frédéri MIAILLE wrote:

Quote:

Question ! (j'arrive pas à trouver dans mes bouquins)
des fois je vois des fonctions déclarées comme suit :
void FuncMachinChose(int lala) const;

Ce doit être une fonction membre d'une classe, non ?

Quote:

Le dernier "const" il sert à quoi ?

A dire que l'appel de cette fonction ne modifie pas
pas l'objet appelant (sauf subtilité "mutable" que tu verras
dans un deuxième temps).

Quote:

Autre question :

void MaFunc()
{
int a; float b;
// ..implémentation.
}

Fonction normale. Les variables a et b sont déclarées et allouées à chaque
passage dans la fonction. Question performances, ça donne quoi ?
Y a t'il une perte si insignifiante soit-elle ?

Par rapport à quoi ?

Quote:

Veut-mieux t'il déclarer ces variables en globales ?

Hormis cas très particulier: NON !
Car les variables locales aux procédures
1) sont détruites (et la mémoire libérée) à la fin de
la procédure
2) les variables locales permettent la récursivité
3) l'espace de nom est "local", tu peux donc te permettre
d'avoir deux fonctions qui manipulent des variables locales
de même nom. Cele permet aussi de "localiser" l'usage d'une
variable (imagine le nombre de variable utilisées dans un
prog de 200.000 lignes).

Quote:

void MaFunc()
int a; float b;
{
// ..implémentation.
}
Alors a et b on une portée locale au bloc de la function "MaFunc()".
Nous sommes d'accords.
Ils sont realloués à chaque passage dans la fonction ?

Oui.

Quote:

Enfin, dernière question :
si on les met inline, j'ai remarqué que ces fonctions prennent plus de temps
que les macros. Il y a donc bien un appel.

Ca dépend des compilateurs, des options, etc.

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Gabriel Dos Reis
Guest

Posted: Wed Jul 30, 2003 1:17 pm Post subject: Re: const

Marc Boyer <Marc.Boyer (AT) enseeiht (DOT) yahoo.fr> writes:

Quote:

In article <bg8en6$tmv$1 (AT) biggoron (DOT) nerim.net>, Frédéri MIAILLE wrote:
Question ! (j'arrive pas à trouver dans mes bouquins)
des fois je vois des fonctions déclarées comme suit :
void FuncMachinChose(int lala) const;

Ce doit être une fonction membre d'une classe, non ?

Le dernier "const" il sert à quoi ?

A dire que l'appel de cette fonction ne modifie pas
pas l'objet appelant (sauf subtilité "mutable" que tu verras
dans un deuxième temps).

Plus exactement à dire que la fonction promet ne pas modifier l'objet
-- mais elle peut renier sa promesse, elle n'a pas besoin de la
présence de mutable pour cela.

-- Gaby

Christophe Lephay
Guest

Posted: Wed Jul 30, 2003 2:41 pm Post subject: Re: const

"Frédéri MIAILLE" <bobranger_no_spam (AT) wanadoo (DOT) fr> a écrit dans le message de
news:bg8en6$tmv$1 (AT) biggoron (DOT) nerim.net...

Quote:

void MaFunc()
{
int a; float b;
// ..implémentation.
}

Fonction normale. Les variables a et b sont déclarées et allouées à chaque
passage dans la fonction. Question performances, ça donne quoi ?
Y a t'il une perte si insignifiante soit-elle ?
Veut-mieux t'il déclarer ces variables en globales ?

Programmer en C++ au lieu de l'assembleur implique en général une perte de
performance, aussi insignifiante soit-elle. De fait, pourquoi te poser des
questions sur des baisses de performances si elles sont insignifiantes ?
D'une manière générale, si tu utilises correctement le langage, tu n'auras
pas de problèmes de performance alors que ton code, en revanche, sera bien
plus lisible et robuste (deux critères qui priment nettement sur l'aspect
performances pures).

En plus, pour ce qui concerne les performances, c'est souvent au niveau
algorithmique que les gains sont les plus important. Alors il vaut mieux
avoir une baisse de performance insignifiante d'un coté du fait de l'emploi
normal du langage qui fait bénéficier, d'un autre coté, de possibilités bien
plus poussées coté algorithmique (et surtout bien plus facilement).

Quote:

Oui. Ceci dit, la pile est allouée au chargement du programme. Le terme
"allocation" quand on l'applique aux variables auto (sur la pile) désigne
plus un appel au constructeur qu'une véritable allocation.

Tu peux éviter une "allocation" à chaque passage en déclarant les variables
static dans ta fonction, bien que ce ne soit conseillé que quand tu as
vraiment une bonne raison pour le faire (la ré-allocation l'est rarement en
elle-même). Entre autres inconvénients, des variables locales static ne
permettent pas une utilisation récursive de la fonction (comme le signale
Marc dans un autre post).

D'une manière générale, il faut limiter le plus possible la portée des
identificateurs car ils polluent l'espace de nom (en voulant accéder à une
variable, tu peux avoir un problème difficile à trouver si une utre variable
avec le même nom a été définie plus localement, par exemple) et compliquent
la lisibilité (tu comprends mieux comment un code fonctionne si tu ne dois
pas ouvrir cinquante fichiers pour retrouver les différentes déclarations).
Dans le cas des variables globales, plus particulièrement, tu n'as aucune
indication sur quelle fonction y accède ou les modifie, ce qui peut
également créer des problèmes de déboguage ("l'effet de bord").

Quote:

Enfin, dernière question :
si on les met inline, j'ai remarqué que ces fonctions prennent plus de
temps
que les macros. Il y a donc bien un appel.

Il n'y a pas de garanties que le compilateur expanse la fonction en ligne
même si tu la déclares inline. Notemment, les compilateurs désactivent
généralement cette fonctionnalité quand tu es en mode debug. Par ailleurs,
si le compilateur ne réalise pas l'expansion en ligne de la fonction même en
mode release (le contraire du mode debug), c'est que la fonction est trop
complexe, ce qui exclue de toute façon son remplacement par une macro.

Quote:

j'ai même vu qu'il existait un __forceinline sous certains environnements
que je ne citerai pas. Franchement, ça sert à quoi sachant que si le
compilateur ne peut pas, il ne met pas inline et s'il le peut, il met
inline. Alors que dans la doc machinsoft, le __forceinline dit la même
chose. Ils réinventent les mots clés ?

En plus de pouvoir le faire ou non, le compilateur fait une estimation sur
l'intéret effectif d'inline. C'est pour bypasser ("circonvenir" ?) ce
mécanisme que de tels mots clés peuvent exister le cas échéant.

Chris

kanze@gabi-soft.fr
Guest

Posted: Thu Jul 31, 2003 9:06 am Post subject: Re: const

"Frédéri MIAILLE" <bobranger_no_spam (AT) wanadoo (DOT) fr> wrote

Quote:

Question ! (j'arrive pas à trouver dans mes bouquins)

des fois je vois des fonctions déclarées comme suit : void
FuncMachinChose(int lala) const;

J'ai rêvé ?
Le dernier "const" il sert à quoi ?

À générer une erreur de compile.

Pour qu'on puisse déclarer une fonction const, il faut qu'elle soit
membre non-statique d'une classe. L'effet immédiate de déclarer la
fonction membre const, c'est que le pointeur this est un pointeur vers
const. Ce qui a plusieurs répercussions :

- On ne peut pas modifier des données membre de la classe à
l'intérieur de la fonction, au moins d'utiliser un const_cast, ou
qu'elles soient déclarées mutable.

- On peut appeler la fonction avec un pointeur ou une référence à un
const, ou sur un objet const. Normalement, si la fonction n'est pas
déclarée const, il faut lui fournir un pointeur à non-const pour le
this -- si l'objet est const, ou si on a un pointeur ou une
référence à const, on ne peut pas obtenir un pointeur non-const pour
le this.

Note que cette règle s'applique à l'intérieur des fonctions const --
le this étant const, on ne peut appeler que des fonctions const sur
l'objet.

En général, la présence de const sur la fonction est prise comme une
promesse de ne pas changer la « valeur » de l'objet -- la définition de
ce qu'on entend par sa « valeur » faisant partie du contrat de la
classe. Donc, si j'ai une classe simple :

class String
{
public:
// ...
void someFunction() const ;

private:
char* myText ;
} ;

À l'intérieur de someFonction, je ne peux pas modifier myText (au moins
d'utiliser un const_cast). En revanche, en ce qui concerne le langage,
il n'y a rien qui m'empêche de faire des choses comme
« *myText = '' ». Conventionnellement, en revanche, on ne les fait
pas -- on considère que le « const » exprime un contrat de la
non-mutation de la valeur. (C'est la distinction entre le const
« bit-wise » et le const logique. Il y a eu pas mal de discussions sur
le sujet aux alentours de 1993, avec la caractèrisation du const logique
comme « le const Humptey-Dumpty » (voir « À travers le miroire », de
Lewis Carrol) , mais je crois qu'aujourd'hui, il y a un concenssus sur
le const logique.)

Quote:

Autre question :

void MaFunc()
{
int a; float b;
// ..implémentation.
}

Fonction normale. Les variables a et b sont déclarées et allouées à
chaque passage dans la fonction. Question performances, ça donne
quoi ?

Ça dépend de la machine. En général, les compilateurs génère une trame
de pile nouvelle à chaque appel de fonction ; l'allocation de la place
pour des variables locales en fait partie, et donc, ne coûte absolument
rien. Dans certains cas des fonctions « feuilles », c'est possible que
certains compilateurs s'en passe ; dans ces cas-là, la présence des
variables locales peut peut-être exiger une ou deux instructions de
plus.

Mais par rapport à quoi ? Si tu as besoin de la variable, tu en as
besoin, non ? (Et il ne faut pas oublier non plus que si tu as des
expressions trop compliquées, le compilateur peut être amené à générer
des variables locales sans que tu en déclares.)

Quote:

Y a t'il une perte si insignifiante soit-elle ? Veut-mieux t'il
déclarer ces variables en globales ?

Typiquement, au moins sur les machines actuelles auxquelles j'ai accès
(Sparc, par exemple), l'accès à une variable globale coûte nettement
plus cher que l'accès à une variable locale. Même sur des architectures
anachronistique, comme l'Intel, l'utilisation des variables globales
posent des problèmes pour l'optimisateur.

Quote:

void MaFunc()
int a; float b;
{
// ..implémentation.
}

Alors a et b on une portée locale au bloc de la function "MaFunc()".
Nous sommes d'accords. Ils sont realloués à chaque passage dans la
fonction ?

Oui.

Quote:

Enfin, dernière question :
si on les met inline, j'ai remarqué que ces fonctions prennent plus de
temps que les macros. Il y a donc bien un appel.

Moi, je n'ai pas remarqué une telle chose. Ce n'est le cas ni avec g++,
ni avec Sun CC. Quand on démande l'optimisation, évidemment ; sans
l'optimisation, ni l'un ni l'autre génère inline.

Quote:

Tout dépend du compilateur. Il existe de rares compilateurs qui font la
décision de façon complètement autonôme, sans prendre en compte
l'expression de l'utilisateur du tout. Mais pour la plupart, le
compilateur ferait davantage d'effort à générer en ligne une fonction
déclarée inline.

Il y a aussi le fait que inline te permet à mettre la définition de la
fonction dans toutes les unités de compilation. Il y a encore assez peu
de compilateurs qui sont capable à générer du code en ligne si l'unité
de compilation ne contient pas la définition de la fonction.

Quote:

Alors que dans la doc machinsoft, le __forceinline dit la même
chose. Ils réinventent les mots clés ?

Ça, il faut lire la documentation du compilateur. A priori, d'après le
nom, je m'attendrais à ce que le compilateur génère la fonction en ligne
quoiqu'il arrive, et non seulement qu'il fasse davantage d'effort. En
revanche, je ne vois pas comment un compilateur pourrait mettre quelque
chose comme le suivant en ligne :

double
sum( double* array, size_t length )
{
return length == 0
? 0.0
: *array + sum( array + 1, length - 1 ) ;
}

(Évidemment, ce n'est pas comme ça que j'écrirais la fonction
normalement:-). C'est juste pour montrer.)

--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Loïc Joly
Guest

Posted: Thu Jul 31, 2003 4:57 pm Post subject: Re: const

read_in wrote:

Quote:

les fonctions inline sont plus rapides car il n'y a pas tout le traffic de
sauvegarde/restauration des registres comme on le fait pour une fonction
normale (humm, les cours d'ASM...)

Un autre gain souvent encore plus important de l'inlining est que
l'appel de fonction n'est plus une frontière pour l'optimisation, et
donc l'optimisation possible est souvent bien plus efficace.

--
Loïc

drkm
Guest

Posted: Thu Jul 31, 2003 9:22 pm Post subject: Re: const

"Christophe Lephay" <christophe-lephay (AT) wanadoo (DOT) fr> writes:

Quote:

Oui. Ceci dit, la pile est allouée au chargement du programme.

Mais elle peut grandir au cours de l'exécution du programme, non ?
Par exemple, dans le programme suivant, il n'apparaîterait pas
d'allocation de (parties de) la pile ?

void f( int i )
{
char dummy[] =
"GCC 3.4 Release Seriesn"
"Changes, New Features, and Fixesn"
"Caveatsnn"
" * With -nostdinc the preprocessor used to ignore both"
" standard include paths and include paths contained in"
" environment variables. It was neither documented nor intended"
" that environment variable paths be ignored, so this has been"
" corrected.n"
" * GCC no longer accepts the options -fvolatile,"
" -fvolatile-global and -fvolatile-static. It is unlikely that"
" they worked correctly in any 3.x release.n"
" * GCC no longer ships <varargs.h>. Use <stdarg.h>"
" instead.n"
" * Support for all the systems obsoleted in GCC 3.3 has"
" been removed from GCC 3.4. See below for a list of systems"
" which are obsoleted in this release.n"
" * GCC now requires an ISO C90 (ANSI C89) C compiler to"
" build. K&R C compilers will not work.nn"
"General Optimizer Improvementsnn"
" * Usability of the profile feedback and coverage testing"
" has been improved.n"
" o Performance of profiled programs has been improved"
" by faster profile merging code.n"
" o Better use of the profile feedback for"
" optimization (loop unrolling and loop peeling).n"
" o File locking support allowing fork() calls and"
" parallel runs of profiled programs.n"
" o make profiledbootstrap available to build a faster"
" compiler.n"
" * Inlining heuristics for C, ObjC, C++ and Java have been"
" improved significantly. Call graph based out-of-order"
" inlining is now enabled by default at -O3.nn"
"New Languages and Language specific improvementsn"
"C/ObjC/C++nn"
" * Precompiled headers are now supported. Precompiled"
" headers can dramatically speed up compilation of some"
" projects. There are some restrictions; read the manual for"
" the details.nn"
"C++nn"
" * A hand-written recursive-descent C++ parser has replaced"
" the YACC-derived C++ parser from previous GCC releases. The"
" new parser contains much improved infrastructure needed for"
" better parsing of C++ source codes, handling of extensions,"
" and clean separation (where possible) between proper"
" semantics analysis and parsing. The new parser fixes many"
" bugs that were found in the old parser.nn"
"Objective-Cnn"
" *nn"
"Javann"
" *nn"
"Fortrannn"
" * Fortran improvements are listed in the Fortran"
" documentation.n" ;

if ( i > 0 ) {
f( i - 1 ) ;
}
}

int main()
{
f( 10000 ) ;
}

Hormis bien sûr le fait que ce programme dépasse la limite de
longueur des chaînes litérales Wink

. Qui est de 509, si je me souviens
bien. Pourquoi un tel nombre au fait ?

--drkm

Loïc Joly
Guest

Posted: Thu Jul 31, 2003 11:28 pm Post subject: Re: const

drkm wrote:

Quote:

"Christophe Lephay" <christophe-lephay (AT) wanadoo (DOT) fr> writes:

Oui. Ceci dit, la pile est allouée au chargement du programme.

Mais elle peut grandir au cours de l'exécution du programme, non ?
Par exemple, dans le programme suivant, il n'apparaîterait pas
d'allocation de (parties de) la pile ?

void f( int i )
{
char dummy[] =
"GCC 3.4 Release Seriesn"
"Changes, New Features, and Fixesn"
"Caveatsnn"
" * With -nostdinc the preprocessor used to ignore both"
" standard include paths and include paths contained in"
" environment variables. It was neither documented nor intended"
" that environment variable paths be ignored, so this has been"
" corrected.n"
" * GCC no longer accepts the options -fvolatile,"
" -fvolatile-global and -fvolatile-static. It is unlikely that"
" they worked correctly in any 3.x release.n"
" * GCC no longer ships <varargs.h>. Use <stdarg.h>"
" instead.n"
" * Support for all the systems obsoleted in GCC 3.3 has"
" been removed from GCC 3.4. See below for a list of systems"
" which are obsoleted in this release.n"
" * GCC now requires an ISO C90 (ANSI C89) C compiler to"
" build. K&R C compilers will not work.nn"
"General Optimizer Improvementsnn"
" * Usability of the profile feedback and coverage testing"
" has been improved.n"
" o Performance of profiled programs has been improved"
" by faster profile merging code.n"
" o Better use of the profile feedback for"
" optimization (loop unrolling and loop peeling).n"
" o File locking support allowing fork() calls and"
" parallel runs of profiled programs.n"
" o make profiledbootstrap available to build a faster"
" compiler.n"
" * Inlining heuristics for C, ObjC, C++ and Java have been"
" improved significantly. Call graph based out-of-order"
" inlining is now enabled by default at -O3.nn"
"New Languages and Language specific improvementsn"
"C/ObjC/C++nn"
" * Precompiled headers are now supported. Precompiled"
" headers can dramatically speed up compilation of some"
" projects. There are some restrictions; read the manual for"
" the details.nn"
"C++nn"
" * A hand-written recursive-descent C++ parser has replaced"
" the YACC-derived C++ parser from previous GCC releases. The"
" new parser contains much improved infrastructure needed for"
" better parsing of C++ source codes, handling of extensions,"
" and clean separation (where possible) between proper"
" semantics analysis and parsing. The new parser fixes many"
" bugs that were found in the old parser.nn"
"Objective-Cnn"
" *nn"
"Javann"
" *nn"
"Fortrannn"
" * Fortran improvements are listed in the Fortran"
" documentation.n" ;

if ( i > 0 ) {
f( i - 1 ) ;
}
}

int main()
{
f( 10000 ) ;
}

Hormis bien sûr le fait que ce programme dépasse la limite de
longueur des chaînes litérales Wink

. Qui est de 509, si je me souviens
bien. Pourquoi un tel nombre au fait ?

--drkm

Je pense que n'importe quel compilateur un peu intelligent traduira ton
programme en :

int main()
{
}

--
Loïc

Christophe Lephay
Guest

Posted: Fri Aug 01, 2003 1:41 am Post subject: Re: const

"drkm" <darkman_spam (AT) yahoo (DOT) fr> a écrit dans le message de
news:wk8yqepf10.fsf (AT) yahoo (DOT) fr...

Quote:

Changer la taille de la pile, celà voudrait dire une nouvelle allocation et
le déplacement de tout ce qui s'y trouve. C'est probablement faisable, mais
à quel coût ! D'ailleurs, si on le faisait, il deviendrait assez peu
interessant d'y stocker les variables locales, vu que c'est justement
l'intéret de les stocker dans la pile (ou "sur la pile" ?).

La pile est de taille fixe et allouée par le loader au chargement du
programme. Un exécutable peut demander au loader une taille de pile plus ou
moins importante, mais elle ne change pas durant l'exécution du programme.

Dans l'exemple que tu donnes, la chaine de caractère n'est pa stockée dans
la pile mais dans un segment de données. Si tu as plus de données dans la
pile qu'elle ne peut en contenir, elle ne s'agrandit pas et ton programme
plante (la façon dont il plante dépend de l'environnement).

En fait, la taille de la pile change bel et bien au cours de l'exécution
dans la mesure où elle se rétrécit à chaque imbrication de fonction, et se
ré-agrandit quand tu quittes une fonction. Cependant la mémoire est allouée
au chargement du programme, et la taille qui semble varier n'est du qu'au
déplacement du pointeur de pile (incrémentation ou décrémentation du
registre correspondant).

Chris

drkm
Guest

Posted: Fri Aug 01, 2003 1:51 am Post subject: Re: const

Loïc Joly <loic.actarus.joly (AT) wanadoo (DOT) fr> writes:

Quote:

Je pense que n'importe quel compilateur un peu intelligent traduira
ton programme en :

int main()
{
}

Ok. Mais la question portait sur la pile. Tu peux ajouter une
sortie du tableau de caractères dans un flux, par exemple, et tirer le
paramètre effectif de l'appel dans main d'une variable d'environement.
Le compilateur sera bien obligé d'utiliser la récursivité.

Et que se passera-t-il au niveau de la pile ? Elle grandira au fur
et à mesure. Non ?

--drkm

drkm
Guest

Posted: Fri Aug 01, 2003 2:31 am Post subject: Re: const

"Christophe Lephay" <christophe-lephay (AT) wanadoo (DOT) fr> writes:

Quote:

"drkm" <darkman_spam (AT) yahoo (DOT) fr> a écrit dans le message de
news:wk8yqepf10.fsf (AT) yahoo (DOT) fr...

"Christophe Lephay" <christophe-lephay (AT) wanadoo (DOT) fr> writes:

Oui. Ceci dit, la pile est allouée au chargement du programme.

Mais elle peut grandir au cours de l'exécution du programme,
non ? Par exemple, dans le programme suivant, il n'apparaîterait
pas d'allocation de (parties de) la pile ?

Changer la taille de la pile, celà voudrait dire une nouvelle
allocation et le déplacement de tout ce qui s'y trouve. C'est
probablement faisable, mais à quel coût ! D'ailleurs, si on le
faisait, il deviendrait assez peu interessant d'y stocker les
variables locales, vu que c'est justement l'intéret de les stocker
dans la pile (ou "sur la pile" ?).

La pile est de taille fixe et allouée par le loader au chargement du
programme. Un exécutable peut demander au loader une taille de pile
plus ou moins importante, mais elle ne change pas durant l'exécution
du programme.

J'aimerais que quelqu'un vienne confirmer tes dires, car je pense
vraiment que sur Unix, la pile est un segment, donc extensible au
moyen de `brk()´ ou `sbrk()´.

Mais il est vrai que cela est dépendant du système. Je ne sais pas
ce qui se passe sur d'autres architectures. Mais une pile réellement
statique me semble une implémentation bien peu satisfaisante.

Quote:

Dans l'exemple que tu donnes, la chaine de caractère n'est pa
stockée dans la pile mais dans un segment de données.

? C'est une variable locale à la fonction, de type tableau de
caractères (et non un pointeur). Les tableaux locaux ne sont pas
stockés sur la pile ?

Quote:

Si tu as plus de données dans la pile qu'elle ne peut en contenir,
elle ne s'agrandit pas et ton programme plante (la façon dont il
plante dépend de l'environnement).

En fait, la taille de la pile change bel et bien au cours de
l'exécution dans la mesure où elle se rétrécit à chaque imbrication
de fonction, et se ré-agrandit quand tu quittes une
fonction.

La taille *libre*, alors, et non véritablement la taille.

Quote:

Cependant la mémoire est allouée au chargement du programme, et la
taille qui semble varier n'est du qu'au déplacement du pointeur de
pile (incrémentation ou décrémentation du registre correspondant).

Je vois ce que tu décris plutôt comme 1) une taille allouée
constante et 2) une position courante (une stack frame courante).

--drkm

drkm
Guest

Posted: Fri Aug 01, 2003 2:41 am Post subject: Re: const

"Christophe Lephay" <christophe-lephay (AT) wanadoo (DOT) fr> writes:

Quote:

"drkm" <darkman_spam (AT) yahoo (DOT) fr> a écrit dans le message de
news:wk4r12pev8.fsf (AT) yahoo (DOT) fr...

"Christophe Lephay" <christophe-lephay (AT) wanadoo (DOT) fr> writes:

Programmer en C++ au lieu de l'assembleur implique en général
une perte de performance,

Je suis intimement convaincu, sans m'être jamais livré à
l'expérience, que le compilateur doit générer de l'assembleur bien
plus performant d'après la description en C++ que je lui fournis,
que ce que je pourrais moi-même écrire directement en assembleur.

Ce que je disais n'était pas à prendre au premier degré Wink

Mais l'idée selon laquelle l'assembleur est le langage de
prédilection lorsqu'il s'agit de performances a la vie dure. Or, il
me semble que c'est faire abstraction de nombre d'autres paramètres.

Je ne suis pas certain que programmer Mozilla en assembleur améliore
ses performances. Je pense plutôt le contraire. Dans ce genre de
projet, le fait de pouvoir raisonner à un autre niveau permet un
processus d'abstraction qui a également un impact sur le code écrit
(en C++, et donc en assembleur puis dans le binaire).

Mais je ne dit pas que sur un avertissement du profiler, une petite
insertion d'assembleur ne soit pas bénéfique dans une section
critique.

--drkm

Christophe Lephay
Guest

Posted: Fri Aug 01, 2003 3:38 am Post subject: Re: const

"drkm" <darkman_spam (AT) yahoo (DOT) fr> a écrit dans le message de
news:wkispinlpo.fsf (AT) yahoo (DOT) fr...

Quote:

Programmer en C++ au lieu de l'assembleur implique en général
une perte de performance,

Je suis intimement convaincu, sans m'être jamais livré à
l'expérience, que le compilateur doit générer de l'assembleur bien
plus performant d'après la description en C++ que je lui fournis,
que ce que je pourrais moi-même écrire directement en assembleur.

Ce que je disais n'était pas à prendre au premier degré ;)

Mais l'idée selon laquelle l'assembleur est le langage de
prédilection lorsqu'il s'agit de performances a la vie dure. Or, il
me semble que c'est faire abstraction de nombre d'autres paramètres.
Je ne suis pas certain que programmer Mozilla en assembleur améliore
ses performances. Je pense plutôt le contraire. Dans ce genre de
projet, le fait de pouvoir raisonner à un autre niveau permet un
processus d'abstraction qui a également un impact sur le code écrit
(en C++, et donc en assembleur puis dans le binaire).

Dans le post dont tu as extrait le message, j'ajoute qu'il est couremment
admis que les gains en performance les plus élevés se trouvent au niveau
algorithmique...

Quote:

Mais je ne dit pas que sur un avertissement du profiler, une petite
insertion d'assembleur ne soit pas bénéfique dans une section
critique.

On est d'accord...

Chris

Christophe Lephay
Guest

Posted: Fri Aug 01, 2003 3:45 am Post subject: Re: const

"drkm" <darkman_spam (AT) yahoo (DOT) fr> a écrit dans le message de
news:wkptjqnm5n.fsf (AT) yahoo (DOT) fr...

Quote:

"Christophe Lephay" <christophe-lephay (AT) wanadoo (DOT) fr> writes:
La pile est de taille fixe et allouée par le loader au chargement du
programme. Un exécutable peut demander au loader une taille de pile
plus ou moins importante, mais elle ne change pas durant l'exécution
du programme.

J'aimerais que quelqu'un vienne confirmer tes dires, car je pense
vraiment que sur Unix, la pile est un segment, donc extensible au
moyen de `brk()´ ou `sbrk()´.

Je ne pense pas que la question ne se pose en terme de faisabilité (car ça
l'est), mais plutôt en termes de coût. Or, ce qu'on attend de la pile, c'est
justement un maximum de performances.

Quote:

Mais il est vrai que cela est dépendant du système. Je ne sais pas
ce qui se passe sur d'autres architectures. Mais une pile réellement
statique me semble une implémentation bien peu satisfaisante.

Dans l'exemple que tu donnes, la chaine de caractère n'est pa
stockée dans la pile mais dans un segment de données.

? C'est une variable locale à la fonction, de type tableau de
caractères (et non un pointeur). Les tableaux locaux ne sont pas
stockés sur la pile ?

Pas les constantes de type chaine de caractère, en général...

Quote:

Je vois ce que tu décris plutôt comme 1) une taille allouée
constante et 2) une position courante (une stack frame courante).

Tout à fait...

Chris

Christophe Lephay
Guest

Posted: Fri Aug 01, 2003 1:11 pm Post subject: Re: const

<kanze (AT) gabi-soft (DOT) fr> a écrit dans le message de
news:d6652001.0308010421.33259d9c (AT) posting (DOT) google.com...

Quote:

Mais le programme en question n'avait pas de constantes de type chaîne
de caractère. Il n'avait qu'un tableau local (alloué donc sur la pile),
avec une initialisation.

Je ne comprends pas bien : "abcd" n'est-il pas une constante de type chaine
? Ne se trouverait-elle pas plutôt dans le (ou un) segment de données ?

Chris

Jean-Marc Bourguet
Guest

Posted: Sat Aug 02, 2003 8:45 am Post subject: Re: const

drkm <darkman_spam (AT) yahoo (DOT) fr> writes:

Quote:

"Christophe Lephay" <christophe-lephay (AT) wanadoo (DOT) fr> writes:

Programmer en C++ au lieu de l'assembleur implique en général une
perte de performance,

Je suis intimement convaincu, sans m'être jamais livré à
l'expérience, que le compilateur doit générer de l'assembleur bien
plus performant d'après la description en C++ que je lui fournis,
que ce que je pourrais moi-même écrire directement en assembleur.

Du moins dès que le programme dépasse quelques dizaines de lignes.

Ecrire de l'assembleur plus performant que ce que ne fait le
compilateur, c'est pas trop compliqué, du moins sur un programme donné
et un modèle de processeur donné. Le gros problème, c'est de le faire
aussi vite... la technique habituelle c'est d'écrire du langage de
haut niveau, le compiler, regarder l'assembleur généré et virer les
conneries puis vérifier que c'est pas toi qui t'es planté.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Display posts from previous:

	C++Talk.NET Forum Index -> C++ (French)	All times are GMT Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum