Détruire un objet avant la fin du script ?

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é.

Et je précise que pendant la lecture du fichier d'entrée, les hashs et
les liens fonctionnent à mort. Un appel disque tous les 10 000 accès
pendant que je fais ce petit tricotage me plomberait la vitesse de mon
programme - l'a fait au début, en fait - d'un facteur que je ne veux
même pas connaître tant tout devenait exaspérément lent. Peut-être un
facteur 1000).

À (at) Fri, 06 Jan 2006 11:37:17 +0100,
FDA <armingaud@gmail.com> écrivait (wrote):

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.

Lisez donc la doc de 'mmap'... Si 'mmap' dépendendait du swap, la
quasi totalité des softs sur votre machine (qui n'a pas de swap) ne
fonctionneraient plus.

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.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

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à. Les coûts ont totalement
changé depuis.

2. Parce que ces systèmes sont également destinés à faire tourner des
serveurs, qui n'ont personne devant eux et ont tout intérêt à gérer tout
seuls leur mémoire en fonction de leurs profils d'utilisation dans la
journée, ce qui ne s'applique en rien à un ordinateur personnel.

Essayez le swapping space à zéro, et vous ne pourrez bientôt plus
comprendre comment vous avez pu travailler autrement. Autant tenter de
faire au 400m haies les performances d'un 400m libre, les haies étant
ici les appels disque.

À (at) Fri, 06 Jan 2006 12:18:16 +0100,
FDA <armingaud@gmail.com> écrivait (wrote):

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à. Les coûts ont
totalement changé depuis.

C'est sûr : les derniers pentium, AMD ou PowerPC sont conçus par des
vieux croutons qui n'ont pas su évolué avec leur temps ;-)

2. Parce que ces systèmes sont également destinés à faire tourner des
serveurs, qui n'ont personne devant eux et ont tout intérêt à gérer
tout seuls leur mémoire en fonction de leurs profils d'utilisation
dans la journée, ce qui ne s'applique en rien à un ordinateur
personnel.

C'est bien connu : les serveurs sont des rolls très poussives alors
que les ordinateurs personnels sont des petis bolides de courses.

Essayez le swapping space à zéro, et vous ne pourrez bientôt plus
comprendre comment vous avez pu travailler autrement. Autant tenter de
faire au 400m haies les performances d'un 400m libre, les haies étant
ici les appels disque.

Pour reprendre votre image, continuez à laisser votre ordinateur
courir en libre et à se casser la gueule à chaque fois qu'il rencontre
une haie. ;-)

Personnellement, je préfère lui mettre, dans la mesure du possible, un
maximum de RAM (pour espacer les haies) mais lui laisser le swap (pour
qu'il sache passer les haies lorsqu'il en rencontre).

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

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à. Les coûts ont
totalement changé depuis.

C'est sûr : les derniers pentium, AMD ou PowerPC sont conçus par des
vieux croutons qui n'ont pas su évolué avec leur temps ;-)

Ah bon ? Il y aurait une partie de l'OS dans les microprocesseurs,
d'après toi ? En fait, tu n'es pas sans savoir qu'aucun OS n'utilise
encore la proporiété du 386 - reconduite sur tout ce qui a suivi -
d'avoir trois niveaux d'exécution : système, application, utilisateur.
Les systèmes ont donc pour le moment beaucoup de retard sur le matériel.

2. Parce que ces systèmes sont également destinés à faire tourner des
serveurs, qui n'ont personne devant eux et ont tout intérêt à gérer
tout seuls leur mémoire en fonction de leurs profils d'utilisation
dans la journée, ce qui ne s'applique en rien à un ordinateur
personnel.

C'est bien connu : les serveurs sont des rolls très poussives alors
que les ordinateurs personnels sont des petis bolides de courses.

Plus exactement la mesure de performance d'un serveur est son
/thoughput/ et non sa vitesse. Si tu veux la vitesse maximale de ta
voiture dans un tunnel, il faut y foncer tout seul à 110 km/h. Si tu
veux au contraire le /débit/ maximal dans ce tunnel, il faut ralentir
les véhicules à 60 km/h, ce qui leur permet de rouler moins espacés.
Ici, mutatis mutandis...

Essayez le swapping space à zéro, et vous ne pourrez bientôt plus
comprendre comment vous avez pu travailler autrement. Autant tenter de
faire au 400m haies les performances d'un 400m libre, les haies étant
ici les appels disque.

Pour reprendre votre image, continuez à laisser votre ordinateur
courir en libre et à se casser la gueule à chaque fois qu'il rencontre
une haie. ;-)

