cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 21 déc. 2010 à 17:32
Pour les allocations locales, il faut des petits blocs car sinon la fonction est obligée de passer par une allocation globale.
L'allocation globale est plus lente car elle doit faire appel au système plutôt que de rester dans son processus.
Je s
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 21 déc. 2010 à 01:11
Il faudrait être un idiot pour croire que réalloc puisse toujours avoir le même pointeur. Cependant, il y aurait des solutions intermediaires: allouer une zone virtuelle plus grosse et allouer physiquement par petit morceaux à la demande. C'est ce que je t'ai expliqué plus haut mais tu as crié à l'impossibilité, or, ce que tu ne sais pas faire n'est pas forcement impossible.
Deuxièmement, le changement de pointeur est embêtant dans quels cas: Quand le pointeur est partagé par plusieurs fonctions ou threads. Il serait possible de faire les fonctions AllocForRealloc et Realloc2 qui contiendraient la gestion de la memoire virtuelle en plus.
Donc oui, je serais capable de la programmer et non, je ne l'ai pas encore fait. Cela ne veut pas dire que c'est impossible mais juste que je n'en ai pas eut encore besoin.
@++
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 21 déc. 2010 à 00:22
mmap.realloc:;(MMAP*,*,CB):CF&EAX=SIZE,!CF
LBEG
mov ebx,__parm(1)
mov eax,__parm(2)
xor edx,edx
mov esi,[ebx+MMAP.pdir]
mov ecx,[ebx+MMAP.cdir]
call mmap.getnode
jb .5
mov edx,[esi+ecx*8+4]
lea edi,[esi+ecx*8+4]
.1; tant que ccb < cbreq
cmp edx,__parm(3)
mov eax,__parm(2)
jb .3
je .4
.2;recherche du bloc suivant
mov esi,[ebx+MMAP.pdir]
add eax,edx
mov ecx,[ebx+MMAP.cdir]
call mmap.getnode
jb .5
.21;allocation du bloc suivant
btr pd[esi+ecx*8+4],BLOCLOCK
jnb .5
.22;liberation du bloc suivant
add edx,[esi+ecx*8+4]
mov pd[esi+ecx*8],0
mov pd[esi+ecx*8+4],2
jmp .1
.3;coupe le bloc.
mov eax,__parm(3)
sub edx,__parm(3)
add eax,__parm(2)
call mmap.allocnode
mov eax,edx
mov edx,__parm(3)
jnb .4
add edx,eax
.4;met a jour la node.
mov [edi],edx
mov __eax,edx
clc
LEND
ret
.5
mov __eax,edx
stc
LEND
ret
Cette fonction réalloc ne change jamais le pointeur, elle préfère ressortir en echec. A l'utilisateur de réallouer une autre zone et de copier la précedente. J'aurais pu automatiser mais je n'ai jamais utilisé ni même testé cette fonction. Par contre, on y pense pas forcement mais un réalloc d'une zone plus petite libèrera la partie en trop.
Vu que ça semblait te tenir à coeur de la voir, la voilà...
ToutEnMasm
Messages postés587Date d'inscriptionjeudi 28 novembre 2002StatutMembreDernière intervention13 décembre 20223 15 déc. 2010 à 18:37
Je n'ai pas trop le temps de "cogiter" là desus et HeapReAlloc me va bien.Merci quand même.
Ce qui peut être fait,si la chose t'interesse,ce sont des tests de rapidité sur le même type de fonctions que HeapReAlloc.Avec la heap ,avec globalrealloc..
Globalrealloc est donné plus rapide sur de gros blocs de mémoire et Heaprealloc plus rapide sur de petits blocs de mémoires,reste a savoir dans quels conditions et à vérifier l'assertion.
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 15 déc. 2010 à 12:36
Si tu avais regardé le source, tu aurais vu que le code n'est plus mis à jour. Ma version est ok. Pour finir, ce n'est pas une question de mieux ou de moins bien, mais de choix...
Si tu nous exposais les tiens, il y aurait peut-être matière à cogiter...
ToutEnMasm
Messages postés587Date d'inscriptionjeudi 28 novembre 2002StatutMembreDernière intervention13 décembre 20223 12 déc. 2010 à 14:28
"Si tu avais regardé le code, tu aurais vu qu'une fonction réalloc verifie avant de changer d'adresse, si il n'est pas possible de le faire sans."
Voila,j'ai gagné 10 mn à regardé ton code et j'obtiens en plus un aveu,le changement d'adresse est nécessaire dans certains cas.
HeapReAlloc ne fait rien d'autre et surement mieux que toi (sans vouloir te vexer).
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 12 déc. 2010 à 12:17
Et puis au lieu de me parler de "Microsoft", parle moi plutôt de Russinovich et des programmeurs qui existent réellement.
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 12 déc. 2010 à 12:11
Si tu avais regardé le code, tu aurais vu qu'une fonction réalloc verifie avant de changer d'adresse, si il n'est pas possible de le faire sans.
Je n'ai pas la prétention de faire mieux que microsoft mais toi tu as celle de faciliter la gestion de la memoire. Je ne fais que transmettre des choses que j'ai réfléchies à l'avance...
ToutEnMasm
Messages postés587Date d'inscriptionjeudi 28 novembre 2002StatutMembreDernière intervention13 décembre 20223 10 déc. 2010 à 17:31
Si on suit tes dires , tu es capable de créer le même type de fonction que HeapReAlloc ,remplissant le même rôle, et ceci sans que la fonction décale les adresses.
J'attends cette fonction,et non pas une autre,ou du baratin.
Ta prétention est,je fais mieux que microsoft.Prouve le.
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 9 déc. 2010 à 17:14
"Si patatalo veut faire "sa sauce" à la place de microsoft,rien ne l'empêche de faire un source.
Ce serait une bonne réponse."
Tu trouveras dans la source "livecd" un fichier qui s'appelle mmap.asm: c'est un début d'idée, le porter sur Windows serait très simple.
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 9 déc. 2010 à 03:56
Il y a une autre solution qui est utilisée dans le kernel Windows mais pas pour cette raison je crois. Il faudrait associer des tags aux allocations, ce qui permettrait de savoir à quel usage correspond telle ou telle allocation.
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 9 déc. 2010 à 02:38
Je me demandais comment ton truc pourrait fonctionner et peut-être est-ce là l'idée que tu avais:
pour empêcher les fuites de memoire, il faudrait que le programme soit découpé en morceau bien distinct. Chaque morceau disposerait de son propre tableau. Quand le programme saute d'une étape à l'autre, on sait que l'on peut liberer le tableau dans son ensemble.
Ca me paraît quand même assez chaud à mettre en place pour un logiciel digne de ce nom. De plus, ce que l'on gagnerait en sécurité, on le perdrait en besoin de traitement.
Pour finir, je dirais que le code qui gère le tableau ne devrais pas retourner des indexes à l'appelant mais le pointeur quand même afin d'eviter des appels trop fréquents au tableau. Le tableau ne servirait ainsi que de garde fou. ( C'est peut-être déjà comme cela que tu l'as prévu, je n'ai pas regardé le code car les .inc ne sont pas téléchargeables directement.) A ce propos, tu peux tout à fait faire un include "file.asm", ce n'est pas gênant pour l'assembleur.
@++
ToutEnMasm
Messages postés587Date d'inscriptionjeudi 28 novembre 2002StatutMembreDernière intervention13 décembre 20223 7 déc. 2010 à 10:48
Si patatalo veut faire "sa sauce" à la place de microsoft,rien ne l'empêche de faire un source.
Ce serait une bonne réponse.
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 6 déc. 2010 à 23:02
Evidement que c'est le système qui s'occupe de gerer les choses derrières les fonctions que tu utilises (heureusement non ?). Cela ne t'empêches certainement pas de faire ta propre sauce. D'ailleurs, les gestionnaires de heap n'ont pas tous les mêmes benchmark et les mêmes capacitées.
Je pense plutôt que tu travaille sur des sujets que tu ne maîtrises pas tout en voulant nous faire croire que oui. L'utilité de cette source pour toutes les raisons que tu avances est loin d'être prouvé.
ToutEnMasm
Messages postés587Date d'inscriptionjeudi 28 novembre 2002StatutMembreDernière intervention13 décembre 20223 6 déc. 2010 à 08:11
Ce que tu ne comprend pas c'est la manière dont le système gère la mémoire.Les blocs doivent rester contigus car on ne peut pas adresser une mémoire composée de petits morceaux.
La gestion de la mémoire est faite par le système et non par mon ingéniosité.Autrement dit,tu es en train de donner des leçons a microsoft,amusant non !?
Pour t'en convaincre,regarde la documentation de la fonction HeapReAlloc (MSDN),il est bien préciser que le pointeur de heap peut changer.
citation msdn
HeapReAlloc is guaranteed to preserve the content of the memory being reallocated, even if the new memory is allocated at a different location.
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 5 déc. 2010 à 01:53
Si la mémoire avait dû être gérée par index comme les HINSTANCE et autres handles, je ne pense pas qu'ils aient eut besoin de l'ingeniosité de Toutenmasm ;-)
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 5 déc. 2010 à 01:30
A noter également que c'est inutilisable en environnement multithread.
C'est évidement faisable et assez simplement ce que je dis. Les petits blocs entre les gros blocs sont utilisés pour l'allocation des petits objets justement.
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 5 déc. 2010 à 01:07
pas vraiment compris ce que tu racontes. Tu ne confondrait pas memoire virtuelle et memoire physique ?
ToutEnMasm
Messages postés587Date d'inscriptionjeudi 28 novembre 2002StatutMembreDernière intervention13 décembre 20223 1 déc. 2010 à 09:40
Le changement d'adresse des tampons mémoires est un choix fait par le système pour optimiser la gestion de la quantité de mémoire disponible.En particulier éviter les trous inutilisables.
Même si c'était possible,je ne vois pas l'intérêt de le faire vu que ça diminue la quantité de mémoire disponible.
cs_patatalo
Messages postés1466Date d'inscriptionvendredi 2 janvier 2004StatutModérateurDernière intervention14 février 20142 30 nov. 2010 à 20:49
salut,
Tu devrais pouvoir agrandir l'index sans changer l'emplacement en mémoire en reservant une partie plus grosse mais en commitant morceau par morceau.
Le heap étant pour moi une interface entre la memoire virtuelle et une allocation memoire malloc, les éléments de petite taille pourraient avoir une gestion d'allocation différente de ceux de grosse taille. Chaque petit objet < 16 octets seraient stockés dans une liste chainée.
--HEAD
| DATA1
->NODE1--
DATA2 |
NODEN<-
DATAN
Je ne suis pas sur que cela puisse empêcher d'oublier de liberer un bloc mémoire devenu inutile dans le programme (leak). Windows libère la mémoire d'un process quoi qu'il en soit à la fermeture de ce process. Rien de gagné pour le système en lui-même.
21 déc. 2010 à 17:32
L'allocation globale est plus lente car elle doit faire appel au système plutôt que de rester dans son processus.
Je s
21 déc. 2010 à 01:11
Deuxièmement, le changement de pointeur est embêtant dans quels cas: Quand le pointeur est partagé par plusieurs fonctions ou threads. Il serait possible de faire les fonctions AllocForRealloc et Realloc2 qui contiendraient la gestion de la memoire virtuelle en plus.
Donc oui, je serais capable de la programmer et non, je ne l'ai pas encore fait. Cela ne veut pas dire que c'est impossible mais juste que je n'en ai pas eut encore besoin.
@++
21 déc. 2010 à 00:22
LBEG
mov ebx,__parm(1)
mov eax,__parm(2)
xor edx,edx
mov esi,[ebx+MMAP.pdir]
mov ecx,[ebx+MMAP.cdir]
call mmap.getnode
jb .5
mov edx,[esi+ecx*8+4]
lea edi,[esi+ecx*8+4]
.1; tant que ccb < cbreq
cmp edx,__parm(3)
mov eax,__parm(2)
jb .3
je .4
.2;recherche du bloc suivant
mov esi,[ebx+MMAP.pdir]
add eax,edx
mov ecx,[ebx+MMAP.cdir]
call mmap.getnode
jb .5
.21;allocation du bloc suivant
btr pd[esi+ecx*8+4],BLOCLOCK
jnb .5
.22;liberation du bloc suivant
add edx,[esi+ecx*8+4]
mov pd[esi+ecx*8],0
mov pd[esi+ecx*8+4],2
jmp .1
.3;coupe le bloc.
mov eax,__parm(3)
sub edx,__parm(3)
add eax,__parm(2)
call mmap.allocnode
mov eax,edx
mov edx,__parm(3)
jnb .4
add edx,eax
.4;met a jour la node.
mov [edi],edx
mov __eax,edx
clc
LEND
ret
.5
mov __eax,edx
stc
LEND
ret
Cette fonction réalloc ne change jamais le pointeur, elle préfère ressortir en echec. A l'utilisateur de réallouer une autre zone et de copier la précedente. J'aurais pu automatiser mais je n'ai jamais utilisé ni même testé cette fonction. Par contre, on y pense pas forcement mais un réalloc d'une zone plus petite libèrera la partie en trop.
Vu que ça semblait te tenir à coeur de la voir, la voilà...
15 déc. 2010 à 18:37
Ce qui peut être fait,si la chose t'interesse,ce sont des tests de rapidité sur le même type de fonctions que HeapReAlloc.Avec la heap ,avec globalrealloc..
Globalrealloc est donné plus rapide sur de gros blocs de mémoire et Heaprealloc plus rapide sur de petits blocs de mémoires,reste a savoir dans quels conditions et à vérifier l'assertion.
15 déc. 2010 à 12:36
Si tu nous exposais les tiens, il y aurait peut-être matière à cogiter...
12 déc. 2010 à 14:28
Voila,j'ai gagné 10 mn à regardé ton code et j'obtiens en plus un aveu,le changement d'adresse est nécessaire dans certains cas.
HeapReAlloc ne fait rien d'autre et surement mieux que toi (sans vouloir te vexer).
12 déc. 2010 à 12:17
12 déc. 2010 à 12:11
Je n'ai pas la prétention de faire mieux que microsoft mais toi tu as celle de faciliter la gestion de la memoire. Je ne fais que transmettre des choses que j'ai réfléchies à l'avance...
10 déc. 2010 à 17:31
J'attends cette fonction,et non pas une autre,ou du baratin.
Ta prétention est,je fais mieux que microsoft.Prouve le.
9 déc. 2010 à 17:14
Ce serait une bonne réponse."
Tu trouveras dans la source "livecd" un fichier qui s'appelle mmap.asm: c'est un début d'idée, le porter sur Windows serait très simple.
9 déc. 2010 à 03:56
9 déc. 2010 à 02:38
pour empêcher les fuites de memoire, il faudrait que le programme soit découpé en morceau bien distinct. Chaque morceau disposerait de son propre tableau. Quand le programme saute d'une étape à l'autre, on sait que l'on peut liberer le tableau dans son ensemble.
Ca me paraît quand même assez chaud à mettre en place pour un logiciel digne de ce nom. De plus, ce que l'on gagnerait en sécurité, on le perdrait en besoin de traitement.
Pour finir, je dirais que le code qui gère le tableau ne devrais pas retourner des indexes à l'appelant mais le pointeur quand même afin d'eviter des appels trop fréquents au tableau. Le tableau ne servirait ainsi que de garde fou. ( C'est peut-être déjà comme cela que tu l'as prévu, je n'ai pas regardé le code car les .inc ne sont pas téléchargeables directement.) A ce propos, tu peux tout à fait faire un include "file.asm", ce n'est pas gênant pour l'assembleur.
@++
7 déc. 2010 à 10:48
Ce serait une bonne réponse.
6 déc. 2010 à 23:02
Je pense plutôt que tu travaille sur des sujets que tu ne maîtrises pas tout en voulant nous faire croire que oui. L'utilité de cette source pour toutes les raisons que tu avances est loin d'être prouvé.
6 déc. 2010 à 08:11
La gestion de la mémoire est faite par le système et non par mon ingéniosité.Autrement dit,tu es en train de donner des leçons a microsoft,amusant non !?
Pour t'en convaincre,regarde la documentation de la fonction HeapReAlloc (MSDN),il est bien préciser que le pointeur de heap peut changer.
citation msdn
HeapReAlloc is guaranteed to preserve the content of the memory being reallocated, even if the new memory is allocated at a different location.
5 déc. 2010 à 01:53
http://msdn.microsoft.com/en-us/library/aa366887%28VS.85%29.aspx
Si la mémoire avait dû être gérée par index comme les HINSTANCE et autres handles, je ne pense pas qu'ils aient eut besoin de l'ingeniosité de Toutenmasm ;-)
5 déc. 2010 à 01:30
C'est évidement faisable et assez simplement ce que je dis. Les petits blocs entre les gros blocs sont utilisés pour l'allocation des petits objets justement.
5 déc. 2010 à 01:07
1 déc. 2010 à 09:40
Même si c'était possible,je ne vois pas l'intérêt de le faire vu que ça diminue la quantité de mémoire disponible.
30 nov. 2010 à 20:49
Tu devrais pouvoir agrandir l'index sans changer l'emplacement en mémoire en reservant une partie plus grosse mais en commitant morceau par morceau.
Le heap étant pour moi une interface entre la memoire virtuelle et une allocation memoire malloc, les éléments de petite taille pourraient avoir une gestion d'allocation différente de ceux de grosse taille. Chaque petit objet < 16 octets seraient stockés dans une liste chainée.
--HEAD
| DATA1
->NODE1--
DATA2 |
NODEN<-
DATAN
Je ne suis pas sur que cela puisse empêcher d'oublier de liberer un bloc mémoire devenu inutile dans le programme (leak). Windows libère la mémoire d'un process quoi qu'il en soit à la fermeture de ce process. Rien de gagné pour le système en lui-même.
@++