• # encore ?

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

    J'ai l'impression d'entendre la même rengaine à chaque nouvelle version : c'est vachement plus rapide…

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: encore ?

      Posté par  . Évalué à 5. Dernière modification le 06 juin 2022 à 22:53.

      Quel intéret de commenter sans lire l'article ? Il contient plein de benchs, comparant Python 3.8, 3.9, 3.10 et 3.11. Et y'a pas photo : si on avait chaque fois droit à des petites améliorations entre les versions, cette fois c'est un joli bond.

      • [^] # Re: encore ?

        Posté par  . Évalué à 4. Dernière modification le 07 juin 2022 à 07:43.

        Mais que mesurent réellement les benchs ?

        Si tu va voir la liste des améliorations, tu verras que ce sont des optimisations très spécifiques, et qui ne dépassent pas 25% individuellement qui plus est.

        Comment peut-on en arriver jusqu’à 60% ? Doit-on penser qu’une même ligne de code peut bénéficier de plusieurs optimisations à la fois ? Faute d’analyse critique des résultats du bench on n’en saura rien, car il ne suffit pas d’aligner des chiffres…

        Un élément d’explication, le plus plausible, serait que les tests, très courts du peu que j’ai vu, aient surtout bénéficié du démarrage plus rapide (ce qui est déjà un très bon point pour un langage qui devrait permettre le scripting et le prototypage).

        En tout cas perso, je pense que l’annonce doit être prise avec des pincettes et j’attendrai de voir avec du code réel si amélioration il y a (mais comme je l’utilise pas…).

        Mort aux cons !

      • [^] # Re: encore ?

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

        Quel intéret de commenter sans lire l'article ?

        Il y a une sixième page que j'ai loupée ?

        Il contient plein de benchs, comparant Python 3.8, 3.9, 3.10 et 3.11.

        Et ça ne va à l'encontre de mon commentaire : si tu avais lu l'article tu verrais aussi qu'il y a évolution à chaque version…

        Et y'a pas photo : si on avait chaque fois droit à des petites améliorations entre les versions, cette fois c'est un joli bond.

        Avons-nous lu la même chose ? Je ne « vois » pas de « bond » pour ma part, et en prime il s'agit encore de cas spécifiques (pour lesquels certains benchs semblent avoir été conçus.)

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: encore ?

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

      Sauf que là depuis la 3.10, c'est la vocation de toute la team d'améliorer les perfs de Python pour revenir dans la course contre Javascript, Java, Go, etc…

      Car ces dernières années, avec les ajouts de fonctionnalités, il a pas mal ralentit.

      Alors oui, on a déjà eu quelques optimisations du bytecode en 3.9 et 3.10, mais la 3.11 ils ont décidé de prendre la pelle à merde et de creuser.

      Et a chaque nouvelle rc de la 3.11, les benchs sont de plus en plus positifs. C'est surtout ça que tu entends depuis un certains temps, le progrès de la 3.11 sur ce sujet.

      https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

      • [^] # Re: encore ?

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 07 juin 2022 à 05:47.

        Tu devrais remplacer Java et Go par PHP dans ton commentaire… ça serait déjà pas mal.

        • [^] # Re: encore ?

          Posté par  (Mastodon) . Évalué à 6. Dernière modification le 07 juin 2022 à 15:52.

          Ça dépend la métrique, comme toujours.

          On va prendre un exemple simple :
          écrire la liste des carrés des entiers jusqu'à 1 million.

          En python :

          time (emacs test.py; python3 test.py > test_python)
          real    0m43,203s
          user    0m5,319s
          sys 0m0,461s
          

          En bash :

          time (emacs test.sh; bash test.sh > test_bash)
          real    0m40,464s
          user    0m5,060s
          sys 0m1,402s
          

          Bilan le bash reste encore plus rapide, et je vous mets au défi de faire plus vite en C, C++, Go, JS, PHP, Java, etc.
          Pour info l'écriture du code python m'a pris 43s, en bash 36s, mais je soupçonne emacs de s'être démarré plus rapidement la seconde fois.
          Et non, j'aurais perdu du temps avec vi : rien que sauvegarder et quitter, la recherche qwant pour retrouver comment faire, on était dans les choux.

          Le bash gagne encore sur la concision :

          ls -al test.*
          ... 72 ... test0.py
          ... 62 ... test0.sh
          
          • Yth.
          # cat test.py test.sh
          #!/usr/bin/python3
          
          print("\n".join(str(x**2) for x in range(1000000)))
          #!/bin/bash
          
          for x in $(seq 1000000); do echo $((x**2)); done
          

          Et oui, on n'a même pas calculé exactement la même chose entre les deux codes, mais l'énoncé était flou, les deux réponses sont donc acceptées.

          • [^] # Re: encore ?

            Posté par  (Mastodon) . Évalué à 6.

            Bilan : 1 personne qui a de l'humour et 3 qui ont été plus lent à coder ce truc avec leur langage de prédilection.

            Mais plus sérieusement, mon message indiquait que la rapidité d'écriture du code, sa lisibilité, sa maintenabilité, et même sa concision, sont aussi à prendre en compte dans un projet.

            Les perfs brutes, ça sert là où ça sert.
            Si tu dois faire des calculs matriciels complexes, numpy est un bon candidat.
            Si tu cherches à faire du polling sur une base redis pour lancer un traitement spécifique derrière en fonction des données disponibles, tu vas pas faire ça en C, le python va prendre 5 lignes, et comme le programme passera sa vie en select les ressources seront négligeables.
            Si tu veux importer et convertir des fichiers XML vers une base de donnée postgreSQL, franchement, si tu n'y arrives pas en bash (parce que le XML c'est pénible), le python va être royal pour ça.
            Pour recoder le système de package de ta distrib, ne sort pas le Go, modernise ton bash et utilise du Python, ou du Ruby si tu connais mieux, le gain potentiel en perf ne vaudra pas la complexité comparative de maintenance.

            Mais si tu veux concurrencer l'Unreal Engine, non, fais pas ça en python, choisi plutôt du Rust (par exemple), ou un langage qui va te fournir des primitives efficace pour gérer tes fils d'exécutions parallèles, ta mémoire, tes transferts de mémoire, tes traitements massivement parallélisable sur le GPU, etc.
            Le Python n'est pas le meilleur langage pour ça.

            Mais bigre, pour du backend web ou de l'API, sérieux, si je ne refais plus jamais du PHP ou du node.js ça sera déjà trop tôt, c'est tellement plus agréable, et rapide, de le faire en Python !

            • Yth.
            • [^] # Re: encore ?

              Posté par  (site web personnel) . Évalué à 2. Dernière modification le 08 juin 2022 à 22:05.

              Là ou le temps développeur est très supérieur au temps processeur, Python est probablement un bon choix. Pour le reste, ça s'évalue. Plutôt que spéculer il faut profiler et mettre l'effort là où c'est utile.

              Adhérer à l'April, ça vous tente ?

              • [^] # Re: encore ?

                Posté par  . Évalué à 2. Dernière modification le 09 juin 2022 à 17:33.

                Je crois que le point auquel c'est plutot: La ou le temps d'IO est superieur au temps processeur, python est un bon choix.

                Ce qui est bien souvent la réalité dans le backend, ou on passe son temps a attendre une base de donnees, ou alors sur un backend oriente machine learning, parce qu'on passe son temps a attendre un calcul sur dask/numpy (mais dans ce cas la, c'est plus un souci un souci d'IO).

          • [^] # Re: encore ?

            Posté par  . Évalué à 10.

            On va prendre un exemple simple :
            écrire la liste des carrés des entiers jusqu'à 1 million.

            ~$ time echo "la liste des carrés des entiers jusqu'à 1 million."
            la liste des carrés des entiers jusqu'à 1 million.
            
            real    0m0.000s
            user    0m0.000s
            sys     0m0.000s
            

            Vala vala ;)

            • [^] # Re: encore ?

              Posté par  (Mastodon) . Évalué à 5.

              Ah non, tu as mis le code dans la ligne de commande, à la rigueur :

              # time cat
              La liste des entiers jusque 1 million
              La liste des entiers jusque 1 million
              <ctrl-d>
              real    0m8,989s
              user    0m0,000s
              sys 0m0,001s
              

              Plus réaliste !
              Bravo, le shell gagne donc encore haut la main !

              • Yth ;)
              • [^] # Re: encore ?

                Posté par  . Évalué à 3.

                Ruby On Rails va encore plus vite :

                $ time curl -Ss https://linuxfr.org/nodes/127931/comments/1892762|grep -o "la liste des carrés des entiers jusqu'à 1 million."
                la liste des carrés des entiers jusqu'à 1 million.
                
                real    0m0.105s
                user    0m0.022s
                sys     0m0.010s
                

                Vraiment formidable !

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 5.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: encore ?

              Posté par  (Mastodon) . Évalué à 3.

              Ah, je connaissais pas cette notation, merci !

              • Yth, content.
        • [^] # Re: encore ?

          Posté par  (site web personnel, Mastodon) . Évalué à 6.

          C'est marrant parce-que ça fait un petit paquet d'années que PHP a de belles performances mais on continue de faire comme si ce n'est pas le cas…
          Perso, j'aurais été d'avis de ne cibler aucun langage (tant qu'on ne précise pas exactement la métrique et les conditions de comparaison, ou ça vient de la team core…)

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: encore ?

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

        depuis la 3.10, c'est la vocation de toute la team d'améliorer les perfs de Python pour revenir dans la course

        Oui, j'avais lu ça à l'époque et je trouve que c'est une bonne chose pour le langage par lui-même (et non pour le concours contre d'autres langages, tous ne jouant pas dans la même cour je pense)

        Alors oui, on a déjà eu quelques optimisations du bytecode en 3.9 et 3.10,

        Ouf… Orfenor a voulu me faire croire que je rêvais.

        Et a chaque nouvelle rc de la 3.11, les benchs sont de plus en plus positifs. C'est surtout ça que tu entends depuis un certains temps, le progrès de la 3.11 sur ce sujet.

        Ouf… Comme en plus je suis sur certaines listes, je vois passer pas mal d'annonces.
        Merci pour ta réponse : ça me rassure en plus d'éclairer fortement ce qui se joue. Vivement la version finale.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: encore ?

          Posté par  . Évalué à 2.

          Ouf… Orfenor a voulu me faire croire que je rêvais.

          non, c'est juste qu'Orfenor est un peu naïf, peu compétent en programmation et réagit un peu vite :-)

          • [^] # Re: encore ?

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

            :s/voulu/failli/
            Laissons de côté la naïveté et la compétence (je n'en ai pas beaucoup non plus)
            Je prends la promptitude à laquelle j'ajouterai la différence d'appréciation : je suis revenir lire ma réponse (et les questions incluses), et je crois qu'on n'a juste pas perçu les graphes de la même façon. Si on a ajoute le fait d'être dans le bruit des évolutions régulières pour moi, la chose ne m'a pas fait wahoo (même s'il est vrai que les petites marches finissent par faire un sacré escalier)

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: encore ?

      Posté par  . Évalué à 4.

      sauf que la en plus c'est encore plus incompatible avec la version précedente :p

  • # Commentaire supprimé

    Posté par  . Évalué à 2.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

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