IdentifiantMot de passe
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 !

Google affirme qu'il est non seulement possible, mais aussi relativement facile de remplacer C/C++ par Rust dans les firmwares.
L'entreprise explique en quoi ce changement est avantageux

Le , par Stéphane le calme
38 commentaires

65PARTAGES

12  0 
« Les équipes Rust chez Google sont deux fois plus productives que celles qui se servent de C++ », d’après un responsable de l’entreprise
Qui lance le débat de la productivité entre Rust et C++

Les comparatifs entre les langages Rust et C++ portent en général sur des aspects comme la performance et la sécurisation des espaces mémoires des applications. Certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++. C’est sur la question de l’impact que le choix de ces langages a sur la productivité des développeurs que les intervenants ne se sont pas trop penchés. Google vient de publier les résultats d’un sondage en interne et il en ressort que les équipes Rust en son sein sont deux fois plus productives que celles qui se servent du langage C++.

Les conclusions de Google se basent sur les perceptions des répondants au sondage. Le temps nécessaire à une réimplémentation en Rust comparé à celui d’une précédente réimplémentation en langage C++ est l’un des premiers aspects sur lesquels le sondage en interne au géant technologique a porté.

« Nous avons noté une réduction de 50 % de l’effort nécessaire pour mettre sur pied un service en langage Rust ainsi que pour en assurer la maintenance », déclare Lars Bergstrom dans son comparatif d’impact sur la productivité des développeurs causé par les langages Rust et C++.



L’enquête comparative de l’impact du choix des langages C++ et Rust sur la productivité des développeurs s’est étendue au-delà de la production du code informatique. Les répondants ont en sus partagé leurs perceptions pour ce qui est de la productivité en Rust comparée à celle d’autres langages (C++, Java, etc.) dont ils font usage. Dans les chiffres, le tiers des répondants a déclaré devenir aussi productif en Rust que dans les autres langages en 2 mois au maximum.



Lorsqu'un développeur a fini de travailler sur un ticket, un autre membre de son équipe passe en revue le code en se posant les questions suivantes :

  • Le code présente-t-il des erreurs logiques évidentes ?
  • Après examen des exigences, tous les cas ont-ils été complètement mis en œuvre ?
  • Les nouveaux tests automatisés sont-ils suffisants pour le nouveau code ? Les tests automatisés existants doivent-ils être réécrits pour intégrer les modifications apportées au code ?
  • Le nouveau code est-il conforme au guide stylistique actuel ?

C’est un jeu de questions qui démontre le potentiel impact des revues de code sur la productivité d’un ou d’une équipe entière de développement. Les résultats de l’enquête de Google suggèrent que le langage Rust est susceptible de s’avérer être un bon choix pour ceux désireux de se simplifier les revues de code. En effet, plus de la moitié des répondants du sondage déclarent que les revues de code en langage Rust sont plus aisées que dans d’autres langages (C++, Java, Python, etc.)



Le sondage s’est en sus penché sur la qualité du code comme indicateur de productivité. Dans les chiffres, 85 % des répondants sont d’avis que le langage Rust permet d’obtenir des bases de code d’un niveau de qualité supérieur à celui d’autres langages.



L’analyse du temps passé par les développeurs de logiciels dans les activités de création de produits et les tâches nécessaires pour mettre le code en production fait partie des métriques sur lesquelles s’appuie McKinsey dans l’évaluation de la productivité des développeurs. De façon concrète, il s’agit de mesurer la répartition du temps entre les activités de codage, de construction et de tests unitaires (boucle interne) et les activités d’intégration, de test d’intégration, de publication et de déploiement (boucle externe). C’est la mise en œuvre d’un procédé en principe similaire qui permet à Google d’arriver à la conclusion que les équipes Rust chez Google sont deux fois plus productives que celles qui s’appuient sur le langage C++.


La productivité des développeurs est en général sujette à débats. Certains intervenants de la filière sont d’avis que le sondage de Google souffre d’un biais de sélection des répondants dont les perceptions orientent les résultats.


Certains intervenants de la filière mettent souvent la chaîne d’outils du langage Rust en avant comme l’un des atouts susceptibles d’améliorer la productivité des développeurs en comparaison à d’autres langages de programmation. Des observateurs sont néanmoins d’avis que le compilateur Rust est un tueur silencieux de la productivité des développeurs qui travaillent sur des bases de code importantes.


