Luc Habert wrote:

> Linux ne s'amuse pas à swapper pour le plaisir. Avec la connaissance de
> ton algorithme, tu peux le programme de sorte qu'il n'accède pendant une
> longue tranche de temps qu'à un bloc de 500Mo sur les 100Go de son espace
> mémoire virtuel, et alors tu vas vite te retrouver avec cette tranche
> présente en mémoire physique et tout le reste partit dans le swap, et à
> partir de là, tout va rouler.
>
> Et ça te facilite hallucinement la tache d'implémentation, de laisser l'OS
> faire le boulot.

Merci pour ta réponse.
Je ne suis pas sûr que cela soit la meilleure façon de faire.
En effet, voici de manière imagée ce que j'ai à réaliser: je dispose de n
(ex: 200) tableaux T de taille m (ces m tableaux correspondant chacun à une
taille de 500 Mo), et je fais des opération compliquées sur p éléments de
chacun des tableau T de taille m: je commence pas les p premiers éléments:
1..p, puis 2..p+1, puis ainsi de suite jusqu'aux éléments m-p+1..m
Donc si je commence à traiter par exemple le tableau n=17, qui est
complètement sur le swap, et que je fais une opération sur les p premiers
éléments (ex: moyenne arithmétique), l'OS va aller les chercher sur le
disque, et les mettre en RAM (éventuellement virer quelque chose qui y
était déjà). Mais quand je vais traiter les éléments 2..p+1, il va devoir
aller chercher T[p+1] sur le swap, et ainsi de suite. Si m très grand
devant p, cela va faire un paquet d'accès disque. Alors que si je libère la
mémoire allouée jusqu'à présent, et que je charge en mémoire l'intégralité
du tableau m de 500 Mo, je vais pouvoir réaliser l'opération sur le tableau
sans un seul accès disque: donc ça va être plus rapide.
Es-tu d'accord avec ce que je dis?
Dans ce cas, cela voudrait dire que je n'aurais pas à utiliser
mmap/msync/munmap, mais plutôt à stocker mes structures de données dans des
fichiers, et d'écrire et lire dedans. Comme dit dans un précédent post, là
j'aurais 200 fichiers de 500Mo. Je ne vois pas ce que pourrait m'apporter
mmap/mync/munmap ici.
Et alors, a priori même si mes fichiers ne sont pas contigus sur le disque,
cela ne devrait pas prendre un temps très grand. Comme suggéré par Rémi
Moyen, je pourrais utiliser deux threads: un qui lit ou écrit les résultats
des calculs, et un qui calcule pendant ce temps-là.

Cordialement,

Julien

--
"Allez, Monsieur, allez, et la foi vous viendra." (D'Alembert).

Tribulations Parallèles wrote in message
<4490442d$0$10291$636a55ce@news.free.fr>:
> En effet, voici de manière imagée ce que j'ai à réaliser: je dispose de n
> (ex: 200) tableaux T de taille m (ces m tableaux correspondant chacun à une
> taille de 500 Mo), et je fais des opération compliquées sur p éléments de
> chacun des tableau T de taille m: je commence pas les p premiers éléments:
> 1..p, puis 2..p+1, puis ainsi de suite jusqu'aux éléments m-p+1..m
> Donc si je commence à traiter par exemple le tableau n=17, qui est
> complètement sur le swap, et que je fais une opération sur les p premiers
> éléments (ex: moyenne arithmétique), l'OS va aller les chercher sur le
> disque, et les mettre en RAM (éventuellement virer quelque chose qui y
> était déjà). Mais quand je vais traiter les éléments 2..p+1, il va devoir
> aller chercher T[p+1] sur le swap, et ainsi de suite. Si m très grand
> devant p, cela va faire un paquet d'accès disque. Alors que si je libère la
> mémoire allouée jusqu'à présent, et que je charge en mémoire l'intégralité
> du tableau m de 500 Mo, je vais pouvoir réaliser l'opération sur le tableau
> sans un seul accès disque: donc ça va être plus rapide.
> Es-tu d'accord avec ce que je dis?

Non, ça ne va pas se passer comme ça. Ce qui va se passer, c'est que quand
tu vas lire pour la première fois les éléments 0 à p, le noyau va se dire
que tu vas probablement bientôt avoir besoin de l'élément p+1, donc il va
initier son chargement en mémoire, de manière asynchrone, pendant que tu
reprends la lecture des éléments 2 à p, ce qui fait que quand tu en arrives
à l'élément p+1, il est déjà en mémoire, et tu n'as perdu absolument aucun
temps.

Au contraire, si tu fais manuellement le chargement-déchargement, ton
processus es bloqué pendant les opérations disque, alors qu'il aurait pu
passer le temps à faire du calcul utile, donc tu perds du temps. D'autre
part, le noyau sait mieux que toi quelle quantité de mémoire est
effectivement disponible, et il fera donc des décisions plus éclairées,
comme garder en mémoire un exemplaire et demie de ton tableau plutôt que
seulement un, ou même dégager openoffice pour en faire tenir deux.

D'une manière générale, quand tu es confronté à ce genre de situation, la
règle d'or est: profile, don't speculaite: tu ne passes pas des heures à
te demander si machin va te faire gagner quelques pouillèmes de seconde par
rapport à truc alors que ce sont des quantités très difficilement
quantifiables; au contraire, tu écris ton programme au plus simple (donc
ici, machine 64bits et mmap ou malloc de l'ensemble des données, et laisser
le noyau se débrouiller avec la MMU), et tu examines a posteriori si le
résultat est trop lent.

Si c'est effectivement trop lent, il y a des moyens simples de conseiller le
noyau pour la meilleure stratégie. Sous Linux, en particulier, il y a
l'appel système madvise qui sert précisément à ça. Mais re répète, il ne
faut commencer à faire des bidouilles avec madvise.que si les performances
de la version naïve sont mauvaises.

Nicolas George wrote:

> Non, ça ne va pas se passer comme ça. Ce qui va se passer, c'est que quand
> tu vas lire pour la première fois les éléments 0 à p, le noyau va se dire
> que tu vas probablement bientôt avoir besoin de l'élément p+1, donc il va
> initier son chargement en mémoire, de manière asynchrone, pendant que tu
> reprends la lecture des éléments 2 à p, ce qui fait que quand tu en
> arrives à l'élément p+1, il est déjà en mémoire, et tu n'as perdu
> absolument aucun temps.

Est-ce le "prefetch" évoqué à la fin de:

http://en.wikipedia.org/wiki/Virtual_memory

ou est-ce encore autre chose?

"Recently, some experimental improvements to the 2.6 Linux kernel have been
made by Con Kolivas, published in his fairly popular CK patchset. The
improvements, called "Swap Prefetch", employ a mechanism of pre-fetching
previously swapped pages back to physical memory even before they are
actually needed, as long as the system is relatively idle (so not to impair
performance) and there is available physical memory to use. This gives
several orders of magnitude faster access to the affected pages when their
owning process needs access to them, since they are effectively not swapped
out by then."

Julien

--
"Allez, Monsieur, allez, et la foi vous viendra." (D'Alembert).

Tribulations Parallèles wrote in message
<44907478$0$27366$626a54ce@news.free.fr>:
> Est-ce le "prefetch" évoqué à la fin de:
>
> http://en.wikipedia.org/wiki/Virtual_memory
>
> ou est-ce encore autre chose?

Pas exactement, je pense, mais c'en est proche. Mais je le répète: ne
commence à te poser ces questions que si tu constates un manque de
performances à ce niveau.