C ++ vs Fortran pour HPC

Dans mon programme de doctorat en sciences informatiques, nous travaillons presque exclusivement en C ++ et en Fortran. Il semble que certains professeurs préfèrent l'un à l'autre. Je me demande lequel est 'meilleur' ​​ou si l'un est meilleur que l'autre dans certaines circonstances.

Comme souvent, le choix dépend (1) du problème que vous essayez de résoudre, (2) des compétences que vous avez et (3) des personnes avec qui vous travaillez (sauf s’il s’agit d’un projet solo). Je vais laisser (3) de côté pour le moment car cela dépend de la situation de chacun.

Dépendance au problème: Fortran excelle dans le traitement des matrices. Si votre problème peut être décrit en termes de structures de données simples et de tableaux, Fortran est bien adapté. Les programmeurs Fortran finissent par utiliser des tableaux même dans des cas non évidents (par exemple pour représenter des graphiques). C ++ convient mieux aux structures de données complexes et hautement dynamiques.

La compétence dépend: il faut beaucoup plus d’expérience de programmation pour écrire de bons programmes C ++ que pour écrire de bons programmes Fortran. Si vous débutez avec une expérience limitée en programmation et que vous disposez de moins de temps pour apprendre cet aspect de votre travail, vous obtiendrez probablement un meilleur retour sur investissement en apprenant Fortran qu'en apprenant le C ++. En supposant, bien sûr, que votre problème convient à Fortran.

Cependant, la programmation ne se limite pas à Fortran et à C ++. Je recommanderais à quiconque se lancer dans la science informatique de commencer avec un langage dynamique de haut niveau tel que Python. Rappelez-vous toujours que votre temps est plus précieux que le temps de calcul!

Je pense que C ++ et Fortran sont assez bons et fonctionnent bien.

Cependant, je pense que Fortran convient mieux au calcul scientifique numérique , aux algorithmes pouvant être exprimés à l'aide de tableaux et ne nécessitant pas d'autres structures de données sophistiquées, donc dans des domaines tels que les différences / éléments finis, les solveurs PDE, les calculs de structure électronique. Fortran est une langue spécifique à un domaine. En particulier, je pense qu'il est plus facile d'écrire des programmes rapides en Fortran qu'en C ++, par un scientifique (pas nécessairement un expert en informatique).

C ++ est un langage polyvalent, donc on peut y exprimer n'importe quel algorithme, et c'est certainement mieux pour les algorithmes qui ne peuvent pas être exprimés en utilisant des tableaux, à partir du champ HPC, probablement des graphes, des générateurs de maillage, des manipulations symboliques, etc.

Il est également possible d'écrire des algorithmes de tableaux en C ++, mais selon mon expérience, cela demande beaucoup plus de connaissances en informatique et en général plus de travail (par exemple, il faut créer ou réutiliser des classes pour la manipulation de tableaux, et gérer manuellement la bibliothèque comme Teuchos de Trilinos). Les non-experts ont tendance à écrire de très bons programmes Fortran, mais des programmes C ++ horribles (parlant de ma propre expérience).

Disclaimer: Personnellement, j'aime beaucoup Fortran et je le préfère au C ++ pour l'informatique numérique. J'ai passé plus de 2 ans en programmation C ++ tous les jours et presque une année en Fortran moderne (dans la zone des éléments finis). J'utilise aussi beaucoup Python et Cython.

Je lance également mes deux cents en retard, mais je viens tout juste de voir ce fil et je sens que, pour la postérité, il y a quelques points qui doivent absolument être abordés.

Notez dans la suite que je parlerai de C et non de C ++. Pourquoi? Autrement, c’est aux pommes et aux oranges de comparer un langage orienté objet à typage dynamique à part entière avec un objet aussi statique que Fortran. Certes, certaines implémentations modernes des dernières normes Fortran peuvent faire plus que cela, mais très peu de personnes les utilisent réellement. Ainsi, lorsque nous parlons de Fortran, nous pensons à un langage simple, statique et impératif. C est là où C est aussi, je vais donc remplacer C par C ++ pour ce qui suit.

Tout d’abord, toute discussion sur le fait que Fortran / C ait de meilleurs compilateurs est sans objet. Les compilateurs C / Fortran dédiés appartiennent au passé. Gcc / gfortran et icc / ifc ne sont que deux frontaux distincts, c’est-à-dire que votre programme sera transformé en une description abstraite par le front-end, puis optimisé et assemblé par le back-end. Si vous écrivez sémantiquement le même code en Fortran ou en C, le compilateur produira dans les deux cas le même assemblage qui fonctionnera tout aussi rapidement.

