Conversion d'une boucle DO à l'ancienne

Bonjour,

je suis en train de réécrire un bout de code (des FFTs) en vieux Fortran:

Code:

---

1 2 3 4 5

do 1001 i=1,10 do 1001 j=1,20 [...] 1001 continue

---

J'ai bêtement pensé que c'était équivalent à:

Code:

---

1 2 3 4 5 6

do 1001 i=1,10 do 1002 j=1,20 [...] 1002 continue 1001 continue

---

Et donc en version plus récente:

Code:

---

1 2 3 4 5 6

do i=1,10 do j=1,20 [...] enddo enddo

---

Mais apparemment, ce n'est pas le cas... La dernière version me fait un plantage "sigsev / stacksize overflow". Il n'y a que ce genre de boucles dans la subroutine.

Ce post me confirme que ces versions sont les mêmes: http://www.developpez.net/forums/d37...o/#post2307861

Qu'en pensez-vous?

Pas évident.

La première transformation pourrait introduire une erreur via un goto 1001 dont le sens passerait de "cycle" à "exit", mais ça n'explique pas que l'erreur se produise avec la version "enddo" (il ne peut y avoir de goto 1001 oublié puisque la compilation avorterait).

Il reste selon moi 2 possibilités :

1. Tu as bousillé autre chose.
2. Le code un peu différent en syntaxe produit un exécutable un peu différent "permettant" de rendre visible un problème initialement invisible, mais déjà présent.

Je penchais pour la deuxième solution :mouarf: et tu confirmes ce que je pense.

Je ne mets pas de côté la 1ère mais j'ai bien vérifié à coup d'outils de diff (tkdiff, emacs diff et vimdiff ;-) ). Mais bon ca fait quand même 2000 lignes...

Enfin bref, tant pis, j'abandonne!

Merci pour la réponse

Comment ça, « j'abandonne » ? Comme dirait l'autre, de quessé ?

Le problème avec ta stratégie (abandon), c'est que le problème risque de revenir dès tu changeras quelque chose (un petit bout de code, le compilateur, ...).

Pour trouver ce genre d'erreur, la stratégie est toujours la même : mettre toutes les switches d'optimisation à off, toutes les switches de contrôle à on, et si possible, utiliser plus d'un compilateur.

Non mais 2000 lignes de code de fft que je pige que dalle :D

Mais pour faire avancer les choses, j'ai entrepris de faire la même chose avec le dgemm de BLAS, c'est-à-dire remplacer les continue par les enddo et oui apparemment les effets des optimisations compilateur se voient sur le résultat .... :cry:

Bonjour,

Citation:

---

Envoyé par TheOyoStyledMan

Mais pour faire avancer les choses, j'ai entrepris de faire la même chose avec le dgemm de BLAS, c'est-à-dire remplacer les continue par les enddo et oui apparemment les effets des optimisations compilateur se voient sur le résultat .... :cry:

---

Oui, ce n'est pas plus étonnant que ça, surtout si les optimisations du compilo sont "agressives".

Par contre, pour en revenir à ton premier post et le fait que

Citation:

---

La dernière version me fait un plantage "sigsev / stacksize overflow".

---

Ca peut aussi venir de ton environnement qui inclurai un stacksize "trop petit": la nouvelle version demanderai plus de mémoire que l'ancienne et se ferait ainsi tuer à l'exécution lorsqu'elle atteint ce plafond.
Mais ce n'est qu'une hypothèse...
(que tu peux tester en changeant la mémoire "stack" allouée à ta session; sous Unix/Linux via la commande "ulimit -s").

Déjà essayé mais pas plus conluant :cry:

Merci pour le conseil!

Stack size overflow... quel est la taille des tableaux sur la stack? As tu des tableaux automatiques? Quel compilateur utilises tu?

La taille max des tableaux est environ de 2500*2500 complexes double precision (a priori 65Mo par processus).

J'ai bien des tableaux automatiques.

J'utilise Intel 11 et 12.

Les tableaux automatiques c'est pas automatique ! ...

Ahem...

Ils sont alloués sur la stack donc ça peut expliquer ton problème.

Passe les sur le heap en faisant un allocate ça devrait aller mieux.

Si tu compiles avec -openmp, tu peux essayer d'augmenter la KMP_STACK_SIZE aussi. Essaye avec :

export KMP_STACK_SIZE=70m (par défaut c'est 1m)

En sachant que c'est un très mauvais workaround si ça marche, le mieux étant d'aller sur le heap.