Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ question technique sur l'opérateur d'allocation new

question technique sur l'opérateur d'allocation new

29 réponses
Avatar
Frédéric GOURUL
Bonjour,

Je me pose pas mal de questions sur l'implémentation de l'opérateur
d'allocation mémoire void* ::operator new(size_t), en particulier s'il
contient des optimisations pour l'allocation des small-blocks. Si quelqu'un
pouvait éclairer ma lanterne ou m'indiquer un lien sur le sujet, je suis
preneur. En gros, je voudrais savoir si ca a un sens de créer un système qui
ferait de la pré-allocation de mémoire pour les objets de petite taille...

merci.
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Gabriel Dos Reis
James Kanze writes:

[...]

| Exactement comme dans ces cas, les implémentations garantissent le

Si tu trouves cete garantie dans la documentation de GCC, donne-moi la
référence parce que la dernière fois que j'ai cherché je n'ai pas trouvé.

| comportement du remplacement de malloc, et en offrent même plusieurs
| pour que tu n'as pas besoin d'en écrire un toi-même.
|
| |> | Dans la pratique, je ne
| |> | connais pas d'implémentation où on ne peut pas,
|
| |> ce qui ne veut pas dire que cela n'arrivera jamais.
|
| Certes. Mais on parle ici des questions d'optimisation ou de mise au
| point, et non de quelque chose de fondamental dans la fonctionnement du
| programme. La risque pour la portabilité est en fait moins grande que
| si tu utilises des threads.

Remplacer malloc n'est pas une question d'optimisation.
Une optimisation transforme un programme bien formé en un autre
programme bien formé avec la mÊme sémantqiue.

| |> En fait, l'une des prochaines versions de GCC (je ne sais pas si
| |> c'est 3.5 ou 4.0) va probablement changer cela. Certains voient des
| |> optimisations qu'ils peuvent faire et veulent l'implémenter. J'ai
| |> argué pour qu'on ne le fasse pas, mais visiblement j'étais
| |> minoritaire.
|
| Il vont faire en sort qu'on ne peut pas remplacer malloc par sa propre
| version ? Or que « man malloc », au moins sous Solaris, dit

La question est : est-ce que « man malloc » de Solaris fait partie de
la documentation du compilateur, ou est-ce que le malloc de solaris fait
partie de l'implémentation du compilateur.

| expressemment qu'on peut, et qu'on a le choix entre plusieurs versions.
| (En fait, les mallocs de Sun vont plus loins, en ce qu'ils offrent des
| sémantiques différentes, au moins dans le cas de BSD malloc.)

-- Gaby
Avatar
kanze
Gabriel Dos Reis wrote in message
news:...
James Kanze writes:

[...]

| Exactement comme dans ces cas, les implémentations garantissent le

Si tu trouves cete garantie dans la documentation de GCC, donne-moi la
référence parce que la dernière fois que j'ai cherché je n'ai pas
trouvé.


Les versions de gcc dont je me suis servi se sont toujours basées sur le
libc du système d'exploitation. Or, si je fais « man malloc » sur mon
système, j'ai bien cette garantie.

Dans la réalité, c'est une pratique tellement répandue qu'un fournisseur
de compilateur n'oserait plus le supprimer.

| comportement du remplacement de malloc, et en offrent même plusieurs
| pour que tu n'as pas besoin d'en écrire un toi-même.

| |> | Dans la pratique, je ne connais pas d'implémentation où on ne
| |> | peut pas,

| |> ce qui ne veut pas dire que cela n'arrivera jamais.

| Certes. Mais on parle ici des questions d'optimisation ou de mise au
| point, et non de quelque chose de fondamental dans la fonctionnement
| du programme. La risque pour la portabilité est en fait moins grande
| que si tu utilises des threads.

Remplacer malloc n'est pas une question d'optimisation. Une
optimisation transforme un programme bien formé en un autre programme
bien formé avec la mÊme sémantqiue.


N'importe quoi. Cette signification décrit ce que fait un optimisateur
dans le compilateur, mais c'est assez limiter par rapport à ce qui se
fait lors du développement de l'application.

