Journal pythran 0.9.12 - heskenn

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
23
14
juil.
2021

Demat' iNal,

je ne suis plus aussi diligent dans mes annonces de sortie de Pythran, mais j'ai quelques anecdotes à raconter pour la version 0.9.12 sortie hier, donc je me lance.

Petit rappel : Pythran est un compilateur pour noyaux de calcul scientifique écrit en Python. Il transforme ces derniers en code natif ne faisant appel à l'interpréteur qu'aux frontières avec le code interprété (pour la conversion entre objets Python et objet natifs), et peut générer du code vectoriel et/ou multi-threadé (via des directives OpenMP).

Un code Pythran typique ressemble à ceci :

import numpy as np

#pythran export _sum_abs_axis0(float[:,:])
def _sum_abs_axis0(X):
    block_size = 2**20
    r = None
    for j in range(0, X.shape[0], block_size):
        y = np.sum(np.abs(X[j:j+block_size]), axis=0)
        if r is None:
            r = y
        else:
            r += y
    return r

La dernière release de Scipy utilise Pythran pour compiler quelques uns de ces noyaux de calcul. C'est un gros "utilisateur" de Pythran et ça apporte son lot de défi technique. Par exemple Pythran dépend de networkx (lib de graphe) qui dépend depuis peu de Scipy. Hop une dépendance circulaire que l'on a cassée en extrayant le (très petit) sous ensemble de networkx dont nous avions besoin dans un module embarqué dans pythran.

Autre plaisir : Scipy est utilisé sous AIX, et nous n'avions jamais eu le plaisir de nous attaquer à cette plateforme dans Pythran. Fort heureusement les parties spécifiques à l'architecture matérielle sont relégée au compilateur final par Pythran, donc ce port s'est effectué sans douleur.

Sous Windows, le choix a été fait de ne reposer que sur clang-cl pour l'étape de compilation finale, MSVC et le C++ moderne, ça reste une source de déception sans fin pour moi, j'ai remonté plusieurs bugs puis juste abandonné l'idée…

Depuis que Pythran est dans Fedora, nous suivons avec plus de zèle les dernières versions de Python, qui apportent parfois des changements dans l'AST et par conséquence dans Pythran. Fort heureusement, deux petits paquest, gast et beniget, abstraient la majorité des changements, ils ont subit une mise à jour dernièrement et Pythran en tire parti.

