fortran ou C, voire C++ ?

Bonjour le forum,
mon métier est le calcul de structures, dans l'aéronautique; il consiste, quand mes collègues dessinateurs ont fait les plans d'une pièce ou d'un assemblage de pièces, à vérifier par le calcul si c'est assez léger pour décoller puis assez solide pour ne pas casser en vol.
Je vais prochainement devoir améliorer sérieusement un programme que j'ai commencé à faire; c'est une vulgaire moulinette séquentielle, qui traduit des codes qu'elle trouve dans un premier fichier d'entrée, à l'aide de données se trouvant dans deux autres fichiers, pour fabriquer un fichier de sortie qui est une image modifiée du premier fichier d'entrée.
Il se trouve que le premier fichier d'entrée fait environ deux millions de lignes, et les deux autres quelques centaines seulement, et le traitement complet dure environ cinq minutes; il faudrait s'arranger pour que ce processus soit réalisable trois cent mille fois en une semaine; soit en six cent mille secondes, ce qui fait que le processus unitaire devrait durer deux secondes au lieu de cinq minutes. (gain d'un facteur 150)
Il est bien évident que l'on va changer de machine; un linux itanium tourne déjà près de six fois plus vite que la vieille HP 9000 où il y a le compilateur fortran que j'utilise pour l'instant, mais on pourrait gagner un peu plus s'il le faut vraiment.
Il doit également être possible d'utiliser un compilateur le plus performant possible pour cette application.
Par ailleurs dans le programme, certaines boucles de recherche parcourent entièrement les deux petits fichiers d'entrée, et je vais m'employer à ce que les variables puissent être trouvées par indexation, donc directement et sans recherche.
Toujours dans le code, je vais m'arranger pour qu'aucune partie de test ne se fasse deux fois.

Mais j'ai peur que cela ne suffise pas.

En me présentant ces objectifs, mon chef à évoqué du développement en C ou C++; je connais un peu le C, que j'utilise séquentiellement, exactement comme du fortran; alors est-ce que le basculement vers ce langage pourrait nous faire gagner du temps d'exécution ?
Et qu'en est il du C++ ? Je connais très peu la POO (je n'ai jamais fait qu'un seul développement en python) mais il me semble que cette structure de langage ne changerait pas grand chose.

Que pensez vous de tout ça ?
Mreci de me donner toutes vos impressions, même les plus farfelues, parce qu'il me faut vraiment faire feu de tout bois pour y arriver.
David

Bonjour,

Je pense que la meilleure solution est d'embaucher un ingenieur specialise en developpement C qui a de bonnes notions de performances, pour un contrat de 18 mois par exemple :). Tu pourrais par exemple en trouver en M2 de Systemes Repartis (Universite de Paris 5), ou bien a l'ENSIMAG (ecole d'ingenieur a Grenoble), et pleins d'autres encore.

Sinon, je ne connais pas les compilateurs fortran, mais je sais que les programmes C sont reputes plus rapides que leurs homologues Fortran. Tu ne gagneras rien a passer en C++.

Il est bien évident que je ne peux pas rivaliser en développement avec un habitué du C et de la performance, mais il est hors de question d'embaucher ou de faire appel à quelqu'un d'extérieur; de plus, un informaticien s'y connait rarement suffisemment dans notre métier qui est la mécanique, et ça a déjà posé problème.
Je ne connais pas assez, mais il me semble également que le C pourrait être légérement plus rapide, mais que le C++ n'apporterait rien.

Citation:

---

Envoyé par dva2tlse

il est hors de question d'embaucher ou de faire appel à quelqu'un d'extérieur; de plus, un informaticien s'y connait rarement suffisemment dans notre métier qui est la mécanique, et ça a déjà posé problème.

---

Je comprends les problemes de budget, ou de temps, mais l'argument de la connaissance metier me laisse pantois : c'est ce qu'on appelle la collaboration, et c'est ce qu'utilisent enormement de chercheurs, en France et a l'etranger : une equipe de specialistes qui s'occupent de la partie theorique, des algorithmes a implementer, etc... et une equipe de developpeurs qui s'occupent d'implementer lesdits algorithmes.

C'est d'ailleurs bien pour ca que j'ai precise qu'il fallait quelqu'un avec un haut niveau d'etudes (Bac+5), non pas parce que ses competences en developpement seront plus elevees, mais parce qu'il sera plus a meme de comprendre le projet, permettant une meilleure synergie entre les deux equipes.


Bref, si vous voulez tout faire tout seul, le plus performant sera du C avec les parties critiques en assembleur.
Le C++ pourra vous apporter les templates si vous en avez besoin, ce qui est une simplicite d'ecriture, mais qui est forcement moins performant que du C.

Pour les structures de donnees, il y a le probleme de charger a chaque fois les deux millions de ligne. Cela pourrait etre fait par un autre programme, via une memoire partagee par exemple : un programme qui charge les donnees dans une zone memoire Z1, un qui travaille sur les donnees dans la zone Z2, puis on inverse : travail sur Z1 et chargement sur Z2.
On peut aussi chercher a utiliser le parallelisme des multi-coeurs actuels, via un pipeline par exemple, pour peu que vos donnees s'y pretent. Un processeur Nehalem peut se reveler plus interessant dans ce cas, mais je ne suis pas certain.
Vous allez aussi avoir un probleme sur l'ecriture des donnees apres le calcul : un stockage sur disque est relativement lent, et pendant ce temps-la, le programme ne travaille pas.

Je partirai donc sur un quad-coeur, avec 2 coeurs de travail, un coeur de chargement des donnees et un de dechargement (transfert de la memoire vers le disque).

En termes de performances le langage est rarement essentiel, surtout entre Fortran, C et C++ qui sont des langages grosso modo de même niveau (ce n'est pas comme si on comparait le C avec un langage dynamique par exemple). C'est avant tout une question d'algorithmes et de structures de données. Il faut donc mettre en balance les avantages théoriques de chaque langage avec la facilité à aisément mettre en oeuvre et maintenir le code. Et sur ce plan-là, C++ > C > Fortran.

Par ailleurs une des grosses sources possibles de gains est le parallélisme. Or le C++ offre de nombreux outils, notamment MPI qui est orienté vers le calcul scientifique et utilisable efficacement par des personnes venant de filières non-informatiques. Et si l'on souhaite utiliser le GPU (si le problème s'y prête les gains peuvent être fulgurants), j'imagine qu'on se tournera vers C ou C++ avec CUDA. Enfin dans la même veine, il vous faudra un bon outil de profilage, encore un choix qui peut influencer le choix du langage.

Maintenant, sur les performances pures, C et Fortran peuvent se battre pied à pied. Le C++ souffre quant à lui d'un léger désavantage mais qui est largement compensé par les avantages qu'il offre par ailleurs si bien qu'à coût équivalent le C++ sera souvent plus efficace.

Bref, choisir le langage le plus "performant" n'est pas la bonne approche.


PS : A mon avis la seule lecture du fichier (sans aucun traitement) prend déjà plus de deux secondes depuis un disque traditionnel. Vous pouvez toujours le mapper en RAM ou tenter un SSD.

A mon avis, les 2 langages C ou Fotran sont équivalents pour ceuqe tu veux faire SAUF si tu as du traitement matriciel. Dans ce cas le Fortran sera beaucoup plus facile, car déjà prévu pour.


Sinon, en gros tu auras les mêmes performances.

Le seul avantage du C (que tu peux atteindre en Fortran mais en étant très sioux) est d'accélerer les boucles ou les références d'éléments matriciels par une incrémentation de pointeur (une addition) au lieu d'un calcul d'adresse (1 multiplication et une addition.


Enfin, là aussi un avantage de l'écriture du C par pointeur est que tu pourras développer plus facilement un algo récursif.

En dehors de ça pas vraiment de différence. Parce que dans l'aure sens, avec Fortran tu pourras éventuellement le paralléliser facilement avec MPI si tu as besoin.

'fin c'est mon avis..

La réflexion de Souviron me fait penser à une petite remarque importante en termes de performances entre le Fortran et le C/C++ : les pointeurs pseudonymes (pointer aliasing, traduction de mon crû), c'est à dire le fait d'avoir plusieurs symboles permettant l'accès à la même adresse mémoire. Par défaut Fortran l'interdit (sauf dans les versions récentes avec les tableaux marqués target), tandis que rien ne l'empêche en C/C++.

Le problème apparaît dans le code suivant :

Code:

---

1 2	sortie[i] = entrée[j] résultat = entrée[j]

---

Si les pointeurs pseudonymes sont possibles, alors entrée et sortie peuvent désigner le même tableau ou se chevaucher. Donc la valeur lue à la ligne 1 pour entrée[j] peut avoir changé en arrivant à la ligne 2, si bien qu'on doit la recharger ; impossible de la garder dans les registres. Cela supprime donc des opportunités d'optimisation et dans certains scénarios de calculs matriciels la différence est notable.

Le mot-clé restrict en C (et en C++ selon les compilateurs) permet de contourner le problème en déclarant qu'un pointeur n'a pas de pseudonyme. Encore faut-il en être conscient.

Citation:

---

Envoyé par DonQuiche

c'est à dire le fait d'avoir plusieurs symboles permettant l'accès à la même adresse mémoire. Par défaut Fortran l'interdit (sauf dans les versions récentes avec les tableaux marqués target), tandis que rien ne l'empêche en C/C++.

---

Tu devrais mieux te renseigner je pense ;) je ne pense pas que le mot-clé "EQUIVALENCE" ait été supprimé, et pourtant ça fait ça depuis le début ;)

Faire correspondre un tableau de double avec un tableau d'entier avec un tableau de caractères avec un tableau de booléens..


(au début ça servait à fabriquer/utiliser des chaines de caractères, avec les constantes de Hollerith)

Alors ça a peut-être dsparu, mais ça m'étonnerait, parce que c'était une des "features" majeures... Mais je me trompe peut-être, pas au fait des derniers trucs et pas envie de chercher :aie:

Citation:

---

Envoyé par souviron34

Tu devrais mieux te renseigner je pense ;) je ne pense pas que le mot-clé "EQUIVALENCE" ait été supprimé, et pourtant ça fait ça depuis le début ;)

