Question de gros nullos en c++
Voila, je dois allouer puis désalouer un gros paquet d'objets en mémoire
(je sais j'en suis à la préhistoire car j'utilise new et delete)
Pour éviter de fragmenter la mémoire, est-ce qu'il est utile de
désalouer dans le sens inverse de l'allocation, ou bien est-ce que le
système gère ça suffisament bien pour ne pas se poser ce genre de question?
On Tue, 20 Jun 2006 23:54:24 +0200, Jean-Marc Desperrier :
que de nombreux programmes passent un pourcentage important de leur temps à allouer la mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++ est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
Y a-t-il des langages qui font mieux ?
Oui et non.
Je dois dire que je ne constate pas ce problème en C++, déjà. Qu'on le veuille ou non, le C++ privilège la sémantique de valeur, avec les objets sur la pile. Le résultat, d'après mon expérence, c'est que les problèmes de performance, quand il y en a, viennent des copies, et non des allocations en soi. (Dans les cas où un programme passe beaucoup trop de temps dans l'allocateur, c'est en général suite à des copies profondes des structures dynamiques. Et que le C++ offre de très bonnes possibilités d'y intervenir, pour réduire le nombre d'allocations.)
D'autres langages utilisent d'autres idiomes, ce qui rend la comparaison difficile. Si tu crées tous les objets dynamiquement, par exemple, comme en Java, l'utilisation d'un glaneur de cellules compactant pourrait se reveler bien plus efficace que le malloc/free de C++, par exemple. Et si tu fais du Lisp, tu vas te retrouver avec encore beaucoup plus d'allocations qu'en Java. Mais la vaste majorité serait d'un objet d'une taille fixe ; l'implémentation pourrait bien utiliser des pools optimisés pour elles.
En somme, chaque langage a ses idiomes propres, et chaque langage finira par trouver des solutions efficaces pour ces idiomes. Dire que le Java permet une allocation/désallocation plus rapide que le C++ ne signifie rien, parce qu'on est obligé de s'en servir beaucoup plus. Mais on pourrait faire la même rémarque par rapport à la copie et C++.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Tue, 20 Jun 2006 23:54:24 +0200, Jean-Marc Desperrier
<jmdesp@alussinan.org>:
que de nombreux programmes passent un pourcentage important
de leur temps à allouer la mémoire plutot qu'à réaliser les
opérations de l'utilisateur. Le C++ est d'ailleurs un
language qui a tendance a ne pas aider de ce coté.
Y a-t-il des langages qui font mieux ?
Oui et non.
Je dois dire que je ne constate pas ce problème en C++, déjà.
Qu'on le veuille ou non, le C++ privilège la sémantique de
valeur, avec les objets sur la pile. Le résultat, d'après mon
expérence, c'est que les problèmes de performance, quand il y en
a, viennent des copies, et non des allocations en soi. (Dans les
cas où un programme passe beaucoup trop de temps dans
l'allocateur, c'est en général suite à des copies profondes des
structures dynamiques. Et que le C++ offre de très bonnes
possibilités d'y intervenir, pour réduire le nombre
d'allocations.)
D'autres langages utilisent d'autres idiomes, ce qui rend la
comparaison difficile. Si tu crées tous les objets
dynamiquement, par exemple, comme en Java, l'utilisation d'un
glaneur de cellules compactant pourrait se reveler bien plus
efficace que le malloc/free de C++, par exemple. Et si tu fais
du Lisp, tu vas te retrouver avec encore beaucoup plus
d'allocations qu'en Java. Mais la vaste majorité serait d'un
objet d'une taille fixe ; l'implémentation pourrait bien
utiliser des pools optimisés pour elles.
En somme, chaque langage a ses idiomes propres, et chaque
langage finira par trouver des solutions efficaces pour ces
idiomes. Dire que le Java permet une allocation/désallocation
plus rapide que le C++ ne signifie rien, parce qu'on est obligé
de s'en servir beaucoup plus. Mais on pourrait faire la même
rémarque par rapport à la copie et C++.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Tue, 20 Jun 2006 23:54:24 +0200, Jean-Marc Desperrier :
que de nombreux programmes passent un pourcentage important de leur temps à allouer la mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++ est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
Y a-t-il des langages qui font mieux ?
Oui et non.
Je dois dire que je ne constate pas ce problème en C++, déjà. Qu'on le veuille ou non, le C++ privilège la sémantique de valeur, avec les objets sur la pile. Le résultat, d'après mon expérence, c'est que les problèmes de performance, quand il y en a, viennent des copies, et non des allocations en soi. (Dans les cas où un programme passe beaucoup trop de temps dans l'allocateur, c'est en général suite à des copies profondes des structures dynamiques. Et que le C++ offre de très bonnes possibilités d'y intervenir, pour réduire le nombre d'allocations.)
D'autres langages utilisent d'autres idiomes, ce qui rend la comparaison difficile. Si tu crées tous les objets dynamiquement, par exemple, comme en Java, l'utilisation d'un glaneur de cellules compactant pourrait se reveler bien plus efficace que le malloc/free de C++, par exemple. Et si tu fais du Lisp, tu vas te retrouver avec encore beaucoup plus d'allocations qu'en Java. Mais la vaste majorité serait d'un objet d'une taille fixe ; l'implémentation pourrait bien utiliser des pools optimisés pour elles.
En somme, chaque langage a ses idiomes propres, et chaque langage finira par trouver des solutions efficaces pour ces idiomes. Dire que le Java permet une allocation/désallocation plus rapide que le C++ ne signifie rien, parce qu'on est obligé de s'en servir beaucoup plus. Mais on pourrait faire la même rémarque par rapport à la copie et C++.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Marc Boyer wrote:
Le C++ est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
Au contraire, la possibilité d'écrire son propre allocateur est une des forces du C++.
Oui et non. Ça doit bientôt faire dix ans que je n'en ai pas resenti le besoin.
Car bon, je ne connais pas de langage qui fasse mieux, et d'ailleurs, je ne vois pas comment on pourrait (mais je manque peut-être d'imagination)
Rien n'empêche d'utiliser un glaneur de cellules optimisé pour ton application en Java (mais d'accord, c'est une option de l'implémentation, et non quelque chose de prévu par le langage). En Lisp, tu n'as pas besoin de le faire, parce que l'implémentation même s'occupe des allocations et des libérations (et j'imagine que la plupart des implémentations optimisent bien l'allocation d'une cellule -- qui doit représenter un percentage non négligeable des allocations).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Marc Boyer wrote:
Le C++ est d'ailleurs un language qui a tendance a ne pas
aider de ce coté.
Au contraire, la possibilité d'écrire son propre allocateur
est une des forces du C++.
Oui et non. Ça doit bientôt faire dix ans que je n'en ai pas
resenti le besoin.
Car bon, je ne connais pas de langage qui fasse mieux,
et d'ailleurs, je ne vois pas comment on pourrait (mais je
manque peut-être d'imagination)
Rien n'empêche d'utiliser un glaneur de cellules optimisé pour
ton application en Java (mais d'accord, c'est une option de
l'implémentation, et non quelque chose de prévu par le langage).
En Lisp, tu n'as pas besoin de le faire, parce que
l'implémentation même s'occupe des allocations et des
libérations (et j'imagine que la plupart des implémentations
optimisent bien l'allocation d'une cellule -- qui doit
représenter un percentage non négligeable des allocations).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Le C++ est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
Au contraire, la possibilité d'écrire son propre allocateur est une des forces du C++.
Oui et non. Ça doit bientôt faire dix ans que je n'en ai pas resenti le besoin.
Car bon, je ne connais pas de langage qui fasse mieux, et d'ailleurs, je ne vois pas comment on pourrait (mais je manque peut-être d'imagination)
Rien n'empêche d'utiliser un glaneur de cellules optimisé pour ton application en Java (mais d'accord, c'est une option de l'implémentation, et non quelque chose de prévu par le langage). En Lisp, tu n'as pas besoin de le faire, parce que l'implémentation même s'occupe des allocations et des libérations (et j'imagine que la plupart des implémentations optimisent bien l'allocation d'une cellule -- qui doit représenter un percentage non négligeable des allocations).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Desperrier
Gabriel Dos Reis wrote:
Jean-Marc Desperrier writes: | De toute façon, quand on quitte l'application, l'OS libère 100% de sa | mémoire.
Quelle mémoire ?
La mémoire alloué avec new/malloc, je ne suis pas rentré dans plus de subtilitées.
[...] | Cependant on peut noter que c'est aussi pour cela qu'une allocation | mémoire est quelquechose de trés couteux, et que de nombreux | programmes passent un pourcentage important de leur temps à allouer la | mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++ | est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
et cela provient d'un sondage IPSOS-BVA réalisé pour VSD, c'est ça ?
En tout cas, le troll de lancer comme cela à minuit une affirmation vaseuse sans justification a bien fonctionné au niveau du nombre de réponses obtenues :-)
Gabriel Dos Reis wrote:
Jean-Marc Desperrier <jmdesp@alussinan.org> writes:
| De toute façon, quand on quitte l'application, l'OS libère 100% de sa
| mémoire.
Quelle mémoire ?
La mémoire alloué avec new/malloc, je ne suis pas rentré dans plus de
subtilitées.
[...]
| Cependant on peut noter que c'est aussi pour cela qu'une allocation
| mémoire est quelquechose de trés couteux, et que de nombreux
| programmes passent un pourcentage important de leur temps à allouer la
| mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++
| est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
et cela provient d'un sondage IPSOS-BVA réalisé pour VSD, c'est ça ?
En tout cas, le troll de lancer comme cela à minuit une affirmation
vaseuse sans justification a bien fonctionné au niveau du nombre de
réponses obtenues :-)
Jean-Marc Desperrier writes: | De toute façon, quand on quitte l'application, l'OS libère 100% de sa | mémoire.
Quelle mémoire ?
La mémoire alloué avec new/malloc, je ne suis pas rentré dans plus de subtilitées.
[...] | Cependant on peut noter que c'est aussi pour cela qu'une allocation | mémoire est quelquechose de trés couteux, et que de nombreux | programmes passent un pourcentage important de leur temps à allouer la | mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++ | est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
et cela provient d'un sondage IPSOS-BVA réalisé pour VSD, c'est ça ?
En tout cas, le troll de lancer comme cela à minuit une affirmation vaseuse sans justification a bien fonctionné au niveau du nombre de réponses obtenues :-)
Gabriel Dos Reis
Jean-Marc Desperrier writes:
[...]
| > | Cependant on peut noter que c'est aussi pour cela qu'une allocation | > | mémoire est quelquechose de trés couteux, et que de nombreux | > | programmes passent un pourcentage important de leur temps à allouer la | > | mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++ | > | est d'ailleurs un language qui a tendance a ne pas aider de ce coté. | > et cela provient d'un sondage IPSOS-BVA réalisé pour VSD, c'est ça ? | | En tout cas, le troll de lancer comme cela à minuit une affirmation
c'était une question. Le point d'interrogation n'était-il pas lisible ?
| > | Cependant on peut noter que c'est aussi pour cela qu'une allocation
| > | mémoire est quelquechose de trés couteux, et que de nombreux
| > | programmes passent un pourcentage important de leur temps à allouer la
| > | mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++
| > | est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
| > et cela provient d'un sondage IPSOS-BVA réalisé pour VSD, c'est ça ?
|
| En tout cas, le troll de lancer comme cela à minuit une affirmation
c'était une question. Le point d'interrogation n'était-il pas lisible ?
| > | Cependant on peut noter que c'est aussi pour cela qu'une allocation | > | mémoire est quelquechose de trés couteux, et que de nombreux | > | programmes passent un pourcentage important de leur temps à allouer la | > | mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++ | > | est d'ailleurs un language qui a tendance a ne pas aider de ce coté. | > et cela provient d'un sondage IPSOS-BVA réalisé pour VSD, c'est ça ? | | En tout cas, le troll de lancer comme cela à minuit une affirmation
c'était une question. Le point d'interrogation n'était-il pas lisible ?
-- Gaby
Arnaud Debaene
"Fabien LE LEZ" a écrit dans le message de news:
On Tue, 20 Jun 2006 23:54:24 +0200, Jean-Marc Desperrier :
que de nombreux programmes passent un pourcentage important de leur temps à allouer la mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++ est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
Y a-t-il des langages qui font mieux ?
Les langages avec un ramasse-miettes qui compacte la mémoire (Java, .NET, ...). Chaque allocation est beaucoup plus simple dans ce contexte, puisque le tas est considéré comme en permanence compacté (il n'y a pas de recherche linéaire d'espace libre disponible).
Bien sûr, çà a un coût : le GC lui-même (avec ses avantages et ses inconvénients), l'indirection supplémentaire par rapport à des pointeurs bruts....
Arnaud
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
jmug92h0q5uv5doil517ot8ihjgh2hnjus@4ax.com...
On Tue, 20 Jun 2006 23:54:24 +0200, Jean-Marc Desperrier
<jmdesp@alussinan.org>:
que de nombreux programmes
passent un pourcentage important de leur temps à allouer la mémoire
plutot qu'à réaliser les opérations de l'utilisateur. Le C++ est
d'ailleurs un language qui a tendance a ne pas aider de ce coté.
Y a-t-il des langages qui font mieux ?
Les langages avec un ramasse-miettes qui compacte la mémoire (Java, .NET,
...). Chaque allocation est beaucoup plus simple dans ce contexte, puisque
le tas est considéré comme en permanence compacté (il n'y a pas de recherche
linéaire d'espace libre disponible).
Bien sûr, çà a un coût : le GC lui-même (avec ses avantages et ses
inconvénients), l'indirection supplémentaire par rapport à des pointeurs
bruts....
On Tue, 20 Jun 2006 23:54:24 +0200, Jean-Marc Desperrier :
que de nombreux programmes passent un pourcentage important de leur temps à allouer la mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++ est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
Y a-t-il des langages qui font mieux ?
Les langages avec un ramasse-miettes qui compacte la mémoire (Java, .NET, ...). Chaque allocation est beaucoup plus simple dans ce contexte, puisque le tas est considéré comme en permanence compacté (il n'y a pas de recherche linéaire d'espace libre disponible).
Bien sûr, çà a un coût : le GC lui-même (avec ses avantages et ses inconvénients), l'indirection supplémentaire par rapport à des pointeurs bruts....
Arnaud
Jean-Marc Bourguet
"Arnaud Debaene" writes:
Bien sûr, çà a un coût : le GC lui-même (avec ses avantages et ses inconvénients), l'indirection supplémentaire par rapport à des pointeurs bruts....
Je ne vois pas ou il y a une indirection supplementaire avec les GC compactant. Par contre un cout a ne pas negliger, c'est la quantite memoire supplementaire necessaire (l'algo le plus simple de GC compactant force a utiliser au moins 2x plus de memoire que la quantite maximale accessible)
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
Bien sûr, çà a un coût : le GC lui-même (avec ses avantages et ses
inconvénients), l'indirection supplémentaire par rapport à des pointeurs
bruts....
Je ne vois pas ou il y a une indirection supplementaire avec les GC
compactant. Par contre un cout a ne pas negliger, c'est la quantite
memoire supplementaire necessaire (l'algo le plus simple de GC
compactant force a utiliser au moins 2x plus de memoire que la
quantite maximale accessible)
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
Bien sûr, çà a un coût : le GC lui-même (avec ses avantages et ses inconvénients), l'indirection supplémentaire par rapport à des pointeurs bruts....
Je ne vois pas ou il y a une indirection supplementaire avec les GC compactant. Par contre un cout a ne pas negliger, c'est la quantite memoire supplementaire necessaire (l'algo le plus simple de GC compactant force a utiliser au moins 2x plus de memoire que la quantite maximale accessible)
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
Ploc
Arnaud Debaene wrote:
Les langages avec un ramasse-miettes qui compacte la mémoire (Java, .NET, ...). Chaque allocation est beaucoup plus simple dans ce contexte, puisque le tas est considéré comme en permanence compacté (il n'y a pas de recherche linéaire d'espace libre disponible).
En fait, en .Net ce n'est pas oblige. Il me semble que le "unsafe" de c# est la pour empecher le deplacement d'une zone memoire pour le ramasse miette.
Arnaud Debaene wrote:
Les langages avec un ramasse-miettes qui compacte la mémoire (Java, .NET,
...). Chaque allocation est beaucoup plus simple dans ce contexte, puisque
le tas est considéré comme en permanence compacté (il n'y a pas de recherche
linéaire d'espace libre disponible).
En fait, en .Net ce n'est pas oblige. Il me semble que le "unsafe" de c#
est la pour empecher le deplacement d'une zone memoire pour le ramasse
miette.
Les langages avec un ramasse-miettes qui compacte la mémoire (Java, .NET, ...). Chaque allocation est beaucoup plus simple dans ce contexte, puisque le tas est considéré comme en permanence compacté (il n'y a pas de recherche linéaire d'espace libre disponible).
En fait, en .Net ce n'est pas oblige. Il me semble que le "unsafe" de c# est la pour empecher le deplacement d'une zone memoire pour le ramasse miette.
Sylvain
Jean-Marc Bourguet wrote on 22/06/2006 09:02:
"Arnaud Debaene" writes:
Bien sûr, çà a un coût : le GC lui-même (avec ses avantages et ses inconvénients), l'indirection supplémentaire par rapport à des pointeurs bruts....
Je ne vois pas ou il y a une indirection supplementaire avec les GC compactant.
les allocations dynamiques ne retournent pas un pointeur (adresse du bloc) mais un handle (adresse d'un pointeur contenant l'adresse du bloc). le handle est constant pour le code utilisant, le pointeur intermédiaire peut être changer lors du compactage mémoire.
le cout supplémentaire d'indirection existe pour l'utilisateur du handle à chaque utilisation.
Bien sûr, çà a un coût : le GC lui-même (avec ses avantages et ses
inconvénients), l'indirection supplémentaire par rapport à des pointeurs
bruts....
Je ne vois pas ou il y a une indirection supplementaire avec les GC
compactant.
les allocations dynamiques ne retournent pas un pointeur (adresse du
bloc) mais un handle (adresse d'un pointeur contenant l'adresse du
bloc). le handle est constant pour le code utilisant, le pointeur
intermédiaire peut être changer lors du compactage mémoire.
le cout supplémentaire d'indirection existe pour l'utilisateur du handle
à chaque utilisation.
Bien sûr, çà a un coût : le GC lui-même (avec ses avantages et ses inconvénients), l'indirection supplémentaire par rapport à des pointeurs bruts....
Je ne vois pas ou il y a une indirection supplementaire avec les GC compactant.
les allocations dynamiques ne retournent pas un pointeur (adresse du bloc) mais un handle (adresse d'un pointeur contenant l'adresse du bloc). le handle est constant pour le code utilisant, le pointeur intermédiaire peut être changer lors du compactage mémoire.
le cout supplémentaire d'indirection existe pour l'utilisateur du handle à chaque utilisation.
Sylvain.
Jean-Marc Bourguet
Sylvain writes:
Jean-Marc Bourguet wrote on 22/06/2006 09:02:
"Arnaud Debaene" writes:
Bien sûr, çà a un coût : le GC lui-même (avec ses avantages et ses inconvénients), l'indirection supplémentaire par rapport à des pointeurs bruts.... Je ne vois pas ou il y a une indirection supplementaire avec les GC
compactant.
les allocations dynamiques ne retournent pas un pointeur (adresse du bloc) mais un handle (adresse d'un pointeur contenant l'adresse du bloc). le handle est constant pour le code utilisant, le pointeur intermédiaire peut être changer lors du compactage mémoire.
C'est une technique d'implementation, et elle est loin d'etre indispensable. Je ne suis meme pas sur qu'elle soit la plus courante (ca risque de dependre du choix qu'a fait MS pour son implementation de CLI).
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
Bien sûr, çà a un coût : le GC lui-même (avec ses avantages et ses
inconvénients), l'indirection supplémentaire par rapport à des pointeurs
bruts....
Je ne vois pas ou il y a une indirection supplementaire avec les GC
compactant.
les allocations dynamiques ne retournent pas un pointeur (adresse du bloc)
mais un handle (adresse d'un pointeur contenant l'adresse du bloc). le
handle est constant pour le code utilisant, le pointeur intermédiaire peut
être changer lors du compactage mémoire.
C'est une technique d'implementation, et elle est loin d'etre
indispensable. Je ne suis meme pas sur qu'elle soit la plus courante
(ca risque de dependre du choix qu'a fait MS pour son implementation
de CLI).
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
Bien sûr, çà a un coût : le GC lui-même (avec ses avantages et ses inconvénients), l'indirection supplémentaire par rapport à des pointeurs bruts.... Je ne vois pas ou il y a une indirection supplementaire avec les GC
compactant.
les allocations dynamiques ne retournent pas un pointeur (adresse du bloc) mais un handle (adresse d'un pointeur contenant l'adresse du bloc). le handle est constant pour le code utilisant, le pointeur intermédiaire peut être changer lors du compactage mémoire.
C'est une technique d'implementation, et elle est loin d'etre indispensable. Je ne suis meme pas sur qu'elle soit la plus courante (ca risque de dependre du choix qu'a fait MS pour son implementation de CLI).
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
Pierre THIERRY
Le Tue, 20 Jun 2006 23:54:24 +0200, Jean-Marc Desperrier a écrit :
Cependant on peut noter que c'est aussi pour cela qu'une allocation mémoire est quelquechose de trés couteux, et que de nombreux programmes passent un pourcentage important de leur temps à allouer la mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++ est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
Est-ce que cela ne devrait pas être le contraire ? Comme on peut, en C++, modifier la façon dont l'allocation dynamique se fait, on peut aisément choisir celle qui sera la plus efficace... Et on a même accès aux idiomes d'autres langages, mais avec peut-être plus de flexibilité, puisqu'on y est pas contraint.
On peut par exemple utiliser un GC là où cela a du sens, un pool pour une autre partie de l'application et l'opérateur new non surchargé encore autre part...
Curieusement, Nowhere man --
OpenPGP 0xD9D50D8A
Le Tue, 20 Jun 2006 23:54:24 +0200, Jean-Marc Desperrier a écrit :
Cependant on peut noter que c'est aussi pour cela qu'une allocation
mémoire est quelquechose de trés couteux, et que de nombreux
programmes passent un pourcentage important de leur temps à allouer la
mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++
est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
Est-ce que cela ne devrait pas être le contraire ? Comme on peut, en
C++, modifier la façon dont l'allocation dynamique se fait, on peut
aisément choisir celle qui sera la plus efficace... Et on a même accès
aux idiomes d'autres langages, mais avec peut-être plus de flexibilité,
puisqu'on y est pas contraint.
On peut par exemple utiliser un GC là où cela a du sens, un pool pour
une autre partie de l'application et l'opérateur new non surchargé
encore autre part...
Curieusement,
Nowhere man
--
nowhere.man@levallois.eu.org
OpenPGP 0xD9D50D8A
Le Tue, 20 Jun 2006 23:54:24 +0200, Jean-Marc Desperrier a écrit :
Cependant on peut noter que c'est aussi pour cela qu'une allocation mémoire est quelquechose de trés couteux, et que de nombreux programmes passent un pourcentage important de leur temps à allouer la mémoire plutot qu'à réaliser les opérations de l'utilisateur. Le C++ est d'ailleurs un language qui a tendance a ne pas aider de ce coté.
Est-ce que cela ne devrait pas être le contraire ? Comme on peut, en C++, modifier la façon dont l'allocation dynamique se fait, on peut aisément choisir celle qui sera la plus efficace... Et on a même accès aux idiomes d'autres langages, mais avec peut-être plus de flexibilité, puisqu'on y est pas contraint.
On peut par exemple utiliser un GC là où cela a du sens, un pool pour une autre partie de l'application et l'opérateur new non surchargé encore autre part...