Source : Lars Bergstrom

Et vous ?

Quelle appréciation faites-vous des résultats de ce sondage mené en interne par Google ? Sont-ils pertinents ? Quels sont les aspects qui vous semblent biaisés ?
Que pensez-vous de l’analyse du temps passé en C++ puis en Rust dans les activités de création de produits et les tâches nécessaires pour mettre le code en production comme métrique de mesure de la productivité des développeurs ? Quelles sont les métriques susceptibles de la compléter dans le processus de comparaison de l’impact du choix des langages C et C++ sur la productivité des développeurs ?

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
Vous avez lu gratuitement 4 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

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

38 commentaires
Commenter Signaler un problème
NotABread
Avatar de NotABread
Membre actif https://www.developpez.com
Le 10/09/2024 à 9:50
Citation Envoyé par 23JFK Voir le message
Il semble que Rust soit trop strict pour être viable dans la chaîne de développement d'une entreprise qui vise, entre autre, le profit. Le code permit par Rust est un sous-ensemble de tous les codes fiables et sécurisés possibles pour un problème donné. Les dev passeraient ainsi plus de temps à se battre avec le compilateur pour satisfaire à toutes les exigences de Rust qu'à écrire d'autres parties de code permettant de livrer dans les temps un produit "fini" (qui fait au moins ce pourquoi il a été prévu - Osef des bugs, les updates c'est fait pour les corriger) aux utilisateurs. Et de toute façon Rust ne permet pas de se prémunir contre les bugs/failles hardware comme celles qui ont affecté les processeurs Intel (DownFall etc...)
Je ne suis pas d'accord. Je trouve que le fait que le compilateur soit plus strict ne ralenti pas le développement, car entre le moment où tu ponds ton premier binaire et le moment où tu as un binaire près pour la release, et bien tu as des phases de test même minime. Donc certes, tu mettras plus de temps à satisfaire ce tyran de compilateur, mais tu gagneras en vas-et-viens entre la plateforme de test et ton PC car toutes les erreurs de manipulation de la mémoire sont éliminé avant même que les binaires soient mis sur la plateforme.

Après, Rust, c'est pas magique, tu auras toujours des problèmes de précision lié à la représentation numérique, dead lock et autre problème classique qui n'est pas en relation avec l'allocation, l'initialisation, la lecture, l'écriture et la libération de la mémoire. De plus, si la majorité du code doit être en unsafe, Rust ne serait pas adapté (pas assez de connaissance sur les microcontroleurs et firmware pour savoir dans quel scénario ça arrive)
3  0 
fdecode
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 13/09/2024 à 22:53
Citation Envoyé par 23JFK Voir le message
Ou que l'on obligé de faire de l'unsafe et l'unstable.
Et bien non! Il ne vous a pas échappé si vous êtes allés sur le Playground, que le code en question fonctionne dans une version stable de Rust:

Ce qui est nighty, c'est la librairie SIMD, pas les instructions machines répliquées dans le core Rust.

Pour ce qui est de l'unsafe, il est tout naturellement utilisé ici pour inclure du code machine, donc extérieur à Rust, tout comme on utilise de l'unsafe pour inclure une librairie C : cela sert à isoler les parties du code non contrôlées par la sémantique de sécurisation de Rust. Il s'agit pour le coup du contexte d'utilisation le plus simple de l'unsafe: délimiter le code externe. Pas de risque d'UB. Vous ne risqueriez donc pas d'y perdre des dents.
3  0 
fdecode
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 12/09/2024 à 11:15
Citation Envoyé par 23JFK  Voir le message
Reste qu'apparemment, il n'est pas possible de tout faire en Rust et certain projet comme construire une librairie Rust semble carrément impossible, l'algorithme de la racine carré-inverse rapide ne semble pas non plus pouvoir être tolérée par le compilateur (spéculatif, je n'ai pas essayé ; mais étant donné qu'il faille jouer avec les différents motifs mémoire fonction du types des nombres, en Rust ça doit être un enfer) ; la compilation est affreusement lente quand il faut récupérer tous les paquets Cargo pour un gros projet. Franchement passé la hype, je ne vois pas comment Rust pourrait avoir une trajectoire différente d'Ocaml ou Haskell, c'est un truc d'université/laboratoire qui ne semble pas pouvoir s'adapter à la réalité des entreprises.

