Bonjour tout le monde !

Contexte (simplifié) :
J'ai quatre fichiers, 4 coeurs (donc 4 threads disponibles).

Objectif : Lire le plus vite possible les 4 fichiers.

Solution 1 :
Chaque core s'occupe d'un fichier.

Premiere conclusion et question ouverte : Mouais 4 threads ok mais il n'y a toujours qu'un seul disque dur alors ça doit revenir à la même que lire les fichiers un à un avec un seul core.... Est-ce que ça revient à la même chose ?

Situation 2 :
On complexifie un peu la situation. On suppose que les 4 fichiers peuvent être sur plusieurs disques durs en fait.

Solution 2 :
On regarde la racine des filepath et on attribue à chaque thread un disque dur et non un fichier.

Exemple:
2 fichiers sur C:, 1 fichier sur E et un sur G:

Thread 1 va lire F1, puis F2
Pendant que Thread 2 va lire F3
Pendant que Thread 3 va lire F4
Pendant que Thread 4 se la touche.

Conclusion finale et question ouverte : On devrait gagner du temps. Oui ou non ?

Simple curiosité, pourquoi tu veux faire ça?
C'est pas pour me moquer j'aimerai juste connaître le contexte.

Ben je ne vois pas trop ou je te lancerais des perches pour te moquer de moi en repondant a cette question de toute facon.