| |> En fait, l'une des prochaines versions de GCC (je ne sais pas si
| |> c'est 3.5 ou 4.0) va probablement changer cela. Certains voient
| |> des optimisations qu'ils peuvent faire et veulent l'implémenter.
| |> J'ai argué pour qu'on ne le fasse pas, mais visiblement j'étais
| |> minoritaire.

| Il vont faire en sort qu'on ne peut pas remplacer malloc par sa
| propre version ? Or que « man malloc », au moins sous Solaris, dit

La question est : est-ce que « man malloc » de Solaris fait partie de
la documentation du compilateur, ou est-ce que le malloc de solaris
fait partie de l'implémentation du compilateur.


Il fait partie de la documentation de tous les compilateurs dont je me
sers sous Solaris.

| expressemment qu'on peut, et qu'on a le choix entre plusieurs
| versions. (En fait, les mallocs de Sun vont plus loins, en ce qu'ils
| offrent des sémantiques différentes, au moins dans le cas de BSD
| malloc.)


Plus important, évidemment, c'est le fait que dans la pratique, on est
amené à remplacer malloc prèsque toujours, au moins lors des tests. De
même qu'on modifie pas mal d'autres choses afin de les instrumenter. Et
qu'un compilateur qui ne le permettra pas ne servira pas.

Au moins, évidemment, qu'il nous offre les fonctionalités nécessaires
pour qu'on n'a pas besoin de remplacer malloc. Mais dans ce cas-là, la
question ne se pose pas.

--
James Kanze GABI Software mailto:
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

Avatar
Gabriel Dos Reis
writes:

| Gabriel Dos Reis wrote in message
| news:...
| > James Kanze writes:
|
| > [...]
|
| > | Exactement comme dans ces cas, les implémentations garantissent le
|
| > Si tu trouves cete garantie dans la documentation de GCC, donne-moi la
| > référence parce que la dernière fois que j'ai cherché je n'ai pas
| > trouvé.
|
| Les versions de gcc dont je me suis servi se sont toujours basées sur le
| libc du système d'exploitation. Or, si je fais « man malloc » sur mon
| système, j'ai bien cette garantie.

Ma question ne concernait pas que ce tu penses que GCC fait, mais une
garantie dans la documentation de GCC -- qu tu as clamée avant.

| Dans la réalité, c'est une pratique tellement répandue qu'un fournisseur
| de compilateur n'oserait plus le supprimer.

Aarf. Va dire ça à ceux qui proposent l'optimisation en question.
Ils n'en sont plus au stade « oser ». Ils vont le faire, et c'est
juste une question de temps. Et le compilateur survivra.

| > | comportement du remplacement de malloc, et en offrent même plusieurs
| > | pour que tu n'as pas besoin d'en écrire un toi-même.
|
| > | |> | Dans la pratique, je ne connais pas d'implémentation où on ne
| > | |> | peut pas,
|
| > | |> ce qui ne veut pas dire que cela n'arrivera jamais.
|
| > | Certes. Mais on parle ici des questions d'optimisation ou de mise au
| > | point, et non de quelque chose de fondamental dans la fonctionnement
| > | du programme. La risque pour la portabilité est en fait moins grande
| > | que si tu utilises des threads.
|
| > Remplacer malloc n'est pas une question d'optimisation. Une
| > optimisation transforme un programme bien formé en un autre programme
| > bien formé avec la mÊme sémantqiue.
|
| N'importe quoi. Cette signification décrit ce que fait un optimisateur
| dans le compilateur, mais c'est assez limiter par rapport à ce qui se
| fait lors du développement de l'application.


Tu es complèment à côté de tes pompes là. Cette signification vaut
autant pour ce que fait le compilateur que ce que fait le programmeur.

