Journal Pythran à Scipy2013 !

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
37
4
juin
2013

Ô joie, le compilo Pythran dont les évolutions sont suivies par une foule Linuxienne en délire, a droit de citer lors de la grand messe annuelle du Python scientifique, Scipy2013, plus exactement là.

Un grand merci à vous tous qui répondez, critiquez, hurlez, piaillez dans les différents journaux pythranesques, ça m'aide beaucoup pour la motivation, et aussi pour améliorer les choses.

Comme le défi Pythran, c'est d'avoir de la perf en gardant la syntaxe Python, et vu que ça intéresse pas mal d'entre vous, je reproduit ici les résultats que je présenterai là bas (les plus curieux liront l'article complet):

Petite note : les benchs ont été faits sur mon portable, 8 core i7 (dont 4 hyperthreadés), g++ version 4.7.3.

Sur le programme Pystone, digne héritier de whetstone et de don homoloque-au-nom-en-forme-de-gag dhrystone:

+---------+-------------+---------------+------------+------------+
| Tool    |  CPython    |   Pythran     |     PyPy   |  ShedSkin  |
+---------+-------------+---------------+------------+------------+
| Timing  |  861ms      |   11.8ms      |     29.1ms |  24.7ms    |
+---------+-------------+---------------+------------+------------+
| Speedup |  x1         |   x72.9       |    x29.6   |  x34.8     |
+---------+-------------+---------------+------------+------------+

Sur le calcul des n-reines sources

+---------+-------------+---------------+------------+------------+
| Tool    |  CPython    |   Pythran     |     PyPy   |  ShedSkin  |
+---------+-------------+---------------+------------+------------+
| Timing  |  1904.6ms   |   358.3ms     |    546.1ms |  701.5ms   |
+---------+-------------+---------------+------------+------------+
| Speedup |  x1         |    x5.31      |    x3.49   |  x2.71     |
+---------+-------------+---------------+------------+------------+

Sur un calcul de géomatique déjà présenté dans un précédent journal, en utilisant des listes de listes :

+---------+-------------+---------------+------------+------------+
| Tool    |  CPython    |   Pythran     |     PyPy   |  ShedSkin  |
+---------+-------------+---------------+------------+------------+
| Timing  |  1295.4ms   |   270.5ms     |    277.5ms |  281.5ms   |
+---------+-------------+---------------+------------+------------+
| Speedup |  x1         |    x4.79      |    x4.67   |  x4.60     |
+---------+-------------+---------------+------------+------------+

Le même calcul, en utilisant des tableaux numpy

+---------+-------------+---------------+------------------+
| Tool    |  CPython    |   Pythran     | Pythran+OpenMP   |
+---------+-------------+---------------+------------------+
| Timing  |  450.0ms    |   4.8ms       |      2.3ms       |
+---------+-------------+---------------+------------------+
| Speedup |  x1         |    x93.8      |    x195.7        |
+---------+-------------+---------------+------------------+

Un bench numpy classique à base d'expressions sources :

+---------+-------------+----------+-------------+-----------+
| Tool    |  CPython    |  Cython  |  Numexpr    | Pythran   |
+---------+-------------+----------+-------------+-----------+
| Timing  |  192.2ms    |  36.0ms  |    41.2ms   |  17.1ms   |
+---------+-------------+----------+-------------+-----------+
| Speedup |  x1         |  x5.33   |  x4.67      |  x11.23   |
+---------+-------------+----------+-------------+-----------+

Et le détail du bench précédent, pour Pythran

+---------------+----------------+----------------+-----------------+
| Pythran (raw) | Pythran (+AVX) | Pythran (+OMP) | Pythran (full)  |
+---------------+----------------+----------------+-----------------+
|   186.3ms     |    75.4ms      |    41.1ms      |  17.1ms         |
+---------------+----------------+----------------+-----------------+
|    x1.03      |    x2.54       |    x4.67       |  x11.23         |
+---------------+----------------+----------------+-----------------+

