Discussion :

[jacco]

Bonjour,

Je suis un vieux Pascalien et j'ai développé une application qui procède à l'analyse de séries temporelles. Dans le cadre de cette application je dois réaliser des calculs à l'aide de boucles imbriquées.
Ces calculs par définition répétitifs en nombre important entre 10⁶ et 10⁷ sont réalisés par un seul cœur et donc très couteux en temps. Je cherche donc à convertir mon application en Free POO de façon à réaliser un répartition multithreading des calculs.
Ma question est : Existe-t-il un logiciel qui me permettrait de convertir mon application en Free POO sans que j'ai à réécrire complètement 3200 lignes de code.

Merci pour vos conseils.

[Guesset]

Bonjour,

Le pascal objet est un pascal donc a priori qui peut le plus peut le moins...

Mais (il y a toujours un mais) la gestion de l'interface homme machine peut grandement différer d'un outil à l'autre. Ce n'est pas tant la couche objet que le changement de bibliothèques impliqué par le changement d'outils qui demande des adaptations parfois importantes.

Si l'application est avec une IHM minimaliste comme le mode console, ça peut tomber en marche sans rien faire (sinon croiser les doigts).

Dans les autres cas, si la couche présentation a été bien isolée du code fonctionnel le coût de migration devrait être assez limité. Mais si le code mélange allègrement présentation, traitement et accès aux données, la réécriture intégrale de l'équivalent de 3200 lignes sera plus rapide que la technique des petits pas qui sera plus longue et gardera la structure de programme qui pose problème.

Salutations

[jacco]

Bonjour M. Guesset,

