Cher journal,
À l'instar de l'ami omc qui te partageait ses polycops de cours sur "Python for science", je vais moi aussi te parler de Python à travers le prisme de la cristallographie. Mais qu'est ce donc que la cristallographie vas-tu me demander. Historiquement il s'agit d'une discipline qui vise à déterminer la structure atomique (nature et ordonnancement des atomes) de la matière. Cette discipline est en fait à l'intersection d'un très grand nombre de domaines (physique, chimie, biologie,…) comme en témoigne, par exemple, la variété des prix Nobels décernés en lien avec cette discipline (découverte du graphène, de la structure de l'ADN, de la diffusion des neutrons, etc. etc.).
Sans être un expert, on peut aisément voir arriver la complexité calculatoire : nous avons affaire à des atomes et leur distribution dans l'espace, ce qui, même pour des objets tout petits (par exemple quelque micromètres cubes) en représente un nombre colossal. À titre d'exemple, un processeur Intel Xeon contient 10 000 milliards de milliards d'atomes de silicium. Évidemment, au cours de l'histoire plusieurs approximations ont permis de modéliser la matière sans avoir à explicitement prendre en compte autant d'atomes simultanément. Néanmoins, la tendance ces dernières années est de s'affranchir progressivement de ces approximations, tendance rendue possible par la démocratisation de processeurs et co-processeurs de plus en plus performants.
J'en viens maintenant à Python. Ce langage, associé aux bibliothèques NumPy et SciPy (ainsi que les innombrables scikits spécialisés), est devenu le standard de fait pour le calcul scientifique dans un très grand nombre de domaines. Pour ce qui concerne le calcul scientifique, le principal inconvénient de Python vanilla est le coté typage dynamique/interprété qui annihile complètement les performances. NumPy permet d'en atténuer les conséquences en introduisant le calcul vectoriel et ainsi s'affranchir de l'écriture de boucles. Cependant, pour de très grands vecteurs, ou tout simplement pour des cas où le code ne peut être vectorisé, NumPy n'est pas d'une grande aide. C'est là où interviennent des compilateurs dont l'objectif est de transformer le code python en "code natif" typé statiquement. Dans l'article que j'ai le plaisir de partager ici ( https://hal.archives-ouvertes.fr/hal-02194025v2 ) nous abordons 4 de ces compilateurs:
- NumExpr
- Numba
- Pythran
- Cython
Je suis d'autant plus flatté de parler de ce sujet ici car, du fait de sa syntaxe simple et ses excellentes performances, Pythran est de loin mon favori, et je sais que son créateur traîne ses guêtres par ici. L'article fait une comparaison systématique de ces compilateurs pour 4 exemples qui parleront aux cristallographes, mais pas seulement : évaluation de séries de Fourier, de distances euclidiennes, etc. L'article est accompagné de notebooks Jupyter qui permettront aux lecteurs intéressés de reproduire les calculs. L'idée est de fournir une base de démarrage pour les nouveaux venus à la programmation Python et au calcul haute performance au sein de notre laboratoire (étudiants ou doctorants principalement). Mais cela peut peut-être être utile à un public plus varié, d'où ce journal.
Pour résumer les conclusions de l'article :
- NumExpr: syntaxe très simple (proche de Numpy), performances moyennes (meilleures que Numpy mais moins bonnes que les autres)
- Numba & Pythran: syntaxe simple, excellentes performances. Bonus pour pour Pythran qui présente des performances plus stables et plus reproductibles.
- Cython : excellentes performances et probablement le plus versatile, mais syntaxe lourde (pour un simple scientifique)
# coucou
Posté par barmic 🦦 . Évalué à 4.
Hey l'ESRF ! J'avais failli faire un stage chez vous il y a quelques années :)
L'article est super intéressant et facile d'accès :) Par contre vous parlez de HPC pour ce qui n'en est pas, non ? Pour moi le HPC c'est tout le domaine des supercalculateurs, non ?
C'est super d'avoir les notebook avec :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: coucou
Posté par aboulle . Évalué à 3.
Merci. Il me semblait qu’on pouvait utiliser l’expression « calcul haute performance » dés lors qu’on faisait du parallélisme (cf le slogan de openmp par exemple). Cela étant dit, n’étant pas spécialiste de HPC je reconnaîtrai aisément être dans l’erreur sur ce point :-)
# Julia ?
Posté par Jean-Baptiste Faure . Évalué à 5.
Est-ce que vous avez testé ou évalué Julia ou envisagé de le faire ?
[^] # Re: Julia ?
Posté par aboulle . Évalué à 5.
Dans cette étude nous n’avons pas utilisé Julia. A titre personnel je regarde ce langage du coin de l’oeil car je n’ai lu et entendu que des choses intéressantes à son propos. Cela étant dit Python a l’avantage de l’antériorité. Du coup, même pour des domaines (scientifiques ou non) très restreints, qui ne concernent au final qu’un nombre extrêmement faible d’utilisateurs, on trouve très aisément des bibliothèques tierces particulièrement utiles.
[^] # Re: Julia ?
Posté par kif . Évalué à 3.
Julia est un langage vraiment cool ! J'adore ce coté Just In Time et j'avais vraiment envie de m'y mettre. Puis j'ai testé numba, et les deux ont le même usage à mes yeux avec les avantages de Python en plus pour numba (et mes 20+ années de pratique).
# versatile ?
Posté par Tit . Évalué à 0.
ça signifie quoi versatile dans ce contexte ?
c'est un anglicisme ? polyvalent ? universel ?
http://www.academie-francaise.fr/versatile-pour-polyvalent
[^] # Re: versatile ?
Posté par Pol' uX (site web personnel) . Évalué à -4.
Tes questions sont elles vraiment des questions ? Pourquoi ne commencent-elles pas par des majuscules ?
Adhérer à l'April, ça vous tente ?
[^] # Re: versatile ?
Posté par Tit . Évalué à 1. Dernière modification le 04 septembre 2019 à 08:51.
Oui ce sont de vraies questions, je n'ai pas compris la phrase, puisque la phrase est en français je l'ai lue avec le(s) sens français du mot versatile. De plus je suis assez nul en anglais, et jusqu'ici je n'avais jamais lu/entendu le mot versatile associé à un "langage".
Pour les majuscules, bof, c'est juste un peu de flemme et pour gagner du temps, mais j'ai l'impression que ça ne pose aucun problème de lecture ou de compréhension de ne pas les mettre ;-)
# flagornerie
Posté par serge_sans_paille (site web personnel) . Évalué à 4.
>^-^<Malgré le plaisir coupable que j'ai à lire ces lignes, je me demande si cela introduit un biais dans la mise en oeuvre de la comparaison ? Il est tellement facile d'obtenir ce que l'on veut quand on sait ce que l'on cherche.
Ceci dit, avec le même biais que toi, j'arrive aux mêmes conclusions. Cython est un chouette langage hybride, il perd en investissement de départ et en pérennité de cet investissement ce qu'il gagne en flexibilité. Numba fournit un JIT ce qui le rend facile d'accès, mais à un support moindre des fonctions haut niveau de Numpy.
[^] # Re: flagornerie
Posté par freejeff . Évalué à 2. Dernière modification le 04 septembre 2019 à 07:39.
Salut Serge,
J'en profite de te voir ici pour te poser une question qui en plus, n'est pas du tout hors sujet.
Lorsque l'on fait du numpy, on utilise énormément linalg. Pour le moment, il n'y a pas grand chose de supporté. Penses tu pouvoir ajouter des fonction comme la diagonalisation avec eig ou autre opération tensorielle, inversion …
C'est vraiment des outils qu'il est très difficile de contourner et qui rend le portage de code complexe.
[^] # Re: flagornerie
Posté par serge_sans_paille (site web personnel) . Évalué à 4.
https://github.com/serge-sans-paille/pythran/issues/155 ouvert en 2013 :-) Il y a du travail, c'est sûr… je ne sais pas quoi te dire de plus, je comprends l'importance de ce dev, je n'ai juste pas le temps nécessaire pour rentrer de dans tout de suite. Une grosse envie de contribuer poindrait-elle en toi ?
[^] # Re: flagornerie
Posté par freejeff . Évalué à 2.
J'adorerais, mais mon niveau en programmation C++ est proche du néant …
[^] # Re: flagornerie
Posté par Nicolas Boulay (site web personnel) . Évalué à 4. Dernière modification le 05 septembre 2019 à 13:11.
Peut être qu'un truc simple type plugin ou lib d'intégration pourrait aider ceux qui n'y connaisse pas grand chose en c++ ?
Est-ce que g'mic pourrait aider ? ( https://linuxfr.org/news/g-mic-2-7-0-une-rentree-pleine-de-style-pour-le-traitement-d-images )
Si j'ai bien compris il faudrait recoder certaine fonction d'algèbre linéaire présent dans une lib qui ne va pas bien avec C++. G'mic en propose déjà en C++, est-ce qu'il serait possible de l'utiliser à la place ?
"La première sécurité est la liberté"
[^] # Re: flagornerie
Posté par serge_sans_paille (site web personnel) . Évalué à 3.
Un mécanisme de plugin est envisageable, mais je crains que cela ne change rien à la difficulté intrinsèque de l'exercice, qui doit beaucoup, avouons-le, à l'absence de documentation de haut niveau sur
pythonic, mais pas que.Pour le moment, plutôt que G'mic, la tendance serait de se rapprocher de xtensor qui a l'avantage d'être header-only (ça facilite la distribution)
# coucou(bis)
Posté par omc . Évalué à 6.
\o/ :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.