Ceci mène maintenant à mon deuxième point: pourquoi voyons-nous encore des différences? Le problème est que la plupart des comparaisons sont faites par les programmeurs Fortran qui essayent quelque chose en C ou vice-versa. Avez-vous déjà remarqué comment la plupart des auteurs ou des poètes préfèrent écrire dans leur langue maternelle? Voudriez-vous écrire de la poésie dans une langue dans laquelle vous ne vous sentez pas totalement confiant ou chez vous? Bien sûr que non ... Je considère moi-même que C est mon langage de programmation "natif". Cependant, j'ai également passé trois ans à travailler dans un groupe utilisant uniquement le Fortran, dans lequel j'ai atteint un certain niveau de fluence. Cependant, je n’écrirais jamais rien seul à Fortran car je suis plus à l’aise avec C et, par conséquent, le code obtenu sera meilleur , quelle que soit votre définition.

Donc, la principale différence réside dans le programmeur, pas dans la langue. Donc, il n'y a pas de différences? Pas tout à fait. Voici quelques exemples:

• SIMD: Qu'il s'agisse de SSE, SSE3 ou AltiVec, si vous souhaitez les utiliser dans Fortran, espérez mieux que le compilateur devine exactement ce que vous voulez et le fasse ainsi. Bonne chance. En C, vous avez généralement des fonctions intrinsèques pour chaque architecture ou, plus récemment, des types de vecteurs SIMD généraux dans gcc . La plupart des compilateurs Fortran n'utilisent que les instructions SIMD pour dérouler les boucles, mais si vous avez un noyau qui fonctionne sur des vecteurs courts de données de manière non évidente, le compilateur ne le verra probablement pas.

• Différentes architectures matérielles: Toute l'architecture CUDA est construite autour de noyaux en C. Le groupe Portland dispose désormais d'un compilateur fortran compatible CUDA , mais il est commercial et surtout, il ne provient pas de NVIDIA. Il en va de même pour OpenCL, pour lequel le meilleur que j'ai pu trouver est un projet récent qui ne prend en charge que quelques appels de base.

• Programmation parallèle: Oui, MPI et OpenMP fonctionnent parfaitement avec C et Fortran. Cependant, si vous voulez un réel contrôle de vos threads, c'est-à-dire que si vous avez un calcul de mémoire partagée entièrement dynamique, vous serez dans le froid avec Fortran. En C, vous avez les pthreads standards qui, sans être chauds et confus, vous permettront quand même de traverser la tempête. En général, la plupart des calculs reposant sur l'accès au système d'exploitation, tels que les threads, les processus, le système de fichiers, etc., sont mieux gérés avec C. Oh, et n'essayez pas de créer votre propre réseau avec Fortran.

• Facilité d'utilisation: Fortran est plus proche de Matlab que C Une fois que vous avez défini tous les différents mots-clés et comment déclarer des variables, le reste du code ressemble à Matlab, ce qui le rend plus accessible aux utilisateurs ayant une expérience limitée de la programmation.

• Interopérabilité: lorsque vous créez une structure en C, la présentation des données réelles est directe et déterministe. En Fortran, si vous utilisez des tableaux de pointeurs ou des données structurées, la présentation réelle des données dépend fortement du compilateur, non directe, et est généralement non documentée. Vous pouvez appeler C depuis Fortran et vice-versa, mais ne commencez pas à penser qu'il peut être aussi facile de faire passer autre chose qu'un tableau statique de l'un à l'autre et inversement.

Tout cela est un peu geek, de bas niveau, mais c'est de l'informatique haute performance dont nous parlons, n'est-ce pas? Si vous ne souhaitez pas exploiter au mieux les paradigmes matériels sous-jacents, c'est-à-dire implémenter et / ou développer les meilleurs algorithmes pour la mémoire partagée / distribuée, les threads, la vectorisation SIMD, les GPU utilisant SIMT, etc. je fais juste des maths sur un ordinateur.

Cela a pris beaucoup plus de temps que tout ce que je pensais, alors voici un résumé - un ensemble de messages à emporter:

• Vous écrirez le meilleur code que vous pouvez dans la langue que vous connaissez le mieux.
• Il n'y a aucune différence dans la qualité du code produit par deux compilateurs qui utilisent le même back-end - c'est nous qui écrivons du mauvais code dans une langue ou une autre.
• Bien qu’il se sente plus bas niveau, Fortran est une abstraction assez élevée et ne vous permettra pas d’accéder directement à certaines fonctionnalités matérielles / OS, telles que SIMD, threads, réseaux, etc.

