URL: https://linuxfr.org/users/serge_ss_paille/journaux/pythran-rampe Title: pythran rampe Authors: serge_sans_paille Date: 2012年07月16日T17:10:05+02:00 License: CC By-SA Tags: pythran, benchmark et python Score: 23 _Le titre « pythran est en marche » me paraissait bizarre pour un outil qui a trait aux serpents..._ Dans ma folie bienheureuse, et faisant fi des avis pessimistes, j'ai tenté de passer un code résolvant le problème des [Nreines](http://en.wikipedia.org/wiki/Eight_queens_puzzle) dans la moulinette [pythran](https://github.com/serge-sans-paille/pythran). Après de nombreux ~~hacks~~ optimisations, les résultats tombent: * python: 1.34s * pypy: 0.56s * nuitka: 1.34s * shedskin: 0.61s * pythran: 0.32s \\o/ le bébé s'en sort bien. Pour être honnête il faut bien avouer que pythran ne supportant pas encore les paramètres par défaut dans les fonctions ni les _generator expression_, le code d'origine, tiré de [unladden swallow](http://code.google.com/p/unladen-swallow/source/browse/tests/performance/bm_nqueens.py) a été légèrement modifié. Chose amusante (c'est comme le gars qui se prend un seau sur la tête, c'est marrant quand ça arrive aux autres), `shedskin` demande une petite modification du source car il n'aime pas qu'un type `NoneType` et `int` cohabitent, comme dans ```python def foo(l, a=None): if a is None: a=len(l) ... ``` `pythran` s'en sort pas trop mal pour le coup, en utilisant une classe semblable à `boost::variant` spécialisée pour le cas du `None`. Pour la petite histoire (après tout ceci est un journal, on peut lui raconter des histoires), le code généré par `pythran` était initialement très mauvais, à cause de : 1. la gestion des _subscripts_ 2. la gestion de la mémoire Pour *1.* si on passe son temps à créer des sous tableaux copiant des parties du tableau initial alors qu'on y accède qu'en lecture, on est mal barré. La soluce classique - un peu comme quand on fait des coupes sur une matrice 3D - c'est de générer un objet _proxy_ qui mémorise les paramètres de la coupe et surcharge les opérateurs [] et les méthodes `begin()` et `end()` pour faire croire qu'elle possèdent des données qu'elles n'ont pas. Et pour le *2.* l'utilisation de [`boost::pool`](http://www.boost.org/doc/libs/1_38_0/libs/pool/doc/index.html) m'a donné une accélération satisfaisante, mais si quelqu'un a mieux, je passe quand même 20% du temps dans ce cas (`callgrind` à l'appui) à trifouiller la mémoire et allouer des petits tableaux dont je ne connais la taille qu'à l'exécution.