| > | |> En fait, l'une des prochaines versions de GCC (je ne sais pas si
| > | |> c'est 3.5 ou 4.0) va probablement changer cela. Certains voient
| > | |> des optimisations qu'ils peuvent faire et veulent l'implémenter.
| > | |> J'ai argué pour qu'on ne le fasse pas, mais visiblement j'étais
| > | |> minoritaire.
|
| > | Il vont faire en sort qu'on ne peut pas remplacer malloc par sa
| > | propre version ? Or que « man malloc », au moins sous Solaris, dit
|
| > La question est : est-ce que « man malloc » de Solaris fait partie de
| > la documentation du compilateur, ou est-ce que le malloc de solaris
| > fait partie de l'implémentation du compilateur.
|
| Il fait partie de la documentation de tous les compilateurs dont je me
| sers sous Solaris.


Et cette assertion est une véritée revelée, ou tu l'as pondue tout
seul ou tu l'as trouvé dans la documentation de GCC ? Ce n'est pas une
question rhétorique.

| > | expressemment qu'on peut, et qu'on a le choix entre plusieurs
| > | versions. (En fait, les mallocs de Sun vont plus loins, en ce qu'ils
| > | offrent des sémantiques différentes, au moins dans le cas de BSD
| > | malloc.)
|
| Plus important, évidemment, c'est le fait que dans la pratique, on est
| amené à remplacer malloc prèsque toujours, au moins lors des tests. De
| même qu'on modifie pas mal d'autres choses afin de les instrumenter. Et
| qu'un compilateur qui ne le permettra pas ne servira pas.

c'est une prédiction estampillée pacorabane ? Parce que GCC fait déjà
pas mal de suppositions découlant des spécifications de C et C++ pour
les fonctions bibliothèques, et il survit.


http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00560.html
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00590.html
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00592.html
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00631.html
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00663.html

-- Gaby
Avatar
Christophe Lephay
Gabriel Dos Reis wrote:
writes:
Remplacer malloc n'est pas une question d'optimisation. Une
optimisation transforme un programme bien formé en un autre
programme bien formé avec la mÊme sémantqiue.


N'importe quoi. Cette signification décrit ce que fait un
optimisateur dans le compilateur, mais c'est assez limiter par
rapport à ce qui se fait lors du développement de l'application.


Tu es complèment à côté de tes pompes là. Cette signification vaut
autant pour ce que fait le compilateur que ce que fait le programmeur.


En fait, dire que la sémantique du programme est différente ou identique
dépend de beaucoup du niveau à partir duquel on regarde. Au plus haut
niveau, c'est clair que le programme doit rendre le service pour lequel il
est conçu, presque indépendemment de la maniere dont il est conçu. Je dis
presque, parce qu'il est fréquent que le choix de tel ou tel design ait des
répercussions sur les spécifications initiales. Je pense que seuls les plus
grands experts peuvent faire des spécifications définitives avant codage, et
encore, tant que le projet n'est pas trop complexe.

Tout ça pour dire que, de mon point de vue, vous avez tous les deux raison
mais chacun selon un point de vue différent, ce qui n'est pas si inhabituel
que ça, d'ailleurs ;)

Chris



Avatar
kanze
Gabriel Dos Reis wrote in message
news:...
writes:
| Gabriel Dos Reis wrote in message
| news:...
| > James Kanze writes:

| > [...]

| > | Exactement comme dans ces cas, les implémentations garantissent le

| > Si tu trouves cete garantie dans la documentation de GCC,
| > donne-moi la référence parce que la dernière fois que j'ai cherché
| > je n'ai pas trouvé.

| Les versions de gcc dont je me suis servi se sont toujours basées
| sur le libc du système d'exploitation. Or, si je fais « man malloc »
| sur mon système, j'ai bien cette garantie.

Ma question ne concernait pas que ce tu penses que GCC fait, mais une
garantie dans la documentation de GCC -- qu tu as clamée avant.


Il y a une documentation de GCC à cet égard ? GCC utilise le malloc du
système. Ça, c'est documenté, au moins -- c'est une des options du
build. Si mon système offre plusieurs malloc, alors ?

Et ça veut dire quoi, exactement, le malloc du système ? Depuis qu'il
existe, tous les projets sur lesquels j'ai travaillé se sont servi de
Purify. Sans exception. Et Purify remplace le malloc de Sun avec le
sien.