Tout d'abord merci pour votre réponse et votre temps.
Je voudrais rajouter quelques éléments sur la nature de mon application qui est comme vous allez le voir, assez simple ce qui permettra j'espère, de préciser la solution optimale.
L'application de type FPC lie en entrée un fichier text de données assez volumineuses de 100000 A 500000 lignes. Ce fichier est stocké en mémoire et réaccéder à l'aide d’une variable de type pointeur.
n calculs sont effectués en parcourant le fichier (10⁶ < n < 10⁷) faisant intervenir plusieurs fonctions et procédures de type Pascal standard.
Dans l'état actuel de l'application n est le produit 3 boucles imbriquées. Apres chaque calcule si le résultat rempli certaines conditions il est stocké dans un fichier text (il y a très peu de résultats qui satisfont les conditions donc peu d'écritures (entre 1 et 10).
Ce qui serait souhaitable dans un premier temps c'est de paralléliser les calculs contrôles par la boucle la plus interne par le jeu d'un index a l'aide par exemple d'une procédure telle que
procedure DoSomethingParallel(Index: PtrInt; Data: Pointer; Item: TMultiThreadProcItem); ou l'index evidemment controlerait la boucle.
Mais dès que j'introduis ce type de POO il me semble que le compilateur va hurler car les calculs de la boucle utilisent évidemment mes fonctions et procédures Pascal standard mentionnées plus haut ...
Voilà merci pour votre conseil sur la base de ces nouveaux éléments. (surtout s’il y a une possibilité d’éviter la réécriture complète)

[Guesset]

Bonjour,

Apparemment, Si je comprends bien, la POO ne serait utile que pour gérer les threads. Il n'y aurait donc pas une réécriture complète.

C'est un programme en mode console (ligne de commande) ? Sinon il y a de forte chance qu'il utilise nombre de composants qui sont des instanciations d'objets. Auquel cas vous faites déjà de la POO sans le savoir

L'histoire d'un pointeur m'interpelle. Cela évoque un traitement purement séquentiel car c'est le domaine d'excellence des pointeurs. Or le parallélisme suppose qu'il est possible de découper en traitements décorrélés. Est-ce le cas ?

Il faudrait voir le code pour se faire une idée (au moins les trois boucles).

Salutations

[jacco]

Bonjour POO,

Tout d'abord merci pour la réponse.
Oui effectivement il y a des instanciations d'objets dans mon programme.
Par ailleurs le pointeur fait effectivement référence a une lecture séquentielle d'un fichier texte. Mais le découpage se ferait au niveau des paramètres d'optimisation sur lesquels je fais une recherche par balayage. Donc l'idée serait de découper/repartir la boucle extérieure sur n cœurs / threads et on pourrait même pousser plus loin et faire un découpage de 2eme et 3eme niveau pour les boucles internes.
D'où la question : pour ceci dois-je réécrire la totalité de mon pgm ?
(Un bon nombre d'instanciations objets sont évidemment en dehors des 3 boucles).

Bien cordialement,

[Guesset]

Bonjour,

La réécriture devrait se limiter à celle des boucles pour tirer partie du parallélisme. Mais cette réécriture sera d'autant plus difficile si les boucles actuelles ne sont pas intrinsèquement indépendantes (par exemple, si l'itération i+1 d'une boucle dépend de l'itération i, alors ces deux itérations ne peuvent être parallélisées en l'état).

Il n'est pas nécessaire de multiplier les threads à outrance. Pour une machine à n cœurs, le nombre de threads devrait être limité entre n et 1.3 n (si SMT ou HT) au delà il n'y aura pas de gain voire même une légère diminution de performances.

Salutations

[jacco]

Bonjour Guesset et merci pour la réponse,

Les boucles sont je pense indépendantes mais imbriquées. Pour être tout fait clair la boucle la plus extérieure J pour s'incrémenter d'un pas, attend que la boucle K ait complètement réalisée toutes ces itérations de 1 à n qui pour s'incrémenter d'un pas attend elle-même attend que la boucle L ait réalisée toutes ces itérations de 1 à m.
Sur cette base le parallélisme ne devrait pas poser de problème ?

Bien cordialement

[Guesset]

Bonsoir,

A priori, si elles sont imbriquées c'est qu'elles sont interdépendantes. Prenons l'exemple du balayage d'un espace 3D. Il y aura une boucle en X suivie d'une boucle en Y puis d'une boucle en Z avant de pouvoir travailler au sein de la boucle la plus interne (celle en Z) sur le point (X, Y, Z) qui dépend des 3 niveaux de boucle.

En revanche, on peut avoir un thread qui traite le X = 0 modulo 4, un autre pour les X = 1 modulo 4, un autre pour les X = 2 modulo 4, et un quatrième pour les X = 3 modulo 4.

Mais il ne faut qu'il y ait interdépendance entre les itérations de X. Supposons que X évolue de 0 à Xmax et que dans cette boucle on calcule X2 = x* x avec la méthode incrémentale X2 = X2 + 2X + 1. X2 étant calculé à partir de l'itération précédente, elle ne peut fonctionner dans un thread qui va de 4 en 4 au lieu d'un incrément unitaire. Il faudra, soit revenir à x2 = x* x, soit adapter la formule incrémentale x2 = x2 + 8x +16.

Salutations

[jacco]

Bonjour Guesset,

Merci pour votre reponse.
Si je suis votre logique la boucle la plus interne dans ce cas est la seule a etre independante.
Est ce que nous pouvons etre d'accord au moins sur ce point ?
Bien a vous

[Guesset]

Bonjour Jacco,

Une boucle est indépendante des autres si elle n'utilise aucun résultat (y compris l'indice de boucle des autres boucles).
Si la boucle la plus interne n'utilise rien des boucles qui l'entourent, pourquoi serait elle dedans ?

La boucle la plus externe (la première) est a priori indépendante des autre boucles même si on peut imaginer des cas tordus (et souvent difficiles à gérer) où une boucle interne perturbe une boucle externe. La seconde peut être également indépendante auquel cas elle peut être permutée avec la première.

Le fait qu'une boucle externe doive attendre que les boucles interne aient terminé leur job est une dépendance temporelle qui n'est pas propre aux boucles mais au traitement séquentiel des instructions. C'est cela que le parallélisme permet de casser un peu.

En général, la boucle principale se prête bien au parallélisme, mais il peut y avoir des modifications à faire, notamment si il y a des interdépendances entre les itérations de cette même boucles (si une valeur Val_i dépend par exemple de Val_i-1, i étant l'indice de boucle).

Le plus simple serait de voir le code relatif à cette boucle pour je puisse être plus concret.

Salutation

[Jipété]

Bonjour,

je m'immisce car dans ce genre de chose, j'ai besoin d'une précision absolue et il y a là quelque chose qui coince :

Mais il ne faut qu'il y ait interdépendance entre les itérations de X.

il ne faut qu'il y ait

il faut qu'il y ait ?
ou
il ne faut pas qu'il y ait ?
Merci,

[jacco]

Bonjour Guesset,

Merci pour la reponse rapide et pour l'interet porte a mon petit probleme (clavier qwerty sorry je n'ai pas accentuation Francaise sauf a "repiquer" les accents ailleurs).
Pour simplifier appellons la boucle externe 1, intermediaire 2 et interne 3
La boucle 3 est commandée par 3 indices, le code exécuté à ce niveau est

Code :

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

(  (NO_OF_STEP = Indice_1) and  (DERIVATIVE_S4S(CURRPTR,ROUND(Indice_2)) > Indice_3) )

ou Indice_1 est l'indice de la boucle_1, Indice_2 est l'indice de la boucle_2, Indice_3 est l'indice de la boucle_3.

la fonction appelée est

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
FUNCTION DERIVATIVE_S4S(PTR:PTRREC; DEPTH:INTEGER):FLOAT;
{******************}
VAR I:INTEGER;
BEGIN
DERIVATIVE_S4S := 0;
 
     FOR I:=1 TO DEPTH DO
     BEGIN
       if  (PTR^.C<>PTR^.PREV^.C )
       then  DERIVATIVE_S4S := DERIVATIVE_S4S + ( ((  PTR^.C/PTR^.PREV^.C  )-1)*(1 + SSI5) );
        PTR := PTR^.PREV
     END;    
 
END; // FUNCTION DERIVATIVE_S4S

J'espere que ceci vous permettra d'avoir une vue claire du probleme.


(PS Holala je viens de voir le message de Jipete et moi qui ne met pas l'accentuation, il ne va pas etre content du tout ... )

[Andnotor]

Si on se réfère à ce que tu nous montres, la construction ressemble à ceci :

Code :

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

1
2
3
4
5
6
7
for Indice_1 := ...
  for Indice_2 := ...
    for Indice_3 := ...
      if ((NO_OF_STEP = Indice_1) and  (DERIVATIVE_S4S(CURRPTR,ROUND(Indice_2)) > Indice_3)) then
      begin
        // Traitement
      end;

Ce qui n'est clairement pas optimal. On devrait plutôt avoir quelque chose comme cela pour éviter de recalculer DERIVATIVE_S4S n fois (et accessoirement utiliser directement ce résultat comme low de la boucle 3 => un test de moins !) :

Code :

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

1
2
3
4
5
6
7
for Indice_1 := ...
  if Indice_1 = NO_OF_STEP then
    for Indice_2 := 1 to ...
      for Indice_3 := Trunc(DERIVATIVE_S4S(CURRPTR, Indice_2)) +1 to ...
      begin
        // Traitement
      end;

A partir de là, les "boucles" 2 et 3 pourraient être thread-ées. Je mets boucles entre guillemets parce que dans les faits, on utilisera plutôt des variables globales qu'on incrémentera de façon synchronisée par InterlockedIncrement (c'est le thread qui récupère l'indice du prochain élément à traiter).

Oui il y aura un certain travail de réécriture mais qui concernera principalement l'accès aux données (synchronisation) et la séparation UI/métier. Et pour répondre à la question originale, je ne connais aucun utilitaire capable de faire cela

Quant au nombre de threads, il sera déterminé par le nombre de threads en exécution simultanée par rapport au nombre de cœurs.

[Guesset]

Bonjour Jipété

Bonjour,

je m'immisce car dans ce genre de chose, j'ai besoin d'une précision absolue et il y a là quelque chose qui coince :

il ne faut qu'il y ait

il faut qu'il y ait ?
ou
il ne faut pas qu'il y ait ?
Merci,

Même si le "pas" renforce la négation c'est le "ne" qui la porte comme dans "je ne mange ni ne dors", "je ne sais d'où cela vient" etc. Ceci dit, même si la phrase reste correcte, j'aurais dû ajouter le "pas" salvateur à une compréhension aisée.

Ceci pour la forme, pour le fond il ne faut nulle interdépendance entre itérations si celles ci doivent être traitées en parallèle.

Salutations

[jacco]

Bonjour Andnotor,

Merci pour la reponse et le temps consacré.

Mais je ne pense pas que l'on puisse implementer ce type de solution pour la raison suivante :

Tout d'abord j'aurai du donner un code un peu plus complet et je m'en excuse. Le code ( (NO_OF_STEP = Indice_1) and (DERIVATIVE_S4S(CURRPTR,ROUND(Indice_2)) > Indice_3) )est en fait un element d'un test multiples et s'ecrit

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
or  (  (NO_OF_STEP = Indice_1) and  (DERIVATIVE_S4S(CURRPTR,ROUND(Indice_2)) > Indice_3) ) 
 
or  // autre test
.
.
.
or  // autre test
 
then begin
 
// Traitement 1
 
End
else begin
 
// traitement 2
 
end

Donc j'ai besoin d'evaluer DERIVATIVE_S4S avec en Indice_2 > Indice_3. Indice_3 ne peux etre le resultat de l'evaluation de DERIVATIVE_S4S.
Enfin tous les cas doivent etre evalué sequenciellement au niveau de Indice_1 donc le test if Indice_1 = NO_OF_STEP n'a pas lieu d'être.

[jacco]

Bonjour Jipété



Même si le "pas" renforce la négation c'est le "ne" qui la porte comme dans "je ne mange ni ne dors", "je ne sais d'où cela vient" etc. Ceci dit, même si la phrase reste correcte, j'aurais dû ajouter le "pas" salvateur à une compréhension aisée.

Ceci pour la forme, pour le fond il ne faut nulle interdépendance entre itérations si celles ci doivent être traitées en parallèle.

Salutations

Bonsoir Guesset,

Merci pour la forme et le fond, et surtout pour le fond.
" nulle interdépendance " alors la boucle la plus externe pourrait au moins faire l'objet d'un traitement parallèle ?
Sinon le parallèlisme qui est censé s'appliquer en particulier au cas des boucles n'a plus aucun interêt.
Cordialement

[Guesset]

Bonjour,

Je souscris aux remarques de Andnotor.

Il y a un travail de révision du code qui est un préalable - et peut être même un substitut - à une opération de parallélisation. Je renvoie sur la précédente discussion "Test multi conditions " qui semble porter sur le même code et qui proposait déjà quelques évolutions du code.

Par exemple, outre les modifications déjà proposées, on peut écrire ceci (seule la sortie de la boucle de la multiplication par une constante a de l'importance, au doigt mouillé le gain doit être au moins de 20 %):

Code Pascal :

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

1
2
3
4
5
6
7
8
9
10
function Derivative_S4S(Ptr : ptrRec; Depth : integer): float;
begin
   Result := 0.0;
   while Depth1 > 0 do begin
      if Ptr^.C <> Ptr^.Prev^.C then Result += Ptr^.C / Ptr^.Prev^.C - 1.0;
      Ptr := Ptr^.Prev;
      dec(Depth1);
   end;    
   Result := Result * (1 + SSI5);   // Sortir de la boucle la multiplication par une constante (ie. 1 + SSI5 ne varie pas durant la fonction)
end; // function Derivative_S4S

Des modifications unitaires aux modifications structurelles, le potentiel de gains semble important.

La complexité et la taille des tests ne peut être un argument pour garder le code en l'état. Au contraire elles témoignent d'un axe d'améliorations importantes. Paralléliser le code en l'état peut être séduisant à première vue mais je ne m'y risquerais pas

Salutations

[Guesset]

Bonsoir Jacco,

Bonsoir Guesset,
" nulle interdépendance " alors la boucle la plus externe pourrait au moins faire l'objet d'un traitement parallèle ?
Sinon le parallèlisme qui est censé s'appliquer en particulier au cas des boucles n'a plus aucun interêt.
Cordialement

Oui la boucle externe est généralement le meilleur candidat. Si la n^ième itération ne dépend pas des n-1 précédentes alors elle peut être confiées à un thread différent. Il existe bien des mécanismes permettant de s'accommoder de certaines dépendances mais cela a un coût en complexité et performances qui incite fortement à faire sans.

Bonne soirée.

[jacco]

Bonjour,

Je souscris aux remarques de Andnotor.

Il y a un travail de révision du code qui est un préalable - et peut être même un substitut - à une opération de parallélisation. Je renvoie sur la précédente discussion "Test multi conditions " qui semble porter sur le même code et qui proposait déjà quelques évolutions du code.

Par exemple, outre les modifications déjà proposées, on peut écrire ceci (seule la sortie de la boucle de la multiplication par une constante a de l'importance, au doigt mouillé le gain doit être au moins de 20 %):

Code Pascal :

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

1
2
3
4
5
6
7
8
9
10
function Derivative_S4S(Ptr : ptrRec; Depth : integer): float;
begin
   Result := 0.0;
   while Depth1 > 0 do begin
      if Ptr^.C <> Ptr^.Prev^.C then Result += Ptr^.C / Ptr^.Prev^.C - 1.0;
      Ptr := Ptr^.Prev;
      dec(Depth1);
   end;    
   Result := Result * (1 + SSI5);   // Sortir de la boucle la multiplication par une constante (ie. 1 + SSI5 ne varie pas durant la fonction)
end; // function Derivative_S4S

Des modifications unitaires aux modifications structurelles, le potentiel de gains semble important.

La complexité et la taille des tests ne peut être un argument pour garder le code en l'état. Au contraire elles témoignent d'un axe d'améliorations importantes. Paralléliser le code en l'état peut être séduisant à première vue mais je ne m'y risquerais pas

Salutations

Bonsoir Xor,

Merci pour votre réponse.
Je ne suis pas familiarisé avec le langage C et donc je ne connaissais pas la syntaxe += .

Juste une question, implicitement vous supposez que le couple d'instructions: while Depth1 > 0 do begin / dec(Depth1); est plus rapide que la seule instruction FOR I:=1 TO DEPTH DO ?
Sinon je dois reconnaitre que rajouter * (1 + SSI5) a chaque itération n'était pas très performant (quelque fois on veut ecrire rapidement un code et on laisse de coté la performance ...)
Si vous répondez par l'affimative a ma question j'implementerai votre solution surtout si je peux gagner 20% ...
Bonne soirée

[jacco]

Bonsoir Jacco,



Oui la boucle externe est généralement le meilleur candidat. Si la n^ième itération ne dépend pas des n-1 précédentes alors elle peut être confiées à un thread différent. Il existe bien des mécanismes permettant de s'accommoder de certaines dépendances mais cela a un coût en complexité et performances qui incite fortement à faire sans.

Bonne soirée.

Bonsoir Guesset,

Merci pour me permettre de garder un peux d'espoir pour la solution du parallèlisme.
Mais apparemment Xor n'a pas très encourageant ...

Cordialement