Concernant la MKL: entre 10 et 20% est écrite en ASM. Le reste est du C « de base » (car le compilateur peut correctement générer du code de bonne qualité), compilé en plusieurs versions (avec/sans OpenMP, ILP32 ou ILP64, etc.).
Cependant, l'écriture de codes numériques nécessitent une bonne connaissance en physique, mathématique, informatique
Pas d'accord. Enfin pas tout à fait. J'ai besoin d'avoir accès à un physicien/mathématicien lorsqu'il s'agit d'optimiser un code et de vérifier que je ne mets pas en danger la stabilité numérique ou la convergence d'un algo (dans le cas d'une méthode itérative). Mais s'il est toujours utile de connaître un minimum le domaine d'application d'un programme (e.g. éléments finis, etc.), dans 90% des cas, ce que je dois savoir en tant qu'infoteux bas-niveau, c'est comment sont représentés les flottants « normalisés » (IEEE 754) en 32, 64, et 80 bits et « dénormalisés » (spécifiques à l'archi, et souvent lents). Le reste, c'est purement un problème de compilation/optimisation largement à ma portée.
Tu as raison de dire que le temps est limité pour un ingé/scientifique, et qu'il faut donc faire des choix. Mais le problème est que les physiciens/matheux/bla ont eu à « devenir » programmeurs d'un côté pour pouvoir coder leurs modèles (ce qui est très bien), mais aussi à se préoccuper de la machine en dessous (ce qu'ils ne devraient JAMAIS avoir à faire dans l'idéal).
Il existe tout un tas d'efforts en ce moment pour correctement procéder à la séparation de rôles (« separation of concerns », je ne sais pas bien comment le traduire) : d'un côté le physicien/mathématicien qui code son modèle (le langage importe peu), et de l'autre le « tuning expert » qui connaît la machine cible et sait comment correctement causer au compilateur et à la machine en règle générale. Par exemple, il existe les Concurrent Collections (CnC), création dans un labo d'Intel à la base pour le langage C++, mais dont la spécification a donné lieu à des implémentations en Python, Java, etc. Le principe est simple : on écrit son code par « étapes » (steps). Chaque étape doit être une fonction_pure (i.e. le résultat doit être le même à chaque fois que la fonction doit traiter des données identiques, et qui n'a pas d'effet de bord). Le programmeur d'application doit ensuite écrire comment les différentes étapes sont coordonnées, en exprimant explicitement les relations de dépendance de contrôle et de données entre étapes.
J'ai écrit un code de 30 000 lignes il y a 2 ans en Fortran 2003 (orienté objet) + OpenMP + MPI + MKL. Si c'était à refaire, je choisirai à nouveau ce langage. Alors laissez nous le Fortran. Merci.
Là-dessus je te rejoins parfaitement. Le meilleur langage pour programmer quelque chose, c'est celui où tu te sens à l'aise. N'ayant eu que des codes F77 ou F90 "non objet" me passer sous les yeux, je t'avoue que j'ai versé quelques larmes de sang, mais c'était loin d'être aussi terrible que ce qu'on m'avait décrit (bon, les boucles avec étiquettes numériques en F77, ou les blocs COMMON, je m'en serais bien passé).
[^] # Re: mélange de langage ?
Posté par lasher . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 4.
Concernant la MKL: entre 10 et 20% est écrite en ASM. Le reste est du C « de base » (car le compilateur peut correctement générer du code de bonne qualité), compilé en plusieurs versions (avec/sans OpenMP, ILP32 ou ILP64, etc.).
Pas d'accord. Enfin pas tout à fait. J'ai besoin d'avoir accès à un physicien/mathématicien lorsqu'il s'agit d'optimiser un code et de vérifier que je ne mets pas en danger la stabilité numérique ou la convergence d'un algo (dans le cas d'une méthode itérative). Mais s'il est toujours utile de connaître un minimum le domaine d'application d'un programme (e.g. éléments finis, etc.), dans 90% des cas, ce que je dois savoir en tant qu'infoteux bas-niveau, c'est comment sont représentés les flottants « normalisés » (IEEE 754) en 32, 64, et 80 bits et « dénormalisés » (spécifiques à l'archi, et souvent lents). Le reste, c'est purement un problème de compilation/optimisation largement à ma portée.
Tu as raison de dire que le temps est limité pour un ingé/scientifique, et qu'il faut donc faire des choix. Mais le problème est que les physiciens/matheux/bla ont eu à « devenir » programmeurs d'un côté pour pouvoir coder leurs modèles (ce qui est très bien), mais aussi à se préoccuper de la machine en dessous (ce qu'ils ne devraient JAMAIS avoir à faire dans l'idéal).
Il existe tout un tas d'efforts en ce moment pour correctement procéder à la séparation de rôles (« separation of concerns », je ne sais pas bien comment le traduire) : d'un côté le physicien/mathématicien qui code son modèle (le langage importe peu), et de l'autre le « tuning expert » qui connaît la machine cible et sait comment correctement causer au compilateur et à la machine en règle générale. Par exemple, il existe les Concurrent Collections (CnC), création dans un labo d'Intel à la base pour le langage C++, mais dont la spécification a donné lieu à des implémentations en Python, Java, etc. Le principe est simple : on écrit son code par « étapes » (steps). Chaque étape doit être une fonction_pure (i.e. le résultat doit être le même à chaque fois que la fonction doit traiter des données identiques, et qui n'a pas d'effet de bord). Le programmeur d'application doit ensuite écrire comment les différentes étapes sont coordonnées, en exprimant explicitement les relations de dépendance de contrôle et de données entre étapes.
Là-dessus je te rejoins parfaitement. Le meilleur langage pour programmer quelque chose, c'est celui où tu te sens à l'aise. N'ayant eu que des codes F77 ou F90 "non objet" me passer sous les yeux, je t'avoue que j'ai versé quelques larmes de sang, mais c'était loin d'être aussi terrible que ce qu'on m'avait décrit (bon, les boucles avec étiquettes numériques en F77, ou les blocs
COMMON, je m'en serais bien passé).