Comment moderniser une grande base de code de crunching de nombres basée sur Fortran?

Un ami du milieu universitaire m'a demandé conseil (je suis développeur d'applications commerciales C #).

Il possède une base de code héritée qu'il a écrite à Fortran dans le domaine de l'imagerie médicale. Il fait une énorme quantité de calculs à l'aide de vecteurs. Il utilise un cluster (30ish cores) et est maintenant allé vers un seul poste de travail avec 500ish GPUS.

Cependant où aller ensuite avec la base de code donc:

• D'autres personnes peuvent le maintenir au cours du prochain cycle de 10 ans
• Accélérez le réglage du logiciel
• Peut fonctionner sur différentes infrastructures sans recompilation

Après quelques recherches de ma part (c'est un domaine super intéressant), certaines options sont:

• Utilisez Python et CUDA de Nvidia
• Réécrivez dans un langage fonctionnel. Par exemple, F # ou Haskell
• Optez pour le cloud et utilisez quelque chose comme Hadoop et Java
• Learn C

Quelle a été votre expérience avec cela? À quoi mon ami devrait-il songer pour moderniser sa base de code?

MISE À JOUR: Merci @Mark et tous ceux qui ont répondu. La raison pour laquelle mon ami pose cette question est que c'est un moment parfait dans le cycle de vie des projets pour faire un examen. La mise à niveau des assistants de recherche dans Fortran prend du temps (j'aime C #, et surtout l'outillage et je ne peux pas imaginer revenir à des langages plus anciens !!)

J'ai aimé la suggestion de garder le nombre pur à croquer dans Fortran, mais de l'envelopper dans quelque chose de plus récent. Peut-être que Python comme cela semble devenir un bastion dans le monde universitaire en tant que langage de programmation à usage général qui est assez facile à comprendre.

Voir Imagerie médicale et un gars qui a écrit un emballage Fortran pour CUDA, Puis-je publier légalement mes emballages Fortran 90 dans la bibliothèque CUFFT de Nvidias (à partir du SDK CUDA)? .

Les demandes que vous avez faites placent en fait Fortran en tête de liste, pour des problèmes comme celui-ci:

a)
calcul des nombres b) paralellable
c) c'était et est toujours la langue de facto enseignée en dehors des études cs (aux ingénieurs qui ne sont pas des programmeurs professionnels).
d) bénéficie d'un incroyable soutien de l'industrie (!), en ce qui concerne le nombre de compilateurs de qualité industrielle, aucun des fournisseurs ne montrant le moindre signe d'abandon de cette branche. Il y a peu, l'un des représentants d'Intel a révélé que les ventes de leurs produits Fortran sont plus élevées que toutes les autres dans leurs outils de développement.

C'est aussi une langue incroyablement facile à comprendre. Je ne suis pas d'accord pour dire qu'il faut du temps pour mettre à jour les assistants de recherche. Mon premier manuel ne contenait pas plus, oh, je ne sais pas, 30 (?) Pages de texte imprimé clairsemé. C'est une langue dans laquelle après avoir appris 10 mots-clés, on peut écrire des programmes de taille moyenne. J'oserais dire que ces 30 pages écrites en texte Word par défaut constitueraient un "manuel Fortran" plus complet pour la plupart des utilisateurs.

Si vous êtes intéressé par CUDA, vous voudrez peut-être vérifier le compilateur de Portland Group , qui le prend en charge . Je ne connais pas les détails les plus fins, mais les gens en parlent généralement avec éloge.

En dehors de cela, pour les programmes en parallèle, vous avez disponible OpenMP, MPI et maintenant les co-matrices à venir (et attendues depuis longtemps), que le compilateur d'Intel a récemment implémentées. Pour ne pas gaspiller ses mots, Fortran dispose d'un gamma très fin de "bibliothèques" pour paralléliser les programmes.

