Bonjour =E0 tous et meilleurs voeux pour 2006 (la sant=E9 surtout) !
J'ai cr=E9=E9 un script objet en m'aidant de didacticiels en r=E9f=E9rence
sur le forum et j'ai un petit probl=E8me concernant la destruction
d'objet.
J'ai cr=E9=E9 une classe dont le constructeur est du sytle $self =3D
{'array1' =3D [], 'array2' =3D [], 'hash1' =3D {} ...}
Dans les didacticiels il est donc indiqu=E9 qu'on peut utiliser une
classe DESTROY qui n'est utilis=E9e qu'en fin de programme.
Je voudrais d=E9truire un objet une fois celui-ci utilis=E9 afin de
lib=E9rer de la m=E9moire et continuer mon script (j'ai pour l'instant
700 Mo de RAM utilis=E9s pour 750 dispo, je stocke de gros fichiers
texte).
J'ai tent=E9 de r=E9initialis=E9 mes valeurs en r=E9affectant $self =3D
{'array1' =3D [], 'array2' =3D [], 'hash1' =3D {} ...} et en v=E9rifiant
l'=E9tat en cr=E9ant un boucle while (1 =3D=3D 1) {} mais j'ai toujours 700
Mo occup=E9s.
Merci beaucoup si vous pouvez m'aider, c'est assez urgent et pour le
boulot :-)
Là encore tout n'est pas noir ou blanc... La gestion de la mémoire n'est qu'un vaste compromis.
Oui. Il se résout d'ailleurs assez bien avec des modèles simples. À une école d'été de l'AFCET avait été proposé un système comptabilisant l'appel disque au prix du système pendant le temps d'exécution de la requête (on pourrait aujourd'hui diviser par le nombre de processus principaux), et la mémoire à son coût nominal par seconde. Il y avait des microfrancs partout dans les équations, mais on débouchait sur des compromisintéressants, en particulier sur le fait qu'une pile de taille quasi-infinie était possible sous forme de segments en mémoire *sans* pénalité de performance, en swappant vers le disque ou depuis lui le segment se trouvant à une distance critique (et calculée) du sommet de pile.
Je me souviens que la puissance d'un système se ramenait, dans un des ces modèles, à sqrt(a x b), où a était le coût de l'appel disque et b le coût du Ko de RAm par seconde.
Il y a sûrement un newsgroup plus approprié pour discuter de cela, mais je ne sais pas lequel. Sens-toi libre de faire le FU2 approprié.
Là encore tout n'est pas noir ou blanc... La gestion de la mémoire
n'est qu'un vaste compromis.
Oui. Il se résout d'ailleurs assez bien avec des modèles simples. À une
école d'été de l'AFCET avait été proposé un système comptabilisant
l'appel disque au prix du système pendant le temps d'exécution de la
requête (on pourrait aujourd'hui diviser par le nombre de processus
principaux), et la mémoire à son coût nominal par seconde. Il y avait
des microfrancs partout dans les équations, mais on débouchait sur des
compromisintéressants, en particulier sur le fait qu'une pile de taille
quasi-infinie était possible sous forme de segments en mémoire *sans*
pénalité de performance, en swappant vers le disque ou depuis lui le
segment se trouvant à une distance critique (et calculée) du sommet de pile.
Je me souviens que la puissance d'un système se ramenait, dans un des
ces modèles, à sqrt(a x b), où a était le coût de l'appel disque et b le
coût du Ko de RAm par seconde.
Il y a sûrement un newsgroup plus approprié pour discuter de cela, mais
je ne sais pas lequel. Sens-toi libre de faire le FU2 approprié.
Là encore tout n'est pas noir ou blanc... La gestion de la mémoire n'est qu'un vaste compromis.
Oui. Il se résout d'ailleurs assez bien avec des modèles simples. À une école d'été de l'AFCET avait été proposé un système comptabilisant l'appel disque au prix du système pendant le temps d'exécution de la requête (on pourrait aujourd'hui diviser par le nombre de processus principaux), et la mémoire à son coût nominal par seconde. Il y avait des microfrancs partout dans les équations, mais on débouchait sur des compromisintéressants, en particulier sur le fait qu'une pile de taille quasi-infinie était possible sous forme de segments en mémoire *sans* pénalité de performance, en swappant vers le disque ou depuis lui le segment se trouvant à une distance critique (et calculée) du sommet de pile.
Je me souviens que la puissance d'un système se ramenait, dans un des ces modèles, à sqrt(a x b), où a était le coût de l'appel disque et b le coût du Ko de RAm par seconde.
Il y a sûrement un newsgroup plus approprié pour discuter de cela, mais je ne sais pas lequel. Sens-toi libre de faire le FU2 approprié.
Nicolas George
FDA wrote in message <43bd5c8e$0$17738$:
Pour terminer sur ce point, en supprimant le dispositif de swapping, on y gagne au moins de ne pas devoir le charger en mémoire si le système est écrit correctement. C'est toujours (éventuellement) cela de gagné.
Et on y perd la possiblité pour le système de décharger en swap les parties inutiles de certaines applications, au profit de davantage de cache disque.
FDA wrote in message
<43bd5c8e$0$17738$79c14f64@nan-newsreader-05.noos.net>:
Pour terminer sur ce point, en supprimant le dispositif de swapping, on
y gagne au moins de ne pas devoir le charger en mémoire si le système
est écrit correctement. C'est toujours (éventuellement) cela de gagné.
Et on y perd la possiblité pour le système de décharger en swap les parties
inutiles de certaines applications, au profit de davantage de cache disque.
Pour terminer sur ce point, en supprimant le dispositif de swapping, on y gagne au moins de ne pas devoir le charger en mémoire si le système est écrit correctement. C'est toujours (éventuellement) cela de gagné.
Et on y perd la possiblité pour le système de décharger en swap les parties inutiles de certaines applications, au profit de davantage de cache disque.
Nicolas George
FDA wrote in message <43bd5e0e$0$17737$:
Oui. Il se résout d'ailleurs assez bien avec des modèles simples.
Peut-être, mais pour le résoudre _vraiment_ bien, il faut des modèles autrement plus complexes, qui visent à choisir quelles pages de quels processus décharger en priorité de manière à pénaliser le moins possible le système. En pratique, ça donne dans les OS réels des mécanismes de mémoire virtuelle qui sont extrêmement complexes, mais diablement efficaces, très nettement meilleurs en général que quand un administrateur du dimanche se met dans l'idée de les désactiver.
FDA wrote in message
<43bd5e0e$0$17737$79c14f64@nan-newsreader-05.noos.net>:
Oui. Il se résout d'ailleurs assez bien avec des modèles simples.
Peut-être, mais pour le résoudre _vraiment_ bien, il faut des modèles
autrement plus complexes, qui visent à choisir quelles pages de quels
processus décharger en priorité de manière à pénaliser le moins possible le
système. En pratique, ça donne dans les OS réels des mécanismes de mémoire
virtuelle qui sont extrêmement complexes, mais diablement efficaces, très
nettement meilleurs en général que quand un administrateur du dimanche se
met dans l'idée de les désactiver.
Oui. Il se résout d'ailleurs assez bien avec des modèles simples.
Peut-être, mais pour le résoudre _vraiment_ bien, il faut des modèles autrement plus complexes, qui visent à choisir quelles pages de quels processus décharger en priorité de manière à pénaliser le moins possible le système. En pratique, ça donne dans les OS réels des mécanismes de mémoire virtuelle qui sont extrêmement complexes, mais diablement efficaces, très nettement meilleurs en général que quand un administrateur du dimanche se met dans l'idée de les désactiver.
FDA
FDA wrote in message <43bd5e0e$0$17737$:
Oui. Il se résout d'ailleurs assez bien avec des modèles simples.
Peut-être, mais pour le résoudre _vraiment_ bien, il faut des modèles autrement plus complexes, qui visent à choisir quelles pages de quels processus décharger en priorité de manière à pénaliser le moins possible le système. En pratique, ça donne dans les OS réels des mécanismes de mémoire virtuelle qui sont extrêmement complexes, mais diablement efficaces, très nettement meilleurs en général que quand un administrateur du dimanche se met dans l'idée de les désactiver.
Je crois tout de même que nous sommes là - en ce qui concerne les stations de travail personnelles - dans le domaine du passé. Le rapport de temps d'accès d'une RAM actuelle et d'un disque actuel est plus grand encore que ceux d'une RAM de 1980 et d'une bande magnétique de 1980. Utiliser le disque pour stocker des programmes, c'est très bien. Utiliser le disque pour épauler la RAM, cela n'a tout simplement pas de sens. Et a moins de sens encore la manipulation (vue dans une revue qui se veut technique!) de mettre le fichier de pagination dans un RAMdisk réduisant d'autant la RAM, et donc forçant à recourir à ce fichier de pagination. Là, nous entrons dans le délire total.
La mémoire virtuelle fut une grande invention à la fin des années 60, avec les coûts et les performances des années 60. Aujourd'hui, ce n'est plus qu'une survivance historique, qu'on est bien content d'inhiber (il reste les fonctions de relocation dynamique de l'architecture 386, seule chose dont on ait vraiment besoin en fait pour les performances).
FDA wrote in message
<43bd5e0e$0$17737$79c14f64@nan-newsreader-05.noos.net>:
Oui. Il se résout d'ailleurs assez bien avec des modèles simples.
Peut-être, mais pour le résoudre _vraiment_ bien, il faut des modèles
autrement plus complexes, qui visent à choisir quelles pages de quels
processus décharger en priorité de manière à pénaliser le moins possible le
système. En pratique, ça donne dans les OS réels des mécanismes de mémoire
virtuelle qui sont extrêmement complexes, mais diablement efficaces, très
nettement meilleurs en général que quand un administrateur du dimanche se
met dans l'idée de les désactiver.
Je crois tout de même que nous sommes là - en ce qui concerne les
stations de travail personnelles - dans le domaine du passé. Le rapport
de temps d'accès d'une RAM actuelle et d'un disque actuel est plus grand
encore que ceux d'une RAM de 1980 et d'une bande magnétique de 1980.
Utiliser le disque pour stocker des programmes, c'est très bien.
Utiliser le disque pour épauler la RAM, cela n'a tout simplement pas de
sens. Et a moins de sens encore la manipulation (vue dans une revue qui
se veut technique!) de mettre le fichier de pagination dans un RAMdisk
réduisant d'autant la RAM, et donc forçant à recourir à ce fichier de
pagination. Là, nous entrons dans le délire total.
La mémoire virtuelle fut une grande invention à la fin des années 60,
avec les coûts et les performances des années 60. Aujourd'hui, ce n'est
plus qu'une survivance historique, qu'on est bien content d'inhiber (il
reste les fonctions de relocation dynamique de l'architecture 386, seule
chose dont on ait vraiment besoin en fait pour les performances).
Oui. Il se résout d'ailleurs assez bien avec des modèles simples.
Peut-être, mais pour le résoudre _vraiment_ bien, il faut des modèles autrement plus complexes, qui visent à choisir quelles pages de quels processus décharger en priorité de manière à pénaliser le moins possible le système. En pratique, ça donne dans les OS réels des mécanismes de mémoire virtuelle qui sont extrêmement complexes, mais diablement efficaces, très nettement meilleurs en général que quand un administrateur du dimanche se met dans l'idée de les désactiver.
Je crois tout de même que nous sommes là - en ce qui concerne les stations de travail personnelles - dans le domaine du passé. Le rapport de temps d'accès d'une RAM actuelle et d'un disque actuel est plus grand encore que ceux d'une RAM de 1980 et d'une bande magnétique de 1980. Utiliser le disque pour stocker des programmes, c'est très bien. Utiliser le disque pour épauler la RAM, cela n'a tout simplement pas de sens. Et a moins de sens encore la manipulation (vue dans une revue qui se veut technique!) de mettre le fichier de pagination dans un RAMdisk réduisant d'autant la RAM, et donc forçant à recourir à ce fichier de pagination. Là, nous entrons dans le délire total.
La mémoire virtuelle fut une grande invention à la fin des années 60, avec les coûts et les performances des années 60. Aujourd'hui, ce n'est plus qu'une survivance historique, qu'on est bien content d'inhiber (il reste les fonctions de relocation dynamique de l'architecture 386, seule chose dont on ait vraiment besoin en fait pour les performances).
FDA
FDA wrote in message <43bd5c8e$0$17738$:
Pour terminer sur ce point, en supprimant le dispositif de swapping, on y gagne au moins de ne pas devoir le charger en mémoire si le système est écrit correctement. C'est toujours (éventuellement) cela de gagné.
Et on y perd la possiblité pour le système de décharger en swap les parties inutiles de certaines applications, au profit de davantage de cache disque.
Les parties inutiles d'une application n'ont rien à faire en mémoire. L'overlay, c'est autrement plus performant que la mémoire virtuelle, et ce n'est pas fait pour les chiens.
FDA wrote in message
<43bd5c8e$0$17738$79c14f64@nan-newsreader-05.noos.net>:
Pour terminer sur ce point, en supprimant le dispositif de swapping, on
y gagne au moins de ne pas devoir le charger en mémoire si le système
est écrit correctement. C'est toujours (éventuellement) cela de gagné.
Et on y perd la possiblité pour le système de décharger en swap les parties
inutiles de certaines applications, au profit de davantage de cache disque.
Les parties inutiles d'une application n'ont rien à faire en mémoire.
L'overlay, c'est autrement plus performant que la mémoire virtuelle, et
ce n'est pas fait pour les chiens.
Pour terminer sur ce point, en supprimant le dispositif de swapping, on y gagne au moins de ne pas devoir le charger en mémoire si le système est écrit correctement. C'est toujours (éventuellement) cela de gagné.
Et on y perd la possiblité pour le système de décharger en swap les parties inutiles de certaines applications, au profit de davantage de cache disque.
Les parties inutiles d'une application n'ont rien à faire en mémoire. L'overlay, c'est autrement plus performant que la mémoire virtuelle, et ce n'est pas fait pour les chiens.
Nicolas George
FDA wrote in message <43bdb58d$0$19028$:
Le rapport de temps d'accès d'une RAM actuelle et d'un disque actuel est plus grand encore que ceux d'une RAM de 1980 et d'une bande magnétique de 1980.
Oui. Raison de plus de permettre au maximum au système de décharger les parties peu utiles de la mémoire au profit de cache disque plus utile, par exemple.
FDA wrote in message
<43bdb58d$0$19028$79c14f64@nan-newsreader-07.noos.net>:
Le rapport
de temps d'accès d'une RAM actuelle et d'un disque actuel est plus grand
encore que ceux d'une RAM de 1980 et d'une bande magnétique de 1980.
Oui. Raison de plus de permettre au maximum au système de décharger les
parties peu utiles de la mémoire au profit de cache disque plus utile, par
exemple.
Le rapport de temps d'accès d'une RAM actuelle et d'un disque actuel est plus grand encore que ceux d'une RAM de 1980 et d'une bande magnétique de 1980.
Oui. Raison de plus de permettre au maximum au système de décharger les parties peu utiles de la mémoire au profit de cache disque plus utile, par exemple.
Nicolas George
FDA wrote in message <43bdb5c0$0$19028$:
Les parties inutiles d'une application n'ont rien à faire en mémoire.
Exactement. Or sans mémoire virtuelle, avec la plupart des designs d'OS actuels, elles y restent quand même. C'est comme ça.
FDA wrote in message
<43bdb5c0$0$19028$79c14f64@nan-newsreader-07.noos.net>:
Les parties inutiles d'une application n'ont rien à faire en mémoire.
Exactement. Or sans mémoire virtuelle, avec la plupart des designs d'OS
actuels, elles y restent quand même. C'est comme ça.
Les parties inutiles d'une application n'ont rien à faire en mémoire.
Exactement. Or sans mémoire virtuelle, avec la plupart des designs d'OS actuels, elles y restent quand même. C'est comme ça.
Paul Gaborit
À (at) Thu, 05 Jan 2006 18:52:11 +0100, FDA écrivait (wrote):
Pour terminer sur ce point, en supprimant le dispositif de swapping, on y gagne au moins de ne pas devoir le charger en mémoire si le système est écrit correctement. C'est toujours (éventuellement) cela de gagné.
Ce serait un gain minime... qui n'existe pas car ce n'est pas parce qu'on supprime le swap qu'on supprime la besoin de gestion de mémoire virtuelle. La plupart des systèmes (unix... pour Windows je ne sais pas) utilisent l'appel système 'mmap' pour le code et beaucoup de softs l'utilisent pour les données. Or, ça aussi, ça utilise de la mémoire paginée qui se ballade entre la mémoire réelle et le disque.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Thu, 05 Jan 2006 18:52:11 +0100,
FDA <armingaud@gmail.com> écrivait (wrote):
Pour terminer sur ce point, en supprimant le dispositif de swapping,
on y gagne au moins de ne pas devoir le charger en mémoire si le
système est écrit correctement. C'est toujours (éventuellement) cela
de gagné.
Ce serait un gain minime... qui n'existe pas car ce n'est pas parce
qu'on supprime le swap qu'on supprime la besoin de gestion de mémoire
virtuelle. La plupart des systèmes (unix... pour Windows je ne sais
pas) utilisent l'appel système 'mmap' pour le code et beaucoup de
softs l'utilisent pour les données. Or, ça aussi, ça utilise de la
mémoire paginée qui se ballade entre la mémoire réelle et le disque.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Thu, 05 Jan 2006 18:52:11 +0100, FDA écrivait (wrote):
Pour terminer sur ce point, en supprimant le dispositif de swapping, on y gagne au moins de ne pas devoir le charger en mémoire si le système est écrit correctement. C'est toujours (éventuellement) cela de gagné.
Ce serait un gain minime... qui n'existe pas car ce n'est pas parce qu'on supprime le swap qu'on supprime la besoin de gestion de mémoire virtuelle. La plupart des systèmes (unix... pour Windows je ne sais pas) utilisent l'appel système 'mmap' pour le code et beaucoup de softs l'utilisent pour les données. Or, ça aussi, ça utilise de la mémoire paginée qui se ballade entre la mémoire réelle et le disque.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
FDA
La plupart des systèmes (unix... pour Windows je ne sais pas) utilisent l'appel système 'mmap' pour le code et beaucoup de softs l'utilisent pour les données. Or, ça aussi, ça utilise de la mémoire paginée qui se ballade entre la mémoire réelle et le disque.
Et il fait la correspondance de ta mémoire avec quoi, le mmap, sinon l'espace de swap ? Je lui prédis quelques difficultés.
(En ce qui me concerne, les deux seuls fichiers que j'utilise sont celui d'entrée, pour lire mes données, et celui de sortie, dans lequel j'envoie mes résultats après la cloture de mon ficher d'entrée; le mmap ne m'apporterait vraiment rien. Cela dit, je le répète, je suis sur une machine personnelle, qui ne joue pas de rôle de serveur (hormis serveur X quand je suis en Linux, héhé).
La plupart des systèmes (unix... pour Windows je ne sais
pas) utilisent l'appel système 'mmap' pour le code et beaucoup de
softs l'utilisent pour les données. Or, ça aussi, ça utilise de la
mémoire paginée qui se ballade entre la mémoire réelle et le disque.
Et il fait la correspondance de ta mémoire avec quoi, le mmap, sinon
l'espace de swap ? Je lui prédis quelques difficultés.
(En ce qui me concerne, les deux seuls fichiers que j'utilise sont celui
d'entrée, pour lire mes données, et celui de sortie, dans lequel
j'envoie mes résultats après la cloture de mon ficher d'entrée; le mmap
ne m'apporterait vraiment rien. Cela dit, je le répète, je suis sur une
machine personnelle, qui ne joue pas de rôle de serveur (hormis serveur
X quand je suis en Linux, héhé).
La plupart des systèmes (unix... pour Windows je ne sais pas) utilisent l'appel système 'mmap' pour le code et beaucoup de softs l'utilisent pour les données. Or, ça aussi, ça utilise de la mémoire paginée qui se ballade entre la mémoire réelle et le disque.
Et il fait la correspondance de ta mémoire avec quoi, le mmap, sinon l'espace de swap ? Je lui prédis quelques difficultés.
(En ce qui me concerne, les deux seuls fichiers que j'utilise sont celui d'entrée, pour lire mes données, et celui de sortie, dans lequel j'envoie mes résultats après la cloture de mon ficher d'entrée; le mmap ne m'apporterait vraiment rien. Cela dit, je le répète, je suis sur une machine personnelle, qui ne joue pas de rôle de serveur (hormis serveur X quand je suis en Linux, héhé).
FDA
FDA wrote in message <43bdb58d$0$19028$:
Le rapport de temps d'accès d'une RAM actuelle et d'un disque actuel est plus grand encore que ceux d'une RAM de 1980 et d'une bande magnétique de 1980.
Oui. Raison de plus de permettre au maximum au système de décharger les parties peu utiles de la mémoire au profit de cache disque plus utile, par exemple.
Consacre carrément 90% de ta mémoire au cache disque, tu seras ravi : la mémoire étant devenue trop petite pour ton application, celle-ci n'arrêtera pas de swapper, ce qui justifiera /a posteriori/ que tu aies pris un grand cache disque :-D
Ce n'est pas sans rappeler l'histoire de Gribouille qui voulait aller dans la Lune en se tirant par les cheveux ;-)
FDA wrote in message
<43bdb58d$0$19028$79c14f64@nan-newsreader-07.noos.net>:
Le rapport
de temps d'accès d'une RAM actuelle et d'un disque actuel est plus grand
encore que ceux d'une RAM de 1980 et d'une bande magnétique de 1980.
Oui. Raison de plus de permettre au maximum au système de décharger les
parties peu utiles de la mémoire au profit de cache disque plus utile, par
exemple.
Consacre carrément 90% de ta mémoire au cache disque, tu seras ravi : la
mémoire étant devenue trop petite pour ton application, celle-ci
n'arrêtera pas de swapper, ce qui justifiera /a posteriori/ que tu aies
pris un grand cache disque :-D
Ce n'est pas sans rappeler l'histoire de Gribouille qui voulait aller
dans la Lune en se tirant par les cheveux ;-)
Le rapport de temps d'accès d'une RAM actuelle et d'un disque actuel est plus grand encore que ceux d'une RAM de 1980 et d'une bande magnétique de 1980.
Oui. Raison de plus de permettre au maximum au système de décharger les parties peu utiles de la mémoire au profit de cache disque plus utile, par exemple.
Consacre carrément 90% de ta mémoire au cache disque, tu seras ravi : la mémoire étant devenue trop petite pour ton application, celle-ci n'arrêtera pas de swapper, ce qui justifiera /a posteriori/ que tu aies pris un grand cache disque :-D
Ce n'est pas sans rappeler l'histoire de Gribouille qui voulait aller dans la Lune en se tirant par les cheveux ;-)