Discussion :

[cosmoff]

Bonjour � tous,

voila si je veux lire un fichier je peux faire :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

int fd = open("fichier_a_lire.txt", O_RDONLY);

et ensuite je peux faire :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

read(fd, buffer, 256);

ou faire

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
void* addr = mmap(NULL,length_of_fichier_a_lire,…, fd, 0);
strncpy( buffer, addr, 256);

mais c'est quoi le mieux?
dans les deux cas le fichier est charg� en RAM par le noyau via l'appel syst�me open, donc pourquoi s�emb�ter avec mmap ?

merci de vos �claircissements

[Sve@r]

Bonjour

dans les deux cas le fichier est charg� en RAM par le noyau via l'appel systeme open

Perdu

Quand tu lis un fichier via open(), une partie du fichier est charg�e en m�moire pour �conomiser les acc�s disques (bufferisation) donc les lectures suivantes se font depuis le buffer m�moire ok. Mais d�j� la bufferisation ne concerne qu'une portion du fichier (portion �quivalente � la taille du buffer) et d'autre part, du point de vue programme, la lecture par read(), m�me si elle est faite depuis le buffer, est quand-m�me consid�r�e comme se faisant depuis un fichier disque.

Bien entendu, si le fichier est assez petit, alors effectivement la diff�rence devient n�gligeable (si tout le fichier est charg� dans le buffer les read seront tr�s rapide) mais tu ne peux pas impl�menter un choix technique en te fondant sur la chance.

Donc si ton algorithme n'a besoin que d'un caract�re, ou 10 ou 100 en s�quentiel, alors tu pars sur open()+read() et si ton algo a besoin de tout le fichier en RAM, alors nmap(). Mais dans ce cas il faut vraiment que le besoin soit r�ellement justifi� (comme par exemple tu as besoin de te ballader super souvent et super rapidement � diff�rentes positions du fichier aussi bien avant que arri�re) parce que charger tout un fichier en RAM �a peut vite devenir gourmand...

[Matt_Houston]

Justement, ou alors je n'ai pas saisi ce que tu as exprim� Sve@r : l'int�r�t d'mmap un fichier est de produire une vue de son contenu en m�moire syst�me. Cela permet � l'application de faire comme si elle disposait d'un buffer gigantesque alors que le kernel r�alise une transposition d'adresse et charge et d�charge � la vol�e les pages requises.

Lorsque l'on read, les donn�es sont a priori r�ellement charg�es en m�moire.

[Christophe]

mmap permet de charger un fichier complet dans l'espace d'adressage d'un processus. L�int�r�t par rapport � fopen/read est de pouvoir se balader comme on veut dedans. Pour des fichiers standards, l�int�r�t est faible, surtout que je pense que mmap utilise le syst�me du copy on write ce qui peut �tre dangereux en cas d'erreur IO, plus facilement contr�lable par la famille des fonctions fopen/fread.

L�int�r�t de mmap est aussi de pouvoir changer les droits d'acc�s lors du chargement (exemple zone de code au lieu de donn�es), n�cessaire pour charger du code ex�cutable par exemple. Les fonctions execve utilisent mmap (la page de man fait r�f�rence � exec, et fork notamment)

Tu peux consid�rer mmap comme une fa�on exotique de charger un fichier en m�moire. A ne pas faire si on ne maitrise pas ce qu'on fait.

[Sve@r]

Lorsque l'on read, les donn�es sont a priori r�ellement charg�es en m�moire.

Oui parce que le read() est limit� � 32767 caract�res donc ces 32767 caract�res sont r�ellement charg�s dans la RAM. Alors que le fichier charg� par mmap() est probablement charg� dans la RAM+SWAP.

