En fait Rust n'a pas de problèmes de performances avec le bound checking.
Dans bon nombre de cas le compilateur peut reconnaître tout seul que l'accès est correct et il n'introduit pas de vérification superflue.
Si tu sais que l'accès est bien dans le tableau mais que le compilateur ne peux pas le savoir, tu peux marquer l'accès unsafe et utiliser get_unchecked.
Si tu n'en est pas sûr alors tu utilise get et tu gères le cas où l'accès est incorrect ou tu utilise les [] et si l'accès est incorrect le programme s'interrompt.
L'avantage de Rust c'est que c'est explicite. unsafe -> je fait du vélo sans les mains. Mais le linter te conseilleras d'expliquer pourquoi tu peux faire ça ici. Et tout bon relecteur passera 5 minutes de plus à cet endroit pour vérifier que tes hypothèses sont correctes.
En C il est trop facile d'oublier de vérifier que l'accès est correct et ça peut conduire à des bugs et des failles de sécurité.
Rust a aussi une forte tendance à copier/bouger les choses en mémoires
Je dirais que c'est vrai pour du code《naïf》(vite fait?) mais de mon expérience il est souvent (toujours?) possible d'écrire le code différemment et d'éviter ces copies.
Sur nos cas d'évaluation, code bare-metal pour micro-contrôleurs à fonctionnalités strictement égales nous avions les mêmes performances en C et Rust à 0,1%
Une fois à l'avantage de C une fois à l'avantage de Rust.
Pareil pour la taille du programme des tailles très similaires.
Par contre j'ai moins de difficultés à relire du code en Rust que en C. Sauf pour les parties en unsafe qui demandent parfois de serieux efforts de vérifications.
[^] # Re: Performances
Posté par jsbjr . En réponse au journal Rust dans Linux, ça démarre fort!. Évalué à 10. Dernière modification le 28 septembre 2022 à 23:03.
En fait Rust n'a pas de problèmes de performances avec le bound checking.
Dans bon nombre de cas le compilateur peut reconnaître tout seul que l'accès est correct et il n'introduit pas de vérification superflue.
Si tu sais que l'accès est bien dans le tableau mais que le compilateur ne peux pas le savoir, tu peux marquer l'accès
unsafeet utiliserget_unchecked.Si tu n'en est pas sûr alors tu utilise
getet tu gères le cas où l'accès est incorrect ou tu utilise les[]et si l'accès est incorrect le programme s'interrompt.L'avantage de Rust c'est que c'est explicite.
unsafe-> je fait du vélo sans les mains. Mais le linter te conseilleras d'expliquer pourquoi tu peux faire ça ici. Et tout bon relecteur passera 5 minutes de plus à cet endroit pour vérifier que tes hypothèses sont correctes.En C il est trop facile d'oublier de vérifier que l'accès est correct et ça peut conduire à des bugs et des failles de sécurité.
Je dirais que c'est vrai pour du code《naïf》(vite fait?) mais de mon expérience il est souvent (toujours?) possible d'écrire le code différemment et d'éviter ces copies.
Sur nos cas d'évaluation, code bare-metal pour micro-contrôleurs à fonctionnalités strictement égales nous avions les mêmes performances en C et Rust à 0,1%
Une fois à l'avantage de C une fois à l'avantage de Rust.
Pareil pour la taille du programme des tailles très similaires.
Par contre j'ai moins de difficultés à relire du code en Rust que en C. Sauf pour les parties en
unsafequi demandent parfois de serieux efforts de vérifications.