Des bibliothèques numériques standard de l'industrie sont développées pour cela avant tout, d'autres langues suivent plus ou moins dans le portefeuille de fonctions / routines.

Tout cela étant dit, je recommanderais cependant (selon le moment où il a été écrit à l'origine) s'il s'agit, disons, du code F77 ou plus ancien, en le réécrivant partiellement dans le temps vers des dialectes plus récents - F90 au moins, si possible avec les fonctionnalités F2003. Un article / thèse sur ce sujet a été récemment publié (fichier PDF de taille moyenne à venir). Non seulement cela, s'il est fait correctement, garantit la portabilité sur plusieurs plates-formes, mais il facilitera également la maintenance future.

ps En ce qui concerne la "maintenance future", juste une anegdote que j'aime parfois mentionner. Lors de la rédaction de ma thèse, j'ai réutilisé du code de mon mentor, écrit il y a 35 ans à partir du moment de la rédaction. Il a compilé avec une seule erreur; une déclaration manquante à la fin, en raison d'une erreur de copier-coller :)

@DaveMateer (réponse au commentaire) - Je vais faire un commentaire dans ce qui suit qui peut être un peu impoli, mais ne le prenez pas mal, car c'est dans les bonnes intentions.

Il me semble que vous abordez ce «problème» de manière erronée. Ce que je veux dire en quelques points courts (car il est très tard ici, et ma capacité à composer des phrases lisibles (et encore moins compréhensibles) me laisse après 22 heures)

a) vous avez mentionné que vous essayez de minimiser le temps de codage supplémentaire, mais vous envisagez une réécriture d'un langage spécialisé pour l'informatique numérique à un parmi un choix coloré de langues , si vous me pardonnez mon expression

• dont certains ne prennent pas en charge les tableaux multidimensionnels, entre autres
• la plupart d'entre eux ne conviennent pas aux travaux numériques lourds (des capacités de traitement parallèle de Haskell et Hadoop, je l'admets, je n'en sais rien ... mais je ne les ai jamais entendues, même mentionnées dans ces cercles)
• il a peut-être été essayé, mais je n'ai jamais entendu parler d'une réécriture de Fortran, un langage pour les problèmes discrétisés, vers un langage fonctionnel
• il y a eu récemment une discussion sur comp.lang.fortran (essayez de chercher dans les groupes google) sur les aspects du calcul scientifique "dans le cloud"
  (je ne voudrais pas vous démotiver, mais pour être honnête, personne n'était vraiment sûr de ce que ce terme représente même, moins seul avait un exemple d'application réussie. La plupart des gens ont convenu que le potentiel existe mais jusqu'à présent, ils sont satisfaits de la façon dont les choses fonctionnent pour l'instant.). De nombreux problèmes ne conviennent pas non plus à ce type de parallélisation.

b) quels seraient les coûts d'une telle réécriture? personnes / heures.

c) -les versions correctes des bibliothèques à compiler ...- est un problème dans n'importe quelle langue, qui ne peut être évité, quelle que soit la façon dont vous le regardez.

d) J'ai entendu parler de Python (un joli langage vraiment) utilisé dans des applications parallèles à quelques reprises, mais sa pénétration sur ce marché ne semble toujours pas augmenter, et sa nature en constante évolution en fait un choix très mauvais pour un projet à long terme (pensez à la compatibilité descendante). Certaines personnes l'aiment beaucoup comme un langage "collant".

Ugh, si je pense à autre chose, je l'ajouterai demain. Je dois dormir un peu ...

Je doute que Fortran meure un jour - il a un si grand héritage de logiciels et de bibliothèques écrits dedans que les gens y travaillent encore, ne faisant que stabiliser cette situation. De plus, c'est toujours un très bon langage si vous ne voulez rien faire de plus que le calcul des nombres - la syntaxe est très élégante et logique, et le compilateur peut facilement deviner ce qui se passe. Ainsi, il est garanti que toute nouvelle technologie d'accélérateur matériel prendra en charge C, Fortran et une sorte d'OpenCL (quand elle convergerait finalement vers quelque chose de solide).

