Navigation

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

Débats sur le développement - Le Best Of Discussion :

Programmation : une étude révèle les langages les plus voraces en énergie


Sujet :

Débats sur le développement - Le Best Of

  1. #101
    Membre éprouvé
    L'avenir de python
    Citation Envoyé par la.lune Voir le message
    Les gens qui nous vantent de python qui enregistre une forte croissance, doivent vraiment nous trouver les arguments devant cette position de python. Si python continue à devenir le langage de programme le plus utilisé donc prochainement il faut s'assurer que la majorité des programmes vont contribuer à l'échauffement climatique.
    tout ce qui manque à Python, c'est un bon compilateur statique, capable de te sortir un ELF avec toutes les librairies intégrées dedans.

  2. #102
    Membre éprouvé
    Citation Envoyé par archqt Voir le message
    Oui je suis d'accord il y a une vidéo entre la vitesse C vs C++ qui montrait que le C++ était légèrement plus rapide, notamment sur du tri car grâce aux templates le code compilé l'était pour un tableau d'entier et non pas sur un algo QuickSort général qui existe en C (et qui fonctionne en C++ aussi). Globalement on montrait que, ben non le C++ n'est pas plus lent que le C. Donc la valeur donnée ici est très étonnante. Et je suis d'accord qu'ils ont dû comparer des bibliothèques plutôt et non pas le langage.
    Je suis aussi d'accord, cependant si tu test du C++ en dédiant tout à des librairies C, est-ce qu'on peut appeler cela un test C++ ?

    Si on veut parler d'écologie, il faut pas oublier d'inclure toute la chaîne de production, et aux nombres de personnes requises pour développer et maintenir par exemple une application en C par rapport à du C#/Java, il n'est pas certain d'être gagnant. On peut aussi mentionner le Cloud, faire payer à la consommation de CPU/RAM/Stockage ça a eu l'avantage de pousser en avant des solutions qui gaspillent moins.

    Petite question : que fait typescript dans le lot ? Ce n'est pas censé être transpilé en Javascript avant d'être interprêté ?

    On peut noter que Java est supérieur au C# en énergie/temps mais pas en espace. Ce qui en soit est logique. J'aurai eu quelque doute si Java était autant en avance que le C# sur les 3.

  3. #103
    Expert éminent sénior
    Citation Envoyé par la.lune Voir le message
    Les gens qui nous vantent de python qui enregistre une forte croissance, doivent vraiment nous trouver les arguments devant cette position de python. Si python continue à devenir le langage de programme le plus utilisé donc prochainement il faut s'assurer que la majorité des programmes vont contribuer à l'échauffement climatique.
    Le truc c'est qu'il faut garder une approche pragmatique. Il est clair que le Python ne doit pas être utilisé directement pour le calcul intensif. Mais il peut tout a fait servir pour piloter des composants qui sont écrits dans des langages de plus bas niveau.

    Citation Envoyé par defZero Voir le message

    Ces chiffres comparent la rapidité d’exécution et la consommation d’énergie, chosent qui n'ont absolument rien à voir avec un quelconque langage, mais uniquement leurs implémentations.
    C'est en grande partie vrai : la qualité de l'implémentation est essentielle et laisse planer un doute sur la pertinence de certaines mesures de cette étude. Mais il faut aussi reconnaître que le langage utilisé a quand même une influence sur les performances possibles. A un même niveau d'effort d'optimisation, un langage comme JavaScript ne pourra pas être, de manière consistante, aussi performant que des langages bas niveau comme C, C++ ou Rust. La nature de chaque langage fait que les possibilités d'optimisation offertes au compilateur sont différentes.

    Citation Envoyé par defZero Voir le message

    Malheureusement, il n'y a pas encore et pour le moment d'alternatives viables.
    Rust dépend encore de la glibc en standard, même si la team RedoxOS a réimplémenter une libc en pure Rust, ça craint un "remplaçant" qui dépend du "remplacé" .
    L'utilisation de la libc n'est pas une limitation technique de Rust. Il est tout a fait capable de se passer de la libc, c'est d'ailleurs ce qui se passe en mode nostd (indépendant de l'OS).
    Le problème est juste que la plupart des OS (Windows, macOS, *BSD) n'ont pas une API noyau stable. Donc il faut passer par la libc (qui,elle est stable) pour ne pas risquer de voir son programme cassé par une upgrade du système. Comme tu le dis, avec Redox, un OS qui a une api système faite pour le Rust, le problème ne se pose pas.

    De toute façon, en soi, utiliser la libc, n'a aucun impact technique sur le Rust.

    Citation Envoyé par defZero Voir le message

    Les vrai remplaçants seraient plutôt à chercher du côté de C2, Zig, Jai (?), ...etc qui se veulent de vrais substitues modernisés à tous points de vue.
    Ces langages ont les mêmes contraintes que Rust vis a vis de l'OS. Je dirais même que si les liens entre le Rust et le C te posent problème, ils devraient être encore plus problématiques pour toi, vu que certains d'entre eux sont carrément transpilés en C.

    Citation Envoyé par CaptainDangeax Voir le message
    Il me revient un exemple en tête. Je devais faire une recherche dans des logs. Je le fais en python + regex, c'est le plus facile pour moi. Mébon, 100 lignes à la seconde, ce n'était pas jouable. Je ré-écris le truc en C avec une lib regex, bah pas mieux.
    Pas étonnant vu que dans la bibliothèque standard de Python, l'implémentation des regex est faite en C.
    Si l'essentiel du travail de ton programme repose sur des expressions régulières, en effet, tu ne verras pas de différence. Mais si tu avais utilisé une bibliothèque de regex écrite en pur Python, je suis prêt a parier que les performances auraient été pire.

    Citation Envoyé par CaptainDangeax Voir le message
    tout ce qui manque à Python, c'est un bon compilateur statique, capable de te sortir un ELF avec toutes les librairies intégrées dedans.
    Pour ce qui est d'obtenir des performances similaires aux langages du top du tableau, c'est loin d'être suffisant. Le Python est bâti sur des choix techniques (typage dynamique, GC,...) qui font qu'il ne sera jamais optimal pour faire de la performance brute.

    Citation Envoyé par walfrat Voir le message
    Si on veut parler d'écologie, il faut pas oublier d'inclure toute la chaîne de production, et aux nombres de personnes requises pour développer et maintenir par exemple une application en C par rapport à du C#/Java, il n'est pas certain d'être gagnant.
    En effet c'est quelque chose d'important a considérer, mais ça serait a étudier de manière séparée : l'impact de la puissance de calcul employée et du travail d'une équipe de développeur sont deux choses différentes et qui peuvent être très variable d'un projet à l'autre.

    On peut avoir, par exemple, un travail de simulation physique qui demandera peu de codage mais qui nécessitera énormément de temps de calcul machine, ou inversement une interface de saisie complexe qui ne demandera peu de temps processeur mais beaucoup de travail aux développeurs.

    Citation Envoyé par walfrat Voir le message
    Petite question : que fait typescript dans le lot ? Ce n'est pas censé être transpilé en Javascript avant d'être interprêté ?
    Tout comme le code compilé n'a pas forcément la même qualité d'optimisation en fonction du langage d'origine, le code transpilé est rarement similaire à du code idiomatique, notamment du point de vue performance

  4. #104
    Membre à l'essai
    Il faut voir le python comme une glue, son but est de remplacer le bash. Pour ce qui est des algorithmes il s'appuie sur le C ou (certainement) le rust, le fortran ou ce qu'on veut (aller voir le code source numpy par exemple, je suis sur que c'est du C).

  5. #105
    Membre régulier
    Le meilleur !
    Pourquoi le langage C++ demeure incontournable 35 ans après sa sortie ?
    Tout simplement parce que c'est le meilleur langage !
    What else ?

  6. #106
    Membre averti
    Je ne comprend pas la place du Pascal et du Fortran.

    C'est, pour moi, des langages équivalent au C. Mais avec un domaine de prédilection différent (Le Fortran est très utilisé en calcul scientifique, par exemple).

    Et je ne comprend pas également la place du Java, car quand on voit une pile d'appel en Java, on pend peur. De mon point de vue, il devrait être plus ou moins à la même place que le C#.

  7. #107
    Expert éminent
    Surtout, rien que pour le C, entre une compilation avec Visual Studio, en cochant ou décochant certaines cases, on arrive à un binaire avec un rapport de 1 pour 2. Sans parler de ce qu'on obtient avec gcc, sous Linux ou sous Windows... et je ne parle pas de ma myriade d'options de compilations qui peuvent drastiquement changer les performances mais pas forcément être utilisées en production... genre le contrôle des dépassements lors des opérations... si on les désactive, évidement que ça va plus vite, mais à quel prix ?

    Bref, résultats au mieux surprenants, probablement totalement décorrélés de la réalité.
    On ne jouit bien que de ce qu’on partage.

  8. #108
    Membre habitué
    Evident! Le 'C' c'est l'alphabet du programmeur
    Le 'C' avec ou sans ++, va rester le langage des langages en informatique (ca fait 30 ans qu'on le dit). Pour des questions d’universalité, de maitrise et enfin on en parle : de dépense énergétique !

    En effet, c’est l’axe de recherche qui pourrait changer les rapports de force, notamment pour l’Europe qui pourrait revenir dans la course si nos industrie IT se mettaient à refaire tout ce qui est déjà fait , mais programmé comme il faut, avec donc une dépense énergétique 2 fois, 10 fois, 100 fois moindre dans certain cas.

    S’il reste des programmeurs dans ce pays… foncez sur l’industrialisation optimisée!

  9. #109
    Membre éclairé
    Citation Envoyé par Uther Voir le message

    Moi pas vraiment. Il est clairement en dessous de la plupart des langages bas niveau (C/C++/Rust) et statiquement typé (Java/C#/Go), mais bien au dessus des langages sans grosses prétention de performance comme (Perl, Python, Lua, Php,...)
    Tu le voyais plus haut ou plus bas?
    Clairement je l'aurais imaginé en-dessous du python et du PHP, parceque c'est toutjours la-dessus qu'on le tacle.

  10. #110
    Membre régulier
    Etant plutot a l'origine dev C/C++ je me renseigne sur RUST qui a l'air prometteur en terme de perfs... et quel ne fut pas ma grande deception !
    Franchement je ne comprends pas la logique a part inventer un nouveau langage pour faire le contraire des autres.
    Ou l'on apprend qu'une variable est par defaut CONSTANTE (alors que dans la plupart des programmes c'est l'inverse - plus de variables que de constantes).
    Du coup on ajoute un mot clé MUT a chaque variable pour signaler qu'elle est mutable/variable (donc mot cle requis dans 95% des cas et non pas les 5%).
    Et c'est comme ca tout le long sur quasiment chaque sujet, les tableaux memoires etc.
    Hallucinant.
    Pourquoi allez passer des heures sur un langage si c'est pour obtenir les memes perfs que quelque chose qui existe deja, qui n'impose pas de reinventer toute une gesticulation cerebrale pour reinventer des syntaxes toute plus ou moins barbares. Au final a part reinventer la roue carree, aucun gain.

    Ou je comprends mieux maintenant le gars qui a inventé python.
    Le gars se faisait chier, a decidé pour s'occuper d'inventer un langage.
    ""I didn't have a very rich social life at the time. So, instead of just watching TV, I would be coding, or sometimes doing both at the same time," he admits.'

    https://www.techrepublic.com/article...2c8QQRks4f_cRg

    un peu de hype et quelques articles et voila son truc lancé. Ca ne resoud rien qu'on ne savait pas resoudre auparavant (meme de maniere aussi elegante). Le plus important est SURTOUT de faire l'inverse de ce qu'ont fait les autres (meme si la logique au final ne ressemble a rien) sinon ca n'a aucun interet.
    Pas sur que ce soit bien rentable de passer du temps sur un langage a la mode a la syntaxe douteuse. Bref des fois il faut savoir sauter des "technos/langages"

  11. #111
    Membre actif
    Citation Envoyé par cecedu26 Voir le message

    Pourquoi allez passer des heures sur un langage si c'est pour obtenir les memes perfs que quelque chose qui existe deja, qui n'impose pas de reinventer toute une gesticulation cerebrale pour reinventer des syntaxes toute plus ou moins barbares. Au final a part reinventer la roue carree, aucun gain.
    Pour avoir l'assurance de l'état de la mémoire. Puis au final, le borrow checker, une fois compris, c'est surtout quelque chose qui te permet de moins te prendre la tête justement.

    Pour le surplus de syntaxe :
    - ça dépend énormément de comment tu codes.
    - ça permet d'avoir une variable mut avec la garanti d'un seul accès concurrent et plusieurs en lecture. Ce qui veut dire moins se prendre la tête pour la concurrence.

    Bref l'avantage de Rust par rapport à C, c'est pas du tout les perfs. L'histoire d'être proche en perf, c'est juste le minimum pour être un concurrent de C

  12. #112
    Membre habitué
    Ce qui me surprend, c'est qu'il n'y a pas eu de comparatif avec le langage D alors que ces gourous le vantent comme un moyen de conserver 90% de l'efficacité du C mais de n'en garder que 10% de sa complexité.
    Si quelqu'un à la réponse, je suis preneur.

  13. #113
    Expert éminent sénior
    Citation Envoyé par jpouly Voir le message
    Je ne comprend pas la place du Pascal et du Fortran.
    C'est, pour moi, des langages équivalent au C. Mais avec un domaine de prédilection différent (Le Fortran est très utilisé en calcul scientifique, par exemple).
    Je suis loin d'être une expert du Pascal, mais de ce que j'en connais, il est en effet techniquement a ranger dans les langage potentiellement proches du C. Je vois deux principales pistes d'explication a ces faibles performances.

    Premièrement, je ne suis pas sur du niveau d'efficacité des compilateurs actuels. Les compilateurs C ont fait des progrès énormes et Pascal ayant moins le vent en poupe, je ne sais pas si les compilateurs Pascal ont suivi. Beaucoup de langages modernes (dont Rust) ont fait le choix de s'appuyer sur des backend de compilateur C (GCC, LLVM, ...) pour pouvoir bénéficier à moindre frais de leur capacité d'optimisation.

    Une autre piste serait que la communauté n'a tout simplement pas soumis des programmes suffisamment optimisés au Bechmark game. Le Benchmarck game étant participatif les langages qui ont une communauté active est plus intéressée par les performances ont potentiellement de meilleurs résultats.

    Citation Envoyé par jpouly Voir le message
    Et je ne comprend pas également la place du Java, car quand on voit une pile d'appel en Java, on pend peur. De mon point de vue, il devrait être plus ou moins à la même place que le C#.
    Les piles d'appel à rallonge ne sont pas une propriété intrinsèque de Java, mais de la façon dont il est souvent utilisé : pour faire des choses très simples en apparence, de manière terriblement compliquée en interne via des frameworks complexes tels que Spring.
    Le benchmark game c'est l'inverse : aucune architecture, juste un algo qui nécessite beaucoup de puissance de calcul.

    Citation Envoyé par VBurel Voir le message
    Le 'C' avec ou sans ++, va rester le langage des langages en informatique (ca fait 30 ans qu'on le dit). Pour des questions d’universalité, de maitrise et enfin on en parle : de dépense énergétique !
    Pour l'universalité, en effet, le C est roi : tous les langages qui communiquent entre eux le font par son ABI. Par contre, pour le C++ ça n'est pas le cas.
    Pour ce qui est de la maitrise, le C++ est en effet bon, mais il y a quand même d'autres langages dans le coup notamment Ada et Rust.

    Citation Envoyé par L33tige Voir le message
    Clairement je l'aurais imaginé en-dessous du python et du PHP, parceque c'est toutjours la-dessus qu'on le tacle.
    On a pas du voir les même références alors. JavaScript était peut-être lent au début des années 2000, mais ça fait un moment que les développeurs de navigateur se battent pour booster ses performances. Sans ça, il n'aurait probablement jamais quitté les navigateurs.

    Au contraire, j'ai toujours entendu parler de Python et PHP comme des langages plutôt lents.

    Citation Envoyé par cecedu26 Voir le message
    Ou l'on apprend qu'une variable est par defaut CONSTANTE (alors que dans la plupart des programmes c'est l'inverse - plus de variables que de constantes).
    Du coup on ajoute un mot clé MUT a chaque variable pour signaler qu'elle est mutable/variable (donc mot cle requis dans 95% des cas et non pas les 5%).
    Je pense que tu n'as pas compris quel est le but de Rust. Le but premier n'est pas de simplifier l'écriture de n'importe quel code, mais de t'aider a produire du bon code.

    Je ne sait pas si tu as travaillé avec longtemps, mais pour moi à l'usage le mot clé mut n'est clairement pas requis dans 95% des cas. A vue de nez je dirais qu'il est vraiment utile dans un peu moins de la moitié des cas. Le problème des variables mutable par défaut, c'est que l'on peut facilement oublier de déclarer comme 'const' une variable qui aurait du l'être alors que l'inverse est immédiatement détecté par un erreur de compilation. Et avoir les variables immuables a des avantages que tu ne vois pas forcément, au niveau des optimisations et des risques de mauvaise utilisation notamment.

    Citation Envoyé par cecedu26 Voir le message
    Pourquoi allez passer des heures sur un langage si c'est pour obtenir les memes perfs que quelque chose qui existe deja, qui n'impose pas de reinventer toute une gesticulation cerebrale pour reinventer des syntaxes toute plus ou moins barbares. Au final a part reinventer la roue carree, aucun gain.
    Sauf que les gesticulations cérébrales que tu fais en Rust, tu doit faire les mêmes en C++ si tu veux faire un code de qualité. Rust t'interdit juste de faire du code potentiellement problématique.

    Citation Envoyé par Ecasla Voir le message
    Ce qui me surprend, c'est qu'il n'y a pas eu de comparatif avec le langage D alors que ces gourous le vantent comme un moyen de conserver 90% de l'efficacité du C mais de n'en garder que 10% de sa complexité.
    Si quelqu'un à la réponse, je suis preneur.
    C'est simplement que le langage D n'est pas dans le Benchmark Game.

  14. #114
    Modérateur

    @cecedu26 , pour moi l'objectif de Rust est de tirer le meilleur du C++, il ne s'agit pas simplement d'inverser des concepts mais de mettre à disposition des mécanismes qui par défaut rendront ton code plus safe, plus de débat NULL/nullptr, un type unique_ptr via une lib, du code avec des const T* partout etc
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  15. #115
    Membre émérite
    Bonjour.

    Ce test donne l’impression que le langage interprété java est super performant.

    Est-ce que ce test prend en compte l'utilisation cpu de la jvm ?

  16. #116
    Expert éminent sénior
    Ça fait plus de 20 ans que Java n'est plus interprété, du moins dans le sens traditionnel du terme. La Java Virtual Machine fait de la compilation à la volée.
    Et oui, les mesures du benchmark game tiennent bien compte de la consommation intrinsèque liée à la JVM, pour la simple et bonne raison que ça n'est pas vraiment possible de la mesurer séparément du reste.

  17. #117
    Membre émérite
    Bonjour.

    Citation Envoyé par Uther Voir le message
    Et oui, les mesures du benchmark game tiennent bien compte de la consommation intrinsèque liée à la JVM, pour la simple et bonne raison que ça n'est pas vraiment possible de la mesurer séparément du reste.
    Je ne comprends pas le
    ça n'est pas vraiment possible
    , c'est possible, c'est pas vraiment possible ou c'est impossible.

    De mes connaissances, la JVM, c'est un process. Et un process, ça consomme du cpu.

    Tu lances un programme Java, c'est aussi un process, qui consomme du cpu, ou alors il me manque une subtilité. Ce qui est possible.

    Du coup, je m'attends, pour une comparaison honnête avec des langages sans JVM, à : consommation cpu (JVM) + consommation cpu (Java programme) vs consommation cpu (langage non interprété).

    C'est le sens de ma question initiale.

    Vu que Java, au niveau consommation mémoire soit dans le bas du tableau, confirmerait qu'ils en tiennent compte en effet. Je pose donc cette question parce que je ne suis pas en mesure de la vérifier.


    Cordialement.

  18. #118
    Expert éminent sénior
    Je pense que la subtilité qui te manques, c'est que le programme Java n'est pas un processus séparé de sa JVM.

    A chaque fois que l'on lance un programme en Java, on crée une nouvelle JVM avec son propre processus. La JVM charge le bytecode de son application java, et le compilera au fur et a mesure des besoins. Le code compilé est exécuté, dans le processus de la JVM. On ne peut pas donc mesurer séparément le programme Java et sa JVM vu qu'ils sont intimement liés. Quand on mesure les performance processeur et la consommation mémoire d'un programme Java, on analyse en fait le processus de sa JVM.

    Le mieux que l'on puisse faire pour étudier l'impact spécifique de la VM sur les performance serait d'estimer le temps et la mémoire que consomme la JVM pour faire la compilation JIT. Il n'y a pas, à ma connaissance, d'outil pour mesurer ça et ça serait certainement imprécis et pas forcément significatif.

  19. #119
    Membre émérite
    Bonjour.

    Citation Envoyé par Uther Voir le message
    Je pense que la subtilité qui te manques, c'est que le programme Java n'est pas un processus séparé de sa JVM.
    Merci pour cette précision, je comprends mieux maintenant.

    Du coup, si tu mesures les performances cpu pendant que le Garbage Collector fait son travail, les résultats vont être désastreux.

    De ce que je vois avec les serveurs Java, le GC se manifeste à intervalle très régulier. Cela pourrait expliquer certains comportements lorsque tu fais du test de performance sur ces serveurs. Par exemple, la non linéarité des résultats.


    Citation Envoyé par Uther Voir le message
    On ne peut pas donc mesurer séparément le programme Java et sa JVM vu qu'ils sont intimement liés.
    Là j'ai un doute qui ne demande qu'à être comblé. D'accord c'est le même processus, mais sont-ils aussi le même thread ? Parce que l'on sait mesurer aussi les performances de chaque thread.

  20. #120
    Expert éminent sénior
    Citation Envoyé par moldavi Voir le message
    De ce que je vois avec les serveurs Java, le GC se manifeste à intervalle très régulier. Cela pourrait expliquer certains comportements lorsque tu fais du test de performance sur ces serveurs. Par exemple, la non linéarité des résultats.
    En effet c'est un problème connu des langages à GC, les performances sont moins prédictible vu que le GC impose des pauses de durée et de fréquence variable en fonction des stratégies adoptées. C'est en parti pour ça que ces langages sont a éviter pour les usages qui réclament une trop grande prédictibilité des performances. En tout cas ça ne serait pas honnête de vouloir sortir le coût du GC de l'analyse des performance d'un programme vu que la gestion mémoire fait partie de son bon fonctionnement.
    Même dans les langages sans GC, la gestion de la mémoire a aussi des coûts (allocation, désallocation, comptage de référence,...), c'est juste qu'ils sont généralement plus prédictibles.

    Citation Envoyé par moldavi Voir le message
    Là j'ai un doute qui ne demande qu'à être comblé. D'accord c'est le même processus, mais sont-ils aussi le même thread ? Parce que l'on sait mesurer aussi les performances de chaque thread.
    Bonne question. Je ne connais pas assez les détails spécifiques du fonctionnement des JVM pour répondre. Je ne crois pas que la spec de Java garantisse l'usage de thread particuliers pour les taches spécifique de la JVM.

###raw>template_hook.ano_emploi###