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?
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?
Le système gère ça relativement bien étant donné les informations qu'il a sur ce qui doit être alloué (aucune).
Mais il peut être intéressant d'utiliser son propre allocateur moins généraliste lorsqu'on connaît les contraintes dont on a besoin.
Par exemple, si l'on doit allouer et désallouer souvent des objets toujours de même taille, on peut surcharger le new et le delete pour gérer un pool d'emplacements mémoire. Cela évitera de faire des appels système pour chaque allocation/désallocation et peut amener à des améliorations sensibles de performance.
Maintenant, tant qu'aucun problème de performance n'a été identifié, ce n'est pas nécessairement la peine de l'engager là-dedans. D'autant plus que ce genre de système peut être rajouté facilement a posteriori sans modification du code (on continue d'allouer avec new ou new[] et de désallouer avec delete ou delete[]).
-- Arnaud
JM wrote:
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?
Le système gère ça relativement bien étant donné les informations qu'il
a sur ce qui doit être alloué (aucune).
Mais il peut être intéressant d'utiliser son propre allocateur moins
généraliste lorsqu'on connaît les contraintes dont on a besoin.
Par exemple, si l'on doit allouer et désallouer souvent des objets
toujours de même taille, on peut surcharger le new et le delete pour
gérer un pool d'emplacements mémoire. Cela évitera de faire des appels
système pour chaque allocation/désallocation et peut amener à des
améliorations sensibles de performance.
Maintenant, tant qu'aucun problème de performance n'a été identifié, ce
n'est pas nécessairement la peine de l'engager là-dedans. D'autant plus
que ce genre de système peut être rajouté facilement a posteriori sans
modification du code (on continue d'allouer avec new ou new[] et de
désallouer avec delete ou delete[]).
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?
Le système gère ça relativement bien étant donné les informations qu'il a sur ce qui doit être alloué (aucune).
Mais il peut être intéressant d'utiliser son propre allocateur moins généraliste lorsqu'on connaît les contraintes dont on a besoin.
Par exemple, si l'on doit allouer et désallouer souvent des objets toujours de même taille, on peut surcharger le new et le delete pour gérer un pool d'emplacements mémoire. Cela évitera de faire des appels système pour chaque allocation/désallocation et peut amener à des améliorations sensibles de performance.
Maintenant, tant qu'aucun problème de performance n'a été identifié, ce n'est pas nécessairement la peine de l'engager là-dedans. D'autant plus que ce genre de système peut être rajouté facilement a posteriori sans modification du code (on continue d'allouer avec new ou new[] et de désallouer avec delete ou delete[]).
-- Arnaud
JM
Maintenant, tant qu'aucun problème de performance n'a été identifié, ce n'est pas nécessairement la peine de l'engager là-dedans. D'autant plus que ce genre de système peut être rajouté facilement a posteriori sans modification du code (on continue d'allouer avec new ou new[] et de désallouer avec delete ou delete[]).
Ok merci.
J'avais peur de laisser plein de trous partout dans la mémoire.
Maintenant, tant qu'aucun problème de performance n'a été identifié, ce
n'est pas nécessairement la peine de l'engager là-dedans. D'autant plus
que ce genre de système peut être rajouté facilement a posteriori sans
modification du code (on continue d'allouer avec new ou new[] et de
désallouer avec delete ou delete[]).
Ok merci.
J'avais peur de laisser plein de trous partout dans la mémoire.
Maintenant, tant qu'aucun problème de performance n'a été identifié, ce n'est pas nécessairement la peine de l'engager là-dedans. D'autant plus que ce genre de système peut être rajouté facilement a posteriori sans modification du code (on continue d'allouer avec new ou new[] et de désallouer avec delete ou delete[]).
Ok merci.
J'avais peur de laisser plein de trous partout dans la mémoire.
Jean-Marc Desperrier
JM wrote:
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?
La fragmentation n'est présente que si à la fin de ta désallocation il y a un des éléments, alloués au milieu des autres, qui n'est pas désalloué. Donc la question est surtout de *tout* désallouer, pas dans quelle ordre.
Les situations où la fragmentation devient un problème significatif sont quand même assez rare, car pratiquement toujours la vraie source de la fragmentation est une petite fuite mémoire qu'il vaut mieux résoudre en elle même.
JM wrote:
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?
La fragmentation n'est présente que si à la fin de ta désallocation il y
a un des éléments, alloués au milieu des autres, qui n'est pas
désalloué. Donc la question est surtout de *tout* désallouer, pas dans
quelle ordre.
Les situations où la fragmentation devient un problème significatif sont
quand même assez rare, car pratiquement toujours la vraie source de la
fragmentation est une petite fuite mémoire qu'il vaut mieux résoudre en
elle même.
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?
La fragmentation n'est présente que si à la fin de ta désallocation il y a un des éléments, alloués au milieu des autres, qui n'est pas désalloué. Donc la question est surtout de *tout* désallouer, pas dans quelle ordre.
Les situations où la fragmentation devient un problème significatif sont quand même assez rare, car pratiquement toujours la vraie source de la fragmentation est une petite fuite mémoire qu'il vaut mieux résoudre en elle même.
JM
La fragmentation n'est présente que si à la fin de ta désallocation il y a un des éléments, alloués au milieu des autres, qui n'est pas désalloué. Donc la question est surtout de *tout* désallouer, pas dans quelle ordre.
Si on quitte l'application, je veux bien le croire. Mais tant que l'application fonctionne, est-ce que le système "comble" les trous? Parce que pour une appli qui tourne un certain temps, si ce n'était pas le cas, cela pourrait devenir problématique.
La fragmentation n'est présente que si à la fin de ta désallocation il y
a un des éléments, alloués au milieu des autres, qui n'est pas
désalloué. Donc la question est surtout de *tout* désallouer, pas dans
quelle ordre.
Si on quitte l'application, je veux bien le croire.
Mais tant que l'application fonctionne, est-ce que le système "comble"
les trous?
Parce que pour une appli qui tourne un certain temps, si ce n'était pas
le cas, cela pourrait devenir problématique.
La fragmentation n'est présente que si à la fin de ta désallocation il y a un des éléments, alloués au milieu des autres, qui n'est pas désalloué. Donc la question est surtout de *tout* désallouer, pas dans quelle ordre.
Si on quitte l'application, je veux bien le croire. Mais tant que l'application fonctionne, est-ce que le système "comble" les trous? Parce que pour une appli qui tourne un certain temps, si ce n'était pas le cas, cela pourrait devenir problématique.
Jean-Marc Desperrier
JM wrote:
La fragmentation n'est présente que si à la fin de ta désallocation il y a un des éléments, alloués au milieu des autres, qui n'est pas désalloué. Donc la question est surtout de *tout* désallouer, pas dans quelle ordre.
Si on quitte l'application, je veux bien le croire.
De toute façon, quand on quitte l'application, l'OS libère 100% de sa mémoire.
Mais tant que l'application fonctionne, est-ce que le système "comble" les trous?
Ta question n'est pas très claire pour moi.
Veux-tu demander si le système note dans tous les cas les blocs de mémoire que l'on a libéré et est capable immédiatement de les réutiliser pour une allocation, y compris quand un des bloc alloué plus loin dans la mémoire n'est pas encore libéré ?
Oui, bien sur que c'est le cas, c'est le minimum qu'on demande à un allocateur.
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é.
Un allocateur qui n'aurait plus cette contrainte serait en fait hyper simplifié et aurait un gain de performances qui influencerait tout le programme. Sur de l'embarqué, on peut se poser la question de partir dans cette voie.
JM wrote:
La fragmentation n'est présente que si à la fin de ta désallocation il
y a un des éléments, alloués au milieu des autres, qui n'est pas
désalloué. Donc la question est surtout de *tout* désallouer, pas dans
quelle ordre.
Si on quitte l'application, je veux bien le croire.
De toute façon, quand on quitte l'application, l'OS libère 100% de sa
mémoire.
Mais tant que l'application fonctionne, est-ce que le système "comble"
les trous?
Ta question n'est pas très claire pour moi.
Veux-tu demander si le système note dans tous les cas les blocs de
mémoire que l'on a libéré et est capable immédiatement de les réutiliser
pour une allocation, y compris quand un des bloc alloué plus loin dans
la mémoire n'est pas encore libéré ?
Oui, bien sur que c'est le cas, c'est le minimum qu'on demande à un
allocateur.
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é.
Un allocateur qui n'aurait plus cette contrainte serait en fait hyper
simplifié et aurait un gain de performances qui influencerait tout le
programme. Sur de l'embarqué, on peut se poser la question de partir
dans cette voie.
La fragmentation n'est présente que si à la fin de ta désallocation il y a un des éléments, alloués au milieu des autres, qui n'est pas désalloué. Donc la question est surtout de *tout* désallouer, pas dans quelle ordre.
Si on quitte l'application, je veux bien le croire.
De toute façon, quand on quitte l'application, l'OS libère 100% de sa mémoire.
Mais tant que l'application fonctionne, est-ce que le système "comble" les trous?
Ta question n'est pas très claire pour moi.
Veux-tu demander si le système note dans tous les cas les blocs de mémoire que l'on a libéré et est capable immédiatement de les réutiliser pour une allocation, y compris quand un des bloc alloué plus loin dans la mémoire n'est pas encore libéré ?
Oui, bien sur que c'est le cas, c'est le minimum qu'on demande à un allocateur.
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é.
Un allocateur qui n'aurait plus cette contrainte serait en fait hyper simplifié et aurait un gain de performances qui influencerait tout le programme. Sur de l'embarqué, on peut se poser la question de partir dans cette voie.
Fabien LE LEZ
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 ?
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é.
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 ?
JM
Veux-tu demander si le système note dans tous les cas les blocs de mémoire que l'on a libéré et est capable immédiatement de les réutiliser pour une allocation, y compris quand un des bloc alloué plus loin dans la mémoire n'est pas encore libéré ?
Oui, bien sur que c'est le cas, c'est le minimum qu'on demande à un allocateur.
C'est tout à fait ce que je me demandais.
Bon, vu que j'alloue/désalloue pas mal mais sur la durée, cela répond à ma question, pas la peine que je me prenne la tête avec ça.
Merci
Veux-tu demander si le système note dans tous les cas les blocs de
mémoire que l'on a libéré et est capable immédiatement de les réutiliser
pour une allocation, y compris quand un des bloc alloué plus loin dans
la mémoire n'est pas encore libéré ?
Oui, bien sur que c'est le cas, c'est le minimum qu'on demande à un
allocateur.
C'est tout à fait ce que je me demandais.
Bon, vu que j'alloue/désalloue pas mal mais sur la durée, cela répond à
ma question, pas la peine que je me prenne la tête avec ça.
Veux-tu demander si le système note dans tous les cas les blocs de mémoire que l'on a libéré et est capable immédiatement de les réutiliser pour une allocation, y compris quand un des bloc alloué plus loin dans la mémoire n'est pas encore libéré ?
Oui, bien sur que c'est le cas, c'est le minimum qu'on demande à un allocateur.
C'est tout à fait ce que je me demandais.
Bon, vu que j'alloue/désalloue pas mal mais sur la durée, cela répond à ma question, pas la peine que je me prenne la tête avec ça.
Merci
Sylvain
Jean-Marc Desperrier wrote on 20/06/2006 23:54:
Un allocateur qui n'aurait plus cette contrainte serait en fait hyper simplifié et aurait un gain de performances qui influencerait tout le programme. Sur de l'embarqué, on peut se poser la question de partir dans cette voie.
un code embarqué (si "embarqué" n'est pas un FPGA avec plusieurs centaines de méga RAM) n'utilise jamais l'allocation dynamique.
Sylvain.
Jean-Marc Desperrier wrote on 20/06/2006 23:54:
Un allocateur qui n'aurait plus cette contrainte serait en fait hyper
simplifié et aurait un gain de performances qui influencerait tout le
programme. Sur de l'embarqué, on peut se poser la question de partir
dans cette voie.
un code embarqué (si "embarqué" n'est pas un FPGA avec plusieurs
centaines de méga RAM) n'utilise jamais l'allocation dynamique.
Un allocateur qui n'aurait plus cette contrainte serait en fait hyper simplifié et aurait un gain de performances qui influencerait tout le programme. Sur de l'embarqué, on peut se poser la question de partir dans cette voie.
un code embarqué (si "embarqué" n'est pas un FPGA avec plusieurs centaines de méga RAM) n'utilise jamais l'allocation dynamique.
Sylvain.
Gabriel Dos Reis
Jean-Marc Desperrier writes:
| JM wrote: | >> La fragmentation n'est présente que si à la fin de ta désallocation | >> il y a un des éléments, alloués au milieu des autres, qui n'est pas | >> désalloué. Donc la question est surtout de *tout* désallouer, pas | >> dans quelle ordre. | > Si on quitte l'application, je veux bien le croire. | | De toute façon, quand on quitte l'application, l'OS libère 100% de sa | mémoire.
Quelle mémoire ?
[...]
| 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 ?
| JM wrote:
| >> La fragmentation n'est présente que si à la fin de ta désallocation
| >> il y a un des éléments, alloués au milieu des autres, qui n'est pas
| >> désalloué. Donc la question est surtout de *tout* désallouer, pas
| >> dans quelle ordre.
| > Si on quitte l'application, je veux bien le croire.
|
| De toute façon, quand on quitte l'application, l'OS libère 100% de sa
| mémoire.
Quelle mémoire ?
[...]
| 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 ?
| JM wrote: | >> La fragmentation n'est présente que si à la fin de ta désallocation | >> il y a un des éléments, alloués au milieu des autres, qui n'est pas | >> désalloué. Donc la question est surtout de *tout* désallouer, pas | >> dans quelle ordre. | > Si on quitte l'application, je veux bien le croire. | | De toute façon, quand on quitte l'application, l'OS libère 100% de sa | mémoire.
Quelle mémoire ?
[...]
| 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 ?
-- Gaby
Marc Boyer
Le 20-06-2006, Jean-Marc Desperrier a écrit :
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++. 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)
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Le 20-06-2006, Jean-Marc Desperrier <jmdesp@alussinan.org> a écrit :
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++.
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)
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. Paul Éluard)
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++. 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)
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
