• # Scatogiciel

    Posté par  . Évalué à 10.

    À quand une implémentation de libcaca en pypy ?

    • [^] # Re: Scatogiciel

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

      libpipi est déjà disponible, tu sais...
      http://caca.zoy.org/wiki/libpipi

      • [^] # Re: Scatogiciel

        Posté par  . Évalué à 3.

        En effet, je ne connaissais pas.
        La charte graphique ne laisse planer aucun doute sur le fait que les développeurs sont bien de chez nous... ;-)

        • [^] # Re: Scatogiciel

          Posté par  . Évalué à 8.

          tu veux dire par là qu'on voit bien qu'ils ont travaillé chez Debian ?

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # Excellente nouvelle... qui se lance ?

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

    Quelqu'un a déjà testé ? dans sa cave ? en dans son bureau ? en production ?

    Qui pense l'adopter rapidement ?

    bref, j'aimerai avoir le ressenti des moules... ça m'intéresse.

    Alexandre COLLIGNON

    • [^] # Re: Excellente nouvelle... qui se lance ?

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

      De mon coté j'ai testé sur de nombreux algorithmes (recherche de chemin, coupure de graph, ray tracing) et généralement j'ai des perfs bien meilleurs (de l'ordre de 2-3x, plus certaines fois). Je suis tombé sur quelques cas pathologiques (bien plus lent) et quelques minutes après sur le chan IRC de pypy en discutant avec les dev, j'ai eu le droit à une explication du pourquoi c'était lent, et generalement un patch (de pypy) reglait le problème dans les minutes à venir.

      Bref, globalement c'est vraiment positif pour les performances sur des algos "crunching numbers". Pour la stabilité en production et l'occupation mémoire, je ne peux pas me prononcer.

    • [^] # Re: Excellente nouvelle... qui se lance ?

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

      Moi aussi ça m'intéresse... je vais essayer ça à l'occasion.

      D'autant plus que les nouvelles version de Python (3.x) ne m'enthousiasme pas des mases :
      * incompatible avec les versions 2.x
      * pas de "vraies" nouveautés de grande empleur
      * tous les modules ne sont pas encore traduit pour Python 3, et / ou pas encore empaquetés dans les distributions Linux

      Je suis le seul dans cette situation ?

      • [^] # Re: Excellente nouvelle... qui se lance ?

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

        incompatible avec les versions 2.x

        Oui, elles sont en effet incompatibles, c'est le prix à payer pour les vraies nouveautés et pour retrouver une syntaxe cohérente (passage au monde moderne avec l'unicode par défaut, fin du mot-clé print et des noms de modules avec des majuscules et bien d'autres). Sans parler de la ré-écriture du code. T'as un excellent utilitaire fourni avec les archives de Python qui te traduit du code 2.x vers 3.x. Le script s'appelle 2to3.

        pas de "vraies" nouveautés de grande empleur

        Si on omet ce que j'ai déjà évoqué, ça fait quand même deux versions (2.6 et 2.7) que les nouvelles fonctionnalités les plus intéressantes de la branche 2.x arrivent directement de la branche 3.x.

        tous les modules ne sont pas encore traduit pour Python 3, et / ou pas encore empaquetés dans les distributions Linux

        Franchement ça se fera pas en un jour mais le chantier progresse bien. Tu trouves des grosses bibliothèques comme sqlalchemy qui tournent sous python3. Sachant que Python c'est "battery included" t'as vraiment de quoi t'en sortir en attendant.

        Enfin pour quelqu'un qui veut commencer le Python aujourd'hui, lui conseiller même python2.7 face à python3.1 ou python3.2 qui sort en début 2011 serait une grave erreur à mon avis (alors que je considère que python2.7 est une excellente dernière version de branche).

        • [^] # Re: Excellente nouvelle... qui se lance ?

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

          L'unicode, tu as raison, c'est la seule nouveauté qui m'intéresse vraiment dans Python 3 !

          Python inclut des batteries mais elles ne me suffisent pas... j'ai besoin de GTK pour faire des interfaces graphiques, de Cairo pour le graphisme, d'OpenGL / Soya pour la 3D,...

          Le changement de syntaxe est plus gênant qu'autre chose... je suis pas convaincu que ça justifie de perdre la compatibilité antérieure (il n'y avait VRAIMENT pas moyen d'avoir un print qui accepte les 2 syntaxes, ou d'ignorer les u qui précède les chaînes de caractères ?).

          Quand à 2b3, les premiers essais que j'avais fait étaient guère concluant... le code généré était pas optimal, pas toujours très lisible et pas toujours fonctionnelle non plus :-(
          Il faut dire que dans un langage "duck typé" comme Python, comment changer tous les appel à une méthode (par exemple dict.items()) quand on ne peut pas savoir si une variable contient un dictionnaire ou un autre objet qui a aussi une méthode dict ?

          • [^] # Re: Excellente nouvelle... qui se lance ?

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

            Gtk et cairo (enfin, toute la pile G) est disponible pour python 3 avec gobject-introspection, et cela d'une façon bien plus propre que ce qui était fait avant pour python2. En bref, le binding python python se génère automatiquement à partir des données d'introspection fournies par les librairies, ainsi tu met à jour cairo et hop, tu a la nouvelle API dans python-cairo automatiquement. (Sans mettre à jour python-cairo qui en fait n'existe plus ;)

            Pour OpenGL, je m'en sert tous les jours avec python3, aucun soucis.

            Pour Soya, tu sais ce qu'il te reste à faire ? ;)

            Sinon, pour le u'' et le print, tu peux faciliter ta transition en utilisant (python2.6), from __future__ import print_function, unicode_literals.

            Personnellement, ce qui me pose le plus de problème actuellement avec python3 c'est le manque de packaging correcte de la plupart des distributions. Hormis ce détail, et bien... Python3 c'est bon, mangez en ;)

            (Et globalement, pypy c'est pire que python3 d'un point de vu extensions portées, il faut compiler toutes les extensions soit même)

        • [^] # Re: Excellente nouvelle... qui se lance ?

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

          > pas de "vraies" nouveautés de grande empleur

          Si on omet ce que j'ai déjà évoqué, ça fait quand même deux versions (2.6 et 2.7) que les nouvelles fonctionnalités les plus intéressantes de la branche 2.x arrivent directement de la branche 3.x.

          Python 3 est devenu le nouveau "trunk" du projet Python. Les nouveautés sont développées dans Python 3 et certaines ont été portés dans Python 2(.7).

          C'est un choix que Python 3 ne contienne pas trop de nouveautés : une grosse partie des nouveautés de Python 3.1 et 3.2 ont été portés dans Python 2.7 pour... faciliter le portage Python 2 vers Python 3.

          tous les modules ne sont pas encore traduit pour Python 3, et / ou pas encore empaquetés dans les distributions Linux

          J'ai commencé une liste, sûrement incomplète : http://www.haypocalc.com/wiki/Python#Modules_disponibles_pou(...)

          PyQt est un gros projet qui a été porté vers Python 3. Par contre, Twisted, Zope et Django, ce n'est pas encore fait je crois.

    • [^] # Re: Excellente nouvelle... qui se lance ?

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

      parler de "ressenti des moules" quand on parle de PyPy, c'est borderline je trouve

    • [^] # Re: Excellente nouvelle... qui se lance ?

      Posté par  . Évalué à 1.

      J'ai testé sur un petit algo qui recherche les différentes possibilités de déplacement d'un cheval sur un damier sans repasser par la même case... Je ne sais pas si c'est très clair, ça donne par ex sur un damier 3x3

      147
      6X2
      385

      J'ai écrit le code pour python, c, php, java et différentes variations python.

      Avec pypy1.4 il n'y a quasiment pas de différence avec cpython, en revanche il y a énormément de différence avec psyco... (de 3m contre 2s), je trouve curieux que ce genre de code n'ait pas été plus optimisé, il faudra que je leur en parle...
      http://hg.flibuste.net/libre/games/cheval/file

      En revanche je viens d'essayer sur petit programme de calcul d'itinéraires (un vrai programme en prod), c'est impressionnant, le résultat est similaire qu'avec psyco, le rapport est de 1 à 100 ! C'est très prometteur.

      • [^] # Re: Excellente nouvelle... qui se lance ?

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

        J'ai un peu joué avec ton code. Perso j'obtiens un gain de l'ordre de 6 entre python et pypy1.4 (et en *nettoyant* un peu, j'obtiens un gain de l'ordre de 6 entre ta version et la mienne ;)

        http://hg.insecable.net/hgwebdir.cgi/guibou/hg/cheval/file/4(...)

        Sur cette solution je suis à 13s alors qu'avant c'était 50s

        Il y a encore moyen de bien gagné en faisant une table des jumps possibles, je passe à 9 secondes.

        Il y a aussi une autre solution qui doit être encore plus rentable en C, c'est de faire une grille circuit un peu plus grande (de 2 de plus sur chaque bords) et de mettre les valeurs de ces bords à != 0, comme cela tu peux virer tous les tests dans la boucle principale ;)

        • [^] # Re: Excellente nouvelle... qui se lance ?

          Posté par  . Évalué à 1.

          Merci de t'être intéressé à mon code ! Je viens de l'essayer, sauf erreur ton code est beaucoup plus rapide avec pypy mais moins avec cpython ou psyco. Tu confirmes ?

          ton code
          cpython 124s
          pypy 13s
          psyco 4s

          le mien
          cpython 86s
          pypy 107s
          psyco 1s

          • [^] # Re: Excellente nouvelle... qui se lance ?

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

            J'obtient:

            Mon code:

            cpython (2.6) 98s
            pypy (1.4) 13s
            psyco (Pas/plus disponible sur ubuntu maverick)

            Ton code:

            cpython: 69s
            pypy: 88s

            Au passage, j'utilise le pypy 64 bits...

            C'est en effet marrant ;) Autant qu'il y ai une telle différence entre les deux pypy c'es marrants, mais que dans le cas de ton code pypy mette plus de temps que cython alros que dans le cas de monde code c'est l'inverse...

  • # Erreur de l'article

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

    A noter que l'article dis une grosse connerie, ou peut être mal interprété.

    Il permettra d’exécuter du code Python adapté (basé sur un sous-ensemble du langage, RPython) plus rapidement qu’avec l’interpréteur officiel (CPython)

    En pratique pypy est écrit en RPython, sous ensemble de python, mais pypy exécute n'importe quelle code python (2.5) sans modifications.

  • # Liens

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

    L'annonce officielle sur le PyPy Status blob : http://morepypy.blogspot.com/2010/11/pypy-14-ouroboros-in-pr(...)

    Lie vers un benchmark entre CPython 2.6 et PyPY 1.4 : http://speed.pypy.org/comparison/?exe=2%2B35,1%2B172&ben(...)

    ça a l'air de bien déménager !

  • # Pour les perfs il y a aussi Psyco

    Posté par  . Évalué à 2.

    http://psyco.sourceforge.net/introduction.html

    Uniquement pour Python 2.6 et pour architectures x86 seulement, par contre pour la stabilité ???

    • [^] # Re: Pour les perfs il y a aussi Psyco

      Posté par  . Évalué à 3.

      Je cite la page de psyco :
      "My plans for 2006 are to port the techniques implemented in Psyco to PyPy."

      C'est un peu à l'abando psycho. Mais sinon des projets pour "accélérer" python, on a quelqu'un hein : Unladen Swallow, Stackeless, Cython...

      • [^] # Re: Pour les perfs il y a aussi Psyco

        Posté par  . Évalué à 4.

        Cela dit Psyco a été mis à jour post 2006 pour supporter Python 2.6. Il y a une même une branche initiée pour le support de 2.7 [1]. Dans le temps [2], il semblait obtenir de très bons résultats : trois fois plus rapide sans pour autant consommer davantage de mémoire. Malheureusement limité, comme vous le dîtes, à la plateforme x86.

        Unladen [3] semble bien ralenti malheureusement. Le dernier changement de code date d'août et la dernière sortie est intervenue fin 2009. Néanmoins, les auteurs ont rédigé en janvier une PEP [4] pour demander l'inclusion dans CPython. A ce propos, je vois que son statut est à accepted. Après recherche, il semblerait que les auteurs visent la fusion avec CPython 3.3 [5]. La sortie 2009Q3 promettait une CPython accéléré de l'ordre de x1.5 dans les tests pour une consommation mémoire un peu plus importante [6].

        Stackless [7] est un peu à part car il implémente le concept de tasklets, destiné à la concurrence. De fait, j'imagine qu'il faut des morceaux de code spécialement écrits avec / pour. Par ailleurs, pour ceux que cela intéresse, Greenlets [8] est un module Python standard qui permet d'utiliser les tasklets sans Stackless.

        Cython [9] me parait l'un des plus intéressants de la liste si l'on cherche les performances. Il permet, en employant le sous-langage typé, qui limite un peu le Python classique mais reste tout de même proche, au moins dans sa syntaxe, de concevoir des modules traduits en C. Ceux-ci apporteraient des gains très importants. Notons aussi Shedskin [10], un compilateur Python -> C++ dont les résultats sont tout aussi impressionnants (de 2 à 2000 fois plus rapide que CPython il parait). Là aussi, le but est de générer des modules Python avec du statiquement typé (de manière implicite) voire des exécutables indépendants.

        Bref, comme vous le disiez, les pistes ne manquent pas pour enlarge your Python.

        1 : [http://psyco.sourceforge.net/]
        2 : [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)]
        3 : [http://code.google.com/p/unladen-swallow/]
        4 : [http://www.python.org/dev/peps/pep-3146/]
        5 : [http://groups.google.com/group/unladen-swallow/msg/b966b7d5e(...)]
        6 : [http://code.google.com/p/unladen-swallow/wiki/Release2009Q3]
        7 : [http://www.stackless.com/]
        8 : [http://bitbucket.org/ambroff/greenlet]
        9 : [http://www.cython.org/]
        10: [http://code.google.com/p/shedskin/]

  • # GIL

    Posté par  . Évalué à 2.

    Petite question:

    Qu'utilise PyPy pour l'exécution concurrente.

    Y a t'il un GIL ?

    • [^] # Re: GIL

      Posté par  . Évalué à 1.

      Oui il y a un GIL et il n'est pas prévu de le retirer dans un futur proche

Suivre le flux des commentaires

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