Discussion :

[i2kneo]

Bonjour,

J'ai réalisé un code de calcul en fortran 90. C'est un code de simulation pétrolière.
J'ai fait une première version qui était faite avec beaucoup de modules pour des raisons de simplicité et d'utilisation d'autres codes.
J'ai décidé d'optimiser le tout en changeant de stratégie car il m'arrivait souvent de recalculer plusieurs fois les mêmes variables. J'ai donc stocké sous forme de tableaux et donc utilisé moins d'appels à des subroutines.
A ma grande surprise, la version 2 est plus lente - en temps d'exécution - que la première. Je ne comprends pas pourquoi... J'ai profilé le code, rien de spécial.
J'ai aussi remarqué que le fait de créer des tableaux à grandes dimensions ralentissait énormément le code.
J'aimerais avoir vos conseils et les grandes règles qui permettent d'optimiser un code. Je pense que sur l'algo de résolution pur, j'ai optimisé au maximum et maintenant c'est un problème de stratégie de codage.
Merci par avance.

[FR119492]

Salut !
J'ai peut-être une explication, mais pour cela, il me faut deux renseignements:

• Sur quel OS travailles-tu ?
• Quelle est la taille de tes tableaux?

Jean-Marc Blanc

[i2kneo]

Salut,

Je travaille sous linux (suse) et je compile en intel fortran compiler ou pgf90.
Lorsque j'ai fait mes tests j'ai utilisé les deux compilos. Je n'ai pas utiliser d'options d'optimisation. La majorité de mes tableaux sont des tableaux de réels double précision de la forme A(20,2) ou A(60,2) ou A(20,3,2,2) ou A(20,20,3,3,3,3,2) pour les plus gros.

[FR119492]

Salut !
Malheureusement, au vu de tes réponses, mon explication ne joue pas. Je te la donne quand même: travaillant sous Windows, j'avais fait des tests de vitesse d'exécution pour des gros systèmes linéaires et j'avais observé qu'au delà d'une certaine taille, le temps de calcul augmentait brusquement; cela était dû au fait que Windows occupait une partie importante de la mémoire et que les données étaient "swapées" sur disque sans que j'aie le moindre contrôle là-dessus.

Mais, en écrivant ça, il me vient une idée: est-ce que ce n'est pas l'utilisation des cache qui se détériore lorsque tu travailles avec des tableaux. Je ne connais pas ton problème, mais une piste pourrait être de permuter l'ordre de tes indices.
Jean-Marc Blanc

[i2kneo]

J'avais pensé à ta dernière hypothèse, c'est pourquoi je voulais essayer les options du compilo pour optimiser (-O2 ou -O3) qui sont censées arranger ce genre de problème, je crois. Sinon, je vais essayer de permuter les indices.
J'ai aussi remarqué que les commandes du genre F( =0.d0 consommaient beaucoup. Malheureusement, le fortran ayant la fâcheuse habitude, lors d'appel récurrents de ne pas initialiser les tableaux à zero, je suis toujours obligé de fair ça.
Je vais essayer de compiler sous windows pour voir et faire les tests avec l'option d'optimisation.

[FR119492]

Salut !
J'avais vu, il y a de nombreuses années, un exemple très spectaculaire:

Code :

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

1
2
3
4
5
6
7
8
9
10
      Program A
      Implicit None
      Integer I,J
      Real*8 X(1000,1000)
      Do I=1,1000
        Do J=1,1000
          X(I,J)=0.d0
        End Do
      End Do
      End

Code :

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

1
2
3
4
5
6
7
8
9
10
      Program B
      Implicit None
      Integer I,J
      Real*8 X(1000,1000)
      Do J=1,1000
        Do I=1,1000
          X(I,J)=0.d0
        End Do
      End Do
      End

Un des programme prenait plus de 10 fois plus de temps que l'autre. En effet, il faut, autant que possible, parcourir la matrice colonne par colonne et non ligne par ligne (en C c'est le contraire !).

En ce qui concerne l'optimisation du code, la meilleure source me semble être le site www.netlib.org. Je te conseille de regarder comment J. Dongarra a optimisé le BLAS, par exemple la routine DSCAL:

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
      SUBROUTINE DSCAL(N,DA,DX,INCX)
*     .. Scalar Arguments ..
      DOUBLE PRECISION DA
      INTEGER INCX,N
*     ..
*     .. Array Arguments ..
      DOUBLE PRECISION DX(*)
*     ..
*
*  Purpose
*  =======
**
*     scales a vector by a constant.
*     uses unrolled loops for increment equal to one.
*     jack dongarra, linpack, 3/11/78.
*     modified 3/93 to return if incx .le. 0.
*     modified 12/3/93, array(1) declarations changed to array(*)
*
*
*     .. Local Scalars ..
      INTEGER I,M,MP1,NINCX
*     ..
*     .. Intrinsic Functions ..
      INTRINSIC MOD
*     ..
      IF (N.LE.0 .OR. INCX.LE.0) RETURN
      IF (INCX.EQ.1) GO TO 20
*
*        code for increment not equal to 1
*
      NINCX = N*INCX
      DO 10 I = 1,NINCX,INCX
          DX(I) = DA*DX(I)
   10 CONTINUE
      RETURN
*
*        code for increment equal to 1
*
*
*        clean-up loop
*
   20 M = MOD(N,5)
      IF (M.EQ.0) GO TO 40
      DO 30 I = 1,M
          DX(I) = DA*DX(I)
   30 CONTINUE
      IF (N.LT.5) RETURN
   40 MP1 = M + 1
      DO 50 I = MP1,N,5
          DX(I) = DA*DX(I)
          DX(I+1) = DA*DX(I+1)
          DX(I+2) = DA*DX(I+2)
          DX(I+3) = DA*DX(I+3)
          DX(I+4) = DA*DX(I+4)
   50 CONTINUE
      RETURN
      END

Jean-Marc Blanc