Il est bien plus rapide d'"allouer" des buffers locaux sur la pile que
sur le tas, donc on a intéret à maximiser la taille dispo pour la pile.
Bon, pour un x86 on risque d'être limité par l'étroitesse de l'espace
d'adressage, mais sur les AMD-64, j'imagine qu'on peut voir large (par
exemple allouer 4Go d'adressage pour la pile).
Il est bien plus rapide d'"allouer" des buffers locaux sur la pile que
sur le tas, donc on a intéret à maximiser la taille dispo pour la pile.
Bon, pour un x86 on risque d'être limité par l'étroitesse de l'espace
d'adressage, mais sur les AMD-64, j'imagine qu'on peut voir large (par
exemple allouer 4Go d'adressage pour la pile).
Il est bien plus rapide d'"allouer" des buffers locaux sur la pile que
sur le tas, donc on a intéret à maximiser la taille dispo pour la pile.
Bon, pour un x86 on risque d'être limité par l'étroitesse de l'espace
d'adressage, mais sur les AMD-64, j'imagine qu'on peut voir large (par
exemple allouer 4Go d'adressage pour la pile).
On 2004-04-19, roger_that <fabsk+ wrote:Il est bien plus rapide d'"allouer" des buffers locaux sur la pile
que sur le tas, donc on a intéret à maximiser la taille dispo pour
la pile.
C'est beaucoup plus rapide mais tant que la pile sera exécutable cela
posera de gros problèmes au niveau sécurité. Il faut faire attention
à ce que l'on fait. Un programme qui corrompt le tas c'est pas
trop grave (voir plus loin) mais un programme qui corrompt la pile...
Le gros problème sous Windows c'est les implémentations foireuses
de malloc() &co., du genre :
* elles placent des méta informations entre les blocs ce qui fait
qu'un programme qui écrit en dehors d'une zone allouée est
susceptible de corrompre ces données et de faire planter le
programme de façon aléatoire.
* pour allouer un bloc il faut généralement traverser tous ceux
du tas avant de trouver un espace libre, ce qui est cata-
strophique au niveau performance.
* les routines free() sont tellement idiotes qu'elles peuvent essayer
de libérer un pointeur qui n'a pas été alloué auparavent.
Je rappelle que malloc() alloue sa mémoire dans un espace déterminé
et c'est pas trop dur de vérifier au moins si ce pointeur
appartient à cette zone.
Rien qu'en changeant de routine malloc() &co. on y gagne.
Et c'est sans parler des techniques d'optimisation (buffer pool :
allouer de la mémoire par avance et réutiliser les buffers...)
Bon, pour un x86 on risque d'être limité par l'étroitesse de l'espace
d'adressage, mais sur les AMD-64, j'imagine qu'on peut voir large
(par exemple allouer 4Go d'adressage pour la pile).
Tu es limité par la taille de la mémoire virtuelle avant celle de
l'es- pace d'adressage. Je rappelle que les processus sous windows
s'exécutent tous dans un segment virtuel de 4Go. En gros si le tas
peut pas faire 4Go, la pile le pourra pas plus.
On 2004-04-19, roger_that <fabsk+news@free.fr> wrote:
Il est bien plus rapide d'"allouer" des buffers locaux sur la pile
que sur le tas, donc on a intéret à maximiser la taille dispo pour
la pile.
C'est beaucoup plus rapide mais tant que la pile sera exécutable cela
posera de gros problèmes au niveau sécurité. Il faut faire attention
à ce que l'on fait. Un programme qui corrompt le tas c'est pas
trop grave (voir plus loin) mais un programme qui corrompt la pile...
Le gros problème sous Windows c'est les implémentations foireuses
de malloc() &co., du genre :
* elles placent des méta informations entre les blocs ce qui fait
qu'un programme qui écrit en dehors d'une zone allouée est
susceptible de corrompre ces données et de faire planter le
programme de façon aléatoire.
* pour allouer un bloc il faut généralement traverser tous ceux
du tas avant de trouver un espace libre, ce qui est cata-
strophique au niveau performance.
* les routines free() sont tellement idiotes qu'elles peuvent essayer
de libérer un pointeur qui n'a pas été alloué auparavent.
Je rappelle que malloc() alloue sa mémoire dans un espace déterminé
et c'est pas trop dur de vérifier au moins si ce pointeur
appartient à cette zone.
Rien qu'en changeant de routine malloc() &co. on y gagne.
Et c'est sans parler des techniques d'optimisation (buffer pool :
allouer de la mémoire par avance et réutiliser les buffers...)
Bon, pour un x86 on risque d'être limité par l'étroitesse de l'espace
d'adressage, mais sur les AMD-64, j'imagine qu'on peut voir large
(par exemple allouer 4Go d'adressage pour la pile).
Tu es limité par la taille de la mémoire virtuelle avant celle de
l'es- pace d'adressage. Je rappelle que les processus sous windows
s'exécutent tous dans un segment virtuel de 4Go. En gros si le tas
peut pas faire 4Go, la pile le pourra pas plus.
On 2004-04-19, roger_that <fabsk+ wrote:Il est bien plus rapide d'"allouer" des buffers locaux sur la pile
que sur le tas, donc on a intéret à maximiser la taille dispo pour
la pile.
C'est beaucoup plus rapide mais tant que la pile sera exécutable cela
posera de gros problèmes au niveau sécurité. Il faut faire attention
à ce que l'on fait. Un programme qui corrompt le tas c'est pas
trop grave (voir plus loin) mais un programme qui corrompt la pile...
Le gros problème sous Windows c'est les implémentations foireuses
de malloc() &co., du genre :
* elles placent des méta informations entre les blocs ce qui fait
qu'un programme qui écrit en dehors d'une zone allouée est
susceptible de corrompre ces données et de faire planter le
programme de façon aléatoire.
* pour allouer un bloc il faut généralement traverser tous ceux
du tas avant de trouver un espace libre, ce qui est cata-
strophique au niveau performance.
* les routines free() sont tellement idiotes qu'elles peuvent essayer
de libérer un pointeur qui n'a pas été alloué auparavent.
Je rappelle que malloc() alloue sa mémoire dans un espace déterminé
et c'est pas trop dur de vérifier au moins si ce pointeur
appartient à cette zone.
Rien qu'en changeant de routine malloc() &co. on y gagne.
Et c'est sans parler des techniques d'optimisation (buffer pool :
allouer de la mémoire par avance et réutiliser les buffers...)
Bon, pour un x86 on risque d'être limité par l'étroitesse de l'espace
d'adressage, mais sur les AMD-64, j'imagine qu'on peut voir large
(par exemple allouer 4Go d'adressage pour la pile).
Tu es limité par la taille de la mémoire virtuelle avant celle de
l'es- pace d'adressage. Je rappelle que les processus sous windows
s'exécutent tous dans un segment virtuel de 4Go. En gros si le tas
peut pas faire 4Go, la pile le pourra pas plus.
Bonjour,
Je me pose des questions par rapport à la taille de la pile qu'on peut
définir dans son compilateur (VC6 dans mon cas). Si j'ai bien compris,
la taille qu'on spécifie dans les options du projet (ou par l'options
/STACK ou par le programme Editbin) est une taille maximale utilisable
pour la pile. Cela garantit au démarrage une réservation de l'espace
d'adressage.
Au fur et à mesure de l'exécution du programme, lorsque celui-ci
accède à de nouvelles pages de la pile, le système alloue
effectivement ces pages. C'est ce que j'ai vu avec mon debugger (les
"???" de la mémoire inaccessible se transforment en mémoire
accessible lorsque le programme écrit dedans). Et d'autre part, la
consommation mémoire du processus augmente avec l'accès en écriture
dans la pile.
Il est bien plus rapide d'"allouer" des buffers locaux sur la pile que
sur le tas, donc on a intéret à maximiser la taille dispo pour la
pile.
Bon, pour un x86 on risque d'être limité par l'étroitesse de
l'espace d'adressage, mais sur les AMD-64, j'imagine qu'on peut voir
large (par exemple allouer 4Go d'adressage pour la pile).
Partagez-vous mon analyse ?
Bonjour,
Je me pose des questions par rapport à la taille de la pile qu'on peut
définir dans son compilateur (VC6 dans mon cas). Si j'ai bien compris,
la taille qu'on spécifie dans les options du projet (ou par l'options
/STACK ou par le programme Editbin) est une taille maximale utilisable
pour la pile. Cela garantit au démarrage une réservation de l'espace
d'adressage.
Au fur et à mesure de l'exécution du programme, lorsque celui-ci
accède à de nouvelles pages de la pile, le système alloue
effectivement ces pages. C'est ce que j'ai vu avec mon debugger (les
"???" de la mémoire inaccessible se transforment en mémoire
accessible lorsque le programme écrit dedans). Et d'autre part, la
consommation mémoire du processus augmente avec l'accès en écriture
dans la pile.
Il est bien plus rapide d'"allouer" des buffers locaux sur la pile que
sur le tas, donc on a intéret à maximiser la taille dispo pour la
pile.
Bon, pour un x86 on risque d'être limité par l'étroitesse de
l'espace d'adressage, mais sur les AMD-64, j'imagine qu'on peut voir
large (par exemple allouer 4Go d'adressage pour la pile).
Partagez-vous mon analyse ?
Bonjour,
Je me pose des questions par rapport à la taille de la pile qu'on peut
définir dans son compilateur (VC6 dans mon cas). Si j'ai bien compris,
la taille qu'on spécifie dans les options du projet (ou par l'options
/STACK ou par le programme Editbin) est une taille maximale utilisable
pour la pile. Cela garantit au démarrage une réservation de l'espace
d'adressage.
Au fur et à mesure de l'exécution du programme, lorsque celui-ci
accède à de nouvelles pages de la pile, le système alloue
effectivement ces pages. C'est ce que j'ai vu avec mon debugger (les
"???" de la mémoire inaccessible se transforment en mémoire
accessible lorsque le programme écrit dedans). Et d'autre part, la
consommation mémoire du processus augmente avec l'accès en écriture
dans la pile.
Il est bien plus rapide d'"allouer" des buffers locaux sur la pile que
sur le tas, donc on a intéret à maximiser la taille dispo pour la
pile.
Bon, pour un x86 on risque d'être limité par l'étroitesse de
l'espace d'adressage, mais sur les AMD-64, j'imagine qu'on peut voir
large (par exemple allouer 4Go d'adressage pour la pile).
Partagez-vous mon analyse ?
Cyrille Szymanski wrote:
> On 2004-04-19, roger_that <fabsk+ wrote:
>> Il est bien plus rapide d'"allouer" des buffers locaux sur la pile
>> que sur le tas, donc on a intéret à maximiser la taille dispo pour
>> la pile.
>
> C'est beaucoup plus rapide mais tant que la pile sera exécutable cela
> posera de gros problèmes au niveau sécurité. Il faut faire attention
> à ce que l'on fait. Un programme qui corrompt le tas c'est pas
> trop grave (voir plus loin) mais un programme qui corrompt la pile...
>
> Le gros problème sous Windows c'est les implémentations foireuses
> de malloc() &co., du genre :
Ce n'est pas Windows qui implémente malloc : c'est la CRT que tu utilises
celle de VC, celle de Borland ou autre... Tu penses à laquelle en
particulier?
Tu connais des implémentations d'allocateur généraliste (pas de taille
etc...) qui font autrement sans obtenir rapidement une fragmentation
catastrophique?
Raison de performances pour le coup : appeler free sur un pointeur non
par malloc est un comportement indéfini :
> Et c'est sans parler des techniques d'optimisation (buffer pool :
> allouer de la mémoire par avance et réutiliser les buffers...)
Bien sûr, c'est juste beaucoup de boulot en plus.
>> Bon, pour un x86 on risque d'être limité par l'étroitesse de l'espace
>> d'adressage, mais sur les AMD-64, j'imagine qu'on peut voir large
>> (par exemple allouer 4Go d'adressage pour la pile).
>
> Tu es limité par la taille de la mémoire virtuelle avant celle de
> l'es- pace d'adressage. Je rappelle que les processus sous windows
> s'exécutent tous dans un segment virtuel de 4Go. En gros si le tas
> peut pas faire 4Go, la pile le pourra pas plus.
Cyrille Szymanski wrote:
> On 2004-04-19, roger_that <fabsk+news@free.fr> wrote:
>> Il est bien plus rapide d'"allouer" des buffers locaux sur la pile
>> que sur le tas, donc on a intéret à maximiser la taille dispo pour
>> la pile.
>
> C'est beaucoup plus rapide mais tant que la pile sera exécutable cela
> posera de gros problèmes au niveau sécurité. Il faut faire attention
> à ce que l'on fait. Un programme qui corrompt le tas c'est pas
> trop grave (voir plus loin) mais un programme qui corrompt la pile...
>
> Le gros problème sous Windows c'est les implémentations foireuses
> de malloc() &co., du genre :
Ce n'est pas Windows qui implémente malloc : c'est la CRT que tu utilises
celle de VC, celle de Borland ou autre... Tu penses à laquelle en
particulier?
Tu connais des implémentations d'allocateur généraliste (pas de taille
etc...) qui font autrement sans obtenir rapidement une fragmentation
catastrophique?
Raison de performances pour le coup : appeler free sur un pointeur non
par malloc est un comportement indéfini :
> Et c'est sans parler des techniques d'optimisation (buffer pool :
> allouer de la mémoire par avance et réutiliser les buffers...)
Bien sûr, c'est juste beaucoup de boulot en plus.
>> Bon, pour un x86 on risque d'être limité par l'étroitesse de l'espace
>> d'adressage, mais sur les AMD-64, j'imagine qu'on peut voir large
>> (par exemple allouer 4Go d'adressage pour la pile).
>
> Tu es limité par la taille de la mémoire virtuelle avant celle de
> l'es- pace d'adressage. Je rappelle que les processus sous windows
> s'exécutent tous dans un segment virtuel de 4Go. En gros si le tas
> peut pas faire 4Go, la pile le pourra pas plus.
Cyrille Szymanski wrote:
> On 2004-04-19, roger_that <fabsk+ wrote:
>> Il est bien plus rapide d'"allouer" des buffers locaux sur la pile
>> que sur le tas, donc on a intéret à maximiser la taille dispo pour
>> la pile.
>
> C'est beaucoup plus rapide mais tant que la pile sera exécutable cela
> posera de gros problèmes au niveau sécurité. Il faut faire attention
> à ce que l'on fait. Un programme qui corrompt le tas c'est pas
> trop grave (voir plus loin) mais un programme qui corrompt la pile...
>
> Le gros problème sous Windows c'est les implémentations foireuses
> de malloc() &co., du genre :
Ce n'est pas Windows qui implémente malloc : c'est la CRT que tu utilises
celle de VC, celle de Borland ou autre... Tu penses à laquelle en
particulier?
Tu connais des implémentations d'allocateur généraliste (pas de taille
etc...) qui font autrement sans obtenir rapidement une fragmentation
catastrophique?
Raison de performances pour le coup : appeler free sur un pointeur non
par malloc est un comportement indéfini :
> Et c'est sans parler des techniques d'optimisation (buffer pool :
> allouer de la mémoire par avance et réutiliser les buffers...)
Bien sûr, c'est juste beaucoup de boulot en plus.
>> Bon, pour un x86 on risque d'être limité par l'étroitesse de l'espace
>> d'adressage, mais sur les AMD-64, j'imagine qu'on peut voir large
>> (par exemple allouer 4Go d'adressage pour la pile).
>
> Tu es limité par la taille de la mémoire virtuelle avant celle de
> l'es- pace d'adressage. Je rappelle que les processus sous windows
> s'exécutent tous dans un segment virtuel de 4Go. En gros si le tas
> peut pas faire 4Go, la pile le pourra pas plus.
celle de VC, celle de Borland ou autre... Tu penses à laquelle en
particulier?
générallement le malloc utilise un HeapAlloc ou un GlobalAlloc...
Après il est évident qu'un programmeur sait quand est-ce qu'il faut
utiliser ces fonctions ou pas :-)
Tu connais des implémentations d'allocateur généraliste (pas de
taille fixe, etc...) qui font autrement sans obtenir rapidement une
fragmentation catastrophique?
Si la taille des élément reste petite (de 1 octet à quelque kilo) on
peut faire des gestion particulière sur un tas qui augment par pas de
500 kilo ou 5 Mega et qui autorise une défragmentation en mode
Idle... mais ca c'est un truc de programmeur évidemment :-)
Raison de performances pour le coup : appeler free sur un pointeur
non aloué par malloc est un comportement indéfini :
généralement ca plante.
Et c'est sans parler des techniques d'optimisation (buffer pool :
allouer de la mémoire par avance et réutiliser les buffers...)
Bien sûr, c'est juste beaucoup de boulot en plus.
ben, une fois que c'est fait, c'est fait,
et étant donné que ca fait
partie des premieres choses qu'on développe quand on commence
l'informatique : tableau dynamique, gestion de collection d'objet,
gestion mémoire, gestion de fichier, database, tri , dichotomie...
bon je vais pas vous faire le programme de première année de BTS...
mais bon, si ta pas ces outils dans ta musette , change de métier.
Tu es limité par la taille de la mémoire virtuelle avant celle de
l'es- pace d'adressage. Je rappelle que les processus sous windows
s'exécutent tous dans un segment virtuel de 4Go. En gros si le tas
peut pas faire 4Go, la pile le pourra pas plus.
1 Go pour le mapping DLL et un autre pour le mapping system... il
reste même pas 1Go pour le code je crois
,et la pile (par thread )
est par défaut de l'ordre de qqc Mega...
celle de VC, celle de Borland ou autre... Tu penses à laquelle en
particulier?
générallement le malloc utilise un HeapAlloc ou un GlobalAlloc...
Après il est évident qu'un programmeur sait quand est-ce qu'il faut
utiliser ces fonctions ou pas :-)
Tu connais des implémentations d'allocateur généraliste (pas de
taille fixe, etc...) qui font autrement sans obtenir rapidement une
fragmentation catastrophique?
Si la taille des élément reste petite (de 1 octet à quelque kilo) on
peut faire des gestion particulière sur un tas qui augment par pas de
500 kilo ou 5 Mega et qui autorise une défragmentation en mode
Idle... mais ca c'est un truc de programmeur évidemment :-)
Raison de performances pour le coup : appeler free sur un pointeur
non aloué par malloc est un comportement indéfini :
généralement ca plante.
Et c'est sans parler des techniques d'optimisation (buffer pool :
allouer de la mémoire par avance et réutiliser les buffers...)
Bien sûr, c'est juste beaucoup de boulot en plus.
ben, une fois que c'est fait, c'est fait,
et étant donné que ca fait
partie des premieres choses qu'on développe quand on commence
l'informatique : tableau dynamique, gestion de collection d'objet,
gestion mémoire, gestion de fichier, database, tri , dichotomie...
bon je vais pas vous faire le programme de première année de BTS...
mais bon, si ta pas ces outils dans ta musette , change de métier.
Tu es limité par la taille de la mémoire virtuelle avant celle de
l'es- pace d'adressage. Je rappelle que les processus sous windows
s'exécutent tous dans un segment virtuel de 4Go. En gros si le tas
peut pas faire 4Go, la pile le pourra pas plus.
1 Go pour le mapping DLL et un autre pour le mapping system... il
reste même pas 1Go pour le code je crois
,et la pile (par thread )
est par défaut de l'ordre de qqc Mega...
celle de VC, celle de Borland ou autre... Tu penses à laquelle en
particulier?
générallement le malloc utilise un HeapAlloc ou un GlobalAlloc...
Après il est évident qu'un programmeur sait quand est-ce qu'il faut
utiliser ces fonctions ou pas :-)
Tu connais des implémentations d'allocateur généraliste (pas de
taille fixe, etc...) qui font autrement sans obtenir rapidement une
fragmentation catastrophique?
Si la taille des élément reste petite (de 1 octet à quelque kilo) on
peut faire des gestion particulière sur un tas qui augment par pas de
500 kilo ou 5 Mega et qui autorise une défragmentation en mode
Idle... mais ca c'est un truc de programmeur évidemment :-)
Raison de performances pour le coup : appeler free sur un pointeur
non aloué par malloc est un comportement indéfini :
généralement ca plante.
Et c'est sans parler des techniques d'optimisation (buffer pool :
allouer de la mémoire par avance et réutiliser les buffers...)
Bien sûr, c'est juste beaucoup de boulot en plus.
ben, une fois que c'est fait, c'est fait,
et étant donné que ca fait
partie des premieres choses qu'on développe quand on commence
l'informatique : tableau dynamique, gestion de collection d'objet,
gestion mémoire, gestion de fichier, database, tri , dichotomie...
bon je vais pas vous faire le programme de première année de BTS...
mais bon, si ta pas ces outils dans ta musette , change de métier.
Tu es limité par la taille de la mémoire virtuelle avant celle de
l'es- pace d'adressage. Je rappelle que les processus sous windows
s'exécutent tous dans un segment virtuel de 4Go. En gros si le tas
peut pas faire 4Go, la pile le pourra pas plus.
1 Go pour le mapping DLL et un autre pour le mapping system... il
reste même pas 1Go pour le code je crois
,et la pile (par thread )
est par défaut de l'ordre de qqc Mega...
Tu es toujours aussi désagréable à chaque fois que tu réponds, oh
grand gourou de l'informatique?
Tu es toujours aussi désagréable à chaque fois que tu réponds, oh
grand gourou de l'informatique?
Tu es toujours aussi désagréable à chaque fois que tu réponds, oh
grand gourou de l'informatique?
Arnaud Debaene wrote:Tu es toujours aussi désagréable à chaque fois que tu réponds, oh
grand gourou de l'informatique?
Heu, t'es vraiment sûr que c'est pas péjoratif hein ?
Arnaud Debaene wrote:
Tu es toujours aussi désagréable à chaque fois que tu réponds, oh
grand gourou de l'informatique?
Heu, t'es vraiment sûr que c'est pas péjoratif hein ?
Arnaud Debaene wrote:Tu es toujours aussi désagréable à chaque fois que tu réponds, oh
grand gourou de l'informatique?
Heu, t'es vraiment sûr que c'est pas péjoratif hein ?
Tu crois mal : Il y a 2GO pour *toutes* les données du mode user :
code, tas, piles, TLS, données statiques, etc...
Comme l'OP la dit, c'est (généralement) un paramètre du compilateur.
C'est en tout cas un champ dans l'en-tête des fichiers PE
(SizeOfStackReserve et StackOfSizeCommit dans IMAGE_OPTIONAL_HEADER).
La valeur par défaut est 1MO.
Tu crois mal : Il y a 2GO pour *toutes* les données du mode user :
code, tas, piles, TLS, données statiques, etc...
Comme l'OP la dit, c'est (généralement) un paramètre du compilateur.
C'est en tout cas un champ dans l'en-tête des fichiers PE
(SizeOfStackReserve et StackOfSizeCommit dans IMAGE_OPTIONAL_HEADER).
La valeur par défaut est 1MO.
Tu crois mal : Il y a 2GO pour *toutes* les données du mode user :
code, tas, piles, TLS, données statiques, etc...
Comme l'OP la dit, c'est (généralement) un paramètre du compilateur.
C'est en tout cas un champ dans l'en-tête des fichiers PE
(SizeOfStackReserve et StackOfSizeCommit dans IMAGE_OPTIONAL_HEADER).
La valeur par défaut est 1MO.
Le gros problème sous Windows c'est les implémentations foireuses
de malloc() &co., du genre :
Ce n'est pas Windows qui implémente malloc : c'est la CRT que tu utilises :
celle de VC, celle de Borland ou autre... Tu penses à laquelle en
particulier?
* pour allouer un bloc il faut généralement traverser tous ceux
du tas avant de trouver un espace libre, ce qui est cata-
strophique au niveau performance.
Tu connais des implémentations d'allocateur généraliste (pas de taille fixe,
etc...) qui font autrement sans obtenir rapidement une fragmentation
catastrophique?
Raison de performances pour le coup : appeler free sur un pointeur non aloué
par malloc est un comportement indéfini : à prtir de là, ajouter des tests
supplémentaires est certes une aide au débogage mais également un frein aux
perfs.
Rien qu'en changeant de routine malloc() &co. on y gagne.
Et en la remplacant par?
Le gros problème sous Windows c'est les implémentations foireuses
de malloc() &co., du genre :
Ce n'est pas Windows qui implémente malloc : c'est la CRT que tu utilises :
celle de VC, celle de Borland ou autre... Tu penses à laquelle en
particulier?
* pour allouer un bloc il faut généralement traverser tous ceux
du tas avant de trouver un espace libre, ce qui est cata-
strophique au niveau performance.
Tu connais des implémentations d'allocateur généraliste (pas de taille fixe,
etc...) qui font autrement sans obtenir rapidement une fragmentation
catastrophique?
Raison de performances pour le coup : appeler free sur un pointeur non aloué
par malloc est un comportement indéfini : à prtir de là, ajouter des tests
supplémentaires est certes une aide au débogage mais également un frein aux
perfs.
Rien qu'en changeant de routine malloc() &co. on y gagne.
Et en la remplacant par?
Le gros problème sous Windows c'est les implémentations foireuses
de malloc() &co., du genre :
Ce n'est pas Windows qui implémente malloc : c'est la CRT que tu utilises :
celle de VC, celle de Borland ou autre... Tu penses à laquelle en
particulier?
* pour allouer un bloc il faut généralement traverser tous ceux
du tas avant de trouver un espace libre, ce qui est cata-
strophique au niveau performance.
Tu connais des implémentations d'allocateur généraliste (pas de taille fixe,
etc...) qui font autrement sans obtenir rapidement une fragmentation
catastrophique?
Raison de performances pour le coup : appeler free sur un pointeur non aloué
par malloc est un comportement indéfini : à prtir de là, ajouter des tests
supplémentaires est certes une aide au débogage mais également un frein aux
perfs.
Rien qu'en changeant de routine malloc() &co. on y gagne.
Et en la remplacant par?
> ben, une fois que c'est fait, c'est fait, et étant donné que ca fait partie
des premieres choses qu'on développe quand on commence l'informatique :
tableau dynamique, gestion de collection d'objet, gestion mémoire, gestion
de fichier, database, tri , dichotomie... bon je vais pas vous faire le
programme de première année de BTS... mais bon, si ta pas ces outils dans ta
musette , change de métier.
l'ordre de qqc Mega... faut demander à AMCD qui poste plus ici :-)
Maintenant alloué de la mémoire dans la pile, à part pour quelque kilo de
variables locales... ca ne se pratique pas des masses...
> ben, une fois que c'est fait, c'est fait, et étant donné que ca fait partie
des premieres choses qu'on développe quand on commence l'informatique :
tableau dynamique, gestion de collection d'objet, gestion mémoire, gestion
de fichier, database, tri , dichotomie... bon je vais pas vous faire le
programme de première année de BTS... mais bon, si ta pas ces outils dans ta
musette , change de métier.
l'ordre de qqc Mega... faut demander à AMCD qui poste plus ici :-)
Maintenant alloué de la mémoire dans la pile, à part pour quelque kilo de
variables locales... ca ne se pratique pas des masses...
> ben, une fois que c'est fait, c'est fait, et étant donné que ca fait partie
des premieres choses qu'on développe quand on commence l'informatique :
tableau dynamique, gestion de collection d'objet, gestion mémoire, gestion
de fichier, database, tri , dichotomie... bon je vais pas vous faire le
programme de première année de BTS... mais bon, si ta pas ces outils dans ta
musette , change de métier.
l'ordre de qqc Mega... faut demander à AMCD qui poste plus ici :-)
Maintenant alloué de la mémoire dans la pile, à part pour quelque kilo de
variables locales... ca ne se pratique pas des masses...