Le contexte est la lecture de gros fichiers de donnees (dans les 40-60 Mo) qui doivent ensuite etre merges dans un tableau de int. Le merging se fera aussi en parallele (quitte a lire en parallele autant merger en parallele aussi !

Alors juste pour info c'est bien ce que je pensais.

La parallelisation de lecture de fichiers sur un seul disque c'est mortel, le disque est mécanique ça va plus empirer les choses qu'autre chose (mais ça on s'en aperçoit vite quand on essaye par exemple de copier-coller en même temps deux gros dossiers à deux endroits différents sur un même disque dur au même moment).

Sinon d'après les experts, lire des fichiers en parallèle s'ils sont sur des disques différents devrait "en théorie" au pire des cas ramener au cas séquentiel. Donc mon intuition et ma bonne solution étaient pas loin du compte finalement.

Si j'avais lu ça plus vite j'aurai pu t'épargner le test. Toutes les grosses bases de données permettent d'éclater une base en plusieurs groupes de fichiers ayant des chemins différents et de choisir quelles table(s) y mettre. Le but c'est de pouvoir répartir le tout sur des disques physiques différente.

Les gains de performance en cas de jointure de 2 tables sur 2 disques différents sont généralement significatifs, de même que les accès aux groupes en concurrence de façon générale.

Impossible à appliquer dans mon cas présent. J'ai des contraintes physiques à appliquer qui font que les fichiers resources doivent être sur l'ordinateur. Et j'ai de hautes contraintes de performance, or j'imagine qu'accéder à une bdd distante sera toujours plus long qu'accéder à son disque dur non ?

Je prenais juste l'exemple des SGBDR, càd des programmes extrêmement optimisés qui font à la base de la lecture sur disque. Ceci pour confirmer ta théorie sur les lectures parallèles plus rapides sur des disques différents, pour te dire que c'était sûr, certain et exploité.

Ok cool

Peut-être que je pourrai même aller encore plus loin dans l'optimisation si les fichiers étaient toujours dupliqués sur plusieurs disques dure et que je lisais partiellement un fichier sur plusieurs disques dur en même temps !

Il ne faut pas réinventer le Raid 3. Des solutions matérielles existent pour ceci et en plus, faut voir ce que ça apporte réellement à ton application. Faut pas oublier que les gros disques qu'on trouve de nos jours sont déjà pas mal performants sur la lecture d'un fichier (du moins si celui-ci est bien contigu) grâce aux larges caches notamment.

Sur des fichiers de 40mo comme tu cites, ça fera pas des miracles de les splittés en 12.

Oui justement je comptais "imiter le Raid 3".

Ce fera pas de miracles ? Si tu es en Raid 3 ça n'en fera pas, mais si tu as des disques durs plus conventionnels tu peux prévoir avoir un gain plus au moins proportionnel de toute façon j'imagine.

Quand tu lis depuis un disque unique, les donnees qui transite entre le disque et la memoire passent par 3 bottleneck different. La lecture physique du disque vers la memoire du controlleur du disque. Le bus sata entre le disque et le controlleur. Puis le bus entre le controlleur et la ram. Typiquement le bottleneck le plus mechant est la lecture physique du disque (je dis typiquement, parcequ'avec certain disque SSD, on s'apercoit que le controlleur sata peut devenir le bottleneck).

Ce bottleneck de la lecture du disque est souvent directement optimise par le controlleur du disque et/ou le systeme d'exploitation. Fait attention a la taille du buffer que tu lis quand tu fais tes appels system a read(2), si c'est trop petit tu peux ne pas saturer le bus de lecture du disque. Tu peux aussi utiliser des IO asynchrones pour que le noyau ait toutes l'information de lecture, mais peut etre il va s'emmeler les pinceaux si tu fais ca. N'utilises ca que si tu n'arrives pas a un debit proche du debit physique theorique maximal.

Quand tu utilises plusieurs threads, tu te retrouve a devoir partitioner ton espace de lecture et probablement tes access ne sont plus sequentiel. C'est catastrophique pour les disques dur mecaniques. C'est ce que l'on appelle le disk trashing. Note que si ton disque dur est SSD, la difference de perf entre access sequentiel et access aleatoire n'est pas tres differente.

Quand on augmente le nombre de disque dur, les experiences des gens de HPCs montrent qu'il faut soit utilise un thread par disque ou un thread par controlleur. En effet, si tu as 20 disques brancher sur un seul controlleur, avoir 20 thread qui lisent va faire trop d'access au controlleur et tu va trasher le controlleur.

Note que pour lire plusieurs fichier simultanement depuis plusieurs disques, tu n'as pas forcement besoin de plusieurs threads. tu peux faire des IO asynchrones a raison de une par disque ou encore utiliser select(2).

Sinon, tu parlais de faire du multi threading, donc j'imagine que tu as des ressources CPU a jetter par la fenetre. Tu as envisage la compression?

Hum merci pour tes explications godrik ca rejoint tout ce que j'avais appris jusque la, mais je pense que maintenant il faut que je fasse des tests grandeurs natures pour en savoir un peu plus.

La compression des fichiers? Qui dit compression dit decompression aussi non ?

Tout a fait, mais si le bottleneck est sur le disque et que tu as plein de coeurs a jetter par la fenetre comme sur les machines modernes, ca peut etre bien mieux. Apres ca depend de ce que tu compresses, mais j'ai des exemples ou je decompresse des matrices dans un format ASCII et comme les matrices sont grosses, elles sont stocker sur un NFS. Bah ca va vachement plus vite de les decompresser localement (avec un seul thread de decompression) que de les lire pre-decompresse.
Il faut voir quel est la vitesse de ton disque, quel est le ratio de compression et combien de temps tu vas passer a decompresser (sachant que c'est une operation tres parallele).

Je connais pas bien NFS mais généralement le stockage réseau sur du 100mbits, sauf dans le segment haut de gamme ou entreprise c'est assez mou non? Normalement moins que SMB mais assez faible non?

Incomparable sans doute avec un débit de 100mo/sec sur un disque local.

Je parlais du taux de transfert, si c'était pas clair.

Intéressant. En l'occurrence je fais de la lecture audio il faut que je me renseigne sur la décompression et aussi penser à cette opti.

Le NFS est monte a travers une interface infiniband DDR ce qui nous donne un debit de 800MB/s sur des gros transfert. Et le NFS a un cache enorme (48GB) ce qui fait qu'en pratique tu lis depuis la RAM du NFS et pas depuis un disque. Je viens de faire des test avec un fichier de 1GB par tranche de 1MB, la premiere lecture est pas super (entre 85MB/s et 150MB/s, le NFS stocke sur RAID) mais les lectures suivantes font du 350MB/s (en changeant de machine a chaque fois pour eviter le cache du client).

Et perso en local, j'ai jamais fait 100MB/s plutot 60MB/s dans les bon jours.

finalement:

"généralement le stockage réseau sur du 100mbits"
ca existe encore ethernet 100mbit/s ? je pensais que tout le monde faisait du gigabit depuis longtemps!

D'après mes petites recherches le format de compression audio sans perte le plus adapté serait le wavpack :

http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison

Ici dans cette table c'est celui qui remporte en terme de vitesse en tout cas (et le tableau précise qu'ici on est au maximum de la compression donc on peut toujours gagner en perf d'un côté ou de l'autre) : http://www.lossless-audio.com/comparison.htm

Les deux seuls positifs etant :
- ape +5,4%
- wavpack +8,4% (winner!)

En mono-thread dans un système audio c'est tout de même suicidaire a priori si on doit rendre plus d'une piste en même temps, la carte son aura déjà killé le callback avant d'avoir rendu la deuxième piste.

Si on part sur un système de 4-core minimum (ce qui est la tendance de base en config audio) et en esperant que la compression est découpable (ce que je n'aie pas encore vérifié) on peut espérer atteindre une vitesse de décompression de l'ordre de +333%. Là c'est peut-être envisageable par contre.

Hey je vous dis n'importe quoi moi (il est temps que je couche).

Je sais pas ce qui m'a pris de croire que le temps à droite dectime était le temps original du fichier -_____-.

Ce serait le flac qui remporte alors, avec grosso modo un facteur 10. Intéressant... si on divise ça sur au moins deux threads ça fait archi mal. On gagne 58% du temps de lecture de l'autre côté, la différence avec solution sans compression doit donc être positive à première vue.