Rust est-il plus rapide que le C ?

• La comparaison des performances entre Rust et le C est une question complexe, dont la réponse dépend de la définition de l’hypothèse « toutes choses étant égales par ailleurs »
• Dans le cas de l’assembleur inline, les deux langages peuvent générer exactement le même code assembleur, donc il n’y a pas de différence de vitesse propre au langage
• Pour la disposition mémoire des structures, Rust peut obtenir une taille plus petite grâce au réordonnancement des champs, mais l’attribut #[repr(C)] permet aussi d’avoir exactement la même disposition qu’en C
• En pratique, les vérifications à l’exécution et les habitudes des développeurs peuvent entraîner des différences de structure du code et de performances
• En conclusion, il n’existe pas de différence de performances due aux limites intrinsèques du langage ; le résultat varie selon le projet et les développeurs

---

Le problème posé et l’ambiguïté des hypothèses

• Le point de départ est une question soulevée sur Reddit : « À conditions égales, Rust peut-il être plus rapide que le C ? »
• L’expression « toutes les conditions sont identiques » est elle-même très difficile à définir lorsqu’on compare des langages
• Une comparaison de performances dépend non seulement des différences entre langages, mais aussi de la forme du code, des choix de développement et des optimisations du compilateur

Comparaison de l’assembleur inline

• Rust prend en charge l’assembleur inline au niveau du langage, tandis que le C l’implémente via des extensions de compilateur
  • Dans les deux langages, on peut écrire le même exemple utilisant l’instruction rdtsc
  • L’assembleur généré par rustc 1.87.0 et clang 20.1.0 est exactement identique
• Ce cas ne montre pas une différence de performances entre langages, mais il prouve que Rust permet le même niveau de contrôle bas niveau que le C

Différences de layout des structures

• Les structures Rust peuvent optimiser l’usage mémoire via le réordonnancement des champs
  • Dans l’exemple, la structure Rust occupe 16 octets, contre 24 octets pour la structure C équivalente
• En C, il faut modifier manuellement l’ordre des champs pour obtenir la même taille
• En Rust, l’attribut #[repr(C)] permet d’imposer exactement la même disposition mémoire qu’en C

Facteurs sociaux et humains

• Grâce aux vérifications de sûreté de Rust, il existe des cas où les développeurs peuvent tenter des optimisations plus agressives
  • Dans le projet Stylo de Mozilla, deux tentatives de parallélisation en C++ ont échoué, alors que l’implémentation en Rust a réussi
• Même sur un projet identique, les performances et la stabilité du code produit peuvent varier selon le langage et le niveau de maîtrise des développeurs
• Entre débutants et experts, et selon la familiarité avec le langage, le résultat d’une « même tâche » peut différer, ce qui rend toute comparaison simpliste difficile

Vérifications à la compilation et à l’exécution

• Une grande partie des vérifications de sûreté de Rust est effectuée à la compilation, mais certaines restent faites à l’exécution
  • Par exemple, lors d’un accès array[0], Rust effectue une vérification des bornes, alors que le C ne le fait pas
  • En Rust, l’utilisation de get_unchecked() permet d’obtenir le même comportement qu’en C
• Lorsque le compilateur peut prouver la sûreté, les deux langages peuvent éliminer ces vérifications via l’optimisation
• Ces différences influencent la manière d’écrire le code et peuvent, au final, provoquer des écarts de performances

Conclusion

• Même en supposant que le C soit « le langage le plus rapide », rien n’empêche Rust d’atteindre le même niveau de performances
• Plus que les limites du langage lui-même, ce sont les caractéristiques du projet, les compétences des développeurs et les contraintes de temps qui déterminent les écarts de performances
• Ainsi, la question « Rust est-il plus rapide que le C ? » relève davantage du contexte d’ingénierie que d’une simple comparaison entre langages