---

Je ne connaissais effectivement pas ce mot-clé (mes souvenirs de fortran remontent à mes études) mais cela ne change rien au fond de ce que j'ai dit : aucun pseudonyme ne peut exister implicitement, il faut que cette possibilité soit déclarée explicitement.

Autrement dit, par défaut, le compilateur fortran sait qu'un symbole n'a aucun pseudonyme, à moins qu'il ait été marqué comme "target" ou qu'un équivalent ait été défini (et dans ce dernier cas les pseudonymes possibles sont connus ce qui permet au compilateur de savoir exactement quand lever ou non la présomption de non-interférence des symboles).

C'est l'inverse du compilateur C qui doit toujours présumer que deux pointeurs peuvent être pseudonymes à moins que l'un d'eux ait été marqué comme "restrict".

En fait plusieurs comportements étranges du fortran s'expliquent par cette volonté d'empêcher les symboles pseudonymes. Ce qui le rend pénible à utiliser mais efficace.

Citation:

---

Envoyé par DonQuiche

En fait plusieurs comportements étranges du fortran s'expliquent par cette volonté d'empêcher les symboles pseudonymes. Ce qui le rend pénible à utiliser mais efficace.

---

J'avoue ne pas très bien voir ce que tu entends par "étrange" ;)

Tu as surtout une différence de fond :

