Journal Sortie de Pythran 0.13.0

Posté par serge_sans_paille (site web personnel) le 02 mai 2023 à 08:04. Licence CC By‑SA.

Étiquettes :

mai

2023

Demat i'Nal,

J'ai publié ce matin une nouvelle mouture du compilateur pour codes scientifiques écrits en Python nommé Pythran. C'est la version 0.13.0 et elle porte le joli sobriquet bouch'hal.

Les plus impatients téléchargeront immédiatement la dernière version sur PyPi ou Github tandis que les plus curieux s'empresseront de lire le changelog associé.

Mais ce serait louper la suite de ce billet, où j'aimerai vous parler des bienfaits de l'émulation. Lors de ma veille, je suis tombé sur le projet de compilateur pyccel qui partage plusieurs caractéristiques avec le projet Pythran : compilateur source à source, en avance de phase, ciblant le calcul numérique. Avec quelques différences : support (encore plus) limité des constructions Numpy et du langage Python, mais surtout possibilité d'utilisé C ou Fortran comme langage cible. Sympa !

Ce projet a publié une suite de benchmark permettant des points de comparaison avec Pythran. Et sur certains noyaux, Pythran n'était vraiment pas bon. J'ai creusé un peu (car oui, mon ego en a pris un coup) et de manière fascinante, les compilateurs clang et gcc peinent à générer un code équivalent pour les deux fonctions C++ suivantes (cf. godbolt pour les plus saint Thomas d'entre vous):

long ackermann(long m, long n) {
  if (m == 0)
    return n + 1;
  if (n == 0)
    return ackermann(m - 1, 1)
  return ackermann(m - 1, ackermann(m, n - 1));
}

static long ack(long const& m, long const& n) {
  if (m == 0)
    return n + 1;
  if (n == 0)
    return ack(m - 1, 1);
  return ack(m - 1, ack(m, n - 1));
}

long ackermann(long m, long n) { return ack(m, n); }

Pythran générant du code générique, il m'a fallu pas mal d'heures de réflexions pour circonvenir le problème et arriver à un patch. Mais c'est bon, problème de performance corrigé !

# autre compilo python : codon

Posté par Thomas Douillard le 02 mai 2023 à 09:49. Évalué à 4.

Je sais pas si tu as vu passer codon dans ta veille : https://github.com/exaloop/codon

C'est un compilateur, natif par contre, ils clament de gros gains de perfs et une couverture de python importante.
- [^] # Re: autre compilo python : codon
  
  Posté par serge_sans_paille (site web personnel) le 02 mai 2023 à 10:03. Évalué à 3.
  Vu dans les sources de condon:
```
from python import numpy as np  # Codon will call NumPy through CPython's API
```
  - [^] # Re: autre compilo python : codon
    
    Posté par steph1978 le 02 mai 2023 à 18:14. Évalué à 3.
    
    from python import numpy as np # Codon will call NumPy through CPython's API
    
    Plutôt normal, c'est déjà compilé en natif.
    
    C'est pour dire que Pythran devait donc être plus rapide car plus rapide que Numpy ?
- [^] # Re: autre compilo python : codon
  
  Posté par steph1978 le 02 mai 2023 à 18:09. Évalué à 3.
  
  J'ai joué avec à l'occasion du advent of code.
  
  the good
  
  Les gains peuvent atteindre 100x.
  
  the bad
  
  Les modules ne sont pas compilés à la volé, ils doivent l'être en amont. Par conséquent peu de modules sont implémentés en natif, pour le reste il faut se rabattre sur l'interprété.
  
  the ugly
  
  L'import d'un module non natif passe par un from python import module au lieu de import module. Ce qui fait qu'un script ne peut pas être écrit pour les deux, python et codon, dommage.
  - [^] # Re: autre compilo python : codon
    
    Posté par serge_sans_paille (site web personnel) le 02 mai 2023 à 22:31. Évalué à 2.
    
    Les gains peuvent atteindre 100x.
    
    J'ai regardé ton code (pas possible de reproduire les perfs, il me manque le fichier d'entrée et une valeur pour le nombre de round) et le gain de x100 n'est pas surprenant : double boucle imbriquée, le cas parfait pour les compilos statiques ;-)
    
    Note que ça n'enlève rien aux mérites de condon hein, juste pour dire que c'est un point ou cPython ne brille pas et où tout compilateur pour Python devrait s'en sortir plutôt bien. Le support des générateurs et d'expression du style next(filter(lambda m: m[1], moves))[0] c'est chouette (et c'est aussi dans pythran bien sûr ;-))
    
    Je trouve la liste des modules supportés plutôt respectable !
    - [^] # Re: autre compilo python : codon
      
      Posté par steph1978 le 03 mai 2023 à 16:52. Évalué à 2.
      
      Mon input est ici
      
      Il faut 1025 round pour arriver à un état stable. Ça prend 0.85s sur ma machine contre 7.57s en python 3.11. Pas du tout 100x, donc, mais plutôt 10x.
      
      Faudrait que je retrouve mon cas à 100x… Bref.
# Mais pourquoi ?

Posté par Julien Jorge (site web personnel) le 02 mai 2023 à 10:12. Évalué à 5.

Intéressant, mais pourquoi le compilateur a-t-il du mal à générer le même code ?
- [^] # Re: Mais pourquoi ?
  
  Posté par serge_sans_paille (site web personnel) le 02 mai 2023 à 12:15. Évalué à 4.
  
  Bonne question! Si on regarde précisément le code sans passage par référence, on voit qu'une des deux récursions a été transformée en boucle, on peut imaginer une contrainte sur l'analyse d'aliasing ?
  - [^] # Re: Mais pourquoi ?
    
    Posté par Julien Jorge (site web personnel) le 02 mai 2023 à 14:04. Évalué à 5.
    
    J'aurais misé sur une histoire d'aliasing aussi mais vu que les valeurs des paramètres ne sont pas modifiés par les appels je ne vois pas comment ça pourrait être un problème.
    
    Est-ce que ça pourrait être l'inlining ? Si le compilo considère que ack peut être « inlinée » dans ackermann, est-ce qu'il n'essaye pas aussi d'inliner les appels récursifs dans la foulée et conclut que ça ne passe pas ?
    
    En tout cas je me dis qu'on fait peut-être un peu trop confiance au compilateur pour les optims. Ça vaut le coup de vérifier l'assembleur émis :)

Suivre le flux des commentaires

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

the good

the bad

the ugly