Quel est le langage de programmation le plus utilisé dans le calcul haute performance? Et pourquoi? [fermé]

Je crois que beaucoup de Fortran est utilisé dans HPC, mais je ne sais pas si c'est uniquement pour des raisons héritées.

Les fonctionnalités des langages de programmation modernes comme le garbage collection ou le polymorphisme d'exécution ne conviennent pas à HPC car la vitesse est importante, donc vous ne savez pas où C # ou Java ou C ++ entrent en jeu.

Des pensées?

J'ai vu beaucoup de Java utilisé pour HPC dans des domaines où (1) il y a peu de code hérité, et (2) le temps de développement et la qualité du code sont importants. Les domaines d'application typiques sont la finance, l'exploration de données ou la bio-informatique.

Cela dépend vraiment de l'application (il y a de la vie en dehors de l'algèbre linéaire), mais les performances des JVM récentes sont souvent comparables à celles du code C. Parfois plus rapide lorsque la JVM est en mesure d'effectuer à l'exécution des optimisations intelligentes que les compilateurs statiques (C, Fortran) ne peuvent pas faire. Et certainement plus rapide quand il y a beaucoup de calculs symboliques.

Étant donné un temps fixe pour le développement du programme, le code Java résultant est toujours plus rapide que le code C. HPC en Java prend tout son sens lorsque le code est développé ou modifié fréquemment. Une autre caractéristique importante est la mobilité du code sur différents matériels.

Vous trouverez des références dans http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

En ce qui concerne l'hypothèse Fortran selon laquelle deux adresses sont uniques, nous travaillons sur un outil d'analyse statique qui permettra des optimisations similaires pour le code dans les langages de haut niveau, mais sans le bit "Bad Things May Happen". Contactez-moi si vous êtes intéressé.

Dans mes années d'expérience, il y a jusqu'à 5 ans, il a toujours été Fortran et C. Laquelle dépendait principalement de savoir si les gens venaient plus de l'ingénierie ou plus de l'école de pensée CS (je ne sais pas comment mieux mettre cela , ok? :-)

Dans ce que nous faisions, Fortran était presque exclusivement utilisé.

D'après ce que j'ai lu aujourd'hui, avec les nouvelles mises à jour de la norme F2003 / 08 et avec l'introduction de Co-Arrays, il semble reprendre de l'ampleur.

Aussi, un article, sinon un peu biaisé - Le langage de programmation HPC idéal

