Discussion :

[poukill]

A priori (donc je peux dire une c..rie), il y a peut être un 'bouchon' possible sur l'accès disque si les 8 threads tentent de lire/ecrire en même temps. Cet accès concurrent peut être un noeud d'étranglement qui minimise tes gains de passage en multithread. Cela dépend probablement du ratio temps d'accès au disque vs durée des calculs.

C'est sur...
Il n'y a qu'un bus connecté au disque dur. Alors 2 ou n threads ne vont pas accélérer la lecture ou l'écriture... Mais le partager !

[white_tentacle]

Vu la très faible complexité du calcul à effectuer, je ne suis pas sûr qu'il y ait un gain à le passer en multithread (ça risque même d'être pire). Les i/o me semblent le facteur limitant, et le coût de parallélisation risque d'être supérieur au coût du calcul lui-même.

Personnellement, je ferais confiance aux flux C++ pour la mise en cache de la lecture, je ferais un test monothread (ça doit se coder assez rapidement) en faisant les calculs au fil de l'eau, en lisant les 8 fichiers en même temps, et ensuite je profilerai ça si jamais il s'avère que les perfs ne sont pas bonnes. En fonction des résultats du profilage, tu pourras aviser sur les axes d'amélioration (si 80% de ton temps sont des i/o, inutile de chercher à paralléliser).

Sinon, en général on lit ligne par ligne en prenant comme séparateur ',' ou ';', mais c'est vrai que je ne sais pas ce qu'il se passe si '\n' est contenu dans une ligne, même entre guillemets.

Tous les codes que j'ai vus faits comme ça ne gèrent pas correctement ce cas. D'un autre côté, si tu n'en as pas besoin . Mais bon, il ne faut pas oublier que getline fait de toute manière une lecture caractère par caractère derrière, donc niveau perfs ça ne doit pas changer énormément.

[3DArchi]

Personnellement, je ferais confiance aux flux C++ pour la mise en cache de la lecture

Est-ce que l'idée de Joel de passer par un mapping mémoire ne serait pas meilleur ? J'ai rarement entendu dire du bien sur les performances des flux (mais c'est peut être un malheureux 'on-dit').

[white_tentacle]

Est-ce que l'idée de Joel de passer par un mapping mémoire ne serait pas meilleur ? J'ai rarement entendu dire du bien sur les performances des flux (mais c'est peut être un malheureux 'on-dit').

Probablement, je ne saurais pas trop dire. Mais il me semble qu'un des problème de l'op, c'était justement que le fichier ne tenait pas en mémoire (du moins, en prendrait trop à son goût). Et comme il ne fait que lire le fichier dans l'ordre, le gain ne me semble pas évident...

Mon propos, c'est aussi de dire que j'ai l'impression qu'il se pose des objectifs largement supérieurs à son besoin réel, et qu'il devrait d'abord tester une solution simple mais non optimale, et ensuite l'instrumenter pour voir les points à améliorer (s'il y a besoin).

[nikko34]

mais comme il ne veut pas tester...

[poukill]

Mon propos, c'est aussi de dire que j'ai l'impression qu'il se pose des objectifs largement supérieurs à son besoin réel, et qu'il devrait d'abord tester une solution simple mais non optimale, et ensuite l'instrumenter pour voir les points à améliorer (s'il y a besoin).

C'est en général très souvent une bonne idée !

[Joel F]

Probablement, je ne saurais pas trop dire. Mais il me semble qu'un des problème de l'op, c'était justement que le fichier ne tenait pas en mémoire (du moins, en prendrait trop à son goût). Et comme il ne fait que lire le fichier dans l'ordre, le gain ne me semble pas évident...

Dans mes souvenirs, pour un mmap, le fichier n'est pas EN ENTIER dans la mémoire d'un block. Il reste paginée, etc...

[Jean-Marc.Bourguet]

Dans mes souvenirs, pour un mmap, le fichier n'est pas EN ENTIER dans la mémoire d'un block. Il reste paginée, etc...

Et si le problème est celui de l'espace d'adressage, on peut ne pas mapper tout le fichier.

L'avantage du mmap par rapport à read, c'est que la destination va être correctement alignée pour éviter des copies. En gros avec read on a
- lecture du périphérique vers des tampons internes
- copie de ces tampons vers l'espace mémoire utilisateur
mmap permet d'éviter la deuxième étape, le tampon interne peut être mappé directement en mémoire. Ça ne m'étonnerait pas que certains OS optimise les read en mappant directement les tampons en mémoire si la destination a une taille et un alignement convenable, mais même alors ça doit coûter plus qu'un mmap (pour commencer avec mmap l'écriture a la sémantique désirée, avec un read il faut faire du copy on write si on veut conserver le tampon ou alors agir pour éviter qu'il soit utilisé par un autre process ou le même).