On peut donc humblement dire que notre énôôôrme équipe de 2 dev (+1 nouveau et sans oublier les contributions de quelques joyeux teubreux) qui bossent le soir en plus de leurs activités familiales ou estudiantines met bien la nique aux autres, ensuite on retombe sur terre et on se rappel que Pythran n'est pas aussi stable / pas avec la même couverture de Python, m'enfin ça fait plaisir quand même. Et puis on fera une sortie stable d'ici la fin du mois avec un support partiel de numpy, disons 200 fonctions de l'API standard, grâce au financement de Silkan que je remercie chaleureusement pour leur soutient !

Et le top du top, c'est que les gentils zorgas de Scipy nous invitent, et ça, c'est la clâââsse !

  • # Saga

    Posté par  . Évalué à 7.

    Soyons honnête, je ne comprends pas tout, mais cette saga est diablement passionnante. Je t'encourage à continuer !

  • # Manipulation de chaînes de caractères ?

    Posté par  . Évalué à 2. Dernière modification le 04 juin 2013 à 13:39.

    Je ne m’étais encore jamais intéressé à la compilation du code Python. Ça semble intéressant, mais je n’y connais rien. Je constate que ton projet semble concerner avant tout le calcul.

    Qu’est-ce que tu conseillerais pour celui qui manipule massivement des strings et des expressions régulières dans ses programmes ?

    L’idéal serait de compiler l’usage massif de tout ce qui concerne la manipulation des chaînes dans une DLL appelable par du code Python. Quel serait le meilleur outil pour ça ? Est-ce seulement intéressant, attendu que Python fournit des outils que j’imagine déjà optimisés ?

    • [^] # Re: Manipulation de chaînes de caractères ?

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

      (au kazou, rappelons que l'optimisation prématurée est mère de tous les maux)

      Ça semble intéressant, mais je n’y connais rien. Je constate que ton projet semble concerner avant tout le calcul.

      Farpaitement

      Qu’est-ce que tu conseillerais pour celui qui manipule massivement des strings et des expressions régulières dans ses programmes ?

      Pas évident… en se basant sur ce bench tu vois que le moteur de regexp de Python n'est pas le plus flamboyant (niveaux perf) de la planète. Une possibilité serait d'utiliser un backend de regex plus performant (celui de perl, semble-t-il). Il y en a un dans C++11 mais je ne sais pas ce qu'il vaut.

      Pour ce qui est de la manip' de string, c'est un domaine d'optimisation que je connais peu. Shedskin supporte le module re et la manipulation de chaîne, tu peux regarder ce que ça donne…

      PyPy est généralement très bon (cf. les benchs du post), si tu l'essaie sur ton cas et nous donne un retour, ça peut intéresser du monde (en tout cas ça m'intéresse).

      Et oui, l'idée serait de compiler ça en module natif appelable depuis python. c'est ce que fait Pythran , mais certainement pas pour ton cas.

    • [^] # Re: Manipulation de chaînes de caractères ?

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

      Si c'est ton code à toi qui fait des manipulations, ça peut être intéressant (entre autre, un truc coûteux, c'est les boucles).

      Mais si ton code fait juste quelques appels à l'API Python sur les chaînes, alors c'est déjà très optimisé (y'avait eu une régression sur je ne sais plus quel point dans la branche Python3 lors du passage à 3.3 avec la modification du mode de stockage, mais ça a été corrigé).

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: Manipulation de chaînes de caractères ?

        Posté par  . Évalué à 1.

        Oui, globalement, je me sers des méthodes de l’API Python (celles de string par défaut et re). En revanche, j’ai quand même pas mal de boucles.

        c'est déjà très optimisé (y'avait eu une régression sur je ne sais plus quel point dans la branche Python3 lors du passage à 3.3 avec la modification du mode de stockage, mais ça a été corrigé).

        La 3.3.0 est impactée alors, je présume.

        • [^] # Re: Manipulation de chaînes de caractères ?

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

          A priori oui (c'est, de mémoire de mes lectures dans les comp.lang.python, une personne qui râlait vs le nouveau système de stockage des chaînes, avec des raisons discutables… mais aussi un argument valide sur une opération qui était devenue nettement plus lente).
          Par contre, on en est à 3.3.2 du 13 mai, je pense que ça a dû être corrigé.

          Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

    • [^] # Re: Manipulation de chaînes de caractères ?

      Posté par  . Évalué à 2.

      Il faut voir quelles sont les expressions rationnelles que tu utilise. Sur certaines, on peut gagner pas mal en cherchant à la main. Sur d'autres, on peut optimiser le cas ou l'expression n'est pas trouvée. Sinon, il y a bien d'autres optimisations possibles sur les chaînes de caractères.

      • [^] # Re: Manipulation de chaînes de caractères ?

        Posté par  . Évalué à 1.

        Il faut voir quelles sont les expressions rationnelles que tu utilise.

        Un peu de tout. Du très simple au plutôt complexe, avec beaucoup de negative lookbehind assertion, de negative lookbefore assertion et beaucoup de | dans des groupes capturants ou non.

        Sur certaines, on peut gagner pas mal en cherchant à la main.

        À la main ? ;) Pas compris. Tu veux dire avec find et autres fonctions de la librairie str ?

        Sinon, il y a bien d'autres optimisations possibles sur les chaînes de caractères.

        Je suis entrain de regarder ça, il y a pas mal de trucs un peu partout, mais si tu as des documents de référence, je suis preneur, sachant que j’utilise Python 3.3.

  • # typage...

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

    (il est tout à fait possible que je ne comprenne pas les tenants et les aboutissants de ce dont je vais parler, excusez-moi par avance)

    Nous (les gens qui enseignent du python dans le secondaire) avons émis le souhait que le python puisse devenir statiquement typé. Le tout pour un soucis purement pédagogique. Le typage dynamique sous python, si il est une libération pour ceux qui programment, pose de vrais soucis de formation lors de l'apprentissage de la programmation envers des étudiants qui n'ont jamais programmé et auxquels on demande en 10 heures de comprendre ce qu'ils font.

    mypy est un projet prometteur, qui permet de lier certaines nouveautés de la syntaxe de python 3 :
    def greeting(name:str) -> str:
    return 'hello, ' + name

    Vraie question : ceci peut-il être utilisé par pythran pour gagner encore en ouverture (tendant vers le support de plus en plus de modules python ?)

    • [^] # Re: typage...

      Posté par  . Évalué à 2.

      python puisse devenir statiquement typé

      Je comprend tout à fait le besoin d'enseigner le typage mais il ne faut pas négliger qu'il n y a pas que ça dans la vraie vie.

      Dans ce cas, pourquoi ne pas enseigner un langage qui parait vraiment plus adapter à la pédagogie et qui répondra fondamentalement plus à votre (les gens qui enseignent du python dans le secondaire) besoin ? Je pense notamment à Caml, qui justement est fortement typé est convient parfaitement, à mon sens, à l'apprentissage. (Hummm récursivité !)

      Python fait partie de ces langages dynamiques, alors s'il vous plaît, laissons le dynamique ! Encore une fois je comprend largement le besoin de la pédagogie, mais dans ce cas là, il vaudrait mieux faire rentrer Python dans l'apprentissage d'un langage dynamique. Surtout les notions qui peuvent aller avec (Duck typing etc).

      Après il y a surement des contraintes qui m'échappent.

      • [^] # Re: typage...

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 04 juin 2013 à 18:13.

        Après il y a surement des contraintes qui m'échappent.

        Sûrement cette là: «Nous (les gens qui enseignent du python dans le secondaire)».

        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

        • [^] # Re: typage...

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

          Et celle-ci: «apprentissage de la programmation envers des étudiants qui n'ont jamais programmé et auxquels on demande en 10 heures de comprendre ce qu'ils font.»

          Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

        • [^] # Re: typage...

          Posté par  . Évalué à 4.

          Sûrement cette là: «Nous (les gens qui enseignent du python dans le secondaire)».

          "Bon maintenant les enfants, dans ce cours sur l'apprentissage de ce merveilleux outils qu'est le tournevis, je vais vous apprendre à faire la cuisine avec !"

        • [^] # Re: typage...

          Posté par  . Évalué à 3.

          Justement, si ils ne veulent pas enseigner le typage dynamique, pourquoi avoir choisi python puis demander de l'enlever ?
          Si c'est l'aspect fonctionnel qui est recherché, il y a Haskell.
          Si c'est l'aspect multi-paradigmes qui est recherché, il y a Scala.

    • [^] # Re: typage...

      Posté par  . Évalué à 4.

      Nous (les gens qui enseignent du python dans le secondaire) avons émis le souhait que le python puisse devenir statiquement typé

      Dis de cette facon là cela sonne très bizarre. Tu ne changes pas un outil par ce que quelqu'un l'utilise alors qu'il n'est pas adapté.

      Si pédagogiquement vous avez besoin vous avez besoin de typage, utilisez le bon outil. Modifier quelque chose contre sa nature ou apprendre aux gens quelque chose de complètement travesti me semble loin d'être une heureuse idée.

      • [^] # Re: typage...

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

        J'aurais tendance à être d'accord avec ce commentaire. Il y a plusieurs avantages à apprendre l'**algorithmique** avec Python, p.e. comprendre la complexité d'un algorithme qui compte le nombre d'éléments uniques dans une séquence :

        count_uniq = lambda l : len(set(l))

        Ou pour compter l'élément qui apparaît le plus souvent :

        def most_frequent_element(l):
   d = dict()
   for elem in l:
       d[elem] = 1 + d.get(elem, 0)
   return max((y,x) for x,y in d.iteritems())

        Et l'avantage de ses deux algos (soigneusement choisis, je te le concède) c'est qu'ils sont génériques, donc l'information de type, bah… tu t'en fiche. On peut même embêter le prof de physique et mettre des carottes et des patates :-)

    • [^] # Re: typage...

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

      Nous (…) avons émis le souhait que le python puisse devenir statiquement typé.

      Dans la même situation (IUT mesures physiques), je comprends la demande. Mais il y a peu de chance que ça arrive avec le Python standard. Ça n'est pas dans la nature du langage d'être statiquement typé et on doit sûrement trouver des demandes avec une réponse du BDFL - un peu comme pour le switch.

      (en anglais)
      http://www.artima.com/intv/strongweak.html
      http://www.artima.com/weblogs/viewpost.jsp?thread=85551

      Certaines personnes ont sacrément bossé sur le sujet:
      http://wesscholar.wesleyan.edu/cgi/viewcontent.cgi?article=1941&context=etd_hon_theses

      Sinon, avec les possibilités données par les annotations, vous pouvez regarder du côté de cette recette Method signature type checking decorator for Python 3, assez sympa - et elle va plus loin que le contrôle de type des paramètres / retour.

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

    • [^] # Re: typage...

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

      Tiens, bonne idée, je vais discuter avec eux :-)

    • [^] # Re: typage...

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

      Une solution alternative, et qui rapprocherais la programmation des problématiques en sciences, serait d'utiliser un module pour ajouter le support des données numériques avec des unités — ce qui dans certains domaines est au moins aussi important que le simple typage informatique¹.

      Le dernier outil de ce genre que j'ai vu passer est Pint, voici des exemples de l'intro:

      >>> from pint import UnitRegistry