• En Fortran les variables sont passées par adresse, donc on peut très bien modiier une varaible déclarée comme "int" à l'intérieur 'une fonction
  
• En C les variables sont passées par référence (une copie) donc on ne peut pas modifier une variable (globalement) que si on pase explicitement l'adresse en paramètre

Ensuite, sur l'adressage relatif, la notion '"EQUIVALENCE" a été explictement faite pour par exemple transformer une entrée matrice 2D en entrée matrice 1D, ou réciproquement, ou découper un problème en sous-problèmes plus simples.

C'est une volonté explicite,.. pas une "feature étrange"..

Mais je ne comprends pas a remarque sur "implicte" ou "explicite"..

Tu peux tout à fat avoir ton exemple indiqué plus haut en Fortran.. sans mot-clé "target".. Les noms des variables ne sont pas figés... Je ne comprend pas ce que tu veux dire..

Citation:

---

Envoyé par souviron34

Mais je ne comprends pas a remarque sur "implicte" ou "explicite".. Tu peux tout à fat avoir ton exemple indiqué plus haut en Fortran.. sans mot-clé "target".. Les noms des variables ne sont pas figés... Je ne comprend pas ce que tu veux dire..

---

Je t'invite à essayer de me proposer un code où deux symboles désigneraient le même tableau. Les règles de Fortran t'en empêcheront (par exemple le compilateur signalera une erreur si tu essaies d'assigner le même tableau à deux paramètres distincts d'une fonction).

Le seul moyen de violer cette contrainte est de le faire explicitement, via target, equivalent ou tout autre mot-clé dont j'ignorerais l'existence.

