Détruire un objet avant la fin du script ?

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.

Tu peux t'amuser à faire la simulation suivante : 100 000 pages de 4K se
référençant l'une l'autre de façon parfaitement aléatoire, avec des
chaînages faisant cavaler sur sept ou huit pages en quelques centaines
de cycles. Si tu as tout en mémoire, tu as gagné. Si tu as 80% seulement
de la place en mémoire, tu es mort.

Autre exemple : calcul des nombres premiers de 1 à 4 milliards par la
méthode du crible d'Eratosthène. Tout en mémoire, ça va. 40% en mémoire,
ça rame.

Il est évidemment des programmes mieux configurés, avec des working-sets
plus compacts et ou on peut atteindre un rapport virtuel/réel de 5 à 1
sans perdre plus de 50% des performances. C'était le cas de
l'interpréteur APL du Bull Sems T1600.

Heuristiques signifie bricolages. Un bricolage n'optimise jamais.

Pétition de principe qui n'apporte rien au débat.

Heuristique = non démontré, sans quoi ce n'est plus une heuristique
Non démontré = résultat non garanti, sinon ce serait démontré
Résultat non garanti = bricolage, je persiste et signe.

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 parle du cache aussi. Toute page modifiée doit être réécrite si elle
ne l'a pas été.

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.

Quand on les conserve toutes, la question ne se pose même pas. Au prix
où est la RAM, et à la lenteur des disques durs qui est ce qu'elle est,
la mémoire virtuelle est devenue un anachronisme total - comme il était
anachronique en 1990 de définir son propre système de fichiers pour une
application, ou de faire son propre système de fenêtrage : on ne le fait
que parce qu'on a pris l'habitude de le faire sans se poser de
questions. Un peu comme avant Turbo Pascal les compilateurs PC passaient
par des fichiers intermédiaires sur disque. Par habitude anachronique.

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.

Hmmm... Et si je le sortais de son placard pour le remettre dans sa
configuration DOS, et te livrant le résultat des chronométrages ? Je
peux te garantir que vu le nombre de compilations que je faisais par
heure, je n'avais pas le droit de perdre du temps en écritures et
lectures disque inutiles :

- fichiers .h sur le RAMdisk. Tous. C'était copié au boot.
- fichier .EXE généré sur le RAMdisk aussi : aucune écriture réelle
- fichier source sur le disque tout de même par sécurité

Cycle compilation/exécution semblable à ce que tu as aujourd'hui en
utilisant SciTE et Perl (à ceci près que j'étais en Turbo C)

J'ajoute que mes disques durs de l'époque n'avaient pas de cache
hardware. J'utilisais en revanche IBMCACHE en mode write-back (Turbo C
effectuait des .bak systématiques de toute façon, par renommage).

Le tout était sous DOS, parce que le Windows de l'époque (2.0 ?) ne
branchait pas plus que ça.

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.

Dans mon cas, le temps qui s'écoulaite entre la compilation de mon
source et le moment où je pouvais examiner les résultats à l'écran.

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 ?

J'utilisais DVOO, le réorganisateur de disque de l'époque, parce que je
l'avais gratuit. Il me semble qu'il y en avait un autre dans les Norton
Utilities, mais je ne les avais pas.

De toute façon, avec le BIOS de l'époque, on ne pouvait pas me
semble-t-il lire plus de 17 secteurs consécutifs.

FDA wrote in message
<43beace3$0$20229$79c14f64@nan-newsreader-07.noos.net>:

Tu peux t'amuser à faire la simulation suivante : 100 000 pages de 4K se
référençant l'une l'autre de façon parfaitement aléatoire, avec des
chaînages faisant cavaler sur sept ou huit pages en quelques centaines
de cycles. Si tu as tout en mémoire, tu as gagné. Si tu as 80% seulement
de la place en mémoire, tu es mort.

Et ça prouve quoi ? Qu'il vaut mieux avoir tout en mémoire que pas... Beau
truisme ! Ça ne prouve absolument pas la nocivité de la mémoire virtuelle.