Mais j'ai aussi parl� de "se ballader super souvent et super rapidement � diff�rentes positions du fichier aussi bien avant que arri�re". Si ton fichier est charg� en RAM (que ce soit en vraie RAM ou en SWAP pour le programmeur �a reste de la RAM), tu peux traiter le premier caract�re, puis le dernier, puis le second, puis l'avant-dernier et etc (par exemple : tester que le contenu d'un fichier est un palindrome).
Tu peux obtenir le m�me r�sultat � base de tell() + seek() + read() mais �a sera 1000 fois plus long (ne serait-ce par exemple; que parce que le fichier est trop gros pour tenir enti�rement dans le buffer donc si tu lis le premier caract�re, puis le dernier, puis le second et etc alors � chaque lecture le fichier sera r�ellement pris depuis le disque dur).

[cosmoff]

merci beaucoup pour vos r�ponses tres completes.

donc quand je fais open(), le noyau va juste regarder si le fichier existe et mettre � jour sa table de descriptor de fichier, il ne charge pas le fichier en RAM. Il ne charge les data que lorsque je fais un read(fd, buffer, 256), et il charge un nombre de caractere correspondant � 256 dans mon exemple

[Sve@r]

donc quand je fais open(), le noyau va juste regarder si le fichier existe et mettre � jour sa table de descriptor de fichier,

Probablement (encore que le fichier peut ne pas exister et sera cr�� si tu as demand� l'option "O_CREAT")...

il ne charge pas le fichier en RAM.

L� c'est s�r que non

Il ne charge les data que lorsque je fais un read(fd, buffer, 256), et il charge un nombre de caractere correspondant � 256 dans mon exemple

Exact. M�me s'il est quasi certain qu'il va en charger beaucoup plus dans le buffer IO en pr�vision des read() suivants, toi (progammeur) tu n'en as que 256 � ta disposition imm�diate.

[Matt_Houston]

Je ne te suis pas Sve@r. Lorsque tu mmap le fichier, la pr�sence r�elle des donn�es en m�moire syst�me est enti�rement � la discr�tion du kernel. Tu pourrais tr�s bien lire ou �crire partout dans le fichier de mani�re al�atoire - c'est d'ailleurs un cas d'usage bien connu de mmap - en ne disposant � tout moment que d'une seule page charg�e en m�moire, et ce serait tout aussi transparent pour l'application (except�es les horrible perfs qui en d�couleraient ). Quant � parler de swap, c'est incongru ici.

Je n'ai pas connaissance de cette limite de 2^15 pour read, c'est sens� �tre quoi ? La taille du buffer ? Je serais surpris que POSIX impose un truc aussi arbitraire.

[Sve@r]

Lorsque tu mmap le fichier, la pr�sence r�elle des donn�es en m�moire syst�me est enti�rement � la discr�tion du kernel. Tu pourrais tr�s bien lire ou �crire partout dans le fichier de mani�re al�atoire

Oui, �a rejoint ce que j'ai dit quand je parlais de "se ballader super souvent et super rapidement � diff�rentes positions du fichier aussi bien avant que arri�re"...

Quant � parler de swap, c'est incongru ici.

Euh... si le fichier est super gros, fatalement la RAM sera swapp�e. Comme le PO parlait aussi de perfs comparatives, j'ai juste voulu aussi rappeler que m�me la RAM peut aussi n�cessiter des acc�s disques (tout comme j'ai aussi voulu rappeler que m�me les demandes d'acc�s disques peuvent en r�alit� se faire en RAM quand j'ai parl� de bufferisation). Le yin et le yang quoi...

Je n'ai pas connaissance de cette limite de 2^15 pour read, c'est sens� �tre quoi ? La taille du buffer ? Je serais surpris que POSIX impose un truc aussi arbitraire.

Alors �a �a date de l'�poque o� je travaillais sur Unix et j'avais remarqu� cette limitation. Effectivement je viens de tester, sur un Linux j'ai lu 50000 sans souci (n'ai pas cherch� plus haut). Mais c'est pas tout � fait arbitraire (plus grande valeur d'un short sign�).

Toutefois le man de read parle de SSIZE_MAX comme limitation de la valeur "count" et j'ai trouv� un "_POSIX_SSIZE_MAX" valant 32767 dans "/usr/include/x86_64-linux-gnu/bits/posix1_lim.h" (mais j'ai pas r�ussi � trouver si "SSIZE_MAX" utilisait ce "_POSIX_SSIZE_MAX" � un moment ou un autre...

[Matt_Houston]

Euh... si le fichier est super gros, fatalement la RAM sera swapp�e. Comme le PO parlait aussi de perfs comparatives, j'ai juste voulu aussi rappeler que m�me la RAM peut aussi n�cessiter des acc�s disques (tout comme j'ai aussi voulu rappeler que m�me les demandes d'acc�s disques peuvent en r�alit� se faire en RAM quand j'ai parl� de bufferisation). Le yin et le yang quoi...

On se comprend pas. Peu importe que le fichier occupe 64 octets ou 64 GiB, puisque son adressage est totalement virtuel. C'est ce qu'expliquait �galement chrtophe. En th�orie tu pourrais le mmapper sur une machine avec 4 MiB de RAM.