Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
On peut également espérer que l'adoption grandissante de Python va faire des perfs un enjeu grandissant également
De la même manière, JavaScript avait eu un boost de performance avec la bataille des navigateurs (Google avec la V8, Mozilla avec Spidermonkey...)
On peut déjà voir cette tendance: des librairies utilisent Cython, Python 3.11 a un focus particulier sur les performances etc.
https://www.infoworld.com/article/28...rformance.html
J'aime, java est bien classé et perl est dernier de la classe...
Alors, petite histoire réelle:
La demande au près des dev (java), hasher les mots de passe d'une BDD (environ 120 millions de compte à faire) , résultats: le rendu java mets plus de 4 jours pour faire le boulot en perf sur un env iso prod.
Petit dev en perl (car fait par un non developpeur) pour faire le même boulot : le rendu se fait en moins de 4 heures sur le même environnement.
Pour le coup, lequel ici à une grosse empreinte carbone ?
Morale: avant d'incriminer un langage ou un autre sur son empreinte carbone, faudrait peut-être voir ce qui se passe entre la chaise et le clavier car bien souvent le problème est plutot là !!!
Oui enfin là c'est juste que tes dev Java sont des charlots ou que le programme Perl se contente de faire appel a des programmes externe plus performants
Merci pour l'honnêteté, je fais de mon mieux ;-)Envoyé par Guesset
Disons qu'en général l'argument est en effet litigieux, puisque les ralentissements de windows sont une bonne cause d'obsolescence quasi-programmée des PC (alors que sous linux ils restent souvent très utilisables).
Mais, en l’occurrence dire que python vide la batterie..., je dirais généralement non, vu que python est très peu présent sur android et iphone
Argument presque recevable sur les PC portables (sachant que l'os rame tout seul avant les programmes sous windows)
J'ai écrit un programme seulement en python sur android pour voir, et ce que j'ai trouvé de plus léger et rapide c'est du python transpilé en javascript... (-> App <2Mo) (brython)
Le problème de la consommation de python est qu'il n'a pas été conçu pour l'efficacité à la base, et qu'ils n'ont pas eu assez de moyens jusqu'ici pour l'optimiser a posteriori contrairement à java ou javascript.
Peut être que ça changera avant les calendes grecques. Il y a bien pypy qui est assez rapide avec le JIT mais qui marche mal avec les modules en C... ou la compilation de code python typé avec mypyc que je découvre dans un lien supra qui accélère pas mal le code (mais encore en alpha)
C'est bien ce que je dis, retirons de l'équation les charlots et après on pourra peut-être s'en prendre a tel ou tel langage...
On entend dire partout que le langage python est un langage pour débutant, ce qui en fait un langage très prépondérant pour les charlots, c'est peut-être ça le problème
PS: et ici, je ne veux pas dire que tous les débutants sont des charlots
Entre la facilité d'utilisation d'un langage, l'environnement de développement de la solution, la qualité du code produit, l'environnement d'exécution de la solution, la fréquence à laquelle le programme sera utilisé, et les performances lors de l'exécution du programme associé, on peut facilement voir qu'il y a beaucoup plus de paramètres à prendre en compte pour déterminer quel est le meilleur langage ou la meilleure plateforme à utiliser.
- Les programmes qui sont utilisés ponctuellement ou rarement peuvent être développés dans le langage de notre choix, généralement, celui qui demandera le moins d'effort pour répondre au besoin, car le temps gagné en développement, qui correspond aussi à une économie énergétique, compensera largement la complexité mise en œuvre pour la réalisation d'un programme plus efficace énergétiquement.
- Les programmes utilisés de manière régulière quant à eux sont ceux qui nous intéressent, par exemple des backends de sites très fréquentés, les programmes grand public ou les programmes systèmes. Parmi ceux-là :
- généralement les programmes systèmes sont déjà en C, C++ ou en Rust, sauf rares exceptions. Il faudrait cibler les exceptions, en fonction de leur fréquence d'usage et de déploiement, et cibler les programmes qui sont les plus utilisés globalement pour les rendre plus efficaces énergétiquement.
- Les programmes grand public (comme discord, teams par exemple) sont selon moi très énergivores et pourraient être repensés pour consommer moins. Electron est selon moi un framework peu économe, certes pratique, mais il faut se rappeler de l'époque où il était impossible de faire une application performante en HTML/CSS/JS, et où il était question de faire une version "desktop" en natif.
- Pareil pour les applications mobiles qui ne sont que des webapp embarqués dans une vue web. Il faudrait resonger à les coder en natif pour améliorer leur performance et impact énergétique.
- Mais regardez les jeux-vidéos, quand vous pensez à la consommation CPU et GPU de ces derniers vous pouvez facilement deviner qu'ils consomment énormément! Cependant on ne peut pas demander à la population d'arrêter de jouer aux JV pour sauver la planète, ça ne passera pas ! (étant moi-même joueur j'aurais du mal à accepter)
- Les frontends en général sont en JS plus ou moins complexe, probablement qu'une préférence à avoir serait de faire du server-side rendering pour éviter d'exploiter la machine cliente pour du calcul alors qu'elle n'est pas forcément adaptée à cela. Avec un bon système de cache il est alors possible d'économiser grandement en consommation. Il serait intéressant d'analyser l'emprunte énergétique des différents frameworks de présentation (React vs Angular vs Vue vs Svelte, etc) et de comparer avec ces mêmes frameworks associés à un cache et/ou un ssr.
- En relation avec le point précédent, les programmes backends sont un levier sur lequel on peut agir. Rendre efficace un backend utilisé par des milliers de personnes quotidiennement est autant d'énergie économisée. Il faut peut-être investir dans ce domaine si on veut améliorer l'emprunte énergétique des serveurs dans sa globalité. Peut-on décemment imaginer concevoir un backend en C ? Quelle est la solution la plus efficace, d'un point de vue temps de développement et consommation énergétique pour créer une API ? Go ? Java ?
La question est donc bien plus complexe que de simplement dire qu'un langage est plus efficace énergétiquement qu'un autre sur un algorithme donné. Il y a des cas d'utilisations précis, des frameworks à prendre en compte, une diversité de programmeurs et de besoins. Selon mon point de vue "macro", l'essentiel est de repérer les processus qui s'exécutent le plus sur la planète, et déjà optimiser ceux-là, car 1s gagnée sur un processus utiliser par un million de personne par jour, c'est 1 million de secondes gagnées !
Peace.
Et les autres langages on en parle ?
Bien heureux celui qui pense detenir la vérité absolue sur ce thème.
Je trouve juste l'article très fermé et non 'comparatif' aux autres langages.
Prenons un exemple. JAVA ça parle à des gens ici ? Bien sûr que oui. Il est enseigné en premier langage dans quasiment toutes les études supérieures d'informatique. Combien de lignes faut il pour ecrire le même programme en java comparé à python ? Je n'ai pas forcément la réponse. Mais une chose est sûre beaucoup plus pour java que python. On passe beaucoup de temps devant l'ordinateur pour écrire un programme. On consomme beaucoup d'électricité. Pour une performance certes parfois accrue par rapport à python mais qui reste à mon avis anecdotique en terme de consommation d'énergie. Et pourtant énormément de gens continuent à développer en java. De là à se demander si java est bon pour la planète ?
Vous avez compris que mes propos sont purement provocatoires. Ils n'apportent pas grand chose au débat sauf juste se poser la question : A quoi sert ce genre d'études par des chercheurs qui ont eux-mêmes dépensé beaucoup d'énergie electrique pour écrire un pseudo étude de répercussions sur la planète. Peut-être à être vigilant au temps passé à développer une application....
Je veux bien. Ensuite, si on veut un code inchangé qui tourne sur toutes les plateformes (web, mobiles, PC...) ET qui soit facile à développer (environnement standard fait pour, doc simple, librairies, artéfacts en un clic) ET pas en webview, (en dehors des moteurs de jeu) je vois surtout dart+flutter. (sauf delphi mais trouver des tutos pour faire ça de marnière simple avec une interface moderne m'a stoppé).
Pour le webview, mon intuition au-delà du langage, c'est qu'il existe un usage abusif des frameworks. Quand je vois des pages web/app webview qui servent 6-7Mo de js minifié pour juste afficher un menu, une liste, des MP4 bidons, je me dis qu'on a raté un truc... Sans framework, avec le css w3 et 50 ko de code, j'avais pu faire simplement une GUI simple multi-écrans moderne single page avec lazy loading (maintenant le navigateur gère tout...)
Ce que je veux dire, c'est qu'il me semble qu'il y a une tendance à utiliser les outils les plus répandus, plus que sur l'optimisation.
Effet de masse
Bonjour kilone,
Je pense que ce raisonnement est erroné.
Les gains ne sont pas marginaux. Par exemple, il y a un rapport de plus de 70 entre Python et le premier de la liste. Le temps de développement sera plus rapide en Python mais pas dans le même rapport. Et ce temps est one shot alors que les gains s'expriment à chaque exécution pour chaque utilisateur.
Supposons un traitement de 7 mn en Python, il passe à 6 s en C soit un gain de 414 s/exécution. Si le surcoût de développement est de l'ordre d'un HxM soit environ 580 000 s, il faudra 1400 exécutions pour compenser le surcoût de développement. Avec seulement 1000 utilisateurs, il faudra moins de 2 exécutions par utilisateur pour absorber ce surcoût. Le reste est bonus.
Même si cette illustration peut être discutée, il est impossible de mettre dans la balance un gain de développement unique et un gain d'exécution multiplié par le nombre d'utilisateurs et le temps (nombre d'utilisations par unité de temps).
L'intérêt de ces langages n'est clairement pas là.
La sensibilité au temps développement (plus vite sur le marché), à la portabilité (cible plus large) et au coût du développeur (investissements plus faibles) sont certainement les arguments premiers. En fait, c'est le développement économique vs écologique.
Cela ne change en rien les qualités et défauts des différents langages. Il y a eu des interpréteurs de C et certains langages interprétés se sont vus dotés de compilateurs. Avec un succès très modéré hélas.
Salut
On peu utiliser le language le plus efficient possible, si derrière le dev ne fait aucune optimisation au final le programme consommera bien plus que tout langage interprété mais ayant eu un minimum d’optimisation.
Pour moi il ne sert a rien de se focaliser sur l’efficience du langage, c’est de la manière dont on s’en sert qui est déterminant.
/me runs Copilot in "eco-mode"
Là ou je suis, il y a eu quelques changement d'architecture et d'optimisations qui permet d'économiser environ 25k€/mois sur les cloud AWS.
Cependant je constate généralement :
- un manque de mutualisation des ressources (un serveur de BDD/client)
- les calculs avec Cython sont faits sur le même serveur qui héberge les services web (1 serveur/client)
En optimisation, je verrais :
- des serveurs de BDD mutualisés
- quelques gros serveurs mutualisés pour les gros calculs avec le programme réalisé dans un langage performant... RUST ?
- un serveur/client pour les services web (et encore, on a maintenant un besoin de vouloir connecter un utilisateur sur toutes les plateforme client)
PS : on est sur du Python/Django avec un gros monolithe côté back-end qui mériterais d'être un peu découpé.
Mieux
J'ai vécu une expérience similaire entre un script Perl accédant à une base Oracle et son équivalent ... en Pro*C, donc ce qui était sensé être le summum de la performance!Alors, petite histoire réelle:
La demande au près des dev (java), hasher les mots de passe d'une BDD (environ 120 millions de compte à faire) , résultats: le rendu java mets plus de 4 jours pour faire le boulot en perf sur un env iso prod.
Petit dev en perl (car fait par un non developpeur
Ne pas oublier que chaque programme accède à des librairies qui à un moment ou l'autre, sont en code binaire natif. Et si Perl en utilise une qui est plus performante que la plus populaire de ses équivalents en C (ici il s'agissait probablement des expressions régulières) alors un script Perl peut parfois être plus rapide qu'un programme en C.
Exact. En Perl j'écris beaucoup de scripts qui ne seront exécutés qu'une ou deux fois tout au plus (une en dev et une en prod...) donc le temps de développement réduit compensera largement la perte en performances éventuelle à l'exécution.
Là encore tout à fait d'accord. Parler de "multi-plateforme" pour des logiciels qui s'exécutent côté serveur (donc sur la même machine) n'a pas de sens, ils devraient être optimisés et compilés en natif. Parce que eux, justement, seront largement utilisés.
Côté client, Javascript est une aberration. Si on ne peut évidemment pas avoir un code natif multi-plateforme, là par contre la notion de bytecode prend tout son sens: espérons que WebAssembly finira quand même par percer, ce serait un moindre mal. Au moins on a déjà franchi le pas avec Android et sa machine Dalvik.
KiLVaiDeN et esperanto : je suis totalement d'accord avec vous.
Pour ajouter au débat, il est possible de concevoir un front-end avec du C++ dans Windows, en appelant directement l'API Win32. Cela est souvent plus perforant que les bibliothèques graphiques récentes, et incomparable au front-end JS.
Je pense que les front-end utilisé dans le web ne devrait être utilisé que dans le web.
Le plus important est ce qui ne va pas ;-)
Bonjour Mimoza,
Si je partage le besoin de bien développer, j'essaie d'éviter de négliger les autres composantes d'une réalisation.
En effet, la qualité d'une application dépend d'une chaîne dont notamment :
- qualité de l'expression du besoin
- choix et conception de la solution : outils (entre autres chaîne de développement), modularité (découpage organique), algorithme...
- qualité de l'implémentation.
- qualité des tests
La qualité d'une chaîne étant celle de son maillon le plus faible, il n'y a rien à négliger.
Je ne dois pas être le seul à qui c'est arrivé, mais je me souviens d'un développeur qui, après avoir mis des données de facturations téléphoniques détaillées dans une base, s'inquiéta qu'il faille 4 jours pour les éclater par service. Un programme en C sur les données brutes a fait le job si vite que la première fois, il a été relancé en pensant qu'il n'avait pas tourné.
Depuis, bizarrement, je ne considère plus le choix des outils comme étant secondaire.
Salut.
c'est le type de projet que je suis en train de développer.
Hé ho faudrait pas repomper sur ce que je fais non plus
Sinon concernant les technologies énergivores, pour les Cobolistes et les spécialistes Mainframe faudrait penser à se reconvertir car des entreprises comme Fedex se débarassent de leurs mainframes
article ici
Et le streaming vidéo !!
Ce genre de constat est vraiment du foutage de gueule. Combien consomment les programmes codés en Python par rapport au streaming vidéo sur l'ensemble de la planète avec Youtube, Netflix et Disney+ !!
Sans doute quelques millièmes en pourcentage !!
Détournement argumentaire
Bonjour,
Et le streaming,
Et les jeux,
Et la messagerie,
Et les vols d'avions,
Et l'industrie lourde.
Et le chauffage individuel
Et les véhicules automobiles etc.
C'est l'illustration parfaite des arguments assez classiques de détournement. Sans honte, ou à peine, je me cite "Cette technique, très utilisée par les hommes politiques, consiste à comparer à pire : "Quand on voit la consommation de xyz on se demande pourquoi s'intéresser à sss", "avant de s'intéresser à sss on ferait mieux de régler le cas de xyz". En général, on prend un pire cas difficile à résoudre et à la limite du domaine pour éviter les retours de manivelles par des experts".
J'aimerais bien savoir en quoi le streaming dédouanerait les développeurs de mal développer avec des outils inadéquats. C'est une méthode pour ne régler aucun problème car il y a toujours un autre problème dans un autre domaine qu'on peut mettre en balance surtout sans avoir aucun élément chiffré à présenter.
Un point d'accord :c'est du foutage de gueule.
Salutations
Erreur dans le tableau
Sans avoir lu tout les commentaires (257 tout de même), j'ajoute que le tableau présenté comporte une grosse coquille. Le puissance étant le produit de l'énergie (ici en joule) par le temps (ici en seconde), le tableau donne pour Python 80,7 kW et pour C 0,0448 kW. Dans le cas de C, le résultat est vraisemblable, mais pour Python, c'est n'importe quoi.
Euuuh... bah non. Une puissance, c'est un travail (ou une énergie) divisé par le temps... pas multiplié... sinon ça donne n'importe quoi!
(d'ailleurs, le watt, c'est des joules par secondes... )
Répondre avec citation
Partager