Avant qu'il y avait Purify, on se servait d'un malloc de remplacement
(parfois que j'ai écris) qui offrait à peu près les mêmes fonctionalités
de l'operator new dans MemoryCheck, à mon site.

| Dans la réalité, c'est une pratique tellement répandue qu'un
| fournisseur de compilateur n'oserait plus le supprimer.

Aarf. Va dire ça à ceux qui proposent l'optimisation en question. Ils
n'en sont plus au stade « oser ». Ils vont le faire, et c'est juste
une question de temps. Et le compilateur survivra.


Un compilateur qui empêche d'utiliser Purify aurait bien de problèmes,
au moins dans certains marchés. Que les développeurs de gcc le veuillent
ou non, il y a des gens qui ne veulent pas avoir des fuites de mémoire,
et qui veulent le vérifier.

| > | comportement du remplacement de malloc, et en offrent même
| > | plusieurs pour que tu n'as pas besoin d'en écrire un toi-même.

| > | |> | Dans la pratique, je ne connais pas d'implémentation où on
| > | |> | ne peut pas,

| > | |> ce qui ne veut pas dire que cela n'arrivera jamais.

| > | Certes. Mais on parle ici des questions d'optimisation ou de
| > | mise au point, et non de quelque chose de fondamental dans la
| > | fonctionnement du programme. La risque pour la portabilité est
| > | en fait moins grande que si tu utilises des threads.

| > Remplacer malloc n'est pas une question d'optimisation. Une
| > optimisation transforme un programme bien formé en un autre
| > programme bien formé avec la mÊme sémantqiue.

| N'importe quoi. Cette signification décrit ce que fait un
| optimisateur dans le compilateur, mais c'est assez limiter par
| rapport à ce qui se fait lors du développement de l'application.

Tu es complèment à côté de tes pompes là. Cette signification vaut
autant pour ce que fait le compilateur que ce que fait le programmeur.


On ne s'entend peut-être pas la même chose sous la vocable
« optimiser ». Quand je développe une application, j'« optimise »
constamment, surtout (mais pas exclusivement) la productivité du
programmeur. Et quelque soit ce que j'optimise, j'utilise les moyens à
ma disposition. Qui sont souvent au delà du langage : je peux changer du
compilateur, voire du langage, par exemple.

Remplacer malloc fait partie des possibilités d'optimisation à ma
disposition. Il en fait partie parce qu'il marche.

Dans le cas de gcc, il ne peut pas ne pas marcher, parce que gcc ne
connaît de toute façon pas le malloc que j'utilise de façon standard.
Que ce un des malloc fournis par Sun, que ce soit le malloc fourni par
Purify, ou que ce soit un malloc que j'ai écrit moi-même, dans la mesure
qu'elle remplit le contrat spécifié dans la norme C, comment peut-il
savoir ?

Dans le cas de VC++, il pourrait bien savoir, parce que le malloc
utilisé fait partie du produit compilateur. Mais qu'est-ce que ça
pourrait l'apporter ?

| > | |> En fait, l'une des prochaines versions de GCC (je ne sais
| > | |> pas si c'est 3.5 ou 4.0) va probablement changer
| > | |> cela. Certains voient des optimisations qu'ils peuvent faire
| > | |> et veulent l'implémenter. J'ai argué pour qu'on ne le fasse
| > | |> pas, mais visiblement j'étais minoritaire.

| > | Il vont faire en sort qu'on ne peut pas remplacer malloc par sa
| > | propre version ? Or que « man malloc », au moins sous Solaris,
| > | dit

| > La question est : est-ce que « man malloc » de Solaris fait partie
| > de la documentation du compilateur, ou est-ce que le malloc de
| > solaris fait partie de l'implémentation du compilateur.

| Il fait partie de la documentation de tous les compilateurs dont je
| me sers sous Solaris.

Et cette assertion est une véritée revelée, ou tu l'as pondue tout
seul ou tu l'as trouvé dans la documentation de GCC ? Ce n'est pas une
question rhétorique.


J'ai installé GCC moi-même plusieurs fois. Je n'ai pas installé le
malloc qui est livré avec GCC. Je sais donc qu'il utilise le malloc
« standard » de mon système. Qui est remplaçable.

Si on ne peut pas utiliser Purify (qui, je repête, a sa propre malloc)
avec GCC, on n'utilisera pas GCC. C'est aussi simple que ça.

| > | expressemment qu'on peut, et qu'on a le choix entre plusieurs
| > | versions. (En fait, les mallocs de Sun vont plus loins, en ce
| > | qu'ils offrent des sémantiques différentes, au moins dans le cas
| > | de BSD malloc.)

| Plus important, évidemment, c'est le fait que dans la pratique, on
| est amené à remplacer malloc prèsque toujours, au moins lors des
| tests. De même qu'on modifie pas mal d'autres choses afin de les
| instrumenter. Et qu'un compilateur qui ne le permettra pas ne
| servira pas.

c'est une prédiction estampillée pacorabane ? Parce que GCC fait déjà
pas mal de suppositions découlant des spécifications de C et C++ pour
les fonctions bibliothèques, et il survit.

http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00560.html
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00590.html
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00592.html
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00631.html
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00663.html


C'est marrant, là dedans, on dirait que tu argues exactement ce que je
suis en train d'arguer ici.

Mais d'après les extraits, je ne vois pas trop le problème (mais les
extraits ne décrivent pas l'optimisation envisagée). Je suis bien
d'accord que le compilateur a le droit de supposer que la sémantique de
la fonction malloc (d'où qu'elle vient) correspond à la sémantique
exigée par la norme C. Il n'en est pas autrement pour la fonction
operator new, d'ailleurs -- le fait que j'ai droit de le remplacer ne
veut pas dire que mon remplacement peut faire n'importe quoi.

Par la suite, c'est au charge de la fonction de remplacement de
s'assurer qu'elle ne marche pas sur les plate-bandes du système. Parce
qu'en général, quand on la remplace, c'est qu'on veut qu'elle fasse
quelque chose de plus. Dans mon remplacement de l'operator new, je fais
bien des sorties sur les flux, par exemple, ce qui n'est pas vraiement
garantie par la norme. Et en fait, je suis obligé de prendre des
précautions particulières dans le cas (bien réel) où la sortie appelle
ma fonction operator new. Mais je prends une attitude plutôt pragmatique
là-dedans : la norme ne garantit pas que je peux faire des memcpy ou des
memset non plus. Formellement, l'implémentation a aussi droit d'appeler
new dans une de ces fonctions. N'empêche que j'ai écrit le code comme ci
elle ne le ferait pas. C'est donc un comportement indéfini, mais je
prends la risque.

Remplacer malloc est, en fin de compte, pas bien différent. C'est une
risque, mais à condition de lui donner une sémantique convenable, la
risque n'est pas plus grande que d'utiliser memcpy et memset dans mon
implémentation de operator new.

Ceci dit, je serais intéressé à entendre les optimisations que tu penses
invalideras ma thèse, qui rendra le remplacement de malloc inopérable.
Parce que dans la mesure où GCC utilise de toute façon un malloc qu'il
ne connaît pas, je ne vois pas ce qu'il pourrait faire qui poserait un
problème.

--
James Kanze GABI Software mailto:
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

Avatar
Gabriel Dos Reis
writes:

[...]

| > c'est une prédiction estampillée pacorabane ? Parce que GCC fait déjà
| > pas mal de suppositions découlant des spécifications de C et C++ pour
| > les fonctions bibliothèques, et il survit.
|
| > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00560.html
| > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00590.html
| > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00592.html
| > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00631.html
| > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00663.html
|
| C'est marrant, là dedans, on dirait que tu argues exactement ce que je
| suis en train d'arguer ici.

C'est marrant uniquement parce que tu crois que tu dois me convaincre
de l'utilité de la chose et, je pense, tu n'as visiblement pas pris le
temps de comprendre le sens de mes remarques et questions.
J'ai mis exprès les liens pour que tu te fasses une idée de ma
position. Effectivement, c'est marrant que tu t'en rendes compet :-/

[...]

| Ceci dit, je serais intéressé à entendre les optimisations que tu penses
| invalideras ma thèse, qui rendra le remplacement de malloc inopérable.
| Parce que dans la mesure où GCC utilise de toute façon un malloc qu'il
| ne connaît pas, je ne vois pas ce qu'il pourrait faire qui poserait un
| problème.

Dans le thread en question, j'ai argué, par exemple, que si GCC
commençait à faire ces transformations comme il veut, il va rendre
l'éxécution de certains codes difficiles à suivre (surtout ceux qui
utiliseraient un malloc traçant). Un coup ton malloc est appelé, un
coup il n'est pas appelé. Cela fait partie de « tu as ce que tu
mérites ».

