Journal Pythran 0.9.2 - koailh

Posté par (page perso) . Licence CC by-sa.
19
6
mai
2019

Demat' iNal,

C'est avec délectation que je t'annonce la sortie de la révision 0.9.2 du compilateur pythran. Pythran est un compilateur pour les noyaux de calcul écrits en Python, compatible avec un (large) sous-ensemble de Python. Il comprend les annotations OpenMP et est capable de générer des instructions vectorielles grâce à xsimd.

La dernière sortie date de plus de 4 mois, donc pas mal de nouveautés sont au rendez vous. La liste complète est consultable en ligne.

Changements majeurs

En plus des correctifs de bug et de la prise en charge de nouvelles fonctions de numpy, on peut noter une nouvelle syntax plus concise pour décrire les arguments optionnels dans les annotations Pythran :

#pythran export foo(int, int?)

Cette notation étant équivalente à :

#pythran export foo(int)
#pythran export foo(int, int)

Cette release introduit également une dépendance vers le nouveau paquet beniget qui fournit une analyse de use-def chains pour Python. Avoir un paquet externe m'a forcé à mieux tester l'ensemble, on peut espérer une meilleur stabilité du tout.

Une fuite mémoire importante lors de la traduction d'une vue étendue sur un tableau depuis Pythran vers Python a été détectée et corrigée.

Au final, c'est 43 tickets qui ont été fermés depuis la version 0.9.1 \o/

Exemple

Comme d'habitude, j'aime bien illustrée Pythran a travers un petit code qui ne compile que depuis la nouvelle version. Le code suivant a été glané sur Stackoverflow et bénéficie d'une accélération d'un facteur 6 sans xsimd jusqu'à 9 avec xsimd et des accès contigus en mémoire.

import numpy as np
#pythran export f_dist(float64[:,:], float64[:,:])
#pythran export f_dist(float64[::,::], float64[::,::])
def f_dist(X1, X2):
    return np.sum(np.abs(X1[:, None, :] - X2), axis=-1)

Téléchargement

Pythran est disponible

Remerciements

Les personnes suivantes ont contribué à cette version, à travers des rapports de bug ou des patchs - l'ordre est aléatoire :

  • Yann Diorcet
  • Neal Becker
  • Ashwin Vishnu
  • David Menéndez Hurtado
  • Jean Laroche
  • Anubhab Haldar
  • Thierry Dumont
  • "keke ge-smile"
  • "garanews"
  • Said Hadjout
  • Rodrigo Iga
  • Pierrick Brunet
  • Franck Cornevaux-Juignet

On notera que ces deux derniers lascars sont mentionnés ici pour avoir reporté des bugs en 2013 et 2014, bugs qui ne sont corrigés qu'avec cette version ;-)

Je me permets également un remerciement particulier à Pierre Augier pour son support et le boost de motivation qu'il apporte au projet.

Contribuez

Il existe plein de façon de contribuer au projet ! Les rapports de bugs et/ou les patchs sont toujours appréciés. Un petit message, par courriel ou dans les commentaires de ce journal, c'est une petite étincelle de joie ! Utiliser le projet et le faire utiliser autour de soi aide aussi beaucoup.

Et si vous avez envie d'influencer les développements futurs, parlez-en sur la liste de diffusion ou, si vous êtes timides, contactez-moi.

Ce journal est une traduction libre de l'annonce officielle avec quelques petits ajouts parce que, bon, c'est plus agréable dans sa langue maternelle

  • # "Pythran is an ahead of time compiler for a subset of the Python language" : Subset ?

    Posté par . Évalué à 3 (+0/-0).

    A quel point pythran s'éloigne de python ? A quel point, serait-il compliqué de compiler du code normal ou une partie de celui-ci ? Je pense en particulier pour des applications web ou même pourquoi pas des jeux.

    Plus la base d'utilisateur augmente, plus la base de contributeurs potentiels aussi, non ?

    "La première sécurité est la liberté"

    • [^] # Re: "Pythran is an ahead of time compiler for a subset of the Python language" : Subset ?

      Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 06/05/19 à 12:45.

      A quel point pythran s'éloigne de python ?

      Pythran ne supporte pas les classes, et ne supporte pas le code polymorphique.

      A quel point, serait-il compliqué de compiler du code normal ou une partie de celui-ci ?

      Pour compiler une partie, on peut regarder du côté de https://transonic.readthedocs.io/en/latest/

      Plus la base d'utilisateur augmente, plus la base de contributeurs potentiels aussi, non ?

      Pas si sûr… l'écosystème Python scientifique fait que les compétences Compilation, C++ et calcul intensif ne se retrouvent pas forcément dans la base d'utilisateurs. Mais on commence à avoir quelques contributions significatives, donc je suis content !

      • [^] # Re: "Pythran is an ahead of time compiler for a subset of the Python language" : Subset ?

        Posté par . Évalué à 3 (+0/-0).

        Pythran ne supporte pas les classes, et ne supporte pas le code polymorphique.

        Lisaac générait un code assez bête par défaut : une structure avec un enum qui contenait le type de classe, ainsi l'appel polymorphique était remplacé par un switch.

        Ensuite, il utilisait un algo de flow pour détecter le type réel de l'objet, ainsi il pouvait réduire la taille du switch. Si il trouvait le type final, cela permettait de faire ensuite de l'inlining. C'est comme ça + la notion de gestion du layout mémoire, que IssacOs pouvait avoir un framebuffer qui était un tableau 2D de l'objet pixel, et d'avoir des vrais performances.

        "La première sécurité est la liberté"

  • # Pythran, numpy et tensorflow

    Posté par . Évalué à 1 (+1/-0). Dernière modification le 06/05/19 à 12:21.

    Vu que tensorflow et compagnie sont à la mode en ce moment, et que ça utilise intensivement numpy derrière, oserais-je demander s’il est pertinent de faire tourner tensorflow (TF) sur Pythran, ou non ?

    De mémoire il y a beaucoup de C++ et je ne sais pas si TF utilise numpy réellement pour ses calculs les plus gourmands.

Envoyer un commentaire

Suivre le flux des commentaires

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