La mémoire virtuelle, ça sert plutôt à ce scénario (chiffres au pif) :

512 Mo de RAM, 60 Mo bouffés par l'environnement et différentes conneries,
60 Mo bouffés par un browser web avec plein de tabs ouverts sur la doc qui
permet de mettre au point le programme. On lance le programme, il a besoin
de 400 Mo de RAM.

- Cas 1, sans mémoire virtuelle : il y a 392 Mo libres, le programme ne se
lance pas, ou pire, se lance et échoue faute de mémoire au bout de deux
heures de calculs, à cinq minutes de la fin.

- Cas 2, avec mémoire virtuelle : ça râme pendant une minute le temps que
8 Mo du browser web partent dans le swap, le programme tourne ses deux
heures et fournit son résultat, ça râme pendant une minute quand on veut à
nouveau se servir du browser web.

De toutes façons, ta position est intenable : pour une quantité de mémoire
donnée, soit le programme tient en mémoire, et la mémoire virtuelle n'y
change rien ; soit ça ne tient pas en mémoire, et la mémoire virtuelle
permet d'avoir un résultat au lieu de rien, et même si le surcoût en temps
est prohibitif ce n'est pas pire que sans. Et dans les cas limites, la
mémoire virtuelle permet de dégager plus de mémoire pour le programme.

Résultat non garanti = bricolage, je persiste et signe.

Et c'est bien une pétition de principe qui n'apporte rien.

Je parle du cache aussi. Toute page modifiée doit être réécrite si elle
ne l'a pas été.

Tu confonds cache et tampon. Le cache est constitué de pages du disque qui
ont été lues à un moment, et sont gardées en mémoire au cas où elles
resserviraient, tant que la mémoire n'est pas requise pour quelque chose de
plus important. Rendre une page de cache disponible pour autre chose a un
coût nul.

Quand on les conserve toutes, la question ne se pose même pas. Au prix
où est la RAM, et à la lenteur des disques durs qui est ce qu'elle est,

Cet argument n'est doublement pas valide :

D'une part, augmenter la RAM pour une tâche donnée est possible pour une
machine dédiée à cette tâche, comme un serveur ou une machine de calcul
scientifique. Ce n'est pas le cas sur une machine personnelle, où la
quantité de RAM est fixée par l'exigence que la machine tourne bien au jour
le jour et ait un prix raisonnable.

D'autre part, et surtout, ce n'est pas un argument contre la mémoire
virtuelle : si la question posée était « ajouter de la mémoire ou utiliser
de la mémoire virtuelle », je répondrais immédiatement : les deux. Le fait
est que *pour une quantité de mémoire donnée*, l'utilisation de mémoire
virtuelle en plus améliore les performances dans presque tous les cas.

la mémoire virtuelle est devenue un anachronisme total

Le répéter ne le rendra pas plus vrai, et ce ne sont pas tes comparaisons
fumeuses qui constituent un argument valide.

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.

Hmmm... Et si je le sortais de son placard pour le remettre dans sa
configuration DOS, et te livrant le résultat des chronométrages ?

Tout ce que tu prouverais, c'est que DOS est une bouze, ce qu'on savait
déjà.

Le tout était sous DOS, parce que le Windows de l'époque (2.0 ?) ne
branchait pas plus que ça.

Windows 2.0 à l'époque des pentium 100 ? Et tu espères qu'on te prenne au
sérieux ? Tu es pathétique.

FDA wrote in message
<43bead9b$0$20229$79c14f64@nan-newsreader-07.noos.net>:

Dans mon cas, le temps qui s'écoulaite entre la compilation de mon
source et le moment où je pouvais examiner les résultats à l'écran.

Et tu comparais quelles situations précisément ?

J'utilisais DVOO, le réorganisateur de disque de l'époque, parce que je
l'avais gratuit. Il me semble qu'il y en avait un autre dans les Norton
Utilities, mais je ne les avais pas.