Si j'ai besoin de 2 Go de RAM pour mes applications, je mets 2 Go de
RAM. Cela ne m'avancerait à rien de l'avoir en double-canal à sa
fréquence si toutes les 100 000 opérations je devais me farcir un appel
disque qui me bouffe un million de cycles mémoire. Time is money. Je
n'ai pas les moyens de travailler avec une RAM étriquée, pas plus
qu'avec un bureau qui serait au formar A4 (gasp!).

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

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

Consacre carrément 90% de ta mémoire au cache disque,

Pour ta gouverne, en temps normal, c'est ce que je fais, et je peux dire que
ça se sent très nettement (en comparant entre deux machines qui ont bien
assez de mémoire pour toutes les applications, mais l'une qui a plus de rab
que l'autre).

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

De toute évidence, tu n'as rien compris au fonctionnement de la mémoire
virtuelle d'un système d'exploitation moderne. Le système choisit
dynamiquement ce qu'il va mettre en mémoire, en fonction d'heuristiques pour
optimiser les performances.

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. 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). Quand on quitte l'application en question, la mémoire
libérée est remise dans le pot commun, et se remplira probablement
progressivement de cache disque à mesure que ce sera utile.

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.

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 ».

FDA wrote in message
<43be5c8c$0$13121$79c14f64@nan-newsreader-06.noos.net>:

Ah bon ? Il y aurait une partie de l'OS dans les microprocesseurs,
d'après toi ?

Il y a dans les micorprocesseurs des constructions spécifiquement dédiées à
faciliter certains aspects du travail des OS modernes. On peut en
particulier parler du changement de contextes (les banques de registres des
SPARC, si j'ai bien compris, mais c'est de seconde main), les appels système
(l'instruction syscall des pentiums récents), et bien d'autres.

S'agissant de la mémoire virtuelle, une part importante des microprocesseurs
est spécifiquement dédiée à permettre son implémentation, on appelle ça
« Memory Management Unit », MMU. Pour référence, elle est apparue dans la
série des intel avec le 80386.

FDA wrote in message
<43be49f7$0$13126$79c14f64@nan-newsreader-06.noos.net>:

Et il fait la correspondance de ta mémoire avec quoi, le mmap, sinon
l'espace de swap ?

Avec un fichier, comme tu le saurais si tu avais seulement ouvert la doc de
mmap au lieu de continuer à parler sur ce que tu ne connais pas.

Un appel disque tous les 10 000 accès
pendant que je fais ce petit tricotage me plomberait la vitesse de mon
programme

D'où l'intérêt d'avoir un maximum de cache disque et de la prédiction de
lecture.

Et il fait la correspondance de ta mémoire avec quoi, le mmap, sinon
l'espace de swap ?

Avec un fichier, comme tu le saurais si tu avais seulement ouvert la doc de
mmap au lieu de continuer à parler sur ce que tu ne connais pas.

Et que je n'ai pas à connaître. Je n'ai pas besoin de faire correspondre
la mémoire avec un fichier. Je lis un fichier. C'est du texte. C'est
séquentiel. Pas besoin d'activer la mémoire virtuelle pour ça, puisque
chez moi elle n'est pas activée et que ça marche très bien.

Un appel disque tous les 10 000 accès
pendant que je fais ce petit tricotage me plomberait la vitesse de mon
programme

D'où l'intérêt d'avoir un maximum de cache disque et de la prédiction de
lecture.

"Mon frère n'aime pas les épinards
Et c'est heureux pour mon frère, car
S'il les aimait, il en mangerait
Or il ne peut les supporter"

Voilà qui est à peu près du même niveau. Non, il ne faut pas "un
maximum" de cache disque, il faut la quantité dont tu as besoin et rien
de plus. Au-delà, c'est de l'overkill. La lecture anticipée, oui, mais
les paramètres de hdparm sont là pour ça.

S'agissant de la mémoire virtuelle, une part importante des microprocesseurs
est spécifiquement dédiée à permettre son implémentation, on appelle ça
« Memory Management Unit », MMU. Pour référence, elle est apparue dans la
série des intel avec le 80386.

Merci, on sait. Et cette architecture date de 1986. On a toujours besoin
- et même un peu plus qu'avant - de gérer la mémoire, 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,
surtout quand ces appels disque risquent de se compter par milliards
parce qu'il y a des chaînages en pagaille dans tous les sens à descendre
et à remonter.

La mémoire virtuelle (je ne parle pas su swapin/swapout qui relève
d'autres considérations) est aujourd'hui contre-productive sur un
ordinateur personnel pour pas mal de travaux. Si je l'ai inhibée, ce
n'est pas par hasard, mais parce que je préfère ne pas charger du tout
une application que la charger et voir dans le même moment tout le reste
ralentir d'un facteur cent.