IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bruno

123PARTAGES

18  2 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de walfrat
Membre chevronné https://www.developpez.com
Le 01/12/2021 à 9:21
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 ?
14  1 
Avatar de bizulk
Membre confirmé https://www.developpez.com
Le 01/12/2021 à 10:48
"De la même façon, l'assembleur produira un binaire généralement plus compact et rapide que le C."

Je t'invite à tenter de concurrencer un compilateur C avec ton source en langage d'assemblage.
13  1 
Avatar de Jeff_67
Membre expérimenté https://www.developpez.com
Le 01/12/2021 à 8:32
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.
17  7 
Avatar de Jeff_67
Membre expérimenté https://www.developpez.com
Le 01/12/2021 à 10:53
Citation Envoyé par vanquish Voir le message
De la même façon, l'assembleur produira un binaire généralement plus compact et rapide que le C.
C'était peut-être vrai aux débuts de l'informatique. Mais avec les processeurs RISC et les architectures matérielles de plus en plus complexes, un compilateur sortira généralement du bytecode mieux optimisé que ce qu'aurait fait un humain en assembleur.
8  1 
Avatar de Nayte
Membre à l'essai https://www.developpez.com
Le 01/12/2021 à 10:58
Alors je fais peut être des raccourcis naïfs, mais dans les ordres de grandeur je ne pense pas me tromper :
  1. Les résultats de l'étude portugaise, en terme d'efficacité énergétique, sont fortement corrélés à des résultats de perfs de langage.
  2. Avec WASM, par construction JS se retrouve en concurrence avec les autres langages, y compris compilés et de bas niveau.

Donc pour le point 1, on apprend que plus un langage va vite moins le CPU est utilisé longtemps pour exécuter une tâche : incroyable.
Et dans le point 2, on apprend qu'un langage compilé & bas-niveau va plus vite qu'un langage scripté & haut-niveau : incroyable.

Au final j'ai beaucoup plus appris en lisant les commentaires pertinents des personnes ici. ^^

My 2 cents : ce qu'on voit là est une loi mathématique à l'oeuvre en biologie évolutive.
  • En période d'abondance de ressources, la sélection tend à favoriser d'autres traits avantageux que la chasse aux ressources (i.e. avantages reproductifs).
  • En période de contraction des ressources vitales, la sélection tend à favoriser drastiquement les traits améliorants l'accès aux ressources (i.e. avantages économes).

La queue du Paon, Python, même combat : c'est parfaitement adapté au contexte. Et le jour où l'économie de ressources sera vital, vous voyez très bien quels langages vont souffrir du nouveau contexte et lesquels vont briller.
8  2 
Avatar de Guesset
Membre expérimenté https://www.developpez.com
Le 01/12/2021 à 13:08
Bonjour,

J'ai regardé le code Pascal. Le potentiel d'optimisation est réel.

Dans certain cas, ce sera difficile. Par exemple, PiDigit utilise essentiellement GMP ce qui transforme une amélioration en la recherche d'une autre bibliothèque ou une réécriture de GMP (sans moi). Mais même cet exemple où le codage est essentiellement des appels à GMP, on trouve dans une boucle un mod 10 sur une variable incrémentée.

Le seul programme que j'ai un peu modifié est le spectralnorm. J'ai tiqué sur la fonction A qui calcule un inverse qui est ensuite multiplié par une variable. Comme la valeur inverse calculée n'est pas utilisée plusieurs fois (genre invA := 1/A; x:=invA* dx; y:= invA*dy; dz:= invA*dz), il n'y a aucun intérêt à avoir une division et une multiplication. Autant diviser directement cela économise une multiplication de flottants.
Ensuite on s'aperçoit que le diviseur peut se calculer par simple incrémentation (on économise 2 additions entières, une multiplication entière et un décalage unitaire). Tout cela dans les deux boucles principales. Un gain de plus 30% pour un travail à la paresseuse (sans restructuration) et je n'ai certainement pas tout vu.

Dans le programme n_body on trouve dans la boucle principale :
Code : Sélectionner tout
mag := dt / (sqrt(sqr(dx)+sqr(dy)+sqr(dz))*(sqr(dx)+sqr(dy)+sqr(dz)));
C'est faire une grande confiance au compilateur (peut être légitime) de supposer qu'il ne va pas calculer deux fois les sommes quadratiques.
J'aurais tendance à essayer ceci :
Code : Sélectionner tout
mag := dt * power(dx*dx + dy*dy + dz*dz, -1.5);
Certes, power n'est pas la plus rapide des fonctions mais elle remplace ici une division par une multiplication (bien plus rapide), supprime une racine carrée et une multiplication et lève toute ambiguïté sur l'aptitude du compilateur à éviter des recalculs.

En résumé, cela confirme ce qui a déjà été dit, les grandes communautés auront toujours plus de potentiel pour trouver le meilleur développeur pour un problème donné.

Salutations
6  1 
Avatar de Guesset
Membre expérimenté https://www.developpez.com
Le 02/12/2021 à 11:22
Bonjour,