-- Gaby
Avatar
espie
In article ,
Gabriel Dos Reis wrote:
c'est une prédiction estampillée pacorabane ? Parce que GCC fait déjà
pas mal de suppositions découlant des spécifications de C et C++ pour
les fonctions bibliothèques, et il survit.


http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00560.html
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00590.html
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00592.html
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00631.html
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00663.html


Heureusement pour lui, gcc permet de desactiver ces suppositions fonction
par fonction, grace -fno-builtin-<function>.

C'est meme tellement utile que j'ai ete amene a backporter cette option
en gcc 2.95.

En effet, la vision simpliste -fhosted/-ffree-standing d'un compilateur qui
faisait du C + bibal ou du C embarque n'etait plus du tout satisfaisante
par rapport a la realite.

Accessoirement, certaines des optimisations faites ces temps-ci par gcc
sont problematiques. Je citerai le cas de memset() sur les tampons locaux,
qui disparait si le compilateur pense que les tampons locaux ne servent
plus. Cette optimisation presente helas le probleme de casser assez
fortement tout le code cryptographique qui utilisait memset() pour
s'assurer que les mots de passe et autres cles avaient une duree de vie
tres limitee en memoire.

Tu me diras qu'en C standard, ce comportement de memset est correct, en
l'absence de comportement observable.

