C, strings, calloc et MPI

[invite6ed3677d]

Bonjour,

J'ai une petite question de C qui me turlupine ...

Voila le problème :
j'ai un fichier ascii qui contient une chaine de caractères sur chaque ligne.
Je veux lire le fichier, enregistrer les chaines, compter combien il y en a et les répartir sur plusieurs noeuds avec MPI (il y a un gros traitement à faire par la suite).
Evidemment, je ne connais pas le nombre de ligne (qui peut être assez grand).

En fait, j'ai une solution mais elle me parait assez moche et possiblement couteuse en mémoire et CPU :

je définie un char **, je fixe une taille limite de char par ligne (disons 256) avec un #define et je pose un nombre de lignes par defaut. Je lis le fichier ligne par ligne et lorsque je dépasse mon nombre de ligne par defaut, je realloue le double de lignes (je perds en mémoire mais je m'y retrouve en CPU).

Je me retrouve donc avec un gros tableau 2D dont la fin est vide. J'ai maintenant le nombre de ligne et mon nombre de procs donc je répartir tout ca equitablement : je découpe mon tableau de N lignes en P tableaux de M lignes (P est le nombre de proc et M*P = N (je me suis débrouillé avec la divisibilité)). J'envoie la valeur de M à tous les procs (MPI_Bcast) puis son tableau de taille M à chacun (MPI_Send). Je le récupère avec MPI_Recv.

Le soucis, c'est que je recois un tableau 1D (puisque j'ai envoyé 256*M char à partir de l'adresse du premier élément).
Ce qui fait que je dois recopier mon tableau 1D recu dans un tableau 2D ...

Bon, ca marche mais c'est moche ...
Alors y a t'il un moyen plus malin ?
-----

[invite4ad25ccf]

J'ai du mal à comprendre la problèmatique, qui aiderait à trouver une méthode plus jolie (ou pas )
Si tu pars sur du MPI, c'est qu'a priori, les temps d'accès sont négligeable devant le traitement d'une seule ligne. Pourquoi ne pas faire un truc du genre Lire une ligne et l'envoyer, passer à la suivante et l'envoyer ailleurs. Faire un thread qui recoit les contribution et les réordonne si besoin (liste chainée par exemple), et les écrit dès que possible.

Ex avec un fichier de 5 lignes et 3 proc avec désynchronisation des résultat (en partant du principe que l'ordre compte) :
- lire ligne 1 -> proc 1
- lire ligne 2 -> proc 2
- lire ligne 3 -> proc 3
- lire ligne 4 -> attendre libération d'un proc -> proc 2
- lire ligne 5 -> attendre libération d'un proc -> proc 3

- Ecoute de resultat
- reception traitement ligne 2 -> creation d'une liste chainée (2)
- reception traitement ligne 3 -> ajout de 3 à la liste chainée ordonée (2)->(3)
- reception traitement ligne 5 -> ajout de 5 à la liste chainée ordonée (2) -> (3) -> (5)
- reception traitement ligne 1
- 1 est le plus petit numéro de ligne attendu, écrire les lignes 1,2,3 de la liste chainée
....


Si tu trouves qu'une ligne est trop couteux, passe à X lignes. Pas besoin que cela soit un multiple de P, le dernier proco recevra dans ce cas moins de lignes.

Cette méthode présente aussi l'avantage de pouvoir interrompre le traitement et de reprendre les segment non finalisé (contrairement à balancer tout un gros tableau de lignes).

bon j'espere avoir bien compris la problèmatique et pas avoir dit trop de bétises (vu mon état de fatigue, cela ne m'étonnerais pas que je sois completement HS )

[invite6ed3677d]

Bonjour,

Si tu pars sur du MPI, c'est qu'a priori, les temps d'accès sont négligeable devant le traitement d'une seule ligne.

ah oui ! le traitement d'une ligne c'est une dizaine d'heures !