Je pense que pour une vraie pédale au métal, le seul vrai choix est Fortran. Le raisonnement est que la chose la plus importante pour l'exploitation de l'ILP (Instruction Level Parallism) de bas niveau est la désambiguïsation des adresses mémoire. Les règles de facto de Fortran permettent au compilateur de déterminer que deux adresses sont uniques (et donc l'ordre de chargement et de stockage, ou même les magasins et les magasins peuvent être échangés sans risque de générer un code incorrect). C laisse trop de place aux pointeurs qui se chevauchent pour que le compilateur extrait autant de parallélisme de bas niveau du code.

De plus, l'alignement des tableaux, les lignes de cache wrt et les limites SSE / AVX sont importants pour la génération et l'exécution de boucles efficaces. Si les tableaux sont transmis via des blocs communs, le compilateur / chargeur peut garantir que tous les tableaux démarrent sur les mêmes limites d'alignement d'adresse, et des charges et des magasins SSE / AVX plus efficaces peuvent être utilisés. Le matériel plus récent peut gérer les accès à la mémoire non alignés, mais parce que l'accès à la mémoire n'est pas correctement aligné, une utilisation partielle des lignes de cache entraîne une baisse des performances. Même si un programmeur C aligne correctement tous ses tableaux, existe-t-il un mécanisme pour le communiquer au compilateur?

Pour résumer, les deux problèmes les plus importants sont l'indépendance des adresses mémoire et la reconnaissance par le compilateur que les structures de données consultées ont le même alignement "naturel" que le matériel le souhaite. Jusqu'à présent, Fortran fait le meilleur travail sur ces deux tâches.

Juste une note anecdotique. Je n'ai pas fait de calcul haute performance moi-même.

Pour les calculs (calcul des nombres), Fortran et C. Oui, c'est pour des raisons héritées:

• Grande disponibilité du code source et des recettes du domaine public.
• Les deux prennent en charge MPI .
• Les deux langues sont compilées.
• Les compilateurs pour les deux langues sont fournis par tous les systèmes d'exploitation HPC et les fournisseurs.
• Des compilateurs vectorisateurs sont disponibles.
• Les deux nécessitent un niveau de réglage fou pour obtenir des performances élevées lorsqu'ils sont portés sur un cluster différent (taille de mémoire différente, nombre de processeurs, etc.)
  • Cela explique en fait pourquoi le code open source est important: le peaufinage est nécessaire, donc la recette originale doit être écrite dans un langage qui est bon pour le peaufinage manuel.

La tendance actuelle au resserrement des nombres consiste à écrire des générateurs de programmes qui automatisent le réglage du code source afin d'optimiser les performances compte tenu des caractéristiques du cluster. Ces générateurs produisent souvent en C.

Une deuxième tendance consiste à écrire dans un dialecte spécialisé de C pour des GPU spécifiques ou Cell BE.

Pour les travaux non numériques, tels que les programmes qui traitent les données d'une base de données (mais pas la base de données elle-même), il est beaucoup moins cher de fonctionner sur des grappes de machines "de base" sans les équipements de mise en réseau personnalisés coûteux. Ceci est généralement appelé "High Throughput Computing". Et Python est le langage n ° 1 ici (en utilisant le fameux Map Reduce). Avant Python, les projets de traitement par lots peuvent être écrits dans n'importe quel langage et sont généralement envoyés par Condor .

J'ai travaillé sur du code TRÈS intensif en calculs en (gasp!) C #.

Je construis une implémentation GPGPU de FDTD pour la modélisation optique. Sur un petit cluster (128 processeurs), la plupart de nos simulations prennent des semaines à s'exécuter. Les implémentations GPU, cependant, ont tendance à fonctionner environ 50 fois plus vite - et c'est sur une carte NVidia de qualité grand public. Nous avons maintenant un serveur avec deux cartes à double processeur GTX295 (plusieurs centaines de cœurs), et nous recevrons bientôt des Teslas.

Comment cela se rapporte-t-il à votre langue? De la même manière que le code FDTD C ++ que nous utilisions auparavant était lié au processeur, ceux-ci sont liés au GPU, de sorte que la différence ( très faible) de puissance entre le code géré et le code natif n'entre jamais en jeu. L'application C # agit comme un conducteur - chargeant les noyaux OpenCL, transmettant des données vers et depuis les GPU, fournissant l'interface utilisateur, les rapports, etc. - toutes les tâches qui sont pénibles en C ++.

Au cours des années passées, la différence de performances entre le code managé et le code non managé était suffisamment importante pour qu'il soit parfois utile de supporter le terrible modèle d'objet de C ++ pour obtenir les quelques pour cent de vitesse supplémentaires. De nos jours, le coût de développement de C ++ vs C # dépasse de loin les avantages pour la plupart des applications.

De plus, la plupart de vos différences de performances ne proviendront pas de votre choix de langue, mais des compétences de votre développeur. Il y a quelques semaines, j'ai déplacé une opération de division unique de l'intérieur d'une boucle à triple emboîtement (traversée de matrice 3D), ce qui a réduit le temps d'exécution pour un domaine de calcul donné de 15%. C'est le résultat de l'architecture du processeur: la division est lente, ce qui est l'un de ces visages dont vous avez juste besoin de trouver quelque part.

Fortran est le plus courant, principalement en raison de l'héritage (les gens utilisent toujours l'ancien code) et de la familiarité (la plupart des gens qui utilisent HPC ne connaissent pas d'autres types de langages).

Les fonctionnalités des langages de programmation modernes comme le garbage collection ou le polymorphisme d'exécution ne conviennent pas à HPC car la vitesse est importante, donc vous ne savez pas où C # ou Java ou C ++ entrent en jeu.

Ce n'est pas vrai en général. Le HPC classique faisait principalement de l'algèbre linéaire avec des nombres de précision machine. Cependant, le HPC moderne utilise de plus en plus des superordinateurs pour une plus grande variété de calculs, comme les calculs symboliques avec des expressions mathématiques arbitraires au lieu des nombres de précision de la machine. Cela donne des caractéristiques assez différentes aux outils que vous utilisez et il n'est pas rare d'utiliser des langages de programmation autres que Fortran car le calcul symbolique peut être extrêmement difficile sans GC et d'autres types de compilateur d'optimisation tels que le compilateur de correspondance de modèle d'optimisation d'OCaml.

Par exemple, lisez cet article de Fischbacher et al. qui dit que "les auteurs ont de bonnes raisons de croire que cela pourrait bien être le plus grand calcul symbolique effectué jusqu'à présent".

Fortran, pour des bonnes et des moins bonnes raisons. Pour les calculs mathématiques lourds, une bonne raison est qu'il existe de nombreuses bibliothèques (BLAS, LAPACK) de sous-programmes éprouvés, tous écrits en Fortran (bien que ceux-ci puissent être appelés à partir de C et C ++).

Une raison pas si bonne est l'avantage de performance supposé de Fortran sur C / C ++. Les optimiseurs sont assez bons, et peu de gens comprennent que l'avantage d'optimiser un morceau de code est proportionnel au pourcentage de temps qu'il est occupé, ce qui dans presque tout le code est presque nul.

Une autre raison pas si bonne est un écart de culture entre les programmeurs CS et non CS. Les programmeurs scientifiques ont tendance à apprendre les mauvaises habitudes à Fortran et à mépriser les programmeurs CS et les mauvaises habitudes qui leur ont été enseignées, et qui méprisent les premiers.

Fondamentalement, tous les programmes qui effectuent le travail réel de calcul des nombres sont toujours FORTRAN (les anciens blas, lapack, arnoldi, etc. sont toujours ceux utilisés) ... Cependant, en ce qui concerne la structure de niveau supérieur ... les gens utilisent de plus en plus C ++.

La complexité de la simulation implique un code énorme et pour en tirer un quelconque avantage, il faut le rendre réutilisable. De plus, les concepts utilisés sont également devenus très complexes. C'était presque de la folie de représenter cette information en utilisant FORTRAN. C'est là qu'intervient C ++ car il prend en charge la conception orientée objet. Cependant, le polymorphisme d'exécution est rarement préféré. Au lieu de cela, les gens utilisent presque toujours le polymorphisme statique (qui est implémenté en C ++ avec la méta-programmation de modèle)

De plus, maintenant les compilateurs sont vraiment bons, donc beaucoup d'optimisation est laissée aux compilateurs.

Il y a deux types de problèmes qui doivent être résolus dans les applications HPC: l'un est le nombre de calcul lui-même et l'autre est la gestion des calculs. Le premier est généralement abordé avec du code écrit en Fortran, C ou C ++ en raison de la vitesse et du fait qu'il existe déjà de nombreux algorithmes scientifiques écrits dans ces langages. Le pilotage des calculs est plus facilement implémenté dans les langages de niveau supérieur. Python est un langage de «colle» de choix pour gérer la logique d'application et appeler les extensions implémentées dans les langages compilés. Java est fréquemment utilisé par les projets dans lesquels la gestion des réseaux et de l'informatique distribuée est essentielle.