L'interdiction des pointeurs pseudonymes est une des contraintes de conception au coeur de Fortran, dans un but d'optimisation. C'est ce qui explique le fait qu'il n'y ait pas d'arithmétique possible sur les pointeurs, le fait qu'on ne puise pas assigner un tableau à deux paramètres différents (puisque tu n'en connaissais pas la raison, ne trouvais-tu pas ça "étrange" justement ?), etcétéra.

Citation:

---

Envoyé par DonQuiche

Je t'invite à essayer de me proposer un code où deux symboles désigneraient le même tableau. Les règles de Fortran t'en empêcheront (par exemple le compilateur signalera une erreur si tu essaies d'assigner le même tableau à deux paramètres distincts d'une fonction).

---

Honnêtement je ne vois pas..

Quand tu appelles FOPEN tu peux tout à fait passer 2 (ou 3) fois le même paramètre pour les flags..

De même, si tu as:

Code:

---

1 2	FUNCTION NCH(S, S1) CHARACTER*(*) S, S1

---

tu peux tout à fait mette la même chaine en S et S1..

Ou alors je ne comprend pas du tout ce que tu veux dire...

Le premier exemple est une fonction native, il n'y a aucune raison pour lui appliquer les restrictions d'usage (les fonctions natives sont compilées avec la présomption d'un possible pseudonymat et d'autre part les paramètres scalaires sont passés par valeur).

Le second exemple m'interpelle, je ne connais pas cette syntaxe. S'il s'agit de littéraux, il est normal que la règle ne s'applique pas. S'il s'agit de chaînes de caractères standard, n'y a t-il pas des règles qui feraient que la restriction dont nous discutons ne serait pas nécessaire ? Au pire il pourrait s'agir d'une exception concernant les seules chaînes.

En tous les cas, es-tu d'accord sur le fait qu'en ce qui concerne les tableaux et les types simples fortran t'empêche d'avoir deux pseudonymes si cette possibilité n'est pas explicitement déclarée ?

Bonjour et merci pour ce que j'ai déjà eu comme réponses; ça m'a permis de décider de continuer à bosser en fortran que je connais nettement mieux, et je peux utiliser facilement les adresses de tableaux comme je sais le faire.
Alors qu'en C, que je connais nettement moins bien, il me faudrait "ruser" avec les pointeurs d'une façon que je ne visualise pas bien.

@DonQuichotte et Souviron34 : "Le seul moyen de violer cette contrainte est de le faire explicitement, via target, equivalent ou tout autre mot-clé dont j'ignorerais l'existence" On peut aussi s'arranger en bidouillant honteusement dans les variables en COMMON, mais ce n'est pas mon sujet cette fois ci.
Merci encore pour les conseils du début,
David

Citation:

---

Envoyé par dva2tlse

ça m'a permis de décider de continuer à bosser en fortran que je connais nettement mieux

---

Et c'est un excellent argument. Surtout si d'autres apprentissages sont déjà nécessaires pour le parallélisme voire l'utilisation du GPU.

PS: Réduire les accès I/O au minimum est déjà prévu et c'est une bonne chose. Mais si je peux me permettre un conseil, ce serait de commencer par faire quelques mesures de performances : tester le programme avec les fichiers mappés en mémoire vive et faire tourner un profileur. Tout effort d'optimisation doit s'appuyer sur des mesures car même un programmeur chevronné est incapable de deviner de façon fiable les sources de ralentissement.

Citation:

---

Alors qu'en C, que je connais nettement moins bien, il me faudrait "ruser" avec les pointeurs d'une façon que je ne visualise pas bien.

---

Il ne faudrait pas longtemps pour bien comprendre à vrai dire, quelques exemples trouvés via Google suffiraient, mais peu importe.

Citation:

---

Envoyé par DonQuiche

Et c'est un excellent argument. Surtout si d'autres apprentissages sont déjà nécessaires pour le parallélisme voire l'utilisation du GPU.

---

Tout à fait :)

Citation:

---

Envoyé par DonQuiche

Il ne faudrait pas longtemps pour bien comprendre à vrai dire, quelques exemples trouvés via Google suffiraient, mais peu importe.

---

Bof, pas si évident que ça pour quelqu'un qui ne programme pas depuis longtemps, et qui a toujours utilisé Fortran.. (surtout les anciennes versions)

Citation:

---

Envoyé par DonQuiche

