FR
PerfR transforme les ralentissements C-Rust récurrents en règles réutilisables
Where Does the Performance Go? Understanding and Recovering Performance Regressions in C-to-Rust Translation · arXiv:2610.23044
En termes simples
Cet article étudie pourquoi un logiciel traduit automatiquement du C vers Rust peut s’exécuter plus lentement. PerfR est un cadre d’optimisation guidé par des règles : il repère les fonctions qui consomment le plus de temps, cherche des motifs de ralentissement récurrents et utilise un modèle de langage d’IA pour évaluer des réécritures possibles.
Le modèle vérifie si les conditions d’une réécriture sont réunies. PerfR ne conserve une modification candidate que si les tests montrent que les sorties restent les mêmes et que le temps d’exécution diminue.
Sur des projets distincts, PerfR a été plus rapide que le code traduit non modifié pour presque toutes les tâches testées, tout en produisant des sorties correspondant à celles du C pour l’ensemble des tâches évaluées.
La recherche
Quand un logiciel est traduit automatiquement du C vers Rust, conserve-t-il sa vitesse ? Si ce n’est pas le cas, les causes du ralentissement peuvent-elles devenir des corrections utiles sur d’autres projets ?
Les auteurs étudient ces questions à partir de tâches complètes dont les sorties peuvent être vérifiées, puis réservent des projets distincts pour voir si le cadre fonctionne au-delà de ceux qui ont servi à établir ses règles.
PerfR transforme des ralentissements récurrents en règles pour réécrire le code Rust traduit du C, puis vérifie chaque modification avant de la conserver.
Les exécutions comparées ont montré que, pour 12 des 19 tâches étudiées, le Rust traduit était plus lent de plus de 3 % que le C, par rapport au temps d’exécution de celui-ci.
L’analyse du compilateur et du code source a révélé neuf problèmes récurrents, qui ont servi à établir les règles de réécriture de PerfR.
Sur 41 tâches réparties dans 12 projets d’évaluation distincts, PerfR a été plus rapide que le Rust traduit non modifié pour 40 tâches et a produit des sorties correspondant à celles du C pour les 41 tâches. Ces décomptes étayent une récupération des performances sur les charges de travail testées.
Les résultats portent sur des tâches de programmation déterministes sélectionnées dans 20 projets. Le fait que les sorties C et Rust correspondent pour les entrées testées ne garantit pas le même comportement avec d’autres entrées ou pour d’autres tâches.
La comparaison initiale entre C et Rust utilise aussi des configurations de compilation différentes selon le langage : elle ne permet donc pas de distinguer l’effet de la traduction de ceux du compilateur et du langage.
Ce que montrent les preuves
- La question et les projets étudiés
PerfR est un cadre d’optimisation guidé par des règles. Il utilise un grand modèle de langage (LLM), un système d’IA entraîné sur de grandes quantités de texte, pour améliorer des projets Rust traduits du C par c2rust.
L’article demande si la traduction ralentit des projets réels, quelles en sont les causes et si celles qui reviennent peuvent devenir des corrections réutilisables. Les auteurs étudient des tâches complètes dont les sorties peuvent être vérifiées ; ils établissent les règles à partir de huit projets sélectionnés et les évaluent sur 12 projets distincts.
- Où la traduction ralentit
Sur les 19 tâches de l’étude, les exécutions comparées montrent que le Rust traduit était plus lent de plus de 3 % que le C, par rapport au temps d’exécution de celui-ci, pour 12 tâches. Le problème varie donc selon les tâches ; ces résultats ne montrent pas un ralentissement uniforme à l’échelle d’un projet.
Les auteurs examinent ensuite les fonctions du projet les plus sollicitées dans les tâches plus lentes pour en retracer les causes.
- Des écarts aux règles
En comparant les sorties du compilateur pour les deux langages et le code traduit, les auteurs repèrent neuf problèmes récurrents : deux formes de travail d’exécution superflu, deux transformations manquées par le compilateur et cinq motifs dans le code source.
Chaque problème retenu doit être étayé par la charge de travail et par des éléments sur son mécanisme ; chaque groupe doit compter au moins trois occurrences. Les auteurs obtiennent ainsi des pistes d’optimisation à partir d’écarts observés dans le code, au lieu de considérer comme un problème de performance tout code Rust qui paraît inhabituel.
- Comment PerfR applique les règles
PerfR applique ces pistes en analysant les projets pour repérer les fonctions les plus sollicitées, puis en comparant les éléments produits par le compilateur côté Rust et le code source aux règles.
Le modèle de langage vérifie si les conditions préalables à une réécriture sont réunies dans le contexte du projet. PerfR propose une modification lorsqu’un motif correspond ; des vérifications fonctionnelles et des mesures du temps d’exécution déterminent si elle est conservée.
- Temps d’exécution et sorties
Sur 41 tâches réparties dans les 12 projets d’évaluation distincts, les évaluateurs ont constaté un temps d’exécution inférieur à celui du Rust traduit non modifié pour 40 tâches ; les sorties de PerfR correspondaient à celles du C pour les 41 tâches testées.
Il s’agit de décomptes de tâches, et non d’une accélération moyenne. Les temps d’exécution et les vérifications de sortie étayent une récupération des performances sur cet ensemble de tâches, dans les conditions d’évaluation employées.
- Apport et portée des règles
Deux vérifications supplémentaires examinent l’apport des règles et leur récurrence ailleurs. À partir d’une même base affinée, PerfR a été plus rapide que la version qui omet les fiches d’optimisation pour 34 tâches sur 41, ce qui étaye l’apport des règles dans ce processus.
Dans les projets d’évaluation distincts, au moins un motif associé aux règles apparaissait dans 94 % des fonctions les plus sollicitées ; cette fréquence indique la présence de motifs reconnaissables, pas celle de réécritures acceptées.
Détails
- Auteurs de l’article original
- Zhiqiang Yuan, Chong Wang, Zhenhao Zhou, Junwei Liu, Xin Peng
- Soumis à arXiv
- Licence
- arXiv non-exclusive