Je dirais donc que vous devriez juste séparer clairement la partie numérique, la laisser dans Fortran, faire une reliure claire et écrire le reste dans ce que vous voulez.

Python gagne en effet beaucoup de traction dans la communauté informatique scientifique (pour une vue quelque peu dépassée, voir le volume 9 numéro 3 de CiSE ). Je pense qu'un hybride Python / Fortran est une excellente façon de procéder. Afin de profiter de tous ces GPU, vous pouvez utiliser PyCUDA ou PyOpenCL .

Je suis un mathématicien qui analyse et écrit des solveurs numériques pour les équations aux dérivées partielles. J'étais récemment dans une situation similaire à celle de votre ami; le code Fortran 77 en question est le logiciel Clawpack bien connu . Nous avons réécrit le code de niveau supérieur (toutes les parties qui n'ont pas besoin d'être rapides) en Python et avons utilisé f2py pour envelopper automatiquement les parties de bas niveau.

Le résultat vraiment puissant de cela est que nous avons ensuite pu connecter presque trivialement le code hybride Python / Fortran (baptisé PyClaw ) avec la bibliothèque parallèle PETSc, créant pour la première fois une version parallèle évolutive de Clawpack qui fonctionne bien sur des cœurs 65K. Tout le code parallèle que nous avons dû écrire est contenu dans moins de 300 lignes de Python . Nous résolvons maintenant des problèmes qui n'auraient pas pu être résolus uniquement avec le code hérité. Tout aussi important, il est désormais beaucoup plus facile pour les nouveaux utilisateurs de récupérer le code, car Python est un langage tellement convivial et presque tout peut être modifié au moment de l'exécution plutôt qu'au moment de la compilation.

Si vous souhaitez voir plus de détails sur notre approche et nos résultats, nous avons un article sur l'arXiv .

Toutes mes excuses pour l'auto-publicité, mais il semblait que mon expérience personnelle serait pertinente ici. Si vous souhaitez entendre de nombreuses autres idées, vous pouvez également les publier sur le nouveau http://scicomp.stackexchange.com .

Je suis actuellement dans une situation très similaire à celle de votre ami. Je souhaite également "moderniser" mon ancien code KLOC Fortran-77 de 40 ans. Et malgré le fait que Fortran soit toujours considéré comme le roi des applications de calcul numérique, je voudrais dire que tout n'est pas perdu. (Ce qui suit est une diatribe alors soyez indulgent avec moi).

Tout simplement parce que Fortran est le meilleur langage pour le code numérique ne signifie pas que nous devons transporter cet énorme bagage d'un code compliqué et compliqué avec nous tout le temps (Oui, un code Fortran est forcément désordonné, en particulier Fortran-77 qui est un langage qui n'a littéralement aucune considération pour l'ingénierie logicielle, lorsqu'il traverse un certain KLOC). Ceux qui préconisent Fortran pour le calcul des nombres oublient l'observation générale que lorsque vous effectuez une analyse des performances de tels codes, ce n'est que 5% ou 10% du code qui est gourmand en performances et pour les 90% restants + Fortran est une surcharge inutile, juste là pour faire de votre vie "d'ingénieur logiciel" un enfer vivant.

Lorsque vous passez à Fortran-90 à partir de Fortran-77, vous êtes essentiellement disposé à compromis les performances avec les fonctionnalités linguistiques dans une certaine mesure. Fortran est un puissant cruncher numérique principalement à cause de Fortran-77. Vous pourriez dire que Fortran-90 est aussi rapide, mais le type de problèmes d'optimisation que les rédacteurs de compilateurs ont dû traiter tout en ajoutant des fonctionnalités Fortran-90/2003 et en conservant les performances de Fortran-77 ne sont pas très différents des problèmes que les rédacteurs du compilateur C ont dû traiter. avec (et en conséquence C est également considéré comme aussi rapide, sans oublier que C permet également l'assemblage en ligne). Alors pourquoi ne pas commencer à ajouter du code C petit à petit (au lieu de Fortran-90) dans un code Fortran-77. Mon code a déjà des morceaux en C et des morceaux en Fortran-77 et il fonctionne très bien sous réserve de certains problèmes comme le passage de chaînes, l'indexation zéro / une indexation, etc. Mais l'avantage que j'obtiens de C,