>>> ureg = UnitRegistry()
>>> distance = 24.0 * ureg.meter
>>> print(distance)
24.0 meter
>>> time = 8.0 * ureg.second
>>> print(time)
8.0 second
>>> print(repr(time))
<Quantity(8.0, 'second')>
...
>>> speed.to(ureg.joule)
Traceback (most recent call last):
...
pint.pint.DimensionalityError: Cannot convert from 'inch / minute' (length / time) to 'joule' (length ** 2 * mass / time ** 2)

      Mais il y a d’autres outils de gestion d'unités.

      ¹ Voir Mars Climate Orbiter - Un petit tour, et puis s'en va…, paragraphe "Un simple problème d'unité de mesure".

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

  • # Je déconne !

    Posté par  . Évalué à 3. Dernière modification le 04 juin 2013 à 15:35.

    Plutôt que de perdre ton temps avec un langage jouet pour écrire des scrapers tu ne pourrais pas utiliser ton talent pour ajouter l'auto-vectorisation dans un socle industriel comme l'est la JVM ? ;)

    Non juste par ce que depuis hier je déprime de me prendre un facteur 20 par rapport à du C++ à cause de GCC qui fait du SIMD là où Hotspot se dit que ca va déjà bien assez vite comme ca…

    • [^] # Re: Je déconne ! (moi aussi)

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

      Plutôt que de perdre ton temps avec un langage dont la propriété principale n'est pas la performance, tu ne pourrais pas utiliser ton talent pour coder les parties nécessaires dans un langage adapté puis faire le lien avec la JVM ?

      • [^] # Re: Je déconne ! (moi aussi)

        Posté par  . Évalué à 2.

        Excellente réponse ;)

        En pratique, le problème est quand tu as besoin de ces perfs dans une lib ca devient vite la misère pour les utilisateurs et pour la gestion du packaging. Mais c'était sur ma todo de voir ce qu'on raisonablement faire.

        Plus sérieusement, si j'ai tout suivi il me semble que tu es un peu du domaine. Une idée de pourquoi les JIT ne savent pas encore auto-vectoriser des choses simples ?

  • # J'en veux plus !

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

    Ton projet à l'air super, mais je reste un peu sur ma faim…

    J'aime beaucoup Python mais je connais très mal les "accélérateurs" de ce langage

    Par contre j'en connais beaucoup !
    - Pypy
    - Cython
    - Pyrex
    - Pypy
    - ShedSkin
    - et maintenant Pythran !

    Parmi tout ça, il y a des compilateurs vers C ou C++, des compilateurs JIT et peu être même encore d'autres trucs tordus !
    La preuve, en écrivant ce poste je me suis dis que forcement un mec avait fait un truc avec python et llvm, un coup de Google et gagné : numba vient s'ajouter à ma liste !

    Je trouve ça super cool qu'il y ait autant de vitalité dans le domaine de l'accélération de python, mais ne serait-ce pas un peu "too much" ?

    Enfin tout ça pour dire que j'aimerai savoir pourquoi tu t'es lancé dans ce projet, qu'est-ce qui fait que tu poutres les autres, pourquoi les autres te le rendent bien, qu'est-ce qui fait toutes les différences des projets et les raisons pour lesquels on n'a pas 1 gros projet monolithique d'accélérateur python…

  • # Ouh ça donne envie !

    Posté par  . Évalué à 1.

    Je connaissais pas trop les méthodes d'accélération du code. C'est cool de pouvoir garder l'expressivité de Python et d'avoir un code qui trace ! En tout cas cas ça donne envie d'aller fouiller plus loin, ce que je ferai très certainement bientôt (oui c'est toujours ce qu'on dit quand on le fera surement jamais, mais sait-on ..jamais !).

    Bravo pour le boulot et merci pour le journal , ça donne vraiment envie d'essayer ! Bon courage pour la suite.

  • # c'est quoi cette bête ?

    Posté par  . Évalué à 2. Dernière modification le 05 juin 2013 à 11:37.

    8 core i7 (dont 4 hyperthreadés)

    un portable avec 8 emplacements CPU ? il fait quelle taille ? ça chauffe pas un peu ?

    à moins que tu voulais dire "( donc 4 hyperthreadés)".

    et sinon, bravo pour ce projet.
    je trouve ce genre de travail assez passionnant (j'y avait gouté sur du bytecode java mais pas à ce point) et surement très chronophage..

Suivre le flux des commentaires

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