Mais la, ton codeur cryptographe moyen te dira qu'il n'est pas tres
d'accord, et que le C standard ne lui permet pas de specifier ce qu'il
veut a un niveau de granularite suffisant (volatile etant un peu trop
brutal). D'ailleurs, justement, il avait introduit un memset() pour etre
raisonnablement certain d'avoir un appel de fonction (il n'en est plus
rien) et d'eviter que le compilateur mette ses sales pattes dedans (ca
n'est plus le cas). Et lorsque les optimisations inter-modules vont
debarquer, ca va encore plus compliquer la tache de ces gens-la...
Le passage du C du statut d'assembleur portable au statut de langage
de haut niveau optimise pose quelques problemes a certaines personnes en
fait.

De fait, les preoccupations de James me semblent on ne peut plus legitimes.
gcc survit malgre tout car ces preoccupations ne correspondent pas a la
majorite des programmeurs, mais je suis raisonnablement certain que ces
corrections de gcc ont deja casse de maniere subtile du code critique.

Et non, je n'ai aucune solution miracle. Je constate.

Avatar
Gabriel Dos Reis
(Marc Espie) writes:

| In article ,
| Gabriel Dos Reis wrote:
| >c'est une prédiction estampillée pacorabane ? Parce que GCC fait déjà
| >pas mal de suppositions découlant des spécifications de C et C++ pour
| >les fonctions bibliothèques, et il survit.
| >
| >
| >http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00560.html
| >http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00590.html
| >http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00592.html
| >http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00631.html
| >http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00663.html
|
| Heureusement pour lui, gcc permet de desactiver ces suppositions fonction
| par fonction, grace -fno-builtin-<function>.

Mais pour malloc (comme la plupart des fonctions), GCC se contente
pour le moment d'accpeter et d'ignorer cette directive, exceptées
quelques fonctions de <string.h> et <math.h>.

[...]

| Accessoirement, certaines des optimisations faites ces temps-ci par gcc
| sont problematiques. Je citerai le cas de memset() sur les tampons locaux,
| qui disparait si le compilateur pense que les tampons locaux ne servent
| plus. Cette optimisation presente helas le probleme de casser assez
| fortement tout le code cryptographique qui utilisait memset() pour
| s'assurer que les mots de passe et autres cles avaient une duree de vie
| tres limitee en memoire.
|
| Tu me diras qu'en C standard, ce comportement de memset est correct, en
| l'absence de comportement observable.