De toute façon, avec le BIOS de l'époque, on ne pouvait pas me
semble-t-il lire plus de 17 secteurs consécutifs.

Tout ça m'a l'air antédiluvien. Tu ferais peut-être mieux de te renseigner
sur ce qui se fait depuis une dizaine d'années avant d'aligner ânerie sur
ânerie.

Dans mon cas, le temps qui s'écoulaite entre la compilation de mon
source et le moment où je pouvais examiner les résultats à l'écran.

Et tu comparais quelles situations précisément ?

* RAMdisk de la taille adéquate pour tout contenir + cache de petite
taille d'une part

* L'espace précédent tout consacré au cache d'autre part.

J'utilisais DVOO, le réorganisateur de disque de l'époque, parce que je
l'avais gratuit. Il me semble qu'il y en avait un autre dans les Norton
Utilities, mais je ne les avais pas.

De toute façon, avec le BIOS de l'époque, on ne pouvait pas me
semble-t-il lire plus de 17 secteurs consécutifs.

Tout ça m'a l'air antédiluvien.

On mentionne mes optimisations avec le Turbo C en DOS (seul cas où j'ai
opposé le RAMdisk au cache), je parle de mes optimisations avec le Turbo
C en DOS. En ce qui concerne Windows, un simple coup d'oeil sur la
loupiote de ton disque dur te confirmera qu'il balance des pages sur
disque quand il a une mémoire virtuelle, que ce soit utile ou non, et
rien quand tu inhibes la mémoire virtuelle.

Tu ferais peut-être mieux de te renseigner
sur ce qui se fait depuis une dizaine d'années avant d'aligner ânerie sur
ânerie.

Je crois pour ma part que tu ferais mieux d'expérimenter sur ta machine
au lieu de te fier à un bréviaire qui fut conforme au réel à une époque
et ne l'est plus aujourd'hui.

Et ça prouve quoi ? Qu'il vaut mieux avoir tout en mémoire que pas... Beau
truisme ! Ça ne prouve absolument pas la nocivité de la mémoire virtuelle.

Cela prouve qu'il vaut mieux avoir tout en mémoire *et l'y laisser* que
de le balancer sur disque systématiquement juste au cas où, lorsque tu
sais qu'il n'y en aura aucun besoin.

- Cas 2, avec mémoire virtuelle : ça râme pendant une minute le temps que
8 Mo du browser web partent dans le swap, le programme tourne ses deux
heures et fournit son résultat, ça râme pendant une minute quand on veut à
nouveau se servir du browser web.

Ce qui est bien dommage, car lancer le browser web à partir de zéro est
loin de prendre une minute. Pourquoi ? Parce qu'il se trouve en un seul
morceau si on l'a installé correctement (c'est à dire après une
défragmentation disque). Avec la mémoire virtuelle, cette contiguité
n'est pas assurée et peut demander plusieurs accès disque un peu
partout. Le pagefile.sys lui-même, en Windows, peut être éparmillé en
cinq ou six morceaux. De ce côté-là, Linux est un peu moins mal foutu.

De toutes façons, ta position est intenable : pour une quantité de mémoire
donnée, soit le programme tient en mémoire, et la mémoire virtuelle n'y
change rien ;