J'irais encore plus loin. Même C (et certainement Fortran-90/95/2003) est trop bas si vous voulez une belle interface "humaine" avec un code de calcul de nombres. Je pense à passer à un Python-Fortran-77 ou à un hybride Python-C. Un code dans lequel 90% du code est Python (y compris Numpy, Scipy, la traçabilité et toute cette douceur) et seule la performance intensive 5% -10% reste en code Fortran-77 ou C.

Je suis actuellement en train de mettre à jour une ancienne base de code FORTRAN95 à utiliser sur les environnements industriels modernes car la version précédente ne fonctionnera que sur les machines Windows2000 au plus tard. La base de code FORTRAN elle-même effectue un grand nombre de calculs de nombres impliqués dans les simulations d'irrigation.

Donc, ce que je fais, c'est au lieu de réécrire le FORTRAN dans un langage plus moderne, j'utilise simplement un compilateur commercial appelé Silverfrost FTN95 pour compiler la base de code FORTRAN dans une bibliothèque .Net 4.0 que j'utilise comme backend d'une application WPF . De cette façon, je ne risque pas d'introduire des bogues connus dans le code de simulation et je le modernise en déplaçant la base de code vers le framework .Net 4.0 pour qu'il fonctionne sur des environnements plus modernes.

Mais selon l'ampleur de votre simulation, vous voudrez peut-être simplement réécrire le tout dans un langage plus moderne tel que C #, je prévois moi-même de le faire une fois que j'aurai une version en cours d'exécution de la simulation pour comparer la sortie.

J'espère que mon expérience vous aidera, merci Alex.

J'ai été responsable du développement d'un projet de 2001-2003 qui portait une application Windows 100KLOC de FORTRAN vers C #. C'était une application de calcul de nombre qui avait ses propres liaisons GUI personnalisées aux bibliothèques Win32. Le portage vers C # et WinForms a rendu la gestion du code beaucoup plus simple et a donné à chacun un environnement de développement plus riche dans Visual Studio. Il y a eu pas mal de résistance au début (surtout en termes de déclarations de format), mais en fin de compte, cela en valait vraiment la peine.

À mon avis, il est logique de mordre la balle et de se débarrasser de la quantité maximale de code FORTRAN possible. La vitesse n'a jamais été un problème - les premiers tests exécutant du code en C # par rapport à FORTRAN ont révélé que la différence de performances était négligeable, même si C # exécute du code managé. Vos besoins en vecteurs peuvent cependant être un peu différents, et avoir une quantité minoritaire de code FORTRAN restant serait également acceptable.

Une autre raison de le faire est bien sûr la disponibilité à long terme des personnes ayant une expérience FORTRAN qui peuvent maintenir votre code par rapport aux développeurs C #. De plus, cela aide le moral de l'équipe à travailler dans une langue moderne et bien supportée.

On m'a dit que dans de nombreux contextes, MATLAB remplace FORTRAN pour les applications de calcul scientifique. Non seulement il est moderne et de haut niveau, mais il est également assez rapide dans ce qu'il fait. De nombreux développeurs travaillant sur des logiciels d'imagerie médicale utilisent déjà MATLAB, il dispose donc de plusieurs bibliothèques dédiées à l'imagerie médicale. Cela signifie que vous trouverez à la fois des outils et un support expert de domaine si vous optez pour MATLAB.