En fait, même si je reconnais la valeur de ces optimisations dans des
cas spécifiques, je suis extrêmement reservé sur la manière dont elles
sont appliquées dans GCC. Mais que veux-tu faire face au developpeur
middle-end fou qui veut tester son dernier code de transformations ?
J'aurais largement préféré que ces ressources dépensées pour faire les
transformations du dernier rêve de samedi soir soient plutôt passées
sur le problème d'inlining cohérent et raisonable. :-(

Mais de l'autre côté, il me semble également légitime de prévenir les
programmeurs sur les libertés données au compilateur -- et que
certains commencent à exercer maintenant. Clairement, il faut revoir
certaines méthodes de programmation sclérosées et d'essayer de penser
les programmes autrement.

[...]

| n'est plus le cas). Et lorsque les optimisations inter-modules vont
| debarquer, ca va encore plus compliquer la tache de ces gens-la...

Déjà -funit-at-a-time pose des problèmes à certains.

| Le passage du C du statut d'assembleur portable au statut de langage
| de haut niveau optimise pose quelques problemes a certaines personnes en
| fait.

[...]

| Et non, je n'ai aucune solution miracle. Je constate.

:-)

-- Gaby
Avatar
kanze
Gabriel Dos Reis wrote in message
news:...
writes:

[...]

| > c'est une prédiction estampillée pacorabane ? Parce que GCC fait
| > déjà pas mal de suppositions découlant des spécifications de C et
| > C++ pour les fonctions bibliothèques, et il survit.

| > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00560.html
| > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00590.html
| > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00592.html
| > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00631.html
| > http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00663.html

| C'est marrant, là dedans, on dirait que tu argues exactement ce que
| je suis en train d'arguer ici.

C'est marrant uniquement parce que tu crois que tu dois me convaincre
de l'utilité de la chose et, je pense, tu n'as visiblement pas pris le
temps de comprendre le sens de mes remarques et questions. J'ai mis
exprès les liens pour que tu te fasses une idée de ma
position. Effectivement, c'est marrant que tu t'en rendes compet :-/


Je crois en effet qu'on a un problème de communication. Je ne sais pas à
quoi ça tient, mais je le regrette.

[...]

| Ceci dit, je serais intéressé à entendre les optimisations que tu
| penses invalideras ma thèse, qui rendra le remplacement de malloc
| inopérable. Parce que dans la mesure où GCC utilise de toute façon
| un malloc qu'il ne connaît pas, je ne vois pas ce qu'il pourrait
| faire qui poserait un problème.

Dans le thread en question, j'ai argué, par exemple, que si GCC
commençait à faire ces transformations comme il veut, il va rendre
l'éxécution de certains codes difficiles à suivre (surtout ceux qui
utiliseraient un malloc traçant). Un coup ton malloc est appelé, un
coup il n'est pas appelé. Cela fait partie de « tu as ce que tu
mérites ».


Je n'ai pas de problème avec ça, dans la mesure que chaque fois qu'il
sucre un appel à malloc, il sucre l'appel correspondant à free. Le but
des malloc traçant, c'est en général de trouver les fuites de mémoire ou
les abus (utilisation de la mémoire déjà libérée, etc.). C'est une
instrumentation qui ne fait pas partie de la fonctionnalité essentielle
de l'application. Si un malloc/free disparaît, c'est un contrôl en moins
qui se fait, mais je suppose que pour pouvoir les faire disparaître, le
compilateur aurait déjà fait assez de vérifications statiques pour que
le contrôle soit superflu. Si un malloc/free apparaît en trop, ce n'est
pas grave non plus.

Enfin, ça vaut pour les applications générales. Je pourrais imaginer que
dans certaines applications embriquer, ou la mémoire est serrée, on veut
bien contrôler exactement ce qui est sur la pile et ce qui est dans le
tas.

--
James Kanze GABI Software mailto:
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

1 2 3