Je vais parler de .NET car Java je ne connais pas.
Mais à priori, ils sont assez jumeaux maintenant en terme de fonctionnement.
Le GC ne tourne pas à intervalle régulier. Il tourne "quand on en a besoin".
Si j'écris un "hello world" qui n'alloue pour ainsi dire pas de mémoire, ne fait rien et ne libère jamais d'objet, alors le GC ne va JAMAIS tourner (sauf quand le programme va s'arrêter).
En revanche, si j'ai un traitement qui crée des collections de milliers d'objets puis les libère sans arrêt dans une boucle, le GC va se lancer toutes les quelques secondes, voir plusieurs fois par secondes.
Le déclenchement du GC, en .NET est piloté par au moins 3 éléments :
- La pression mémoire "libérable" : tout au long du traitement, le GC calcule quelle taille il serait capable de libérer s'il se déclenchait. Quand ce nombre devient important par rapport à la taille mémoire disponible, alors le GC se déclenche.
- La charge CPU : quand le programme est dans un "creux d'utilisation" (attente saisie utilisateur par exemple) alors le GC va se déclencher avec un seuil plus faible que si on est en plein calcul multi-threadé.
- A la demande. Il est possible à tout moment, en tant que développeur, de piloter le déclenchement du GC. Ceci permet notamment de garantir qu'il va tourner "au moins quand le programme ne fait rien", et ainsi éviter de tourner par manque de mémoire ne plein milieu d'un traitement intensif.
Cependant, comme il a été mentionné à de nombreuses reprises, ce benchmark est totalement foiré car il permet l'utilisation de librairies qui ne font pas partie du langage lui-même.
Ainsi, si un programme en PHP ou même VBScript fait appel à une librairie codée en ASM par un fondu de l'optimisation, ces programme abominables en termes de performance vont paraître plus rapide, moins coûteux en mémoire que leur équivalent codé en C purement natif, ce qui est une hérésie.
Bref, c'est un peu comme la Formule 1 : on ne teste pas la voiture, on ne teste pas le pilote, mais on teste un mélange des deux, et pas moyen de savoir ce qui fait qu'une écurie a gagné : meilleure voiture ou meilleur pilote ?
Parce ça n'est pas un problème si simple qu'il n'y parait. Le fait de libérer la mémoire a intervalle régulier, c'est bien sur la première chose qui a été essayée, et si les algo de GC sont passé à des techniques plus complexes, c'est parce que ça n'est
clairement pas suffisant pour être fiable et efficace.
Ça fait des années que Java, .net, Go, ... améliorer leurs algorithmes de GC pour essayer le plus efficace possible dans le cas général. Mais il n'y a malheureusement pas un algorithme idéal qui répondrait parfaitement à toutes les situations. Il y a énormément de paramètres qui peuvent jouer. Certains programmes allouent la mémoire par petits bloc, d'autre par gros. Certains libèrent et ré-allouent beaucoup de mémoire, d'autres travaillent quasiment entièrement sur les même blocs, ...
Les objectifs de performances peuvent aussi varier. Certain programmes ont intérêt a éviter les pause longues pour éviter que le comportement du programme paraisse saccadé. Ainsi il peut être intéressant de faire des pauses plus courtes, mais plus nombreuses, même les performance globales sont moins bonnes,
Pour C, conçu initialement pour écrire des systèmes d'exploitation en substitution de l'assembleur, les résultats sont conformes.
En revanche, les performances du Pascal m'étonnent. Moins bonnes que Java qui travaille avec une machine virtuelle.
En supposant l'usage de Free Pascal, il y a peut être un surcoût dû au multi-cible (limitation des optimisations de bas niveaux ?) mais quand même. Je me demande si le code pascal était de qualité.
Auquel cas c'est plus un bench des langages les mieux maîtrisés et des meilleurs compilateurs (en laissant de coté les langages interprétés qui ne jouent pas dans la même cour car ils ne visent pas les mêmes objectifs) que celui d'un langage extrinsèque.
Si je suis d'accord avec l'esprit de cette assertion, je le suis moins avec la forme. Ainsi le langage C ne sait pratiquement rien faire par lui-même. Même un simple printf dépend d'une librairie.
Aussi je propose que le bench ne devrait porter que sur un source intégralement dans le langage en test, y compris les bibliothèques (exit les wrappers en tout genre). Par ailleurs, il faudrait garantir le "toutes choses étant égales par ailleurs" : machine (processeur, mémoire, type disque etc.) et OS notamment.
Le problème serait alors que beaucoup de langages disparaîtraient de la liste. Par exemple, beaucoup de langages proposent des fonctions qui n'existent pas en natif mais proviennent de librairies écrites dans un autre langage, généralement le C (la plupart des grep par exemple).
Mais cela ne paraît pas choquant.
Le benchmark game est en effet avant tout, comme son non l'indique, un jeu poussant les communauté autour de chaque langages a produire un code le mieux optimisé possible. Donc les langages qui ont une communauté nombreuse, partageuse et qui sait optimiser finissent par atteindre un niveau quasi optimal. Par contre, les langages moins courants ont, en effet, parfois des benchmarks pas forcément au niveau qu'ils méritent. Le Pascal étant passé de mode ces dernières années, je ne serais pas surpris que les contributeurs n'aient pas le même niveau de compétence en optimisation que ceux de langages plus en vue. Si vous vous en sentez capable de faire mieux en Pascal que le code actuel, vous pouvez contribuer, le principe du benchmark game est qu'il est ouvert au soumission extérieures.
Formulé comme cela, ça revient de facto a éliminer tous les langages sauf le C vu que pour accéder aux appel systèmes de manière stable, la plupart des OS ne fournissent que la libc ou une API maison sous forme de bibliothèque C.
Bonjour,
Même si des langages autres que c permettent d'appeler directement des API système, celles-ci restent majoritairement écrites en c. C'est pourquoi j'avais isolé l'OS et hésité également à isoler les api graphiques liées à un pilote qui n'est pas strictement du système (exemple : l'accès à l'usage de cuda). Mais c'est un vrai problème car dans les API d'un système, il y a celles du noyau et d'autres qui sont en concurrence avec des librairies classiques.
Salutations
@Guesset je suis d'accord avec vos propos mais je ne saisis pas trop bien à quelle conclusion vous voulez arriver ?
En développement informatique on peut tout faire ou presque.
Bonjour Mat,
Je n'ai pas d'objectif particulier car tous ces benchs me laissent perplexe (mais j'y jette un œil quand même ).
Mettre dans un même comparatif, des compilateurs en natif avec des générateurs de code intermédiaires (pour machine virtuelle comme Java, ou restant à finaliser comme un PCode) et avec des langages interprétés ne me semble pas avoir beaucoup de sens. Ils n'ont pas les mêmes objectifs d'efficacité, de portabilité et de rapidité de mise au point. De même le degré d'abstraction d'un langage est important : comparer de l'assembleur (tiens il n'est pas dans le bench) avec du prolog serait au mieux risible.
En résumé, il faudrait comparer des objets de même nature et de même objectif : par exemple comparer les langages procéduraux (impératifs) compilés entre eux (c, c++, rust, ada, pascal...). Et l'objectif ne me semble pas de désigner le meilleur langage mais de détecter les points forts et faibles relatifs afin de leur permettre d'améliorer leurs outils (compilateurs, dévermineurs, lieurs etc) plus que la nature même des langages (même si ce n'est pas à exclure).
Ayant utilisé pas mal (en quantité sinon en qualité) de langages, je suis assez peu sensible aux chapelles. Le bon langage change selon l'objectif.
C'était mon quart d'heure philosophique.
Salutations
bonsour Guesset merci pour la réponse.
Quoiqu'il en soit je vais me mettre à Direct X version 11 et je ne pense pas programmer le SDK en COBOL ( mais plutôt en C++)
Bonne soirée
Tous ceci me parait bien étrange car comment vraiment bien comparé Le C avec le Pascal ?
Il existe une multitude de compilateur C différents et aussi pour le Pascal mais comment ceci a t-il été comparé dans ces différents cas ?
Comme déjà expliqué a plusieurs reprise, c'est basé sur le Benchmark game, et oui, c'est loin d'être parfait mais si vous pensez pouvoir améliorer les performances des programmes en Pascal, vous êtes libre de participer au jeu.
Ce qui est surtout complètement stupide, c'est que pour avoir lu quelques énoncés du Benchmark, on ne mesure pas la capacité du langage, mais surtoutles compétencesle niveau de mathématiques du développeur.
Les notions abordées sont très abstraites et très orientées mathématiques.
Ainsi, là où un développeur A va pondre une boucle récursive lente à souhait, un autre va faire une bijection de la suite de Fibonacci et résoudre le problème avec 3 instructions.
A mon avis, il aurait été très préférable d'imposer un algorithme, quitte à mettre en concurrence différents algorithmes pour une même problématique, et tirer des conclusions à partir de là.
Mais clairement, ce benchmark me fait avant tout penser à ça :
https://adventofcode.com/2020 (sauf que là au moins j'ai compris les exercices et si mon code était lent, au moins j'ai pu jouer)
On le voit d'ailleurs très bien avec le palmarès des résultats : les langages utilisés à la fac sont contre toute attente, en dépit parfois de leur architecture définitivement plus lourde, genre langage interprété, largement favorisés par rapport aux langages plus anciens que les universitaires n'utilisent pas. Bref, c'est avant tout des TD de 7ème année de fac, très peu des programmes reflétant des cas d'utilisation concrètes.
Rust peut-il sauver la planète ? Un composant JavaScript a été réécrit en Rust
et aurait une amélioration de 50 % de la latence, une réduction de 75 % de l'utilisation du CPU et 95 % de la mémoire
Apocalypse ou pas ? Notre époque n’a jamais été aussi schizophrénique. Alors que les uns se plaignent d’une possible destruction de notre planète du fait des différentes technologies en place aujourd’hui, les autres pensent au contraire que la technologie peut résoudre les problèmes environnementaux. Lors d’une conférence d’AWS tenue cette année, Shane Miller, présidente de la Fondation Rust, et Carl Lerche, chef de projet de Tokio, ont plaidé en faveur de l'utilisation de Rust pour minimiser l'impact environnemental, tout en précisant que sa courbe d'apprentissage abrupte rendait la tâche difficile.
Rust est un langage de programmation compilé multiparadigme, conçu par Graydon Hore alors employé chez Mozilla Research, avec la contribution du créateur de JavaScript Brendan Eich. Utilisé par plusieurs grandes entreprises et par de nombreux développeurs dans le monde, Rust est devenu le langage de base pour certaines des fonctionnalités fondamentales du navigateur Firefox et de son moteur Gecko, ainsi que pour le moteur Servo de Mozilla.
AWS utilise Rust pour fournir des services tels qu'Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Amazon EC2), Amazon CloudFront, et plus encore. Récemment, l’entreprise a lancé Bottlerocket, un système d'exploitation basé sur Linux et écrit en Rust. L’équipe Amazon EC2 utilise le langage Rust pour développer les nouveaux composants du système Nitro d'AWS, y compris les applications sensibles, telles que les enclaves Nitro.
Dans une étude intitulée : Efficacité énergétique dans les différents langages de programmation et publiée en 2019, six chercheurs de trois universités portugaises ont révélé que Perl, Python et Ruby sont les langages de programmations les plus voraces en énergie. Pour comparer correctement l'efficacité énergétique entre différents langages, il faut obtenir des implémentations comparables de solutions à un ensemble représentatif de problèmes. Et c’est ce qui avait été fait par les chercheurs des universités portugaises.
Rust est l’un des langages de programmation les plus appréciés et dont la croissance est la plus rapide à l'heure actuelle. Selon Google, les défauts de sécurité de la mémoire menacent fréquemment la sécurité des appareils, en particulier pour les applications et les systèmes d'exploitation. Par exemple, sur le système d'exploitation mobile Android, Google dit avoir constaté que plus de la moitié des vulnérabilités de sécurité traitées en 2019 résultaient de bogues de sécurité de la mémoire. Rust s'est avéré efficace pour fournir une couche de protection supplémentaire au-delà même de ces outils dans de nombreux autres projets, y compris les navigateurs, les jeux et même les bibliothèques clés.
Microsoft a récemment formé une équipe Rust pour contribuer aux efforts d'ingénierie de l'écosystème du langage. L’entreprise spécialisée dans le développement de logiciel prévoit de travailler avec la communauté Rust sur le compilateur, les outils de base, la documentation et bien plus. Selon Nell Shamrell Harrington, Ingénieur logiciel chez Microsoft et directeur du conseil d'administration de la Fondation Rust, les logiciels et les langages open source sont d'une importance capitale pour son entreprise et pour l'ensemble de l'industrie technologique. « Au fur et à mesure que l'utilisation de Rust se développe chez Microsoft, nous savons qu'il ne suffit pas de l'utiliser uniquement comme logiciel open source. Nous devons également y contribuer », a-t-il déclaré sur le billet de blog publié ce 8 février par Microsoft. « Rejoindre la Fondation Rust est une façon pour nous de soutenir financièrement le projet et de nous engager plus profondément avec la communauté Rust », précise Harrington.
Comment Rust peut-il sauver la planète ?
La réponse est qu'un code plus efficace nécessite moins de ressources pour fonctionner, ce qui se traduit par une réduction de la consommation d'énergie dans les centres de données, ainsi que de l'impact environnemental de la fabrication des équipements informatiques et de leur expédition dans le monde entier. « Les centres de données consomment ... 1 % de toute l'énergie mondiale », a déclaré Miller, ajoutant toutefois que l'énergie totale consommée avait peu évolué en dix ans, grâce aux progrès technologiques et au fait que le cloud tend à réduire la proportion de ressources inutilisées.
La deuxième partie de l'argument est que Rust fait partie des langages de programmation les plus efficaces. La source citée pour cela est l’article susmentionné, de 2017, qui a mesuré les performances, l'utilisation de la mémoire et l'efficacité énergétique de 27 langages de programmation, et a placé C comme le plus efficace, mais Rust juste derrière avec seulement trois pour cent de plus d'utilisation d'énergie. Java utilise près du double d'énergie, C# plus de trois fois, et Python plus de 75 fois, selon l'étude.
Résultat global normalisé pour le temps d'énergie et la mémoire
Le top 5 des langages qui consomment le moins d'énergie est donc C (1,00), Rust (1,03), C++ (1,34), Ada (1,70) et Java (1,98). À l'opposé, les langages les plus voraces en énergie sont Perl (79,58), Python (75,88), Ruby (69,91), Jruby (46,54) et Lua (45,98).
La recherche est problématique, comme l'ont fait remarquer plusieurs participants à la conference, non pas par manque de soin, mais parce que les langages ont de nombreuses implémentations et compilateurs, dont certains sont plus efficaces que d'autres. Il est également étrange de constater que TypeScript est 10 fois moins efficace que JavaScript, étant donné qu'il se compile en JavaScript et qu'un code similaire peut être écrit dans les deux.
Cependant, cela n'est pas si important car l'efficacité de Rust en tant que langage de systèmes ne fait aucun doute, et Miller et Lerche ne se sont pas basés uniquement sur cette recherche. Miller a également fait référence à des études de cas de Discord et de Tenable qui ont montré d'énormes gains d'efficacité. Dans le cas de Tenable, un composant JavaScript a été réécrit en Rust et aurait obtenu une amélioration de 50 % de la latence, une réduction de 75 % de l'utilisation du CPU et une réduction de 95 % de l'utilisation de la mémoire. « C'est assez fou, a déclaré Miller. C'est une économie substantielle, pas seulement dans l'infrastructure, cela se traduit par des économies d'énergie. »
Les langages ramasse-miettes sont intrinsèquement moins efficaces, a déclaré Lerche. Le ramasse-miettes est un moyen courant d'automatiser la gestion de la mémoire et fonctionne en identifiant les objets qui sont hors de portée et en libérant leur mémoire. Mais, « si nous voulons atteindre les objectifs de réduction des émissions de carbone, nous devrons écrire la plupart des nouveaux logiciels dans des langages économes en énergie comme C ou Rust.
Rust a une courbe d'apprentissage quelque peu notoire... Nous assistons à son adoption, mais pas partout. », a jouté Lerche qui est par ailleurs ingénieur principal chez AWS.
« Là où je vois Rust se développer le plus, c'est là où il y a un gain de performance surdimensionné, donc les services de base de données à haut volume, également dans les petits environnements limités en ressources comme l'IoT et l'embarqué. Nous ne le voyons pas tant que ça : vous écrivez un back-end pour une application JavaScript. »
Le problème est que coder en Rust est difficile. L'une des raisons pour lesquelles des langages comme Java, JavaScript et Python ont été si largement adoptés est que les programmeurs peuvent devenir plus rapidement productifs. C'est donc l'éléphant dans la pièce, « la fameuse courbe d'apprentissage », a déclaré Miller. Dans une enquête récente, parmi les ingénieurs qui ont déclaré ne plus utiliser le langage, 55 % ont cité l'apprentissage et la productivité comme raison de leur abandon. « Les ingénieurs expérimentés ont besoin de trois à six mois d'études soutenues par un expert en la matière avant d'être productifs avec le langage. »
En début d’année, AWS, Huawei, Google, Microsoft et Mozilla se sont associées pour lancer la fondation Rust et se sont engagées à lui consacrer un budget de deux ans à hauteur d'un million de dollars. Ce budget permettra au projet de développer des services, des programmes et des événements qui aideront les responsables du projet Rust à développer le meilleur Rust possible. Ces Big Tech ont été rejoint par Facebook quelques mois plus tard. L'annonce avait été faite par Ashley Williams, Directeur exécutif par intérim de la fondation, le 8 février sur le site Internet de l'organisation.
« Aujourd'hui, au nom de l'équipe de Rust, je suis heureux d'annoncer la création de la Fondation Rust, une nouvelle organisation indépendante à but non lucratif chargée de gérer le langage de programmation et l'écosystème Rust, en mettant l'accent sur le soutien de l'ensemble des responsables qui régissent et développent le projet ». Pour Ashley Williams, Rust est un langage qui donne du pouvoir à tout le monde.
Et vous ?
« Coder en Rust serait difficile », qu'en pensez-vous ?
Utilisez-vous le langage Rust ? Avez-vous essayé de l'apprendre ?
Quel commentaire faites-vous de l'immense adoption de Rust par les Big Tech ?
« Rust doit être adopté par les développeurs pour minimiser l'impact environnemental », qu'en pensez-vous ? Le choix du compilateur ne serait-t-il pas plus interessant ?
Selon vous, la Technologie peut-elle résoudre les problèmes environnementaux ?
Voir aussi :
Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts
Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google
Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation
Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents
Il est clair que les codes compilés statiquement apportent un gros plus en terme d'usage CPU et d'empreinte mémoire par rapport aux langages interprétés ou compilés à la volée.
Mais il est fort illusoire de croire que les devs JS migrent massivement vers Rust. Et JS est une catastrophe à tout point de vue, pas qu'environnementale.
C'est quand même incroyable qu'il est toujours des mecs qui tapent sur des technologies juste pour le plaisir : PHP, JavaScript, Python aussi, etc
Oui on peut faire des horreurs avec ces langages mais on peut faire bien pire avec n'importe quel langage (je pense qu'on peut pas mal s'amuser avec du C, du Lisp, etc)
Oui le dossier "node_modules" pèse 1to sur ton disque, néanmoins je connais pas un autre langage où tu peux être opérationnel en seule une ligne de commande. Et on peut continuer longtemps.
Est-ce qu'on pourrait, une bonne fois pour toutes, arrêter avec ce genre de remarques inutiles et hostiles ?
Combien ça représenterais d'énergie vraiment économisée ?
Combien ça pèserai face au flx stream 4k voir 8k qui saturent nos réseaux ?
Le fait que TypeScript soit plus gourmand que Javascript n'est pas étonnant : il ajoute tout un tas de code Javascript que l'on aurait pas si on avait directement écrit en Javascript.
De la même façon, l'assembleur produira un binaire généralement plus compact et rapide que le C.
Mais je suis quand même surpris que l'écart soit si faible en terme de volume et si énorme au niveau performance.
Vous comparez deux langages complètement différent. Si rust avait été plus performant que du c++ ok y'aurait eu un article à faire. JS c'est de l'interprété, ça sert pas à la même chose, d'ailleurs on peut très bien faire des binds vers du c++ ou du rust.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager