IO opérations sur ndArray

**ToTo13** · 27/04/2016, 00h02

Bonjour,

je travaille sur une GRANDe quantité de volumes. Pour être précis, j'ai 2 000 000 de volumes, de dimensions 19 x 19 x19. J'ai donc potentiellement à travailler avec un NumPy nbarray de dimensions [2 000 000, 1, 19, 19, 19] (le 1 étant pour le nombre de couleurs, car ces volumes sont en fait des portions d'images 3D).

Actuellement, pour récupérer les informations afin de remplir un tel tableau, j'ai 2 000 000 de dossiers, chacun contenant 19 images de taille 19 x 19.
Or pour pouvoir charger ces images et ainsi commencer à faire le vrai boulot, cela prend plusieurs heures (presque une journée me semble t-il) et je trouve cela trop long. D'autant plus, que je lance beaucoup de script et que chaque script doit faire ce même travaille de lecture chargement.

Ma question est donc : est ce qu'il existe un moyen en python de sauver toutes mes images (dans un format différent) afin qu'elles puissent être lues beaucoup plus rapidement ?

Merci par avance...

PS : petite/grosse précision... il arrive que je n'ai besoin QUE de 500 000 volumes. Donc j'aimerai ne pas avoir à charger les 2 000 000 volumes pour n'en garder qu'un quart à la fin.

**wiztricks** · 27/04/2016, 07h40

Salut,

Envoyé par ToTo13

Ma question est donc : est ce qu'il existe un moyen en python de sauver toutes mes images (dans un format différent) afin qu'elles puissent être lues beaucoup plus rapidement ?

Si une telle chose existait, ce serait plutôt une bibliothèque C accessible au programmeur Python via un wrapper.
Pour le reste, la vitesse de la mémoire étant 1000 X plus rapide que celle des disques, on pourra paralléliser avec des threads mais çà restera "IO bound": pour améliorer le temps de chargement, il faudra ajouter (plein) des disques (pour distribuer les IO tout en s'assurant qu'on ne sature pas la mémoire, les bus d'entrée-sortie,...).
note: on peut dire aussi qu'en liisant 13 images de 13x13, on a un overhead d'opérations côté file system qu'on pourra réduire en mettant les 13 images dans un seul fichier mais il faut s'assurer des capacités physiques pour supporter la charge avant de modifier la structure sur disque.

- W

**ToTo13** · 27/04/2016, 09h23

Merci pour la réponse !

Envoyé par wiztricks

note: on peut dire aussi qu'en liisant 13 images de 13x13, on a un overhead d'opérations côté file system qu'on pourra réduire en mettant les 13 images dans un seul fichier mais il faut s'assurer des capacités physiques pour supporter la charge

Comment est ce que cela fonctionnerait ?

Je travaille sur un cluster, tout est assez solide !

Envoyé par wiztricks

avant de modifier la structure sur disque.

Que faudrait il que je fasse exactement ?

**shell13010** · 27/04/2016, 09h46

Bonjour,

Un système de sprite serait plutôt intéressant dans ce cas précis pour gagner en rapidité et limité le nombre d'opération.

étant donner que tout les images ont les même dimensions, j'aurais regrouper x nombre d'image dans une image, sauvegarder la position des images

dans un fichier index pour pouvoir appeler les images que j'ai besoin suivant leur positions dans l'image principal.

Sa limiterais considérablement le nombre d'opération.

un exemple pour générer des sprite avec PIL.

**ToTo13** · 27/04/2016, 10h03

Merci pour la réponse.
Ta solution est en fait de regrouper les images en une grosse image, afin d'avoir à lire un gros fichier plutôt que plusieurs petits.

**shell13010** · 27/04/2016, 10h47

Envoyé par ToTo13

Merci pour la réponse.
Ta solution est en fait de regrouper les images en une grosse image, afin d'avoir à lire un gros fichier plutôt que plusieurs petits.

Oui exactement,

actuellement de tête, je peux me tromper il a 38 000 000 d'images, alors que si les 19 images d'un dossier regrouper en 1 image le résultat serait de 2 000 000.

Comme ce sont des petites images 19x19 , on pourrait largement regrouper plus d'images pour réduire le nombre d'opération sur fichier.

L'image sera charger qu'une fois en mémoire au lieu de n fois donc le gain de rapidité sera plus importante et le traitement des données moins lourd.

A la base, le système de sprite et beaucoup utiliser en CSS pour limiter le nombre de requête/bande passante.

le rendu peut-être dans ce style ou a la verticale 19px de Large et x en Hauteur, ou a l'horizontal 19px de Hauteur et x de Largeur.

**ToTo13** · 27/04/2016, 11h19

Sur la même idée, n'ai je pas intérêt à utiliser des Pickle/cPickle ?
L'inconvénient majeur serait que je doive lire la totalité du fichier, mais comme c'est "une même string", cela devrait être vraiment plus rapide. Non ?
Si oui, le fait que je perde du temps à lire trop d'information, devrait être compensé par le fait que ça aille beaucoup plus vite.

**wiztricks** · 27/04/2016, 12h31

Envoyé par ToTo13

Sur la même idée, n'ai je pas intérêt à utiliser des Pickle/cPickle ?
L'inconvénient majeur serait que je doive lire la totalité du fichier, mais comme c'est "une même string", cela devrait être vraiment plus rapide. Non ?
Si oui, le fait que je perde du temps à lire trop d'information, devrait être compensé par le fait que ça aille beaucoup plus vite.

L'avantage d'avoir des fichiers plus gros est de profiter d'optimisations matérielles qui favorisent les opérations séquentielles (on réduit les déplacements des têtes). Mais comme pour booster les IO vous avez intérêt à utiliser des disques SSD, il n'y a plus de têtes à déplacer. (Les overheads dus aux petits fichiers sont liées aux accès au file system mais il faut tester car, ils montent pas mal d'informations dans les caches).
Dans un premier temps, il faut augmenter la bande passante disques (en repartissant les IO sur N disques).
Les autres "optimisations" seront à voir lorsque vous aurez un code suffisamment parallélisé pour profiter des N disques.
note: si vous lisez un gros fichier pour en jeter la moitié, vous aurez gaspillé la moitié de votre bande passante disque pour rien (et c'est à priori le goulot d'étranglement).

- W
PS: de toutes façons, il faut arriver à estimer les capacités et combien vous en utilisez. Vous n'irez pas dans la même direction si vous utilisez 80% de la capacité disponible que si vous n'en utilisez que 10 à 20%. Il faut aussi connaître les possibilités que vous avez pour augmenter les capacités: comme on est dans le physique, tout n'est pas possible (économiquement parlant).

Envoyé par ToTo13

Sur la même idée, n'ai je pas intérêt à utiliser des Pickle/cPickle ?

Si c'est pour récupérer 19 images de taille fixe dans un même fichier, c'est juste découper un bytearray si possible avec des memoryview (pour éviter les copies). Par sur que pickle apporte grand chose côté utilisation des ressources mais çà se teste.

**ToTo13** · 27/04/2016, 19h13

Merci !

**YCL-1** · 27/04/2016, 20h43

Bonjour,

concernant Numpy vous ne gagnerez pas plus sur le temps de parsing de ces fichiers.

numpy.loadtxt: Load data from a text file
numpy.genfromtxt: Load data from a text file, with missing values handled as specified (plus lent mais beaucoup plus souple)

Pour la seconde méthode voici une comparaison de performance que j'avais effectué entre la méthode csv.reader + float() et numpy.genfromtxt + dtype=np.float64. Je peux vous fournir le code du test si besoin.

Le gain se fera sur les opérations, si vous en faites, et sur la gestion de la mémoire.

Mais si vous ne comptez pas manipuler ces matrices par opérations mathématiques ni par indexation mais simplement en tant que données alors les structures ctypes peuvent faire l'affaire.

Si je comprends bien chaque portion est un fichier ?

Même avec une grappe de disque dur ou un SSD le goulot d'étranglement restera au niveau du temps d'accès des fichiers et non à la vitesse de lecture de ceux-ci.

Au vu du faible poids par fichier l'idée de shell13010 de faire un sprite/regroupement reste la meilleur solution.

Reste qu'il faut pouvoir les regrouper, les regrouper efficacement, s'il y a une logique/arborescence/lien entre eux pour faciliter l'accès.

En les regroupant par exemple par moment d'accès si le chargement se fait toujours dans le même ordre pour un ensemble/groupe.
ou par fréquence de modification s'il y a lieu d'être

Ceci afin de réduire le nombre d'open/flush/close

Et il y a la question du format, tous ne se valent pas pour faciliter l'accès aléatoire à une portion d'image.
Ça dépend de comment sont agencées les données, s'il est possible d'extraire une portion d'une image sans lire/décoder tout le contenu au préalable, exit donc les compressions JPEG et même PNG, le format brut bitmap lui le permet par exemple.

Mais plus généralement l’optimisation de l'accès à ces données peut être faite sous d'autres formes :

1) En base de données
L'idée serait de créer un seul fichier unique, texte voire binaire si on souhaite gagner en place de stockage et en vitesse de parsing de ces données.
Quand je parle de base de données cela peut être un simple fichier type XML ou JSON et si l'accès est récurant et aléatoire on peut partir sur du SQL avec par exemple sqlite3, sur ce dernier je n'y connais pas grand chose.

2) Ou pour garder la main sur les fichiers il y a aussi l'idée d'un simple archivage, un seul fichier d'archive compressé ou non contenant l'ensemble des fichiers avec l'arborescence d'origine.
L'avantage est qu'il suffit de charger l'en-tête/table d'allocation des fichiers et si on souhaite gagner en temps d'accès on peut mapper tout le fichier en RAM.

Il reste à trouver le format qui corresponde le mieux au besoin d'accès.

Pour avoir regardé par exemple le format d'archive TAR, disponible nativement avec le module tarfile
L’inconvénient est qu'il ne permet pas d'accéder aléatoirement à des fichiers: TAR - Random access
Il ne dispose pas d'index centralisé, il faut donc parcourir l'intégralité du contenu pour en connaître les secteurs.

Il vaut donc mieux partir sur le format d'archivage ZIP qui lui dispose d'un index centralité en en-tête.
Le même principe est utilisé pour le format Office Open XML des fichiers Office de microsoft (docx, xlsx...)

Bref il y a beaucoup de possibilités pour s'affranchir au maximum des limitations I/O, le plus difficile est de trouver la bonne techno viable.

Votre retour d'expérience m’intéressera.

Bon courage.

**ToTo13** · 27/04/2016, 20h47

Merci pour la réponse !!!
Je vais étudier tout cela.

IO opérations sur ndArray

Python

Discussions similaires

Partager

Partager