Discussion :

[siempre]

Bonjour,
J'ai une demande et j'ai besoin de vos aides. En réalité, J'ai fichier XML "input.xml" de taille volumineux. Pour lire ce fichier, j'ai utilisé la fonction 'lire_fichier(nom de fichier)'.
Dans mon cas, je dois décomposer ce fichier xml en plusieurs fichiers XML selon des critères bien définis.
Supposons que N est le nombre de ces fichiers décomposés.

Je vais faire le même traitement X pour chacun de ces N fichiers

Voici une partie de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
for(i=1;i <= N;i++)
{
 
 sprintf(tmp,"input%d",i);
 lire_fichier(tmp);
 //le même traitement  X
..........
............
}

J'ai testé ce code sur ma machine alors ceci prendre beaucoup de temps.

Mon but est d'avoir le temps d'exécution le moins possible.

Est ce que c'est possible d'avoir un temps plus longue si on a travaille sur les N fichiers au lieu de travailler sur un seul fichier ou bien ceci dépend d'autres facteurs?

Dans mon cas, est ce que le mécanisme de parallélisme est possible ? c'est à dire on exécute chaque traitement sur une machine portant un fichier et donc on va utiliser N machines ?
C'est à dire on lance le traitement en même temps. Mais, ceci garantie que on va obtenir le résultat en un temps le moins possible ?

Que proposez vous ?

Merci.

[Mac LAK]

J'ai testé ce code sur ma machine alors ceci prendre beaucoup de temps.

Mon but est d'avoir le temps d'exécution le moins possible.

Au cas où : pense quand même à vérifier que des outils XML adaptés (XSL, librairies-parser, génération de code, etc.) ne te simplifieraient pas la vie, dans le cas où tu n'aurais que l'obligation de résultat et non pas l'obligation de moyens.

Est ce que c'est possible d'avoir un temps plus longue si on a travaille sur les N fichiers au lieu de travailler sur un seul fichier ou bien ceci dépend d'autres facteurs?

Cela dépend d'autres facteurs : typiquement, le disque dur est une ressource critique (=accessible par un seul élément à la fois), donc avoir 10 threads qui tapent dedans allègrement est plus pénalisant qu'autre chose en général : tu perds beaucoup de temps via le temps d'accès du disque...
Dans ton cas, il faudrait un thread lisant les fichiers, mis en cache en mémoire, et distribuant ensuite le boulot à des threads qui n'auraient alors plus besoin d'accéder au disque dur. Ils pourraient alors bénéficier correctement des cœurs multiples disponibles.

Dans mon cas, est ce que le mécanisme de parallélisme est possible ? c'est à dire on exécute chaque traitement sur une machine portant un fichier et donc on va utiliser N machines ?

Tu peux découper ça avec un traitement par cœur de CPU, même. Le transfert sur une machine distante (clustering) ne peut être une solution intéressante QUE si l'on vérifie auparavant que le temps de transfert par le réseau n'est pas pénalisant par rapport au temps de traitement de chaque fichier. Plus ton fichier est petit et plus le traitement est long, et plus le clustering devient intéressant.

C'est à dire on lance le traitement en même temps. Mais, ceci garantie que on va obtenir le résultat en un temps le moins possible ?

Tout dépend de ce que tu mesures : le temps réel physique (on commence le boulot à 13h00 et on le finit à 13h10, donc 10 minutes) ou le temps CPU consommé (si tu parallélises sur 20 unités d'exécution, tes 10 minutes "réelles" deviennent 10 x 20 = 200 minutes...).

Paralléliser coûte en général plus cher en temps CPU qu'un traitement parallèle, mais permet de gagner du temps "réel". Tout dépend ensuite de ce qui est le plus coûteux pour toi...

[siempre]

Ce qui est important pour moi est le temps CPU.

[Mac LAK]

Heu... As-tu bien compris ce qu'était le temps CPU, et ne confonds-tu pas avec le temps physique "réel" ?

Si oui, tu cherches à le maximiser (= saturer la machine), ou à le réduire ?

[siempre]

As-tu bien compris ce qu'était le temps CPU, et ne confonds-tu pas avec le temps physique "réel" ?

non.

tu cherches à le maximiser (= saturer la machine), ou à le réduire ?

à le réduire.

[Mac LAK]

Alors aucun intérêt à paralléliser, vu que ça va augmenter le temps CPU utilisé.

Si tu veux réduire le temps CPU (= la charge de la machine), on passe par des processus peu prioritaires et des traitements les moins lourds/intrusifs possibles : cela veut dire virer l'affichage, virer les tests "inutiles", présupposer la bonne forme des entrées et bosser en laissant du temps aux autres processus (ex : des "sleeps" placés judicieusement, passer toutes les I/O en asynchrone, etc.).


C'est pour ça que je te demandais si tu ne confondais pas les deux... Réduire le temps CPU utilisé n'a en général de sens que sur une machine intensivement partagée sur laquelle le temps CPU est "cher" (serveur d'applications par exemple), et n'a que rarement de sens / but sur des machines "personnelles".