La magie des compilateurs et la magie des processeurs modernes n'existent pas. Ils sont certes de plus en plus sophistiqués et performant mais ils ont beaucoup de handicaps, par exemple :
  • ils ne savent pas à quoi sert le code : l'exemple classique du comptage de bits qui nécessite au moins une dizaine de lignes de code ne sera jamais condensée en un simple popcnt.
  • ils ne connaissent pas les données : par exemple, ils (Comp) ne permuteront pas les cas dans un switch pour mettre les plus probables en début de liste, et l'anticipation des sauts (CPU) trouvera ici très vite sa limite.
  • ils (Comp) n'ont qu'une vision locale du code : certes une division par 2n sera traduite par un sar (décalage droit arithmétique qui conserve le signe) mais une division par une valeur calculée ailleurs qui a l'heur d'être toujours une puissance de 2 ne bénéficiera de cette optimisation.
  • ils n'anticipent pas : par exemple, si vous avez de grande masses de données en mémoire à traiter en séquence, malgré les (très limitées) lignes de cache du processeur, il vous appartiendra d'écrire des instructions de pré-chargement pour éviter un traitement systolique (par à-coup en français ) .

Je pense qu'il y a deux manières de travailler avec ces "magiciens" :
  • Faire comme s'ils n'apportaient rien et faire le meilleur code possible. Les gains qu'ils apporterons seront le bonus. Entre pas d'optimisation et le niveau maximal d'optimisations, sauf cas particulier, les gains sont souvent assez modérés de 8 à 10%. Mais c'est toujours bon à prendre.
  • Plus difficile mais plus efficace, faire un code qui aide compilateur et processeur à mieux travailler : par exemple, un code en assembleur qui entrelace bien ces instructions de façon à avoir le moins de dépendances entre instructions consécutives sera mieux traité par le processeur (out of order et utilisations des unité uop). Mais, outre que le code devient encore plus difficile à lire, le travail est sensiblement plus lourd.

Pour les moins convaincus, il y a un petit test qui échoue sur la plupart des compilateurs. Quelquefois des traitements nécessitent d'avoir à la fois le quotient et le reste (modulo) d'une division. On peut voir le code suivant :
Code C : Sélectionner tout
1
2
q = n \ d;   // => une division 
r = n % d;   // => une division
Or la division produit à la fois q et r. Il est donc possible d'utiliser un petit code assembleur qui évitera une division (Div() en C et C++, DivMod dans d'autre langage). Mais il est aussi possible d'écrire :
Code C : Sélectionner tout
1
2
q = n \ d;  // => une division 
r = n - d*q;  // => une multiplication
Ce dernier code est à peine moins efficient que le code assembleur (il n'y a pas d'appel de fonction dont l'un des retours ne peut être en registre) et reste presque deux fois meilleur que le premier toutes optimisations actives (la multiplication est bien moins gourmande que la division).

Il y a aussi la possibilité d'acheter une machine plus puissante

Salutations
6  1 
Avatar de Astraya
Membre chevronné https://www.developpez.com
Le 06/12/2021 à 21:19
Je vais faire une petite correction à tout ces titres :
WASM peut-il sauver la planète?
Rust, C ou C++ on peut faire la même chose ( hormis quelques paradigme spécifique )
Dire que C est plus rapide que C++ ou Rust c'est du Bullshit.
C++ n'est pas que POO, c'est multi-paradigme, donc on peut faire du C dans un .cpp
Juste pour info le compilateur C chez Microsoft c'est un compilateur C++... Donc C++ fait du C avec optionnellement une couche objet.
5  0 
Avatar de AoCannaille
Membre expert https://www.developpez.com
Le 01/12/2021 à 14:56
Citation Envoyé par Captain Spic Voir le message

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.
mvn clean install.

Ou n'importe quel dependency manager en fait... sur n'importe quel language correctement outillé. Dans mon monde je l'ai constaté en C++ et en Java, j'ai du mal à croire que ça n'existe pas pour du python ou d'autres langages populaires...

Tous les langages ont leur avantages et leurs inconvénients. Faut arrêter d'être sectaire dans un sens ou dans un autre.
Il faut également se tenir au courant de ce qui existe à côté pour comprendre que ce qu'on pense être un avantage n'est qu'en fait la norme.

Et ce genre d'article est intéressant pour garder des ordres de grandeur en tête.

Personnellement c'est la position de PHP qui m'a étonné. Pour moi il avait fait un sacré bon en perf avec sa version 7, ça ne ressort pas de ouf dans le tableau ici.
4  0 
Avatar de Guesset
Membre expérimenté https://www.developpez.com
Le 04/12/2021 à 15:09
Bonjour AoCannaille,

Citation Envoyé par AoCannaille Voir le message
...utiliser la commande time et celle-ci fait déjà la différence entre real (temps total ressenti), user(temps réel CPU accordé à l'utilisateur) et sys ( temps utilisé par les IO système)...
Peut être pas si simple. Il semble qu'ils aient choisi une exécution représentative du vrai monde et multiplié les exécutions pour avoir une moyenne plus stable. Ce qui peut se défendre mais reste sensible au changement de priorité.

En outre, comment le temps CPU est compté dans les multithreads (et il y en a) ? Temps CPU et durée peuvent être sensiblement différents. Par ailleurs, les changements de contextes (reprise d'un traitement d'un thread)) sont généralement à la charge du bénéficiaire ce qui signifie qu'une exécution chahutée sera plus longue - même en temps CPU - qu'une exécution plus zen.

J'ai toujours trouvé la mesure de temps très difficile et insatisfaisante. Et je ne parle même pas des processeurs qui s'amusent à faire évoluer leur vitesse.

Salut
4  0