De mes 15 années de réflexion sur les logiciels scientifiques: si votre code est 25% plus rapide parce que vous l'écrivez en Fortran, mais que vous l'écrivez 4 fois plus longtemps (pas de STL, difficulté à mettre en œuvre des structures de données complexes, etc.), alors Fortran gagne uniquement si vous passez une fraction importante de votre journée à tordre les pouces et à attendre que vos calculs soient terminés. Étant donné que, pour presque tous, le plus précieux est notre temps, voici la conclusion: utilisez le langage qui vous permet de développer, de déboguer et de tester votre code le plus rapidement possible, en ne tenant pas compte du fait que cela peut être plus lent que possible. vous l'avez écrit en Fortran.

Mon approche a été d’utiliser le C ++ pour tout sauf les noyaux informatiques, qui sont généralement mieux écrits en assembleur; Cela vous permet d'acquérir toutes les performances de l'approche HPC traditionnelle, mais vous permet de simplifier l'interface, par exemple en surchargeant les noyaux informatiques tels que SGEMM / DGEMM / CGEMM / ZGEMM en une seule routine, par exemple Gemm. Il est clair que le niveau d'abstraction peut être beaucoup plus élevé en évitant les pointeurs bruts et en basculant vers des classes opaques, mais il s'agit d'une première étape intéressante.

Je trouve que le plus gros inconvénient du C ++ est en grande partie l'augmentation du temps de compilation, mais, d'après mon expérience, les économies de temps de développement compensent largement. Un autre inconvénient est que les compilateurs C ++ des fournisseurs ont tendance à avoir plus de bogues que les compilateurs C et Fortran. Au cours de la dernière année, je pense avoir rencontré près de dix bogues dans les compilateurs C ++.

Cela dit, je pense que la suppression des paquets scientifiques écrits dans des langages de bas niveau (et Fortran) est la réticence à exposer des interfaces pratiques pour des structures de données sophistiquées: la plupart des gens sont satisfaits de l’interface BLAS Fortran, car elle ne nécessite que les pointeurs et les dimensions principales pour décrire les matrices, mais peu de gens diraient que l'interface habituelle du résolveur Fortran à 40 unités de Fortran est plutôt pratique (cf. UHM, SuperLU, PETSc et Trilinos).

En résumé, je préconise l'utilisation d'assembly pour les noyaux de calcul de bas niveau, mais les langages de niveau supérieur pour tout le reste, en particulier lorsque vous utilisez des structures de données non triviales.

$y := \alpha x + y$

Depuis que je suis nouveau ici, je parcourais d’anciennes questions et j’ai trouvé celle-ci. Espérons que ce n'est pas tabou de répondre aux anciens!

Étant donné que personne d'autre n'a mentionné cela, j'ai pensé que je le ferais. Fortran 2003 est presque entièrement supporté par la plupart des grands compilateurs (intel, ibm, cray, NAG, PCG) et même par gcc avec la (bientôt) future version 4.7. Fortran 2003 (et 2008) est un langage orienté objet, bien qu'un peu plus détaillé que le C ++. Une des choses qui me plaisent à propos de Fortran est le fait que le comité standard considère le calcul scientifique comme son public principal (je remercie Damian Rouson de me l'avoir signalé l'autre jour).

Je soulève cette question non pas pour que les programmeurs C ++ deviennent des programmeurs Fortran, mais pour que les gens de Fortran sachent qu’ils disposent de davantage d’options, outre le passage au C ++ ou l’émulation de concepts orientés objet dans Fortran 90/95.

J'ajouterai une mise en garde: il y a un coût à être à la pointe de ce qui est implémenté dans les compilateurs. Si vous entreprenez actuellement un projet majeur dans Fortran 2003, vous rencontrerez des bogues et devrez continuellement mettre à jour votre compilateur (surtout si vous utilisez gcc), bien que cela se soit considérablement amélioré au cours des derniers mois!

Le problème avec C ++ est que vous avez de nombreuses chances de ruiner les performances, par exemple en utilisant aveuglément STL, des exceptions, des classes (surcharge virtuelle et problèmes d'alignement), une surcharge d'opérateurs (nouvelles suppressions / redondances) ou des modèles (compilation sans fin et erreurs cryptiques). semble bénigne, mais vous pouvez perdre des heures de cette façon).

Cependant, plus vous aurez un meilleur accès aux bibliothèques générales et éventuellement une plus grande visibilité de votre code (même si cela dépend fortement du champ et que vous avez toujours du C pur). Et vous pouvez toujours compenser le manque de flexibilité de Fortran en enveloppant son code dans un langage de script tel que R, Lush, Matlab / Scilab ou même Python, Ruby ou Lua.