Le second exemple m'interpelle, je ne connais pas cette syntaxe. S'il s'agit de littéraux, il est normal que la règle ne s'applique pas. S'il s'agit de chaînes de caractères standard, n'y a t-il pas des règles qui feraient que la restriction dont nous discutons ne serait pas nécessaire ? Au pire il pourrait s'agir d'une exception concernant les seules chaînes.

---

Mais tu peux tout à fait le faire avec n'importe quel type de paramètre :

Code:

---

1 2	FUNCTION Toto ( I1, I2 ) INTEGER I1, I2

---

Rien ne t'empêche en entrée (à l'appel) de mettre le même paramètre dans I1 et dans I2..

Citation:

---

Envoyé par DonQuiche

En tous les cas, es-tu d'accord sur le fait qu'en ce qui concerne les tableaux et les types simples fortran t'empêche d'avoir deux pseudonymes si cette possibilité n'est pas explicitement déclarée ?

---

J'aimerais que tu me donnes un exemple en C, avec les déclarations correspondantes, parce que là j'ai vraiment du mal à voir ce que tu veux dire...

Souviron, je ne peux pas t'éclairer parce que je ne suis pas un connaisseur de fortran, que je n'ai fait qu'entrevoir durant mes études (et j'ai eu à lire ponctuellement quelques sources après cela).

