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 :-)
C'est ton droit. Mais puisque tu ne maîtrises pas la question, il serait plus raisonnable que tu évites d'émettre des avis aussi péremptoires, surtout quand ils sont faux.
Non, il ne faut pas "un maximum" de cache disque, il faut la quantité dont tu as besoin et rien de plus.
On n'a pas « besoin » de cache disque, on peut très bien faire sans cache disque du tout, avec juste les buffers d'entrée-sortie. Derrière ça, chaque page de cache disque disponible correspond potentiellement à un accès disque économisé, donc à quelques microsecondes ou millisecondes gagnées. Ce gain de performances est tout à fait sensible sur une machine personnelle, et resterait sensible avec un cache disque bien au delà de la quantité de mémoire raisonnablement disponible sur une machine personnelle.
Au-delà, c'est de l'overkill. La lecture anticipée, oui, mais les paramètres de hdparm sont là pour ça.
Les paramètres hdparm parlent de la lecture physique sur le support, pas de la prévision de lecture au niveau du filesystem.
FDA wrote in message
<43be7362$0$19982$79c14f64@nan-newsreader-07.noos.net>:
Et que je n'ai pas à connaître.
C'est ton droit. Mais puisque tu ne maîtrises pas la question, il serait
plus raisonnable que tu évites d'émettre des avis aussi péremptoires,
surtout quand ils sont faux.
Non, il ne faut pas "un
maximum" de cache disque, il faut la quantité dont tu as besoin et rien
de plus.
On n'a pas « besoin » de cache disque, on peut très bien faire sans cache
disque du tout, avec juste les buffers d'entrée-sortie. Derrière ça, chaque
page de cache disque disponible correspond potentiellement à un accès disque
économisé, donc à quelques microsecondes ou millisecondes gagnées. Ce gain
de performances est tout à fait sensible sur une machine personnelle, et
resterait sensible avec un cache disque bien au delà de la quantité de
mémoire raisonnablement disponible sur une machine personnelle.
Au-delà, c'est de l'overkill. La lecture anticipée, oui, mais
les paramètres de hdparm sont là pour ça.
Les paramètres hdparm parlent de la lecture physique sur le support, pas de
la prévision de lecture au niveau du filesystem.
C'est ton droit. Mais puisque tu ne maîtrises pas la question, il serait plus raisonnable que tu évites d'émettre des avis aussi péremptoires, surtout quand ils sont faux.
Non, il ne faut pas "un maximum" de cache disque, il faut la quantité dont tu as besoin et rien de plus.
On n'a pas « besoin » de cache disque, on peut très bien faire sans cache disque du tout, avec juste les buffers d'entrée-sortie. Derrière ça, chaque page de cache disque disponible correspond potentiellement à un accès disque économisé, donc à quelques microsecondes ou millisecondes gagnées. Ce gain de performances est tout à fait sensible sur une machine personnelle, et resterait sensible avec un cache disque bien au delà de la quantité de mémoire raisonnablement disponible sur une machine personnelle.
Au-delà, c'est de l'overkill. La lecture anticipée, oui, mais les paramètres de hdparm sont là pour ça.
Les paramètres hdparm parlent de la lecture physique sur le support, pas de la prévision de lecture au niveau du filesystem.
Nicolas George
FDA wrote in message <43be7543$0$19981$:
Merci, on sait. Et cette architecture date de 1986.
Et elle continue à faire activement l'objet de recherches intensives de la part des concepteurs de processeurs pour en améliorer les performances.
mais on n'a plus besoin sur un ordinateur personnel, parce que ce n'est plus économiquement intéressant, de pallier un manque de RAM par des ressources allouées sur un périphérique *dix mille fois* plus lent,
Cette affirmation est contraire à tout ce que l'on peut constater au niveau des performances globales d'un système typique en utilisation courante.
FDA wrote in message
<43be7543$0$19981$79c14f64@nan-newsreader-07.noos.net>:
Merci, on sait. Et cette architecture date de 1986.
Et elle continue à faire activement l'objet de recherches intensives de la
part des concepteurs de processeurs pour en améliorer les performances.
mais on n'a plus
besoin sur un ordinateur personnel, parce que ce n'est plus
économiquement intéressant, de pallier un manque de RAM par des
ressources allouées sur un périphérique *dix mille fois* plus lent,
Cette affirmation est contraire à tout ce que l'on peut constater au niveau
des performances globales d'un système typique en utilisation courante.
Merci, on sait. Et cette architecture date de 1986.
Et elle continue à faire activement l'objet de recherches intensives de la part des concepteurs de processeurs pour en améliorer les performances.
mais on n'a plus besoin sur un ordinateur personnel, parce que ce n'est plus économiquement intéressant, de pallier un manque de RAM par des ressources allouées sur un périphérique *dix mille fois* plus lent,
Cette affirmation est contraire à tout ce que l'on peut constater au niveau des performances globales d'un système typique en utilisation courante.
FDA
De toute évidence, tu n'as rien compris au fonctionnement de la mémoire virtuelle d'un système d'exploitation moderne.
La bonne gestion de la mémoire serait celle qui est adaptée d'une part aux structures de données que l'on alloue (ainsi que rappelé plus haut, créer une pile de taille virtuellement infinie ne pose aucun problème ni délai de fonctionnement si l'on a des mécanismes d'anticipation appropriés, et si chaque allocation s'accompagnait d'un profil prévisible d'utilisation pour informer le système. Au lie de cela, nous continons à travailler sur un schéma qui n'a en rien évolué depuis les années 70 : rendre *invisible* au programme la présence ou l'absence d'une page en RAM - ce qui garantit d'empêcher toute tentative d'optimisation, puisqu'on a les yeux bandés.
Le système choisit dynamiquement ce qu'il va mettre en mémoire, en fonction d'heuristiques pour optimiser les performances.
Heuristiques signifie bricolages. Un bricolage n'optimise jamais. AU mieux, il pallie contre des déficiences, nuance.
On ne _choisit_ pas d'affecter 10% aux applications et 90% au cache disque ou le contraire, c'est l'OS qui le détermine en fonction de l'utilisation de la machine à chaque instant.
Le problème est que l'OS ne dispose d'aucune information pour cela. Ce qui fait que l'algorithme d'éviction des pages reste calqué sur celui de l'élimination de collaborateurs en cas de plan social. Dans l'ordre d'élimination :
Si on part d'une situation avec 90% de cache disque et qu'on lance soudainement une application gourmande, le cache disque sera automatiquement réaffecté à cette application (ce qui ne coûte rien en temps).
C'est cela, oui. Flusher le contenu de tout le cache sur disque (s'il y a write-back) et à des emplacements tous différents les uns des autres, c'est sûr que ça ne va rien coûter en temps !
Dans ces conditions, fournir de l'espace d'échange à l'OS augmente la latitude qu'il a pour faire au mieux, donc lui permet d'effectivement faire mieux.
Parce que tu ne veux voir qu'un côté des choses, celui qui t'arrange : fournir de l'espace d'échange (qui fait d'ailleurs en partie double emploi avec le cache hardware du disque) signifie diminuer l'espace alloué aux données des applications. Et comme aucune information, n'est disponible, tu vois les système à mémoire virtuelle se traîner en échanges disques qui n'auraient parfois pas été nécessaires si on avait bien dégagé la RAM pour l'application (le tout étant pour elle de le faire savoir d'une manière ou d'une autre au système, ce qui n'est pas de la tarte).
Et en pratique, même si les heuristiques qui sont effectivement implémentées ne sont pas parfaites, elles sont infiniment meilleures que « je mets pas de swap parce que c'est vraiment trop lent quand ça swappe ».
Je ne vois pas comment on pourrait avoir moins de temps perdu en attente de page que 0. Peut-être fais-tu allusion à des ordinateurs en temps complexe, qui à la différence des ordinateurs en temps réels finiraient leurs travaux avant de les avoir commencés ? :-D
Même pour un résultat intermédiaire de compilation que l'on voudrait garder en mémoire, la mémoire virtuelle se comporte de façon catastrophique, effectuant des swapouts alors qu'on ne lui a rien demandé. Sur mon vieux Pentium 100, j'allais déjà plus vite en faisant cracher ce fichier intermédiaire sur un disque virtuel, malgré l'overhead.
De toute évidence, tu n'as rien compris au fonctionnement de la mémoire
virtuelle d'un système d'exploitation moderne.
La bonne gestion de la mémoire serait celle qui est adaptée d'une part
aux structures de données que l'on alloue (ainsi que rappelé plus haut,
créer une pile de taille virtuellement infinie ne pose aucun problème ni
délai de fonctionnement si l'on a des mécanismes d'anticipation
appropriés, et si chaque allocation s'accompagnait d'un profil
prévisible d'utilisation pour informer le système. Au lie de cela, nous
continons à travailler sur un schéma qui n'a en rien évolué depuis les
années 70 : rendre *invisible* au programme la présence ou l'absence
d'une page en RAM - ce qui garantit d'empêcher toute tentative
d'optimisation, puisqu'on a les yeux bandés.
Le système choisit
dynamiquement ce qu'il va mettre en mémoire, en fonction d'heuristiques pour
optimiser les performances.
Heuristiques signifie bricolages. Un bricolage n'optimise jamais. AU
mieux, il pallie contre des déficiences, nuance.
On ne _choisit_ pas d'affecter 10% aux applications et 90% au cache disque
ou le contraire, c'est l'OS qui le détermine en fonction de l'utilisation de
la machine à chaque instant.
Le problème est que l'OS ne dispose d'aucune information pour cela. Ce
qui fait que l'algorithme d'éviction des pages reste calqué sur celui de
l'élimination de collaborateurs en cas de plan social. Dans l'ordre
d'élimination :
Si on part d'une situation avec 90% de cache
disque et qu'on lance soudainement une application gourmande, le cache
disque sera automatiquement réaffecté à cette application (ce qui ne coûte
rien en temps).
C'est cela, oui. Flusher le contenu de tout le cache sur disque (s'il y
a write-back) et à des emplacements tous différents les uns des autres,
c'est sûr que ça ne va rien coûter en temps !
Dans ces conditions, fournir de l'espace d'échange à l'OS augmente la
latitude qu'il a pour faire au mieux, donc lui permet d'effectivement faire
mieux.
Parce que tu ne veux voir qu'un côté des choses, celui qui t'arrange :
fournir de l'espace d'échange (qui fait d'ailleurs en partie double
emploi avec le cache hardware du disque) signifie diminuer l'espace
alloué aux données des applications. Et comme aucune information, n'est
disponible, tu vois les système à mémoire virtuelle se traîner en
échanges disques qui n'auraient parfois pas été nécessaires si on avait
bien dégagé la RAM pour l'application (le tout étant pour elle de le
faire savoir d'une manière ou d'une autre au système, ce qui n'est pas
de la tarte).
Et en pratique, même si les heuristiques qui sont effectivement implémentées
ne sont pas parfaites, elles sont infiniment meilleures que « je mets pas de
swap parce que c'est vraiment trop lent quand ça swappe ».
Je ne vois pas comment on pourrait avoir moins de temps perdu en attente
de page que 0. Peut-être fais-tu allusion à des ordinateurs en temps
complexe, qui à la différence des ordinateurs en temps réels finiraient
leurs travaux avant de les avoir commencés ? :-D
Même pour un résultat intermédiaire de compilation que l'on voudrait
garder en mémoire, la mémoire virtuelle se comporte de façon
catastrophique, effectuant des swapouts alors qu'on ne lui a rien
demandé. Sur mon vieux Pentium 100, j'allais déjà plus vite en faisant
cracher ce fichier intermédiaire sur un disque virtuel, malgré l'overhead.
De toute évidence, tu n'as rien compris au fonctionnement de la mémoire virtuelle d'un système d'exploitation moderne.
La bonne gestion de la mémoire serait celle qui est adaptée d'une part aux structures de données que l'on alloue (ainsi que rappelé plus haut, créer une pile de taille virtuellement infinie ne pose aucun problème ni délai de fonctionnement si l'on a des mécanismes d'anticipation appropriés, et si chaque allocation s'accompagnait d'un profil prévisible d'utilisation pour informer le système. Au lie de cela, nous continons à travailler sur un schéma qui n'a en rien évolué depuis les années 70 : rendre *invisible* au programme la présence ou l'absence d'une page en RAM - ce qui garantit d'empêcher toute tentative d'optimisation, puisqu'on a les yeux bandés.
Le système choisit dynamiquement ce qu'il va mettre en mémoire, en fonction d'heuristiques pour optimiser les performances.
Heuristiques signifie bricolages. Un bricolage n'optimise jamais. AU mieux, il pallie contre des déficiences, nuance.
On ne _choisit_ pas d'affecter 10% aux applications et 90% au cache disque ou le contraire, c'est l'OS qui le détermine en fonction de l'utilisation de la machine à chaque instant.
Le problème est que l'OS ne dispose d'aucune information pour cela. Ce qui fait que l'algorithme d'éviction des pages reste calqué sur celui de l'élimination de collaborateurs en cas de plan social. Dans l'ordre d'élimination :
Si on part d'une situation avec 90% de cache disque et qu'on lance soudainement une application gourmande, le cache disque sera automatiquement réaffecté à cette application (ce qui ne coûte rien en temps).
C'est cela, oui. Flusher le contenu de tout le cache sur disque (s'il y a write-back) et à des emplacements tous différents les uns des autres, c'est sûr que ça ne va rien coûter en temps !
Dans ces conditions, fournir de l'espace d'échange à l'OS augmente la latitude qu'il a pour faire au mieux, donc lui permet d'effectivement faire mieux.
Parce que tu ne veux voir qu'un côté des choses, celui qui t'arrange : fournir de l'espace d'échange (qui fait d'ailleurs en partie double emploi avec le cache hardware du disque) signifie diminuer l'espace alloué aux données des applications. Et comme aucune information, n'est disponible, tu vois les système à mémoire virtuelle se traîner en échanges disques qui n'auraient parfois pas été nécessaires si on avait bien dégagé la RAM pour l'application (le tout étant pour elle de le faire savoir d'une manière ou d'une autre au système, ce qui n'est pas de la tarte).
Et en pratique, même si les heuristiques qui sont effectivement implémentées ne sont pas parfaites, elles sont infiniment meilleures que « je mets pas de swap parce que c'est vraiment trop lent quand ça swappe ».
Je ne vois pas comment on pourrait avoir moins de temps perdu en attente de page que 0. Peut-être fais-tu allusion à des ordinateurs en temps complexe, qui à la différence des ordinateurs en temps réels finiraient leurs travaux avant de les avoir commencés ? :-D
Même pour un résultat intermédiaire de compilation que l'on voudrait garder en mémoire, la mémoire virtuelle se comporte de façon catastrophique, effectuant des swapouts alors qu'on ne lui a rien demandé. Sur mon vieux Pentium 100, j'allais déjà plus vite en faisant cracher ce fichier intermédiaire sur un disque virtuel, malgré l'overhead.
FDA
FDA wrote in message <43be7362$0$19982$:
Et que je n'ai pas à connaître.
C'est ton droit. Mais puisque tu ne maîtrises pas la question, il serait plus raisonnable que tu évites d'émettre des avis aussi péremptoires, surtout quand ils sont faux.
Je sais utiliser une montre, et j'ai mesuré mes performances *avec* et *sans* mémoire virtuelle avant de me décider. Essaie avant de prétendre critiquer.
Au-delà, c'est de l'overkill. La lecture anticipée, oui, mais les paramètres de hdparm sont là pour ça.
Les paramètres hdparm parlent de la lecture physique sur le support, pas de la prévision de lecture au niveau du filesystem.
La lecture étant séquentielle dans le cas dont je parle, et l'écriture des résultats aussi (il n'y a que le traitement qui demande des accès à la fois directs et très rapides, *sans la moindre* participation du disque justement parce qu'ils sont directs et imprévisibles), une lecture physique piste par piste me convient assez bien en général. De toute façon les temps d'entrée sont eux-mêmes faibles devant les temps de traitement. En sortie, c'est visible. En entrée, c'est simplement une conjecture plausible, puisque je traite en même temps que je lis.
En revanche, un million d'appels disques, fussent-ils à 9ms, introduiraient des délais insupportable pour ce type de traitement, sauf à réécrire totalement le programme; qu'on ne dis pas alors que la mémoire virtuelle simplifie le travail du programmeur.
FDA wrote in message
<43be7362$0$19982$79c14f64@nan-newsreader-07.noos.net>:
Et que je n'ai pas à connaître.
C'est ton droit. Mais puisque tu ne maîtrises pas la question, il serait
plus raisonnable que tu évites d'émettre des avis aussi péremptoires,
surtout quand ils sont faux.
Je sais utiliser une montre, et j'ai mesuré mes performances *avec* et
*sans* mémoire virtuelle avant de me décider. Essaie avant de prétendre
critiquer.
Au-delà, c'est de l'overkill. La lecture anticipée, oui, mais
les paramètres de hdparm sont là pour ça.
Les paramètres hdparm parlent de la lecture physique sur le support, pas de
la prévision de lecture au niveau du filesystem.
La lecture étant séquentielle dans le cas dont je parle, et l'écriture
des résultats aussi (il n'y a que le traitement qui demande des accès à
la fois directs et très rapides, *sans la moindre* participation du
disque justement parce qu'ils sont directs et imprévisibles), une
lecture physique piste par piste me convient assez bien en général. De
toute façon les temps d'entrée sont eux-mêmes faibles devant les temps
de traitement. En sortie, c'est visible. En entrée, c'est simplement une
conjecture plausible, puisque je traite en même temps que je lis.
En revanche, un million d'appels disques, fussent-ils à 9ms,
introduiraient des délais insupportable pour ce type de traitement, sauf
à réécrire totalement le programme; qu'on ne dis pas alors que la
mémoire virtuelle simplifie le travail du programmeur.
C'est ton droit. Mais puisque tu ne maîtrises pas la question, il serait plus raisonnable que tu évites d'émettre des avis aussi péremptoires, surtout quand ils sont faux.
Je sais utiliser une montre, et j'ai mesuré mes performances *avec* et *sans* mémoire virtuelle avant de me décider. Essaie avant de prétendre critiquer.
Au-delà, c'est de l'overkill. La lecture anticipée, oui, mais les paramètres de hdparm sont là pour ça.
Les paramètres hdparm parlent de la lecture physique sur le support, pas de la prévision de lecture au niveau du filesystem.
La lecture étant séquentielle dans le cas dont je parle, et l'écriture des résultats aussi (il n'y a que le traitement qui demande des accès à la fois directs et très rapides, *sans la moindre* participation du disque justement parce qu'ils sont directs et imprévisibles), une lecture physique piste par piste me convient assez bien en général. De toute façon les temps d'entrée sont eux-mêmes faibles devant les temps de traitement. En sortie, c'est visible. En entrée, c'est simplement une conjecture plausible, puisque je traite en même temps que je lis.
En revanche, un million d'appels disques, fussent-ils à 9ms, introduiraient des délais insupportable pour ce type de traitement, sauf à réécrire totalement le programme; qu'on ne dis pas alors que la mémoire virtuelle simplifie le travail du programmeur.
FDA
Cette affirmation est contraire à tout ce que l'on peut constater au niveau des performances globales d'un système typique en utilisation courante.
Flot d'épithètes n'a jamais valu démonstration. Et elle est en tout cas conforme à ce que j'ai constaté, moi, sur mes programmes. Je ne vois d'ailleurs pas ce que peut être un "système typique" dans le monde du PC, les profils d'utilisation de chacun étant aussi différents que faire se peut. Je sais simplement qu'on ne peut pas faire moins d'appels disque que 0, ce n'est pourtant pas difficile à comprendre, si ?
Cette affirmation est contraire à tout ce que l'on peut constater au niveau
des performances globales d'un système typique en utilisation courante.
Flot d'épithètes n'a jamais valu démonstration. Et elle est en tout cas
conforme à ce que j'ai constaté, moi, sur mes programmes. Je ne vois
d'ailleurs pas ce que peut être un "système typique" dans le monde du
PC, les profils d'utilisation de chacun étant aussi différents que faire
se peut. Je sais simplement qu'on ne peut pas faire moins d'appels
disque que 0, ce n'est pourtant pas difficile à comprendre, si ?
Cette affirmation est contraire à tout ce que l'on peut constater au niveau des performances globales d'un système typique en utilisation courante.
Flot d'épithètes n'a jamais valu démonstration. Et elle est en tout cas conforme à ce que j'ai constaté, moi, sur mes programmes. Je ne vois d'ailleurs pas ce que peut être un "système typique" dans le monde du PC, les profils d'utilisation de chacun étant aussi différents que faire se peut. Je sais simplement qu'on ne peut pas faire moins d'appels disque que 0, ce n'est pourtant pas difficile à comprendre, si ?
Paul Gaborit
À (at) Fri, 6 Jan 2006 13:26:48 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
De toute évidence, tu n'as rien compris au fonctionnement de la mémoire virtuelle d'un système d'exploitation moderne.
Effectivement, il me semble bien que cette conclusion s'impose et, pour ma part, cela clôt cette discussion...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 6 Jan 2006 13:26:48 +0000 (UTC),
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
De toute évidence, tu n'as rien compris au fonctionnement de la mémoire
virtuelle d'un système d'exploitation moderne.
Effectivement, il me semble bien que cette conclusion s'impose et,
pour ma part, cela clôt cette discussion...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 6 Jan 2006 13:26:48 +0000 (UTC), Nicolas George <nicolas$ écrivait (wrote):
De toute évidence, tu n'as rien compris au fonctionnement de la mémoire virtuelle d'un système d'exploitation moderne.
Effectivement, il me semble bien que cette conclusion s'impose et, pour ma part, cela clôt cette discussion...
"Mémoire virtuelle d'un système d'exploitation moderne" est aujourd'hui un oxymore.
Nicolas George
FDA wrote in message <43be7963$0$13371$:
ce qui garantit d'empêcher toute tentative d'optimisation, puisqu'on a les yeux bandés.
Non, c'est faux. On connaît les comportements qui sont les plus efficaces en cas de nécessité de swap, il suffit de les appliquer. Ce qu'apporte la mémoire virtuelle, c'est qu'il n'y a pas _besoin_ de s'en occuper : on peut optimiser très finement, mais ça fonctionnera quand même si on ne le fait pas. Et presque toujours plus efficacement qu'en faisant la même chose à la main au plus simple.
Heuristiques signifie bricolages. Un bricolage n'optimise jamais.
Pétition de principe qui n'apporte rien au débat.
Le problème est que l'OS ne dispose d'aucune information pour cela.
Au contraire, dans un environnement multitâche, l'OS a plus d'information que chaque application prise séparément.
C'est cela, oui. Flusher le contenu de tout le cache sur disque (s'il y a write-back) et à des emplacements tous différents les uns des autres, c'est sûr que ça ne va rien coûter en temps !
Je parle du cache, pas des tampons d'écriture. C'est l'utilisation principale de la mémoire sur une machine actuelle correctement dotée avec un OS décent.
Je ne vois pas comment on pourrait avoir moins de temps perdu en attente de page que 0.
Parce que ce n'est pas 0. C'est attendre une page, ou en attendre une autre. La présence de swap laisse plus de marge au système pour déterminer quelles pages utiles conserver en mémoire.
Sur mon vieux Pentium 100, j'allais déjà plus vite en faisant cracher ce fichier intermédiaire sur un disque virtuel, malgré l'overhead.
Je mets en doute cette affirmation, qui ne correspond ni à la théorie ni à la pratique. Ou alors la VM de ton OS à l'époque n'était pas très au point (ce qui est tout à fait plausible avec certaines versions des Unix libres ; quant aux trucs proprios, je n'en sais rien).
FDA wrote in message
<43be7963$0$13371$79c14f64@nan-newsreader-06.noos.net>:
ce qui garantit d'empêcher toute tentative
d'optimisation, puisqu'on a les yeux bandés.
Non, c'est faux. On connaît les comportements qui sont les plus efficaces en
cas de nécessité de swap, il suffit de les appliquer. Ce qu'apporte la
mémoire virtuelle, c'est qu'il n'y a pas _besoin_ de s'en occuper : on peut
optimiser très finement, mais ça fonctionnera quand même si on ne le fait
pas. Et presque toujours plus efficacement qu'en faisant la même chose à la
main au plus simple.
Heuristiques signifie bricolages. Un bricolage n'optimise jamais.
Pétition de principe qui n'apporte rien au débat.
Le problème est que l'OS ne dispose d'aucune information pour cela.
Au contraire, dans un environnement multitâche, l'OS a plus d'information
que chaque application prise séparément.
C'est cela, oui. Flusher le contenu de tout le cache sur disque (s'il y
a write-back) et à des emplacements tous différents les uns des autres,
c'est sûr que ça ne va rien coûter en temps !
Je parle du cache, pas des tampons d'écriture. C'est l'utilisation
principale de la mémoire sur une machine actuelle correctement dotée avec un
OS décent.
Je ne vois pas comment on pourrait avoir moins de temps perdu en attente
de page que 0.
Parce que ce n'est pas 0. C'est attendre une page, ou en attendre une autre.
La présence de swap laisse plus de marge au système pour déterminer quelles
pages utiles conserver en mémoire.
Sur mon vieux Pentium 100, j'allais déjà plus vite en faisant
cracher ce fichier intermédiaire sur un disque virtuel, malgré l'overhead.
Je mets en doute cette affirmation, qui ne correspond ni à la théorie ni à
la pratique. Ou alors la VM de ton OS à l'époque n'était pas très au point
(ce qui est tout à fait plausible avec certaines versions des Unix libres ;
quant aux trucs proprios, je n'en sais rien).
ce qui garantit d'empêcher toute tentative d'optimisation, puisqu'on a les yeux bandés.
Non, c'est faux. On connaît les comportements qui sont les plus efficaces en cas de nécessité de swap, il suffit de les appliquer. Ce qu'apporte la mémoire virtuelle, c'est qu'il n'y a pas _besoin_ de s'en occuper : on peut optimiser très finement, mais ça fonctionnera quand même si on ne le fait pas. Et presque toujours plus efficacement qu'en faisant la même chose à la main au plus simple.
Heuristiques signifie bricolages. Un bricolage n'optimise jamais.
Pétition de principe qui n'apporte rien au débat.
Le problème est que l'OS ne dispose d'aucune information pour cela.
Au contraire, dans un environnement multitâche, l'OS a plus d'information que chaque application prise séparément.
C'est cela, oui. Flusher le contenu de tout le cache sur disque (s'il y a write-back) et à des emplacements tous différents les uns des autres, c'est sûr que ça ne va rien coûter en temps !
Je parle du cache, pas des tampons d'écriture. C'est l'utilisation principale de la mémoire sur une machine actuelle correctement dotée avec un OS décent.
Je ne vois pas comment on pourrait avoir moins de temps perdu en attente de page que 0.
Parce que ce n'est pas 0. C'est attendre une page, ou en attendre une autre. La présence de swap laisse plus de marge au système pour déterminer quelles pages utiles conserver en mémoire.
Sur mon vieux Pentium 100, j'allais déjà plus vite en faisant cracher ce fichier intermédiaire sur un disque virtuel, malgré l'overhead.
Je mets en doute cette affirmation, qui ne correspond ni à la théorie ni à la pratique. Ou alors la VM de ton OS à l'époque n'était pas très au point (ce qui est tout à fait plausible avec certaines versions des Unix libres ; quant aux trucs proprios, je n'en sais rien).
Nicolas George
FDA wrote in message <43be7b1e$0$19976$:
Flot d'épithètes n'a jamais valu démonstration.
Ce n'est pas une démonstration, c'est une constatation expérimentale.
Je sais simplement qu'on ne peut pas faire moins d'appels disque que 0, ce n'est pourtant pas difficile à comprendre, si ?
Ce que tu ne comprends pas, c'est que ce 0 ne mesure que la pertinence de cette affirmation.
FDA wrote in message
<43be7b1e$0$19976$79c14f64@nan-newsreader-07.noos.net>:
Flot d'épithètes n'a jamais valu démonstration.
Ce n'est pas une démonstration, c'est une constatation expérimentale.
Je sais simplement qu'on ne peut pas faire moins d'appels
disque que 0, ce n'est pourtant pas difficile à comprendre, si ?
Ce que tu ne comprends pas, c'est que ce 0 ne mesure que la pertinence de
cette affirmation.
Ce n'est pas une démonstration, c'est une constatation expérimentale.
Je sais simplement qu'on ne peut pas faire moins d'appels disque que 0, ce n'est pourtant pas difficile à comprendre, si ?
Ce que tu ne comprends pas, c'est que ce 0 ne mesure que la pertinence de cette affirmation.
Nicolas George
FDA wrote in message <43be7a78$0$19976$:
Je sais utiliser une montre, et j'ai mesuré mes performances *avec* et *sans* mémoire virtuelle avant de me décider. Essaie avant de prétendre critiquer.
Je parlais de la réactivité générale de la machine : ça ne se mesure pas avec une montre.
Quoi qu'il en soit, j'aimerais bien que tu décrives précisément les conditions dans lesquelles tu as fait tes mesures.
La lecture étant séquentielle dans le cas dont je parle
On ne t'a jamais expliqué que les fichiers étaient rarement d'un seul tenant sur un disque dur ?
FDA wrote in message
<43be7a78$0$19976$79c14f64@nan-newsreader-07.noos.net>:
Je sais utiliser une montre, et j'ai mesuré mes performances *avec* et
*sans* mémoire virtuelle avant de me décider. Essaie avant de prétendre
critiquer.
Je parlais de la réactivité générale de la machine : ça ne se mesure pas
avec une montre.
Quoi qu'il en soit, j'aimerais bien que tu décrives précisément les
conditions dans lesquelles tu as fait tes mesures.
La lecture étant séquentielle dans le cas dont je parle
On ne t'a jamais expliqué que les fichiers étaient rarement d'un seul tenant
sur un disque dur ?
Je sais utiliser une montre, et j'ai mesuré mes performances *avec* et *sans* mémoire virtuelle avant de me décider. Essaie avant de prétendre critiquer.
Je parlais de la réactivité générale de la machine : ça ne se mesure pas avec une montre.
Quoi qu'il en soit, j'aimerais bien que tu décrives précisément les conditions dans lesquelles tu as fait tes mesures.
La lecture étant séquentielle dans le cas dont je parle
On ne t'a jamais expliqué que les fichiers étaient rarement d'un seul tenant sur un disque dur ?