Trois faits:

• Matrices n-dimensionnelles de style F77 en C: pas de problème avec CnD (un plug éhonté, certes)

• Le système de modules du F90 est mal conçu et hostile à la création d’environnements. (Le nom d'un module ne doit pas nécessairement correspondre à son nom de fichier, par exemple)

• Fortran ne supporte pas bien la refactorisation. Pour extraire quelques fonctionnalités d'une fonction, vous devez toucher quatre emplacements: code réel, déclarations de variables, déclarations d'arguments et liste d'arguments. C se débrouille avec deux endroits à toucher. Cela aggrave l'effet de l'incapacité à bien gérer les données (décrit ci-dessous): Comme la modularité à petite échelle est si pénible, presque tout le monde écrit des sous-routines gigantesques.

Une impression personnelle:

• Fortran ne fonctionne pas bien pour gérer les données. Essayez de renvoyer un pointeur sur une structure de données opaque pour l'utilisateur dans F77 ou F90. ( transfer(), nous voilà)

Fortran est optimisé pour les calculs matriciels / matriciels et constitue une tâche ardue pour tout type d’analyse de texte. C et C ++ peuvent ne pas correspondre à Fortran en informatique numérique (c'est proche), mais je trouve qu'il est beaucoup plus facile de traiter du texte et d'organiser des données (c'est-à-dire des structures de données personnalisées) avec C / C ++.

Comme d'autres l'ont mentionné, ne comptez pas les langages interprétés dynamiques (Python et autres). Ils n'offrent peut-être pas la vitesse de fonte du visage de Fortan, mais ils vous permettent de vous concentrer davantage sur la résolution de votre problème de calcul que sur tous les détails de la mise en œuvre. Vous pouvez souvent implémenter une solution en Python et, si les performances sont inacceptables, procéder à un profilage, identifier les zones à problèmes et optimiser ce code à l'aide de Cython ou réimplémenter le programme complet dans un langage compilé. Une fois que vous avez défini la logique de résolution de problèmes, le reste n’est qu’une implémentation et, avec une bonne compréhension des bases de l’informatique, il devrait être simple à représenter dans n’importe quel langage de programmation.

Je travaille actuellement dans l'un des laboratoires nationaux. La plupart des gens autour de moi sont des ingénieurs en mécanique. En discutant avec des membres des groupes HPC, ils travaillent principalement sous Linux et principalement en C ++. Le groupe dans lequel je suis actuellement fait principalement des applications de bureau et nous utilisons Windows et par ordre décroissant: C #, FORTRAN, Python, VBA et VB (6, pas .NET). Certains des moteurs de simulation que nous utilisons ont été écrits dans d'autres laboratoires nationaux de FORTRAN.

Désolé de creuser un vieux fil, mais il semble que même en 2015, Fortran soit beaucoup utilisé.

Je viens de tomber sur cette liste ( lien alternatif ) qui contient en gros une liste de 13 codes approuvés par le centre OCLF du DOE pour fonctionner sur la machine Summit à 300 petaFLOPS qui sera mise à la disposition des chercheurs en 2018. J'ai essayé de trouver la langue principale utilisée pour le code (basé sur une recherche rapide sur Google) et voici ce que j'ai trouvé:

XGC Fortran

SPECFEM Fortran

ACME Fortran (Bunch of climate codes)

DIRAC Fortran (Mostly)

FLASH Fortran

GTC Fortran

HACC C/C++

LS-DALTON Fortran (some C)

NAMD C/C++

NUCCOR Fortran

NWCHEM Fortran

QMCPACK C++

RAPTOR Fortran

Donc, sur 13 codes, au moins 10 (sur la base de ma recherche rapide) semblent être écrits en Fortran. Pas mal pour une langue de 50 ans.

NOTE: Je suis bien conscient que les comparaisons de langue sont inutiles, mais étant donné le nombre de personnes (spécialement les utilisateurs de C ++) qui utilisent Fortran de mauvaise bouche, j'ai pensé qu'il pourrait être utile de le mentionner.

Ce que Jack P. essaie de dire, c'est que vous devriez mélanger et assortir. Un bon logiciel est soigneusement mis en couches. Différentes couches peuvent correspondre plus naturellement ou plus efficacement à différentes langues. Vous devez choisir la langue la plus appropriée pour chaque couche. Vous devez également comprendre comment les langues peuvent interagir, ce qui peut affecter la langue que vous choisissez pour quel calque.

Une meilleure question est de savoir quels exemples de logiciels parfaitement conçus méritent d’être étudiés pour apprendre à concevoir des logiciels en couches.