Tout ce que je sais, mais avec certitude (et une recherche sur fortran et "pointer aliasing" t'en convaincra) c'est qu'une des contraintes de conception de ce langage était de pouvoir déterminer à la compilation si des symboles sont pseudonymes car cela autorise plusieurs optimisations.

Je suis en revanche incapable de te dire à quoi exactement ça s'applique (seulement tableaux ? également scalaires ?) ni l'ensemble des règles qui rendent ça possibles. C'est toi le connaisseur de fortran qui devrait pouvoir préciser le périmètre et la mise en oeuvre. Tout ce que je peux faire pour ma part c'est expliquer la notion de pointeurs pseudonymes et raisonner sur la façon dont un compilateur peut l'implémenter et les contraintes que ça implique sur le langage.


Quant à l'exemple du C, en voici un:

Code:

---

1 2 3 4 5 6 7 8 9 10

int someArray[] = { 1, 2, 3 }; int someFunc(int[] input, int[] output) { output[1] = input[1] * 2; // lit 2, stocke 4 return input[1]; // renvoie 4 } //... someFunc(someArray, someArray);

---

Normalement ce code est interdit en fortran, sommes-nous d'accord ?

Si le compilateur peut déterminer que input et output ne sont pas pseudonymes (cas du fortran) alors il n'est nécessaire de lire qu'une fois input[1]. Par la suite elle est stockée dans les registres et c'est de là qu'on la lira à nouveau.

Si en revanche on doit supposer que les deux symbolses peuvent être pseudonymes (cas du C) alors lors de la seconde lecture il faut relire la valeur depuis la mémoire, sans quoi le code renverrait 2 et non 4.

Citation:

---

Envoyé par DonQuiche

Normalement ce code est interdit en fortran, sommes-nous d'accord ?

---

Euh non, pas du tout... :aie:

ça peut très bien s'écrire ET s'utiliser exactement de la même manière...

Même si mes souvenirs sont lointains, j'ai fait des programmes de traitements d'images et autres programmes graphiques, et il est tout à fait courant de faire ce genre d'opérations il me semble bien...

Citation:

---

Envoyé par DonQuiche

Si le compilateur peut déterminer que input et output ne sont pas pseudonymes (cas du fortran) alors il n'est nécessaire de lire qu'une fois input[1]. Par la suite elle est stockée dans les registres et c'est de là qu'on la lira à nouveau.

Si en revanche on doit supposer que les deux symbolses peuvent être pseudonymes (cas du C) alors lors de la seconde lecture il faut relire la valeur depuis la mémoire, sans quoi le code renverrait 2 et non 4.

---

Par défaut en Fortran tout ce qui est en input est modifiable... Ce n'a rien à voir avec des registres ou quoi (tu fais un tableau de 100000*100000, ça sera pas dans les registres)

C'est même ce qui rend la lecture de programmes Fortran assez opaque pour des gens venant du C ou du Pascal..

Code:

---

1 2 3 4 5 6

FUNCTION TOTO ( K ) INTEGER K   K = K + 1   return K + 1

---

fera que, si à l'appel on avait K=1, la fonction retournera 3, mais K sera modifé et vaudra 2 dans la fonction appellante après l'appel (sauf si on s'est servi d'une variable intermédiaire)...

Citation:

---

Envoyé par souviron34

Euh non, pas du tout... :aie:

ça peut très bien s'écrire ET s'utiliser exactement de la même manière...

---

Je suis convaincu du contraire.

Citation:

---

tu fais un tableau de 100000*100000, ça sera pas dans les registres

---

Non mais l'élément i le sera au moment où il est lu. La question est de savoir si cette valeur pourra être réutilisée lors d'un second accès ou s'il faudra la recharger depuis la mémoire.

Citation:

---

fera que, si à l'appel on avait K=1, la fonction retournera 3, mais K sera modifé et vaudra 2

---

Oui et alors ? Quel rapport avec le problème dont nous discutons ?

Citation:

---

Envoyé par DonQuiche

Je suis convaincu du contraire.
..
Non mais l'élément i le sera au moment où il est lu. La question est de savoir si cette valeur pourra être réutilisée lors d'un second accès ou s'il faudra la recharger depuis la mémoire.

---

Malheureusement je n'ai pas pu garder touts mes sauvegardes (bandes 1600 BPI), mais voici un exemple :

Code:

---

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

C***********************************************************************C C SUBROUTINE TO CALCULATE A SPLINE OF THIRD ORDER . IN THE MAIN C C PROGRAM YOU HAVE TO PUT DIMENSION A(3,N) . AFTER RUNNING A C C CONTAINS THE CUBIC COEFFICIENTS FOR EACH GAP / Xi Xi+1 C C N IS THE NUMBER OF POINTS C C (SACLAY - HPCCD - 1982/84) C C***********************************************************************C SUBROUTINE SPLIN(X,Y,A,S,N) DIMENSION X(1),Y(1),A(1),S(1),B(1) N1=N-1 N2=N-2 DO 1 I=1,N1 X(I)=X(I+1)-X(I) Y(I)=Y(I+1)-Y(I) 1 CONTINUE DO 2 I=1,N2 A(N2+I)=2.*(X(I)+X(I+1)) S(I)=(Y(I+1)/X(I+1)-Y(I)/X(I))*6. 2 CONTINUE DO 22 I=2,N2 A(I)=X(I) 22 CONTINUE DO 23 I=1,N2 A(2*N2+I)=X(I+1) 23 CONTINUE CALL BANSL(A,N2,3,S) DO 3 I=2,N1 A(I)=S(I-1) 3 CONTINUE DO 4 I=2,N1 S(I)=A(I) 4 CONTINUE S(1)=S(2) S(N)=S(N1) DO 5 I=1,N1 A(1+3*(I-1))=(S(I+1)-S(I))/6./X(I) A(2+3*(I-1))=S(I)/2. A(3+3*(I-1))=Y(I)/X(I)-(2.*X(I)*S(I)+X(I)*S(I+1))/6. 5 CONTINUE DO 500 I=N1,1,-1 X(I)=X(I+1)-X(I) Y(I)=Y(I+1)-Y(I) 500 CONTINUE RETURN END

---

Tu noteras en particulier la partie au début :

Code:

---

1 2 3 4 5

DO 1 I=1,N1 X(I)=X(I+1)-X(I) Y(I)=Y(I+1)-Y(I) 1 CONTINUE

---

suivie de - à la fin :

Code:

---

1 2 3 4 5

DO 500 I=N1,1,-1 X(I)=X(I+1)-X(I) Y(I)=Y(I+1)-Y(I) 500 CONTINUE

---

C'est pas ça que tu voulais dire ?

SOuviron, non, ce n'est pas ce que je voulais dire.
1) Est-il possible d'appeler Splin en passant le même tableau à X et à Y ? Pas à ma connaissance.

2) Les deux parties que tu as mis en exergue ne sont pas problématiques : le rechargement de la valeur depuis la mémoire serait ici imposée par les assignations elles-mêmes et non pas par une présomption de pointeurs pseudonymes. Parce que tu assignes de Xi dans Xi, et non pas de Xi dans un Yi qui serait peut-être Xi (si les pseudonymes sont autorisés).

En fait dans ton code la garantie d'absence de pseudonymes ne permettrait aucune optimisation. Pire : à aucun moment dans ton code on est en présence d'un cas où il faudrait forcer le rechargement depuis la mémoire : une fois Xi modifié, il n'est pas nécessaire de le relire durant la boucle. Et il en irait de même en C.