Cela a l'air très personnels et émotionnels comme griefs. Je vais simplement répondre à la demande concrète de votre message: "algorithme de la racine carré-inverse rapide" (de quake, je suppose).
Dans la mesure où c'est un algorithme de calcul très approximatif, et que l'instruction SSE RSQRT existe désormais, il me paraît assez peu intéressant, mais il a quand même été facile de trouver un exemple d'implémentation [playground]:

Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
fn inv_sqrt(x: f32) -> f32 { 
    let i = x.to_bits(); 
    let i = 0x5f3759df - (i >> 1); 
    let y = f32::from_bits(i); 
     
    y * (1.5 - 0.5 * x * y * y) 
} 
 
 
fn print_both(v: f32) { 
    println!("quake: {}", inv_sqrt(v)); 
    println!("real:  {}", 1.0 / v.sqrt()); 
    println!(); 
} 
 
fn main() { 
    print_both(4.0); 
    print_both(10.0); 
    print_both(3.1415); 
}
Ceci-dit, le code de quake n'est pas très intéressant puisque le calcul exact tient en 3 instructions machine.
2  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 13/09/2024 à 9:48
C'est pour ça que le nombre d'instruction machine n'est pas une métrique suffisante pour mesurer la performance. Il faut aussi avoir une bonne idée de l'efficacité des instructions. Et encore le nombre de cycle d'une instruction peut varier en fonction du contexte.

Les instructions de division et de racines carrée sont connues pour être lentes. Toute l'intérêt de l’algorithme de Quake, c'est qu'il n'utilise rien de plus complexe que la multiplications.
2  0 
Pyramidev
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 14/09/2024 à 1:47
Citation Envoyé par 23JFK Voir le message
Désolé, mais dans le code d'en haut, from_bits() semble tagué unstable.
f32::from_bits est stable depuis Rust 1.20.0. C'est le fait que cette fonction soit const (l'équivalent de constexpr en C++) qui n'est pas encore stable.
2  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 18/09/2024 à 9:41
Je sais qui est Mara Bos, mais il y a des bugs bien plus vieux et plus impactants que ça dans le compilateur qui ne sont pas encore corrigés car ils impliqueraient une refonte technique complexe et qu'on considère improbable de les déclencher sans faire exprès.
Le plus connu étant le bug https://github.com/rust-lang/rust/issues/57893 qui permet de faire un transmute sans bloc unsafe. En théorie il casse complètement la sécurité de Rust mais vu que le code qui peut déclencher le problème n'a pas vraiment de sens dans du code normal, il n'est pas considéré urgent et attend la refonte du borrow checker à venir.

Au vu du code tordu de la crate de Mairia Bos, j'ai l'impression qu'on est bien dans cette catégorie.
2  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 19/09/2024 à 9:41
En relisant plus attentivement, ce n'est en effet pas un bug mais une exploitation particulièrement gore des macro procédurales et de la variable d’environnement non documentée dont je parlais.

En gros le code du projet qui contient la macro est transformé en un sous projet et le projet en cours deviens un script de compilation qui va compiler le sous-projet avec la variable d’environnement secrète qui permet d'ignorer l’interdiction. Bref une horreur a éviter.
2  0 
Pyramidev
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 09/09/2024 à 23:30
Citation Envoyé par Stéphane le calme Voir le message
« Vous n'allez pas nous forcer à apprendre Rust », a déclaré un contributeur du noyau Linux lors d'une discussion animée au début de l'année à l'occasion d'une conférence.


Rendez-vous à 28:40
Non seulement il ne veut pas apprendre Rust, mais il est aussi contre le fait d'encoder les règles d'usage d'une API directement dans le système de types. Dans le cas où les règles changent, il dit, à 27m23 : "If that breaks Rust, we will find out whether or not this concept of encoding huge amounts of semantics into the type system is a good thing or a bad thing and instead of trying to convince us what is actually correct, let's see what happens in a year or two" (à 27m23).

Le 21 juin, Jake Edge a bien résumé cette vidéo dans son article Rust for filesystems.