Détrompe-toi : Je ne sais pas ce qu'ils ont été faire à Redmond, mais
des échanges disques se font même quand tout ton programme tient en
mémoire (et je ne parle seulement de ses lectures et écritures
intempestives dans le Registry alors qu'on ne lui demande rien).

Là encore, il y a ce qu'on te raconte dans les livres et ce qui se passe
sur le PC. Je considère qu'en cas de conflit, c'est le PC qui a raison.

soit ça ne tient pas en mémoire, et la mémoire virtuelle
permet d'avoir un résultat au lieu de rien

Ne sois pas ridicule : un résultat 60 fois plus lent, *c'est la même
chose* que rien. Ton temps, fût-il personnel, coûte au moins les 10
euros de l'heure que tu donnes à ton employée de maison pour faire ce
que tu n'as plus le temps de faire toi-même. De plus, en 40 minutes, tu
restes concentré sur ton problème. en 40 heures, non.

Résultat non garanti = bricolage, je persiste et signe.

Et c'est bien une pétition de principe qui n'apporte rien.

Tu n'appellerais pas un avion qui décolle sans avoir une chance
raisonnable d'arriver à destination dans les délais un bricolage ? Moi, si.

Je parle du cache aussi. Toute page modifiée doit être réécrite si elle
ne l'a pas été.

Tu confonds cache et tampon.

Tout ce qu'on flushe doit être réécrit avant que la mémoire soit
libérée. Désolé si j'ai pris l'habitude, mauvaise sans doute, de
considérer la mémoire en blocs de 4K.

Le cache est constitué de pages du disque qui
ont été lues à un moment, et sont gardées en mémoire au cas où elles
resserviraient

Eh non, mon garçon. le cache sert également en écriture au cas où les
pages juste écrites seraient relues. C'est ce qu'on nomme l'algorithme
de la seconde chance.

D'une part, augmenter la RAM pour une tâche donnée est possible pour une
machine dédiée à cette tâche, comme un serveur ou une machine de calcul
scientifique. Ce n'est pas le cas sur une machine personnelle, où la
quantité de RAM est fixée par l'exigence que la machine tourne bien au jour
le jour et ait un prix raisonnable.

Une heure d'ingénieur coûte le prix d'1 Go de RAM. Cela te suffit-il
comme réponse ?

D'autre part, et surtout, ce n'est pas un argument contre la mémoire
virtuelle : si la question posée était « ajouter de la mémoire ou utiliser
de la mémoire virtuelle », je répondrais immédiatement : les deux. Le fait
est que *pour une quantité de mémoire donnée*, l'utilisation de mémoire
virtuelle en plus améliore les performances dans presque tous les cas.

C'est du délire pur et simple. Si tu as la place d'xécuter tes
applications en mémoire, ajouter de la mémoire virtuelle n'augmentera
*rien* . Mais en revanche te ralentira par des appels disque
intempestifs en cours quand tu auras besoin de faire des appels disque
qui servent à quelque chose.

la mémoire virtuelle est devenue un anachronisme total

Le répéter ne le rendra pas plus vrai, et ce ne sont pas tes comparaisons
fumeuses qui constituent un argument valide.

Ecoute, tu l'utilises si tu veux. Pour ma part c'est terminé. Et
restons-en là. Rendez-vous dans quatre ans.

Le tout était sous DOS, parce que le Windows de l'époque (2.0 ?) ne
branchait pas plus que ça.

Windows 2.0 à l'époque des pentium 100 ?

Tu es encore en train de tout mélanger ! Turbo C, ça ne tournait pas
sous Windows. C'est Windows que j'utilisais sur un Pentium 100, et DOS
sur le 386 qui tournait en Turbo C. Pour mémoire, avec deux cartes
Addiciel, on avait fait un serveur minitel 40 voies avec ce truc.
Entièrement en Turbo C. Et avec ma configuration RAMdisk + minicache
pour tout ce qui était compilation. C'était en 1987, si mes souvenirs
sont bons.

FDA wrote in message
<43bec477$0$20486$79c14f64@nan-newsreader-07.noos.net>:

* RAMdisk de la taille adéquate pour tout contenir + cache de petite
taille d'une part

* L'espace précédent tout consacré au cache d'autre part.

Et c'est censé prouver quoi quant à la pertinence d'avoir de la mémoire
virtuelle ? Ça n'a absolument rien à voir avec la choucroute.

On mentionne mes optimisations avec le Turbo C en DOS

Non, à part dans tes rêves.

En ce qui concerne Windows, un simple coup d'oeil sur la
loupiote de ton disque dur

Je ne vois pas ce que windows pourrait faire à la loupiote de mon disque
dur, sachant qu'il n'y en a pas d'exemplaire dans un rayon de plusieurs
dizaines de mètres.

te confirmera qu'il balance des pages sur
disque quand il a une mémoire virtuelle, que ce soit utile ou non, et
rien quand tu inhibes la mémoire virtuelle.

Les vieilles versions de windows ont notoirement une VM merdique. Ça ne
prouve rien.

Je crois pour ma part que tu ferais mieux d'expérimenter sur ta machine
au lieu de te fier à un bréviaire qui fut conforme au réel à une époque
et ne l'est plus aujourd'hui.

... dit celui qui prouve à longueur de message qu'il ne maîtrise ni la
théorie ni la pratique.

FDA wrote in message
<43beca05$0$19657$79c14f64@nan-newsreader-05.noos.net>:

Cela prouve qu'il vaut mieux avoir tout en mémoire *et l'y laisser* que
de le balancer sur disque systématiquement juste au cas où, lorsque tu
sais qu'il n'y en aura aucun besoin.

Personne n'a jamais fait l'éloge de cette solution. Il est vrai que certains
systèmes merdiques ont implémenté cette stratégie, mais c'est unanimement
considéré comme une erreur, et ils en sont revenus. L'évoquer comme tu le
fais n'apporte rien au débat.

Ce qui est bien dommage, car lancer le browser web à partir de zéro est
loin de prendre une minute.

Certes, mais quand tu lances un browser depuis zéro, il t'affiche ta page de
départ, pas les quinze pages que tu avais ouvertes et que tu souhaites
continuer à lire après l'achèvement du programme. Et les retrouver, ces
pages, ça peut prendre largement plus d'une minute.

Détrompe-toi : Je ne sais pas ce qu'ils ont été faire à Redmond

Je n'ai absolument rien à fiche de ce que font les types de microsoft. Si tu
fondes ton avis sur la mémoire virtuelle sur la seule observation de windows
95, c'est sûr que tu ne vas pas trouver ça brillant. Mais c'est parce que
windows 95 est bon à foutre à la poubelle, pas le concept de mémoire
virtuelle.

Ne sois pas ridicule : un résultat 60 fois plus lent, *c'est la même
chose* que rien. Ton temps, fût-il personnel, coûte au moins les 10
euros de l'heure que tu donnes à ton employée de maison pour faire ce
que tu n'as plus le temps de faire toi-même. De plus, en 40 minutes, tu
restes concentré sur ton problème. en 40 heures, non.

Je vais te dire un secret : quand l'ordinateur fait un calcul, on peut faire
autre chose. Je préfère un résultat qui arrive en une heure dans une heure
qu'un résultat qui arrive en une minute dans deux heures parce que j'ai dû
aller acheter une barette de mémoire.

Résultat non garanti = bricolage, je persiste et signe.
Tu n'appellerais pas un avion qui décolle sans avoir une chance

raisonnable d'arriver à destination dans les délais un bricolage ? Moi, si.

Tu as déjà vu des avions dont on avait démontré qu'ils arriveraient à
destination, toi ?

Tu confonds cache et tampon.
Tout ce qu'on flushe doit être réécrit avant que la mémoire soit

libérée.

Oui, et ça ce sont les tampons, pas le cache. C'est bien ce que je disais,
tu confonds.

Eh non, mon garçon. le cache sert également en écriture au cas où les
pages juste écrites seraient relues.

J'avais effectivement simplifié, puisque manifestement tu avais du mal. En
effet, un tampon devient du cache une fois qu'il est effectivement lu.

Et ?

Une heure d'ingénieur coûte le prix d'1 Go de RAM. Cela te suffit-il
comme réponse ?

Non pertinent : c'est pas l'ingénieur qui mouline pendant une heure, c'est
l'ordinateur. À la rigueur, si tu évoquais le pris du kW.h...

C'est du délire pur et simple. Si tu as la place d'xécuter tes
applications en mémoire, ajouter de la mémoire virtuelle n'augmentera
*rien*.

C'est faux : ça peut t'éviter d'avoir à quitter autre chose pour pouvoir
lancer l'application en question.

Mais en revanche te ralentira par des appels disque
intempestifs en cours quand tu auras besoin de faire des appels disque
qui servent à quelque chose.

C'est faux : ça ne ralentit que s'il y a effectivement eu échange, donc si
la mémoire virtuelle a été effectivement utilisée. Ce qui, dans le cas sans
mémoire virtuelle, signifie une application qui se termine inopinément faute
de mémoire.

Je vais te refaire le raisonnement en plus compact. Lis bien, et essaie de
comprendre, tout est dedans :

L'OS a plus d'éléments que quiconque pour évaluer ses besoins en mémoire.
Ses algorithmes de décision choisissent le plus efficace parmi toutes les
possibilités. Si dans une situation donnée, ne pas utiliser la mémoire
virtuelle est plus efficace que l'utiliser, alors il choisira de ne pas
l'utiliser, et obtiendra exactement les mêmes résultats que s'il n'y avait
pas eu de mémoire virtuelle. Conclusion : les performances sont toujours au
pire aussi bonnes avec de la mémoire virtuelle que sans.

Il y a un petit problème à ce raisonnement : les algorithmes de prédiction
de l'OS ne sont pas parfaits, et parfois il ne choisit pas l'optimal. Mais
avec des OS de qualité (pas windows 95), c'est un cas très rare, très
amplement compensé par les cas où l'utilisation de mémoire virtuelle a
effectivement fait gagner du temps.

Ecoute, tu l'utilises si tu veux. Pour ma part c'est terminé.

Eh bien, tant pis pour toi, je ne vais pas te forcer à configurer
correctement ton ordinateur. Je tiens juste à t'empêcher de répandre tes
mauvaises idées.

Tu es encore en train de tout mélanger ! Turbo C, ça ne tournait pas
sous Windows. C'est Windows que j'utilisais sur un Pentium 100, et DOS
sur le 386 qui tournait en Turbo C. Pour mémoire, avec deux cartes
Addiciel, on avait fait un serveur minitel 40 voies avec ce truc.
Entièrement en Turbo C. Et avec ma configuration RAMdisk + minicache
pour tout ce qui était compilation. C'était en 1987, si mes souvenirs
sont bons.

Mais on s'en fiche de ton minitel, de ton turbo c et de ton 386, qu'est-ce
que ça vient foutre là ?

Le 06 jan, à 11:18, FDA papotait :

Demandez-vous aussi pourquoi les concepteurs des *BSD, Linux et autres
Unix propriétaires (et certainement Windows) ainsi que des processeurs
eux-mêmes mettent tant d'énergie, de temps et d'argent dans le
développement, l'amélioration, le paramètrage et les évaluations des
différents mécanismes hards et softs de gestion de mémoire virtuelle
et/ou swappée/paginée.

1. Parce que ces systèmes ont plus de dix ans d'âge, et même vingt pour
Windows et 30 pour Linux si l'on remonte à leur code initial, dont il
doit bien rester des traces de ci, de là.

Le noyau Linux a 30 ans ? Vous êtes sûr de vos sources ?

Suivi en charte sur fcold.
--
No fortunes found

On 2006-01-06, FDA <armingaud@gmail.com> wrote:

encore la proporiété du 386 - reconduite sur tout ce qui a suivi -
d'avoir trois niveaux d'exécution : système, application, utilisateur.

Faux. Il y a quatre niveaux d'exécution, appelés "ring".

Je crois qu'un FU2 vers un groupe plus approprié serait une bonne diée,
mais en revanche ne je sais pas lequel.

Voilà.

--
t> Et après Nautilus, il faut t'attaquer à la face nord de
t> l'Everest: la débloatisation de Gnus.
Ah non, ça fait partie du cahier des charges. Si Gnus n'est plus bloaté,
moi je lirait les news avec netcat.