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.
Je n'ai jamais dit que ça ne pouvait pas être évité, juste que c'est un coût par défaut :)
Oui en utilisant 'unsafe', donc en perdant la memory safety sur des sections spécifique, le coût au runtime peut être by-passé et en Rust on peut égaler le C++.
A noté que je dis C++ car C++ tend déjà a être plus rapide que du C.
Ça revient en pratique à la même différence que en C++ entre les accès .at() (safe) et les accès via opérateur .
L'avantage de Rust est que ce genre d'opération doivent être marquée de manière explicite et c'est une très bonne chose.
En C++ pour du code safety-critical, on tend à le faire via analyses statiques au niveau du CI, ça se fait mais ça reste moins "pratique" à utiliser
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%
C'est aussi ce que j'ai remarqué entre C++ et Rust pour du code non-vectorisé.
Et quand grosse différence de perf il y a, ça vient principalement de l'auto-vectorization qui s'est appliqué dans un cas et pas dans l'autre.
Dans le cas du Kernel, ça n'a aucune importance car la plupart des instructions de vectorisations sont inutilisables (en auto-vec) en espace kernel.
[^] # Re: Performances
Posté par Firwen (site web personnel) . En réponse au journal Rust dans Linux, ça démarre fort!. Évalué à 6. Dernière modification le 29 septembre 2022 à 12:00.
Je n'ai jamais dit que ça ne pouvait pas être évité, juste que c'est un coût par défaut :)
Oui en utilisant 'unsafe', donc en perdant la memory safety sur des sections spécifique, le coût au runtime peut être by-passé et en Rust on peut égaler le C++.
A noté que je dis C++ car C++ tend déjà a être plus rapide que du C.
Ça revient en pratique à la même différence que en C++ entre les accès .at() (safe) et les accès via opérateur .
L'avantage de Rust est que ce genre d'opération doivent être marquée de manière explicite et c'est une très bonne chose.
En C++ pour du code safety-critical, on tend à le faire via analyses statiques au niveau du CI, ça se fait mais ça reste moins "pratique" à utiliser
C'est aussi ce que j'ai remarqué entre C++ et Rust pour du code non-vectorisé.
Et quand grosse différence de perf il y a, ça vient principalement de l'auto-vectorization qui s'est appliqué dans un cas et pas dans l'autre.
Dans le cas du Kernel, ça n'a aucune importance car la plupart des instructions de vectorisations sont inutilisables (en auto-vec) en espace kernel.