Posté par orfenor .
É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.
Posté par PR .
É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…).
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
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.
Posté par Yth (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.
# 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.
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 !
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.
Posté par flagos .
É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).
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
$ 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
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
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
: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
# encore ?
Posté par Gil Cot ✔ (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 orfenor . É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 PR . É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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Il y a une sixième page que j'ai loupée ?
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…
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 David Delassus (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
[^] # Re: encore ?
Posté par YBoy360 (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 Yth (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 :
En bash :
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 :
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 Yth (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 !
[^] # Re: encore ?
Posté par Pol' uX (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 flagos . É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 cg . Évalué à 10.
Vala vala ;)
[^] # Re: encore ?
Posté par Yth (Mastodon) . Évalué à 5.
Ah non, tu as mis le code dans la ligne de commande, à la rigueur :
Plus réaliste !
Bravo, le shell gagne donc encore haut la main !
[^] # Re: encore ?
Posté par cg . Évalué à 3.
Ruby On Rails va encore plus vite :
Vraiment formidable !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: encore ?
Posté par Yth (Mastodon) . Évalué à 3.
Ah, je connaissais pas cette notation, merci !
[^] # Re: encore ?
Posté par Gil Cot ✔ (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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
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)
Ouf… Orfenor a voulu me faire croire que je rêvais.
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 orfenor . Évalué à 2.
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 Gil Cot ✔ (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 ChocolatineFlying . Évalué à 4.
sauf que la en plus c'est encore plus incompatible avec la version précedente :p
[^] # Re: encore ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
optime price ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Commentaire supprimé
Posté par Anonyme . É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.