remplacement de la RAM par du disque dur: variation du temps d'accès
Le
Tribulations Parallèles
Bonjour à tous,
J'ai codé un programme qui réalise des calculs qui demandent beaucoup de RAM
(environ 500 Mo).
Je compte améliorer le programme, mais alors j'ai besoin de 100 Go de RAM
(oui!). Ce n'est pas possible. J'envisage donc de stocker mes données sur
le disque dur; plusieurs question en découlent:
1- Comment va évoluer le temps de lecture ou écriture des données? En
cherchant, je vois que le temps d'accès à la RAM est de l'ordre de 10 nano
seconde, au disque dur de 10 milli seconde. Un facteur un million se
dessine donc: il est trop important. Pour mon application, je peux tolérer
un facteur 10000. Or, quand je fais hdparm -t /dev/hda sur mon ordi, il me
donne 22 MB/sec: cela représente une lecture bien plus rapide que 10 milli
seconde pour accéder à chaque bit; pourquoi? A quoi correspondent ces
temps? Où trouver de la doc didactique sur le fonctionnement du disque dur?
Par exemple, si j'essaie de copier un fichier de quelques centaines de Mo
sur mon disque ($ cp foo.avi bar.avi), cela prend plusieurs dizaines de
secondes; mais là il lit et écrit; comment cela évolue-t-il si je ne fais
que charger le contenu d'un gros fichier dans la RAM? Bref, je suis
dépassé, et j'ai du mal à trouver de la doc sérieuse sur internet (mais
sûrement que je cherche mal).
2- Pour stocker ces données dans des fichiers, avez-vous une expérience à
faire partager? Existe-t-il des bibliothèques spéciales sous Linux? A
priori aucun intérêt à compresser les données?
Bref je suis preneur de tout conseil.
Merci d'avance,
Julien
--
"Allez, Monsieur, allez, et la foi vous viendra." (D'Alembert).
J'ai codé un programme qui réalise des calculs qui demandent beaucoup de RAM
(environ 500 Mo).
Je compte améliorer le programme, mais alors j'ai besoin de 100 Go de RAM
(oui!). Ce n'est pas possible. J'envisage donc de stocker mes données sur
le disque dur; plusieurs question en découlent:
1- Comment va évoluer le temps de lecture ou écriture des données? En
cherchant, je vois que le temps d'accès à la RAM est de l'ordre de 10 nano
seconde, au disque dur de 10 milli seconde. Un facteur un million se
dessine donc: il est trop important. Pour mon application, je peux tolérer
un facteur 10000. Or, quand je fais hdparm -t /dev/hda sur mon ordi, il me
donne 22 MB/sec: cela représente une lecture bien plus rapide que 10 milli
seconde pour accéder à chaque bit; pourquoi? A quoi correspondent ces
temps? Où trouver de la doc didactique sur le fonctionnement du disque dur?
Par exemple, si j'essaie de copier un fichier de quelques centaines de Mo
sur mon disque ($ cp foo.avi bar.avi), cela prend plusieurs dizaines de
secondes; mais là il lit et écrit; comment cela évolue-t-il si je ne fais
que charger le contenu d'un gros fichier dans la RAM? Bref, je suis
dépassé, et j'ai du mal à trouver de la doc sérieuse sur internet (mais
sûrement que je cherche mal).
2- Pour stocker ces données dans des fichiers, avez-vous une expérience à
faire partager? Existe-t-il des bibliothèques spéciales sous Linux? A
priori aucun intérêt à compresser les données?
Bref je suis preneur de tout conseil.
Merci d'avance,
Julien
--
"Allez, Monsieur, allez, et la foi vous viendra." (D'Alembert).
Poser une question
Ça dépend énormément de comment ton programme va y accéder. Si il reste
pendant de (relativement) longues périodes à travailler sur un sous-ensemble
des données tenant en mémoire, alors tu ne sentiras presque pas de
ralentissement : tu auras juste des accès disques de temps en temps pour
changer le sous-ensemble des données stocké en mémoire, mais si ça se
produit suffisament rarement, ça sera négligeable. À l'opposé, si il passe
son temps à sauter à droite à gauche, là tu te prends allègrement un facteur
1000 (en étant optimiste).
Le temps d'accès est le temps que le disque dur met à se mettre à lire à une
adresse que tu lui donnes (déplacement des têtes et cie). Mais une fois
qu'il s'est mis à lire, il peut continuer à te pondre à tombeau ouvert les
secteurs voisins. Donc si tes fichiers sont peu fragmentés et que tu les lis
séquentiellement, le temps d'accès ne se sent pas trop. Le hdparm fait
justement du transfert séquentiel bourrin, ce qui explique ses bonnes
performances.
Wikipedia par exemple.
Bah tu n'as qu'à faire l'expérience (cat foo > /dev/null). Enfin en très
gros ça devrait varier d'un facteur 2.
Tout dépend de quelle forme de données il s'agit.
Note que sur une machine 64 bits, tu pourrais tout bêtement tout garder en
mémoire et laisser l'OS se dépatouiller avec le swap.
Si tu dois passer ton temps à les lire et les réécrire, ça me parait plutôt
nuisible, à moins que tu manques de place.
Étant donné que le domaine "freeee_._frspaM" n'existe pas, je
t'encourage vivement à rajouter ".invalid" à la fin. Merci d'avance.
Tu confonds "temps d'accès" et "vitesse de lecture séquentielle".
Si tu veux lire un bloc contigu de N octets, le temps nécessaire sera
la somme du temps d'accès au premier octet (i.e. le temps de
positionnement des têtes au bon endroit) + le temps de lecture réel de
ces N octets sur le disque dur.
En d'autres termes, lire 1000 octets disséminés un peu partout sur le
disque prendra beaucoup plus de temps que lire 1000 octets contigus.
AMHA, ça dépend beaucoup de l'algorithme utilisé.
Si tu lis 100 Mo d'un coup (i.e. tu les mets en RAM), puis que tu les
écris d'un seul coup également, il y aura peu de déplacements des
têtes, donc ça ira vite.
Si tu lis 1 Ko, puis tu l'écris, puis tu lis à nouveau 1 Ko, etc., ça
prendra énormément de temps (et fera beaucoup de bruits), à cause des
200 000 déplacements des têtes (de la zone à lire à la zone
d'écriture, et vice-versa).
J'avais fait le test il y a peu de temps, et la compression façon gzip
prend trop de temps.
Par contre, une compression plus basique peut être efficace : si tu as
des valeurs qui vont de 1 à 1 million, stocke-les sur 20 bits et pas
sur 32.
Note : il n'est pas impossible que Linux sache gérer ce genre de chose
mieux que toi. Alloue donc une partition de swap de 100 Go, et vois ce
que ça donne.
Mouais, sachant que l'os et le disque lui-même font du read-ahead et gardent
le résultat dans un cache, ça ne doit pas se sentir tant que ça, si?
Il faut une machine 64 bits pour ça, à moins qu'il puisse découper son
calcul en 25 process séparés travaillant chacun sur 4Go.
Habert):
Sous Linux, je ne sais pas.
Sous Windows 2000, la différence (surtout dans le bruit que fait le
disque dur) est flagrante.
S'il s'agit de faire d'énormes calculs, une machine un peu récente est
de mise. Et comme le moindre petit Sempron fonctionne en 64 bits, ça
devrait être jouable.
D'abord merci beaucoup pour ta réponse ainsi qu'aux autres.
Pourquoi? Je veux dire, je suis tout prêt à le changer (c'est pas très
élégant, c'est vrai), mais est-ce que ça pose un problème particulier? J'ai
peur qu'en rajoutant simplement .invalid les robots puissent détecter mon
adresse: c'est pour ça que j'ai pris quelque chose de très compliqué.
Question: comment peut-on écrire simplement une grosse structure C de 500Mo
(une structure avec des pointeurs de pointeurs, des choses comme ça) dans
un fichier? Existe-t-il des bibliothèques dédiées à ça? En effet, je crois
qu'il y a dans la bibliothèque standard C des fonctions comme "tmpfile" qui
ouvre un fichier en écriture binaire, mais il faut que j'écrive ma
structure (compliquée) de manière pertinente, ce qui n'est pas forcément
simple.
De plus, est-on sûr que le fichier sera contigu; d'après ce que vous me
dites, s'il est découpé en quelques morceaux, ce n'est pas trop grave, mais
s'il est découpé en 10000 morceaux, ça va être embêtant. Cela dépend du
système de partitionnement, n'est-ce pas? Et en EXT3, je crois qu'il n'y a
pas ce genre de problèmes:
http://en.wikipedia.org/wiki/Ext3
Par ailleurs, je peux effectivement me débrouiller pour lire des données de
temps en temps, par paquet de 500 Mo (sur 100 Go au total), et travailler
dessus, directement dans la RAM, avant d'écrire le résultat sur le disque.
Si je suis vos commentaires, cela ne devrait donc pas ralentir mon
programme d'un facteur énorme.
Merci,
Julien
--
"Allez, Monsieur, allez, et la foi vous viendra." (D'Alembert).