Pourquoi ne pas faire un truc du genre Lire une ligne et l'envoyer, passer à la suivante et l'envoyer ailleurs. Faire un thread qui recoit les contribution et les réordonne si besoin (liste chainée par exemple), et les écrit dès que possible.

Oui, j'y ai pensé mais j'ai l'impression (pas fait de tests) que ca va être très long en communications, vu qu'il y a pas mal de lignes (de l'ordre de 100 à 1000).
Je vais voir si. en envoyant plusieurs lignes d'un coup, ca va plus vite ...

Merci de la réponse

[invite4ad25ccf]

Je dirais que ca ne sera pas beaucoup plus long :
Grosso modo tu as qqch dans ce genre la
- temps de traitement d'une ligne = temps d'acces au périphérique de stockage (<< 1s) + temps de lecture (X) + temps d'envoi de la ligne (Y) + temps de traitement (10h) + temps d'cces a périphérique pour écriture (<<1s) + temps réception résultat d'une ligne (Z) + temps d'écriture du résultat (T) = 1s + X + Y + 10h + 1s + Z + T

- temps de traitement pour 1000 lignes = temps d'acces au périphérique de stockage (<< 1s) + temps de lecture (1000*X) + temps d'envoi de la ligne (1000*Y) + temps de traitement (1000*10h) + temps d'cces a périphérique pour écriture (<<1s) + temps réception résultat d'une ligne (1000*Z) + temps d'écriture du résultat (1000*T) = 1s + 1000X + 1000Y + 1000*10h + 1s + 1000*Z + 1000*T.

Tu remarque donc que ton temps d'acces ne bouge pas, tout le reste progresse linéairement (dans un monde parfait, mais ca ne va pas jouer énormément). La ou ca devient interressant d'envoyer de grosses unité de traitement, c'est quand :
- temps d'acces non négligeable sur le temps de traitement
- possibilité de travailler en mode déconnecter du réseau.

L'avantage de découper en unité fine, c'est comme je le disais de pouvoir récupérer les lignes non traitée, de mettre en pause le traitement etc.

Pour moi, un traitement de 10h unité (donc 1 unité = 1 ligne) me parait correct, cela permet justement de ne perdre que 10h de calcul si une unité disparait (client qui plante, arret du programme pour fausse manip', ...)

[A voir en vidéo sur Futura]

[invite6ed3677d]

Je dirais que ca ne sera pas beaucoup plus long :
Grosso modo tu as qqch dans ce genre la
- temps de traitement d'une ligne = temps d'acces au périphérique de stockage (<< 1s) + temps de lecture (X) + temps d'envoi de la ligne (Y) + temps de traitement (10h) + temps d'cces a périphérique pour écriture (<<1s) + temps réception résultat d'une ligne (Z) + temps d'écriture du résultat (T) = 1s + X + Y + 10h + 1s + Z + T

Oui, j'ai réalisé ca ... j'ai changé le code et c'est quand même beaucoup plus lisible !

Pour moi, un traitement de 10h unité (donc 1 unité = 1 ligne) me parait correct, cela permet justement de ne perdre que 10h de calcul si une unité disparait (client qui plante, arret du programme pour fausse manip', ...)

Ah non ! pas de plantage !!!!! (j'ai la chance d'avoir un cluster qui marche bien).

Merci beaucoup pour tes conseils.
On verra le premier resultat d'ici une semaine ou deux !

[invite4ad25ccf]

Ah non ! pas de plantage !!!!! (j'ai la chance d'avoir un cluster qui marche bien).

Bah on va dire que moi aussi j'étais persuadé de cela. Et puis un jour, paf, déconnexion réseau d'un des noeuds. La panne : un technicien avait besoin d'un cable et comme le voyant du commutateur était éteind, il a pris celui la. Il c'est avéré plus tard que la diode d'état du port du commutateur était déffectueuse. Heureusement qu'on bossait par "petites" unité de 2j de calculs, ca aurait pu faire tres tres mal :s