Voilà un bien joli défilé de nouvelles, les plus curieux s'empresseront de décorticer le changelog

  • # Je compatis...

    Posté par  (Mastodon) . Évalué à 8.

    Sous Windows, le choix a été fait de ne reposer que sur clang-cl pour l'étape de compilation finale, MSVC et le C++ moderne, ça reste une source de déception sans fin pour moi, j'ai remonté plusieurs bugs puis juste abandonné l'idée…

    Ça s'améliore mais vraiment à une allure de sénateur. Et puis là, ils sont en mode «on ajoute des fonctionnalités» plutôt que de refaire la base (c'est-à-dire avoir un AST qui leur permette de gérer enfin les templates correctement). Et ils galèrent (comme les GCC et clang) sur C++20 qui est un très gros morceau.

  • # AIX

    Posté par  . Évalué à 2.

    Scipy est utilisé sous AIX, et nous n'avions jamais eu le plaisir de nous attaquer à cette plateforme dans Pythran. Fort heureusement les parties spécifiques à l'architecture matérielle sont relégée au compilateur final par Pythran, donc ce port s'est effectué sans douleur.

    Je fais partie d'une équipe qui porte et distribue des logiciels open-sources sous AIX (rarement sans douleur, pour le coup). Je suis donc curieux : ça marche sous AIX tel quel à partir des sources ?

    • [^] # Re: AIX

      Posté par  (site web personnel) . Évalué à 3.

      Et bien à mon grand soulagement, oui. les seules choses qu'il a fallu faire ont été :

      1. Prendre en compte le fait que sys.platform renvoie une valeur jusqu'alors non supportée
      2. La fonction sincos se détecte différemment.

      Pour le reste, il semblerait que Python soit suffisamment bien supporté sous cette plateforme, et que le code C++ généré par Pythran est suffisamment portable.

      Ensuite je n'ai pas testé moi même, ni même lancé la suite de test. C'est juste un retour d'utilisateur satisfait une fois ces deux changements appliqués !

      À mon tour de me montrer curieux : quel genre de galère rencontres-tu ?

      • [^] # Re: AIX

        Posté par  . Évalué à 4. Dernière modification le 14 juillet 2021 à 17:02.

        À mon tour de me montrer curieux : quel genre de galère rencontres-tu ?

        L'export des symboles avant toute chose. Ce n'est pas systématique (heureusement), mais c'est tellement la galère quand ça arrive.

        Le principe est simple : sous Linux, tous les symboles sont exportés par défaut, donc toutes les fonctions sont accessibles de n'importe où ; sous AIX, non. En pratique, ça se rencontre avec tous logiciels qui a un système de plugin, et qui va chercher des fonctions d'une bibliothèque via l’exécutable. Ce qui est le cas en Python. C'est-à-dire pythran.so est chargé par python, qui charge aussi libpython.so, et pythran.so tente d'utiliser des fonctions de libpython.

        Comme tu as pu le constater, on a fait le boulot pour que tout marche bien par défaut avec python, mais on n'est jamais sûr que tout marche vraiment bien dans les cas limites (et pythran peut rentrer dedans).

        Les autres blagues habituelles sont que par défaut, le ld d'AIX cherche des .a qui contiennent des .so pour les bibliothèques dynamiques et pas des .so directement. Soit on tripatouille la compilation (configure / libtool, cmake, voir les Makefile) pour que tout soit propre, soit on utilise des options magiques qui font le travail à notre place, et qui ont des effets de bords catastrophiques.

        Ensuite, concernant le C++, on a des soucis récurrents avec les exceptions avec GCC. Mon collègue connait ça mieux que moi, mais la première fois qu'on a tenté de compiler Boost, GCC n'a pas aimé…

        Dans le détail, on a des fonctions manquantes, parfois des fonctions POSIX standard mal codées, une couche réseau pas tout à fait comme les autres, etc… Bref, le standard du portage. Et pour une raison que l'on a jamais comprise, lorsqu'un bug est reproductible 1 fois sur 100 sous Linux, on est plus à 1 fois sur 2 sous AIX. On a eu le coup plusieurs fois…

        Ensuite je n'ai pas testé moi même, ni même lancé la suite de test. C'est juste un retour d'utilisateur satisfait une fois ces deux changements appliqués !

        Je manque de temps en ce moment, mais je vais essayer de glisser ça dans un coin. Si ça explose, je ne pourrai pas regarder en détail, mais dans tous les cas j'essayerai de te faire un retour.

        • [^] # Re: AIX

          Posté par  (site web personnel) . Évalué à 4.

          Pythran aurait tellement pu tomber dans n'importe lequel de ces soucis… je soupçonne que la suite de test explosera ;-)

          • [^] # Re: AIX

            Posté par  . Évalué à 1. Dernière modification le 15 juillet 2021 à 14:37.

            Un tiers des tests en erreur. Tu veux un rapport de bug ? :D

            Par contre, ça compile sans soucis.

            • [^] # Re: AIX

              Posté par  (site web personnel) . Évalué à 3.

              Si tu as du temps à investir pkoa pas :-) Mais bon, il faudra probablement que tu aies aussi le temps d'aider à les corriger, à toi de voir ;-)

              • [^] # Re: AIX

                Posté par  . Évalué à 1.

                Les corriger, ça ne va pas le faire, j'ai du travail plus prioritaire. Mais je garde ça dans un coin de ma tête pour quand on retouchera à Python.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.