Version imprimable
Bonjour. Afin de manipuler des fichiers pouvant atteindre plusieurs centaines de Mo (ascii ou binaires), je cherche à implémenter un streaming de ces fichiers en C++ pour éviter de surcharger la mémoire.
Cependant je ne sais pas trop par où commencer :roll:. En effet mon ami "gogole" ne me parle que de streaming de fichiers audio ou vidéo. Mais je n'ai pas trouvé d'algo général ni d'exemples de codes pour le streaming de fichiers de données.
Quelqu'un pourrait-il m'aiguiller??
Ouvrir socket serveur. Ouvrir socket client. Client envoie demande à serveur. Serveur ouvre fichier et envoie bout par bout au client. Client reçois données bout par bout et les stocke dans un fichier.
Forcément c'est si simple que je me doute que ta question portait sur un aspect plus spécifique, mais faudrait décrire un peu plus. Déjà rien que le terme streaming est largement perçu comme un terme pseudo-marketing et de fait n'apporte pas une grande valeur à une description technique.
Ok. Donc j'étaye. Ce "streaming" est local. En effet il s'agit de charger un fichier localement en le découpant en petits buffers que le parser de mon appli lira au fur et à mesure. Il n'y a pas de contrainte de transport via un réseau.
Si dans l'ensemble je pense avoir appréhendé la "recette" : remplissage de tampons de taille "raisonnable", empilement de ceux-ci, traitement par le parser, dépilement des tampons traités, je ne sais toujours pas trop comment partir.
Je reste donc tout ouïe.
Bonjour,
ben pourquoi ne pas commencer avec un simple ifstream pour la lecture du fichier et une simple string pour le stockage (éventuellement un vector de string)?
Voir notamment l'utilisation de la fonction membre read de ifstream (cf. cette faq)
Pourquoi ne pas utiliser les fonctionnalités de l'OS.
Tu mappes le fichier en mémoire virtuelle, cela ne coûte rien tant que les pages mémoires du fichiers ne sont pas utilisées. Ensuite, c'est l'OS qui mappe ces pages au fur et à mesure de tes demandes dans l'espace mémoire de ton process.
Sous Microsoft, j'utilise MapViewOfFile() (un point d'entrée ici : http://msdn.microsoft.com/en-us/libr...56(VS.85).aspx) et sous Linux, je pense que c'est mmap() qui fait l'équivalent.
Le problème n'est pas tant la lecture du fichier d'une manière générale. Il existe déjà un reader et un sérializer dans mon appli, ils fonctionnent très bien et s'appuient sur la gestion des flux de la STL.Citation:
Envoyé par r0d
En fait j'aimerai pouvoir "streamer" le fichier comme un morceau de musique. C'est à dire que la lecture du morceau (dans mon cas le parsing de mon fichier) commence alors que celui-ci n'est pas complètement chargé en mémoire.
Ca s'éloigne un peu de ce que je voudrais faire. D'autant que j'aimerais, autant que possible, m'affranchir de fonctions "platform specific".Citation:
Envoyé par ram_0000
Mais néanmoins merci pour le lien je vais regarder ça de près.
As-tu des contraintes de synchronisation? Je demande ça car si la réponse est oui, tu va devoir passer par des threads.Citation:
Envoyé par JBond007
Mais avec ou sans threads, le principe est le même:
1. on lit un bout du fichier que l'on met dans un buffer
2. on traite le buffer
3. retour au 1.
Non je n'ai pas de contrainte de synchro (pas encore??:?).
Par contre les fichiers à parser décrivent des graphs donc ça va impliquer d'autre contraintes.
Cependant pas de souci de compréhension pour le principe en général, c'est plus pour le codage à proprement parler que ça coince.
Je ne sais pas trop comment partir.
Il va sûrement falloir que je définisse de nouvelles structures de données (StreamBuffer avec la possibilté d'interroger son état : ecriture / lecture / lu, une pile de StreamBuffer ...?)
De plus le fait de faire une boucle qui remplit au fur et à mesure des tampons, les empile en attendant qu'ils soient traités, n'est ce pas bloquant? Car pendant ce temps là on ne peut rien faire d'autre. En relisant ça, ça sent les threads non?
Salut,
Pour t'aider il faut preciser l'utilisation du fichier. Tu parles d'un graph, est ce que tu fais un visualiseur de données sous forme de graph avec quelle option ( zoom, deplacement ?). Et comment est structuré ton programme, peut tu deplacer dans ton fichier facilement sans l'avoir précedement parcourt pour l'indexer ?
Effectivement, tu ne fournis pas assez de précisions pour que nous puissions t'aider. Surtout si tu dis que ton problème est au niveau du code, et non de l'algorithme.
Ben oui, la lecture d'un fichier (de même que les traitements) sont bloquants. Comme toute fonction c++. Là je crois que ton problème est plus général et très simple: tu veux faire deux choses en même temps, donc oui, il te faut deux threads.Citation:
Envoyé par JBond007
Il ne s'agit pas de visualiser des données sous forme de graphe. Les données sont déjà organisées sous la forme d'un graphe hiérarchisé.Citation:
Envoyé par themadmax
En fait mon appli permet de visualiser des graphes de scènes avec OpenGL. Donc sans trop rentrer dans les détails de l'implémentation, je dispose d'une API décrivant différents noeuds avec différentes propriétés, qui "assemblés" constituent un graphe de scène. Le chargement est classique c'est à dire que le fichier est entièrement chargé en mémoire, puis parsé. Maintenant il faudrait que je le "streame" pour éviter de saturer la mémoire lorsque les fichiers sont très volumineux.
Pour ce qui est de me déplacer dans mon fichier, je me sers de ce qui existe dans ifstream.
Je le referai plus :oops: (cf post précédent)Citation:
Envoyé par r0d
Hmm. Je sens que le design de ce machin va être chiant...:roll:Citation:
Ben oui, la lecture d'un fichier (de même que les traitements) sont bloquants. Comme toute fonction c++. Là je crois que ton problème est plus général et très simple: tu veux faire deux choses en même temps, donc oui, il te faut deux threads.
Question: Est-ce que tu dois/peux modifier cette API ou juste te débrouiller pour la faire fonctionner différement mais sans la modifier?Citation:
Envoyé par JBond007
C'est le métier qui rentre ;)Citation:
Envoyé par JBond007
En plus tu verras que souvent, en faisant un effort pour expliquer précisément un problème, on trouve soi-même la réponse. En effet, pour expliquer clairement et le plus succintement possible un problème, on est obligé de synthétiser, de trier ce qui est important et ce qui ne l'est pas, de classer les différentes donnés du problème, etc... et ce travail est souvent suffisant pour trouver une solution.
Ben à première vue, ça ne me parait pas si compliqué.Citation:
Envoyé par JBond007
Creer un thread pour faire tourner ton "module" (lecture fichier + traitement données) est très simple: d'abord tu le fais fonctionner en "simple thread", ensuite l'encapsulation dans un thread est très simple, surtout si les données de ce "module" sont indépendantes du reste de l'application.
Je peux modifier "un peu" l'API. Le but étant la rétro compatibilité entre la nouvelle version et les précedentes. Cependant tant que ça ne casse pas le fonctionnement même de celle-ci, c'est bon, je peux ajouter pleins de trucs.Citation:
Envoyé par r0d
Je voyais pas ça de cette façon.Citation:
Envoyé par r0d
->un thread dépiler les buffer "traités", lire le fichier, remplir les buffers à parser et empiler ceux-ci.
->un thread (qui démarre dès qu'il y a au moins un buffer) pour parser le contenu du buffer et le taguer comme "traité" quand il est fini d'être parsé.
Ca semble cohérent ou bien je me fourvoie?
Ca me parait compliqué, mais je connais moins bien le contexte que toi.Citation:
Envoyé par JBond007
Si j'ai bien compris, la solution que tu proposes contiendra 2 threads en plus du processus principal. Et ces 2 threads devront être synchronisés, ce qui implique des sections critiques, des mutex et tout le toutim.
Il me semble (mais encore une fois, je ne connais pas le contexte) que le mieux, car le plus simple, est de faire tout dans le même thread: lecture, gestion des buffers et traitement.
Prenons un exemple simple: tu as 2 buffers. Un pour la lecture, un pour le traitement (les détails d'implémentations - copie ou swap, taille des buffers, marqueurs, etc - dépendrons des contraintes). Dans ta boucle, tu remplis ton buffer de lecture, tu le copie dans le buffer de traitement (plus grand que le buffer de lecture), et tu demandes à ton API de faire un traitement sur ce buffer. Si elle n'a pas assez de données, la fonction de traitement renvoie "false", et on repart pour une boucle de lecture/remplissage.
Tu met cette boucle dans un thread, ce qui permet au reste de ton appli de tourner sans se préoccuper de tout ça.
Au final on a qu'un thread, et aucun problème de synchronisation.
Ah ouais 8OCitation:
Envoyé par r0d
Je me complique effectivement un peu la vie. Bah c'est pas grave c'est aussi pour ça que je suis là ;).
Par contre pas possible pour moi de repartir sur une boucle de lecture/remplissage si j'ai pas assez de données. En effet, dans un graphe de scène, il se peut qu'un noeud contienne tous les autres noeuds, et qu'il commence au début du fichier et se termine à la fin de celui-ci.
Je vais réflechir un peu plus à la conception et faire par de mes avancés ET mes éventuelles questions :mrgreen:.
Ben moi j'ai toujours pas compris la problématique :?
Est-ce un problème de temps : la lecture est trop longue du coup elle bloque l'application.
Ou est-ce un problème de mémoire : les données prennent trop de place en mémoire toutes ensembles, tu cherche à travailler sur une petite partie du fichier à la fois.
Si cette situation arrive souvent, je ne vois pas comment tu peux lire autrement ton fichier qu'en une seul fois.Citation:
En effet, dans un graphe de scène, il se peut qu'un noeud contienne tous les autres noeuds, et qu'il commence au début du fichier et se termine à la fin de celui-ci.
Si ton format de fichier le permet, tu pourrais essayer d'effectuer une lecture aléatoire de ton fichier. Dans le cas où tu as la position de début et de fin de tes noeuds... mais s'il s'agit d'un format du genre xml, ça va pas être facile.
D'après ce que j'ai compris le but est de commencer à afficher une scène avec des délais des lancement aussi courts que possible sans se soucier du fait que, forcément, la scène sera incomplète pendant un temps avant d'être stabilisée, un peu comme avec les JPEG entrelacés qui gagnent en précision au fur et à mesure qu'on les télécharge.Citation:
Envoyé par Sylvain Togni
Ca me fait penser au mode de fonctionnement de Second Life ça, je me trompe?
Sinon, si le but est simplement d'éviter de charger un fichier entièrement en mémoire, les accès aléatoires dans les fichiers ça existe, de même qu'il existe des formats de description d'objets 3D qui n'en nécessitent pas.
Qu'est-ce que te fais penser que les flux de la STL montent tout le fichier en mémoire ?Citation:
Envoyé par JBond007
Perso... je suis un peu comme Sylvain... je comprends pas trop la problêmatique....
a. Découpler le traitement et la lecture ?
b. Découpler l'affichage du résultat et le traitement ?
(a): C'est déjà fait par l'OS, pas besoin de se soucier de ça, à moins de vouloir optimiser quelques ms....
(b): Je ne vois pas trop le rapport avec le streaming.... a moins que les données lues ne soient dépendantes du temps (comme la musique ou la vidéo)... sinon, comme déjà dis... on a un thread qui s'occupe de lire/préparer en mémoire les données... et un thread qui s'occupe de l'affichage...
Comme tu sembles parler de noeuds de scene-graph... tu dois utiliser un moteur graphique, et donc avoir déjà un système de resources découplé de l'affichage. Au pire il est lié au gameplay et à la physique, mais certainement pas à l'affichage...
(c) Tu parles de lire des données variables dans le temps... Dans ce cas, il y a deux modes:
- Pull : L'algo de traitement 'demande' des données au module de lecture au fur et à mesure de ses besoins. Avantage: le plus facile à programmer, Inconvéniant possibilité de retard de ces données... C'est le mode des streams....
- Push : L'algo de traitement est appelé par le module de lecture. Avantage: traitement dès que la donnée est disponible. Inconvéniant, plus difficile à programmer (avec éventuellement un systeme multi-threadé si le traitement est long).
A noter qu'il est facile de passer de l'un à l'autre....
Whoa Que de répnoses/questions. 8O
il y a aussi un problème de temps. Un fichier de 250 Mo mets environ 2mins à se charger, 1 si je le mets d'abord dans un tampon en mémoire. Cependant je peux être amener à manipuler des fichiers de 1Go, dinc la le temps de chargement devient inacceptable. D'où mon idée de "streamer" mon fichier au parser. De plus ce système (du moins je pense) me permettrait de trop consommer de mémoire en ne traitant que des "morceaux" de taille raisonnable.Citation:
Envoyé par Sylvain Togni
Il existe un bibliothèque sous JAVA qui permet de "streamer" des fichiers XML : StAx. Je pense que je peux m'inspirer du concept car la situation décrite plus haut arrive aussi avec des fichiers XML.Citation:
Envoyé par icer
Hmm pas tout à fait (arrh manque de clarté dans mes explications). Le but est d'éviter de consommer trop de mémoire et aussi d'accélérer le chargement.Citation:
Envoyé par zais_ethael
Ou a Dungeon Siege ;).Citation:
Envoyé par zais_ethael
Euh je ne connais pas la méthode des accès aléatoires dans un fichier. Quel est l'intérêt si les données dans le fichier sont ordonnées?Citation:
Envoyé par zais_ethael
Citation:
Envoyé par JolyLoic
Non pas b.Citation:
Envoyé par nicroman
On reprend l'analogie avec Second Life. Le monde est chargé en continu donc pas de temps de chargement. Dans mon cas c'est pareil sauf que je ne cherche pas à afficher ma scène tout de suite. Juste charger des fichiers de cette manière pour éviter la saturation de la mémoire.Citation:
Envoyé par nicroman
Oui.Citation:
Envoyé par nicroman
J'envisageais de concevoir ça comme l'algo Pull.Citation:
Envoyé par nicroman
Pour le cas où un des buffers de streaming ne contiendrait qu'une partie de la description d'un noeud, rajouter un contrôle marquant ce noeud comme incomplet et donc en attente de données supplémentaires ne devrait pas trop poser de problèmes. Du moins j'espère :roll:.
Bon, ça éclaircit un peu les choses.
Je crois pouvoir affirmer que les solutions à base de multithread ne te seront d'aucune utilité dans ce cas, et que même ceux qui t'en ont proposé ne me contrediront pas :)
Tout d'abord, pour corriger un point que tu as évoqué précédemment, les accès aléatoires dans un fichier consistent à déplacer le curseur de lecture. C'est l'un des premiers trucs qu'on t'apprend en C, et il est bien évidemment possible d'en faire avec ifstream. Les disques durs sont plus ou moins faits pour ça, donc on peut se permettre d'en faire dans le mesure où c'est nécessaire (les bases de données notamment en usent et en abusent).
Ensuite, ta question est extrêmement liée à ton format de données.
Par exemple, prenons le cas d'un fichier xml parsé par un parseur DOM. Le but d'un parseur DOM est de créer une arborescence en mémoire à partir d'un fichier texte. On peut considérer qu'à partir du moment où c'est du texte, les accès aléatoires sont impossible, que ce soit sur disque où en mémoire ça ne change rien. Donc comment fait-il? Et bien il se débrouille en lisant un caractère à la suite de l'autre, en stockant quelques caractères dans des buffers qui représentent des tokens et construit son graphe au fur et à mesure. Le nombre d'informations intermédiaires se réduit au maximum à quelques dizaines de caractères.
Alors, comme tu ne nous a pas expliqué en quoi consistait ton format de données je vois deux possibilité:
- c'est un format binaire qui contient en interne des adressages vers d'autres emplacements dans le fichier. La il n'y a effectivement aucun moyen d'éviter les accès aléatoires, mais mieux vaut troquer le chargement entier du fichier en mémoire par des accès aléatoires directement sur disque. La première solution peut être vaguement envisageable pour des questions d'optimisation, mais certainement pas dans le cas de fichiers de 100 Mo, alors direction la deuxième et que ça saute.
- c'est un format texte ou tout autre forme de format ne permettant/ne nécéssitant pas d'accès aléatoires. Dans ce cas je t'invite à aller consulter les cours concernant les compilateurs qui se trouvent sur developpez, c'est ce qu'il y a de plus approprié dans un cas comme celui-ci. Quand bien même ils ne seraient pas cent pour cent adaptés à ta situation ça te fera un petit lavage de cerveau gratuit qui t'aidera probablement à y voir plus clair.
Alors après, pour l'optimisation à outrance, 3 choses:
- ton OS gère un buffer sur disque, ce qui est quasiment une obligation au vu de la conception des disques dur. Malgré cela, les accès à un disque dur sont effroyablement lents par rapport à des traitements en mémoire. Alors ne va pas croire qu'un algo consistant à lire une partie d'un fichier, effectuer un traitement puis rebelotte sera plus lent qu'un qui lit tout le fichier, c'est faux. Ton traitement aussi lent soit-il prendra largement moins de temps que la lecture d'un seul octet.
- si tu arrives à éliminer le chargement entier du fichier en mémoire, ce sera déjà très bien.
- Early optimisation is the root of all evil
Ok. Bon ça va je suis sur la même longueur d'onde :D.Citation:
Envoyé par zais_ethael
On peut considérer ça comme un fichier xml voici un tout petit exemple :Citation:
Envoyé par zais_ethael
Group {
MatrixTransform {
matrix 1 0 0 0
0 0.900447 0.434966 0
0 -0.434966 0.900447 0
-1.11283 -0.558328 -4.30633 1
}
Sphere {
radius 0.315929
}
}
Il est possible pour l'utilisateur de sauvegarder le graphe de scene soit en binaire (moins de place sur le disque mais pas lisible) soit en ascii (plus volumineux mais directement éditable dans notepad par exemple).Citation:
Envoyé par zais_ethael
Donc je gère les deux types de formats.
C'est gentil de me prescrire une petite lobotomie :mrgreen:Citation:
Envoyé par zais_ethael
Ha ben la je peux te le confirmer -> direction les cours de compilateur.Citation:
Envoyé par JBond007
La plupart sont listés ici ou dans la partie Algo. Moi j'avais bien aimé celui la, il explique bien les compilateurs descendants hard-codés.
Et oui c'est dur d'apprendre la compilation. Mais dis toi bien qu'optimiser tes accès disque ne t'apportera pas le millième de bénéfice que ce que pourrait te faire gagner l'utilisation d'algorithmes reconnus qui minimisent les complexités spatiale et temporelle.
Pas de soucis, ces cours sont intéressants mais pas vraiment en rapport avec ce que je veux faire. Le but premier de ma démarche n'est pas d'accélérer le chargement (même si c'est un plus ;)) mais de charger des fichiers de tailles conséquentes sans saturer la mémoire. La partie analyse des données de l'existant est suffisamment robuste et efficace pour que je ne revienne pas dessus.Citation:
Envoyé par zais_ethael
Tssss.
La plupart des compilateurs sont conçus pour ne jamais manipuler plus de deux tokens à la fois, c'est à dire pas plus de quelques octets.
Pourquoi crois tu que je te dirige vers ces cours? Si tu es obligé de charger entièrement un fichier en mémoire il y a de toute évidence un problème de conception (même si je vois vraiment très difficilement ce que ça peut être avec un fichier texte). Si il y a un problème de conception il faut revoir l'algorithme à utiliser, même si ça ne te plait pas.
Et oui, ces cours ne pourraient pas être plus en rapport avec ce que tu veux faire. Lecture de fichier texte == au minimum lexer+parser, c'est aussi simple que ça.
Oui c'est très simple mais ce n'est pas mon problème. Lexer + parser c'est fait. Il me semblait avoir été clair la dessus. De plus je ne manipule pas que des fichiers ASCII, mais aussi des fichiers binaires...Citation:
Envoyé par zais_ethael
De toute façon j'approche d'une solution tout à fait convenable pour ce que je veux faire. Je posterai ça bientôt.
Ben dans ce cas, je me demande vraiment comment tu as implémenté ton lexer. Le barème est simplement de lire caractère par caractère, je ne vois pas où il est nécessaire de charger tout le fichier...
Pas trop le temps de balancer l'implémentation du lexer, par contre la lecture se fait bien caractère par caractère quand le fichier n'est pas bufferisé (j'ai implémenté la possibilité de ne pas bufferiser). Mais bon en terme de perf c'est pas la joie.Citation:
Envoyé par zais_ethael
Ca m'étonnerait vraiment que ce soit si lent que ça. Le buffer du système est largement suffisant pour optimiser les accès disques, surtout lors de lectures du début à la fin.
Tu as fait un benchmark?
Yep j'ai benchmarké. Et pour un fichier ASCII (pour du binaire le gain est négligeable) de 273 Mo sans bufferisation 2'04" et avec bufferisation 59". Deux fois moins de temps, je prends.
Bon bah ça y est j'ai mon pseudo streaming qui fonctionne :yaisse2:.
Maintenant il ne me reste plus qu'à ajouter des contrôles lorsqu'un buffer ne contient que des données partielles (ça sera mon morceau de bravoure :D).
En tout cas merci à tous ceux qui ont pris le temps de m'aider.
Si ça intéresse certains je posterai mon code.
Bref merci encore :merci:.
Je marque ce topic comme résolu.