Il y a perf et perf. Il y a dans le noyau des endroits où la performance compte (car c'est utilisé massivement ou avec des contraintes de dingue : pile réseau, mémoire, système de fichiers). D'autres où honnêtement on s'en fou (la plupart des pilotes ne sont pas à l'instruction près). Du coup les structures de données et les fonctions sont parfois optimisées à l'extrême au détriment d'autres facteurs (comme la lisibilité ou la simplicité) d'une manière que Rust ne ferait pas de manière canonique (ou que le compilateur Rust ne peut pas fournir par défaut). Et je pense que le but d'ajouter du Rust n'est pas de copier bêtement le code C avec des unsafe de partout, ça n'aurait pas grand intérêt.
Par exemple, admettons que Rust fait que avec ses vérifications supplémentaires, ses structures de base un peu plus complexes (mais plus puissantes) qu'en C ajoute 1% de perte de perf en moyenne, dans le cas d'un pilote disque où on va chercher les perfs maximales, ça peut faire grincer des dents. Donc démontrer que on peut avoir Rust qui soit vraiment proche du C (tout en ayant les avantages que fourni Rust) pour ce genre de cas est bienvenue.
Donc le sujet n'est pas si trivial que cela, même si pour la plupart des cas Rust peut valoir C niveau perf et que le peu de différence n'a que peu d'importance, pour le noyau dans certaines parties cela compte vraiment. Genre pour garantir que le noyau puisse traiter des connexions réseaux 10 Gbps et au delà, on en est à compter les instructions près pour garantir le débit dans les traitements.
[^] # Re: Performances
Posté par Renault (site web personnel) . En réponse au journal Rust dans Linux, ça démarre fort!. Évalué à 10.
Il y a perf et perf. Il y a dans le noyau des endroits où la performance compte (car c'est utilisé massivement ou avec des contraintes de dingue : pile réseau, mémoire, système de fichiers). D'autres où honnêtement on s'en fou (la plupart des pilotes ne sont pas à l'instruction près). Du coup les structures de données et les fonctions sont parfois optimisées à l'extrême au détriment d'autres facteurs (comme la lisibilité ou la simplicité) d'une manière que Rust ne ferait pas de manière canonique (ou que le compilateur Rust ne peut pas fournir par défaut). Et je pense que le but d'ajouter du Rust n'est pas de copier bêtement le code C avec des unsafe de partout, ça n'aurait pas grand intérêt.
Par exemple, admettons que Rust fait que avec ses vérifications supplémentaires, ses structures de base un peu plus complexes (mais plus puissantes) qu'en C ajoute 1% de perte de perf en moyenne, dans le cas d'un pilote disque où on va chercher les perfs maximales, ça peut faire grincer des dents. Donc démontrer que on peut avoir Rust qui soit vraiment proche du C (tout en ayant les avantages que fourni Rust) pour ce genre de cas est bienvenue.
Donc le sujet n'est pas si trivial que cela, même si pour la plupart des cas Rust peut valoir C niveau perf et que le peu de différence n'a que peu d'importance, pour le noyau dans certaines parties cela compte vraiment. Genre pour garantir que le noyau puisse traiter des connexions réseaux 10 Gbps et au delà, on en est à compter les instructions près pour garantir le débit dans les traitements.