Le 31 août, sur Mastodon, Asahi Lina a bien expliqué l'intérêt d'encoder les règles d'usage d'une API dans le système de types :

Citation Envoyé par Asahi Lina
I think people really don't appreciate just how incomplete Linux kernel API docs are, and how Rust solves part of the problem.

I wrote a pile of Rust abstractions for various subsystems. For practically every single one, I had to read the C source code to understand how to use its API.

Simply reading the function signature and associated doc comment (if any) or explicit docs (if you're lucky and they exist) almost never fully tells you how to safely use the API. Do you need to hold a lock? Does a ref counted arg transfer the ref or does it take its own ref?

When a callback is called are any locks held or do you need to acquire your own? What about free callbacks, are they special? What's the intended locking order? Are there special cases where some operations might take locks in some cases but not others?

Is a NULL argument allowed and valid usage, or not? What happens to reference counts in the error case? Is a returned ref counted pointer already incremented, or is it an implied borrow from a reference owned by a passed argument?

Is the return value always a valid pointer? Can it be NULL? Or maybe it's an ERR_PTR? Maybe both? What about pointers returned via indirect arguments, are those cleared to NULL on error or left alone? Is it valid to pass a NULL ** if you don't need that return pointer?

[…]

To be clear, I don't blame Linux developers for the incomplete docs. For better or worse, the Linux kernel is very complex and has to deal with a lot of subtlety. Most userspace APIs have much simpler rules you have to follow to use them safely. Kernels are hard!

Even experienced kernel developers get these things wrong all the time. It's not a skill issue. It's simply not possible for humans to keep all of these complex rules in their head and get them right, every single time. We are not built for that.

We need tooling to help us.
Mais il y a de la résistance au changement.
2  1 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 12/09/2024 à 18:00
Citation Envoyé par 23JFK Voir le message
Reste qu'apparemment, il n'est pas possible de tout faire en Rust et certain projet comme construire une librairie Rust semble carrément impossible
Je vais supposer que tu t'es mal expliqué parce qu'il est évident que Rust peut faire des bibliothèques. Le dépôt standard de Rust contient plus de 150 000 crates dont la plupart sont des bibliothèques.
Si tu voulais parler de bibliothèque qui s'interface avec d'autre langages, c'est aussi possible, à condition d'avoir une interface qui respecte l'ABI C. C'est en effet limitant, mais c'est pareil pour tout les langages qui veulent s'interfacer avec d'autres.

Citation Envoyé par 23JFK Voir le message
l'algorithme de la racine carré-inverse rapide ne semble pas non plus pouvoir être tolérée par le compilateur (spéculatif, je n'ai pas essayé ; mais étant donné qu'il faille jouer avec les différents motifs mémoire fonction du types des nombres, en Rust ça doit être un enfer) ;
C'est un peu le problème, beaucoup de gens ont un avis très tranché sur Rust, basé sur des spéculations fausses. Rust peut tout à fait faire des manipulations de bit basiques, c'est juste que les hacks comme les conversions douteuses ou les dépassement volontaires, sont remplacés par des fonctions explicites pour être sur qu'ils sont fait à dessein et que ce n'est pas des erreurs.

Citation Envoyé par 23JFK Voir le message
la compilation est affreusement lente quand il faut récupérer tous les paquets Cargo pour un gros projet.

Ça c'est vrai, mais pour le coup on ne compile pas un gros projet de zéro si souvent que ça. Quand on recompile un projet sur lequel on travaille, ça va beaucoup plus vite. Ça reste plus lent que le C mais pas vraiment plus lent que des langages plus complexes comme le C++.

Citation Envoyé par fdecode Voir le message

Ceci-dit, le code de quake n'est pas très intéressant puisque le calcul exact tient en 3 instructions machine.
Il me semble que la racine inverse rapide est encore pas mal utilisée dans la 3D, l’approximation étant relativement bonne et le gain sensible. Toutes les instructions machines ne se valent pas, 3 instructions complexes, peuvent prendre plus de cycles qu'une dizaine d'instructions plus simples.
1  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 12/09/2024 à 18:28
Après vérification, la racine inverse rapide est environ 2,5 fois plus rapide sur ma machine.
1  0 
Commenter Signaler un problème