Journal Rust dans Linux, ça démarre fort!

Posté par  . Licence CC By‑SA.
Étiquettes :
37
27
sept.
2022

Salut,

Alors que Rust n'est pas encore intégré au noyau Linux (c'est prévu pour la version 6.1), il y a 2 modules tests qui sont en cours de développement: un pilote NVM Express et un serveur de fichier 9P.
L'intérêt du pilote NVM Express est de montrer qu'il atteint presque les même performances que celle du pilote C existant.

Plus ambitieuse encore, Asahi Lina est en train d'écrire un pilote en Rust(*) pour les GPU Apple M1/M2!

Bien sûr, c'est encore un peu en rodage: il y a encore des limitations/problèmes coté Rust, des méfiances/interrogations coté développeurs Linux, mais je trouve que ça démarre fort!

*: le pilote ne sera pas forcément intégralement en Rust

  • # C'est officiel...

    Posté par  (Mastodon) . Évalué à 8.

    … il va falloir que je me mette au Rust !

    Des ressources de référence à conseiller ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: C'est officiel...

      Posté par  . Évalué à 5.

      T'es rouillé mon pauvre

    • [^] # Re: C'est officiel...

      Posté par  . Évalué à 10. Dernière modification le 28 septembre 2022 à 09:41.

      Si tu as déjà appris les bases du langages (pour ça je conseillerais rustlings), il y a ce moteur de jeu pour s'entraîner, ça ressemble à une série d'exercices et c'est plus rigolo que de coder des FizzBuzz.

      • [^] # Re: C'est officiel...

        Posté par  (Mastodon) . Évalué à 8.

        Merci pour la réponse, je vais regarder ça !

        Je me suis permis d'éditer ton post pour mettre un raccourcis vers rustlings, tu peux me confirmer que c'est bien le bon ?

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: C'est officiel...

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Le bouquin officiel «the rust programming language» est particulièrement bien fait je trouve. Si le papier te fait souffrir sache que le livre est disponible gratuitement en ligne.

      Ensuite il faut se trouver un «side project», du temps et surtout … de la persévérance.

      J'ai plus qu'une balle

    • [^] # Re: C'est officiel...

      Posté par  . Évalué à 10.

      Au début des années 1980, j'ai appris seul, comme un grand, le C avec l'incontournable "The C programming language" de K&R. Je me souviens qu'au début, je me disais, en faisant les exercices proposés, les auteurs se moquent un peu de moi avec des exercices aussi triviaux. Puis, en avançant, j'ai constaté que bien au contraire, les auteurs prenaient leurs lecteurs pour des gens sérieux.

      Alors, l'expérience C m'ayant réussi, j'ai commencé, il y a un peu moins d'un mois, à apprendre Rust, toujours comme un grand, avec "The Rust programming language" de Steve Klabnik et Carol Nichols, et des contributions de la communauté Rust.

      Pour l'instant, les exercices sont faciles et parfaitement adaptés à un autodidacte, mais l'avenir me dira si les choses se compliquent.

      Vous allez me dire pourquoi apprendre un nouveau langage de programmation a passé 80 ans (j'en ai pratiqués au moins une bonne vingtaine dans ma carrière) ?
      À rien, mais, comme Cyrano, je pense que "c'est bien plus beau lorsque c'est inutile". Et au passage, cela mes nettoie les méninges

      • [^] # Re: C'est officiel...

        Posté par  (site web personnel) . Évalué à 8.

        Vous arrivez avec 50 ans d'expérience en programmation ? Au japon, ils appellent ça un "trésor national" !

        Avez-vous un commentaire sur l'évolution des langages depuis les années 1970 ? Qu'est-ce qui change dans le travail quotidien ?

        "La première sécurité est la liberté"

        • [^] # Re: C'est officiel...

          Posté par  . Évalué à 10.

          Plus précisément 57 ans, j'ai écrit mon premier programme, en Fortran, lors de mes études d'ingénieur, en 1965.

          L'évolution des langages de programmation ?

          Pas grand chose à en dire, on peut programmer comme un goret* (c'est hélas souvent le cas) avec n'importe quel langage et faire les choses bien également avec n'importe quel langage, cela dépend essentiellement de la personne qui programme.

          Je dirais qu'un tournant important a été fait avec Algol** (le langage de programmation, pas l'étoile), il apportait la récursivité, la structure en blocs, le typage, bref, tout ce qu'il fallait pour faire de la programmation structurée. C'est le précurseur académique de C, Pascal, Modula, Ada etc.

          Je ne suis pas un fanatique des langages objets, dans la mesure où c'est un oreiller de paresse, on peut parfaitement programmer avec le paradigme "objet" en C, par exemple, aucun problème pour implémenter la notion d'héritage en C, on crée une hiérarchie de fonction, ce n'est pas automatique, il faut le coder, mais on y gagne beaucoup en performances, comme je l'ai montré dans un benchmark C <-> C++.

          J'ai tâté de la programmation logique avec Prolog, intéressant sur le plan scientifique et intellectuel, mais pas vraiment utile dans mon domaine.

          APL, langage où l'élément d'information est un tableau sans dimension prédéfinie aussi intéressant sur le plan intellectuel, plaît aux matheux purs et durs (on programme une inversion de matrice en une ligne). À l'opposé des matheux, on peut l'utiliser pour du prototypage, pour valider rapidement un algorithme, que l'on reprend ensuite dans un langage plus adapté.

          Pour conclure, je dirai que ce qui a le plus changé, ce sont les outils mis à disposition pour programmer : éditeur, debuger, environnement de programmation, etc.

          Outils que je n'utilise pratiquement pas. J'utilise un éditeur que j'ai écrit en C; au début des années 80, avec le souci de portabilité et, depuis près de 40 ans, je le transporte de plateforme en platforme. Avec l'avantage que, quelle que soit la plateforme, j'ai le même éditeur. Ce sera sans doute mon premier programme "sérieux" en Rust le portage de mon éditeur.

          Pour les debuger, Je suis de la vieille école, celle où la compilation de 200 lignes de Fortran prenait 10 minutes et où on n'avait pas accès directement à la machine et où l'on pouvait, au mieux, avoir trois passages par jour en machine. Alors, je peaufine soigneusement le source avant de compiler et tester et je n'ai pas trop besoin de debuger, dans les cas rétifs***, je parsème le code de "display" de certaines variables et cela me suffit amplement.

          Mon environnement de programmation est simple : sous Linux, un grand écran, 3 consoles ouvertes : une contenant l'édition du source, une autre le lancement de la compilation (ou de l'assemblage) et une troisième pour le test. C'est simple et efficace.
          .
          .
          .
          . * Avant ma retraite, j'enseignais la programmation embarquée dans une école d'ingénieurs, je disais souvent à mes étudiants lors des TP (travaux pratiques) : "profitez d'être à l'école pour bien faire les choses, vous aurez tout le temps dans l'industrie de faire de la saloperie".

          ** Algol précédait d'une dizaine d'années mon premier programme, ce n'est que plus tard, une dizaine d'année après que j'en ai compris l'importance.

          *** Le cas le plus rétif que j'ai eu dans toute ma carrière, c'était, en fin des années 1960, sur un programme assembler pour l'IBM 1620. J'avais écrit comme code opération TF (transfert arrêté par un flag d'une position mémoire à une autre position) à la place de TFM (transfert à une position mémoire du deuxième opérande de l'instruction). Impossible de faire une analyse post-mortem de la mémoire, le bug mettait toute la mémoire à zéro. Alors je faisais le cheminement à la main, j'arrivais sur le TF fautif, je disais je fais le transfert d'adresse (raisonnement évidemment faux), cela a duré pratiquement une semaine. Et cela m'a marqué profondément, la preuve, je m'en souviens en détail plus de 50 ans après.

          • [^] # Re: C'est officiel...

            Posté par  (Mastodon) . Évalué à 10.

            "profitez d'être à l'école pour bien faire les choses, vous aurez tout le temps dans l'industrie de faire de la saloperie"

            Ça c'est tout simplement magnifique !

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

          • [^] # Re: C'est officiel...

            Posté par  . Évalué à 5.

            L'éditeur est-il disponible quelque part ?

            Sinon merci pour le témoignage très intéressant, je pense qu'il va être utile à beaucoup. :)

            • [^] # Re: C'est officiel...

              Posté par  . Évalué à 6.

              Je vous réponds rapidement.

              L'éditeur, mais il a 40 ans d'âge, avec les méthodes de cette époque. La première mouture fut faite sous MSDOS, avec la limite de 640 ko y compris les données. Comme il n'était pas question de multitâche sous MSDOS, j'avais parsemé le code d'appels à une fonction qui scrutait le clavier, si pas de caractère présent -> retour, si caractère présent, mise en fifo, retour. Le programme principal boucle sur lecture du fifo et si pas vide fait ce qu'il y a à faire.
              Le premier portage a été sous Unix, il a consisté essentiellement à briser la barrière 640 ko et à établir un pipe entre deux tâches tout en éliminant les appels à la fonction clavier. L'affichage utilise curses.
              Les différents portages (sous différents micro-calculateurs) n'ont pas vraiment modifié l'architecture de la chose. Bien entendu pas de coloration syntaxique. pas d'Unicode, mais en revanche des commandes proches de MES besoins : déplacement gauche, droite, haut, bas, vers caractère, mot, ligne, écran, fichier. mode insertion/remplacement, duplication d'une ligne, etc. Tel qu'il est, il correspond parfaitement à mes besoins. Si je le réalise sous Rust, bien évidemment j'incorporerai coloration, Unicode, appairage des débuts/fin de blocs en fonction du langage, etc.

              Je suis tout disposé à vous envoyer le source, une compilation sous Linux (pour que vous expérimentiez) et un mode d'emploi (que j'avais rédigé à l'usage de mes étudiants).
              Le seul problème, c'est que je pars dimanche à 15 h 20 pour le Vietnam où je vais rester deux mois, d'ici début décembre je ne pense pas que j'aurais la possibilité de vous envoyer quoi que ce soit.
              Faites moi connaître le moyen pour prendre contact avec vous. Je ne souhaite pas vraiment donner mon adresse courriel publiquement.

              • [^] # Re: C'est officiel...

                Posté par  . Évalué à 5.

                Est-ce que vous êtes en mesure de mettre votre code dans un dépôt Git public et protégé par une licence, hébergé par exemple sur GitLab ?

                • [^] # Re: C'est officiel...

                  Posté par  . Évalué à 6.

                  Tout à fait possible, mais pas le temps avant mon départ. Mme s'inquiète déjà : les valises ne sont pas faites …

              • [^] # Re: C'est officiel...

                Posté par  (site web personnel, Mastodon) . Évalué à 5.

                Si, comme moi qui n’aie toujours rien compris à github et à ce genre de trucs tu n’es pas très à l’aise avec ça, si c’est possible, tu pourrais peut-être me l’envoyer par courriel id et mon nom de domaine. Je le mettrais à disposition quelque part.

                « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

                • [^] # Re: C'est officiel...

                  Posté par  (site web personnel) . Évalué à 10.

                  L'usage d'un gestionnaire de version devrait être enseigné en école primaire.

                  git

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                  • [^] # Re: C'est officiel...

                    Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 05 octobre 2022 à 18:00.

                    L'usage d'un gestionnaire de version devrait être enseigné en école primaire.

                    Justement, « gestionnaire de version » n'est pas synonyme de « Git » ; ne faisons pas comme Bill qui voulait que traitement de texte signifie son infâme w0rd.

                    edit : mauvais thread (je pensais que c'était celui svn-vs-git) ; mais bon c'est Github le problème ici non ?

                    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                  • [^] # Re: C'est officiel...

                    Posté par  . Évalué à 3.

                    J'ai jamais compris ce qu'il y avait de particulièrement beau dans le DAG de git. C'est un dag quoi.

                    J'ai raté une pépite ?

                    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                    • [^] # Re: C'est officiel...

                      Posté par  . Évalué à 4.

                      Il est particulièrement beau par rapport à CPOLD.

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                      • [^] # Re: C'est officiel...

                        Posté par  (site web personnel, Mastodon) . Évalué à 5.

                        Beau ou bon ? Ce n'est pas censé être décoratif ce genre de truc, non ?

                        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

                        • [^] # Re: C'est officiel...

                          Posté par  (site web personnel) . Évalué à 3.

                          Le DAG, c'est le cœur de Git et la vraie beauté est à l'intérieur !

                          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                        • [^] # Re: C'est officiel...

                          Posté par  . Évalué à 2.

                          Pourquoi opposer les 2 ?

                          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                          • [^] # Re: C'est officiel...

                            Posté par  (site web personnel, Mastodon) . Évalué à 5.

                            Ce n'est pas les opposer, mais ce n'est pas le même sens et c'est agaçant de voir que"bon" a disparu entraînent des imprécisions de langage.

                            « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

                            • [^] # Re: C'est officiel...

                              Posté par  . Évalué à 2.

                              "bon" a disparu ? Tu parles de manière générale ou juste dans cette discussion ? J'ai effectivement constaté que certains remplaçaient "bonne journée" par un "belle journée" mais à part ça il a disparu ailleurs ?

                              • [^] # Re: C'est officiel...

                                Posté par  (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 06 octobre 2022 à 22:28.

                                Récemment, j'ai entendu qu'un plat pourtant immangeable mais bien présenté était une bonne assiette…

                                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                            • [^] # Re: C'est officiel...

                              Posté par  . Évalué à 2.

                              En quoi bon est il plus précis ? Si je dis « mercurial est un bon gestionnaire de version » ça dis quoi en plus par rapport à si je dis « pijul est un beau gestionnaire de version » ?

                              Dans les 2 cas tu peux te dire que je les apprécie.
                              « bon » se veut probablement plus objectif, mais du coup il ment plus souvent.

                              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                      • [^] # Re: C'est officiel...

                        Posté par  . Évalué à 2.

                        On devrait s'émouvoir qu'ils ont écrit des tests aussi ?

                        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                        • [^] # Re: C'est officiel...

                          Posté par  . Évalué à 3.

                          Le jour ça arrivera, sans doute.

                          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: C'est officiel...

            Posté par  (site web personnel) . Évalué à 8.

            Vous devriez faire une conférence avec ce genre de rétrospective. C'est rare d'avoir une vision de l'informatique sur 50 ans. (mes parents ont commencés comme vous avec le Fortran, mais sont devenu "chef" et on laissé tombé la technique)

            Je fais de la MCO de vieux système, on a l'impression de faire de l'archéologie avec les stations SUN et le carte VME vxworks qui date de l'an 2000, le début de ma carrière.

            "La première sécurité est la liberté"

            • [^] # Re: C'est officiel...

              Posté par  . Évalué à 9.

              Arrivé vers 45 ans, j'avais un peu de peine à supporter le stress du développement en pratique, la voie normale, c'est effectivement l'éjection vers le haut et le début de la paperasse, chose qui m'horripile.
              Comme j'avais une certaine expertise dans le logiciel embarqué on m'a demandé si je serais d'accord de partager cette expérience avec des étudiants. J'ai évidemment sauté sur l'occasion d'échapper à la paperasse.
              Et je n'ai jamais regretté mon choix. En contact permanent avec des jeunes, cela m'a aidé à rester jeune. Par exemple, piloter le travail de diplôme d'un, étudiant c'est confronter un enthousiasme parfois excessif avec une expérience plus réaliste. L'activité de recherche, un rêve : être bien payé pour faire ce que l'on aime !

            • [^] # Re: C'est officiel...

              Posté par  . Évalué à 3. Dernière modification le 03 octobre 2022 à 00:26.

              Je vous conseille de jeter un coup d'œil à ce cours qui était encore donné jusqu'à il y a environ deux ans.

              Sinon, de la même personne, il y a plusieurs papiers/transparents sur l'histoire de l'informatique sur sa page web principale, certains s'adressant au grand public.

              J'ai eu l'occasion de l'écouter pour une présentation de 30 min la semaine dernière sur les débuts de l'informatique (1930 - 1970), c'était un régal. Et c'était rigolo de voir que certains problèmes du début sont toujours là (écriture de code correct et chasse aux bugs par exemple).

          • [^] # Re: C'est officiel...

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            À quand le TapTempo en Algol ?

            J'ai plus qu'une balle

  • # Performances

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 28 septembre 2022 à 10:21.

    L'intérêt du pilote NVM Express est de montrer qu'il atteint presque les même performances que celle du pilote C existant.

    Qu'est-ce qui permet de dire que ce serait lent ? J'ai beau aimer Java et le C, je vois pas ce qui en Rust ferait que c'est plus lent qu'en C…

    Les performances devrait atteindre celle du C avec directives pragma (ça ne s'appelle plus comme cela maintenant, ce sont les __attribute__, __restrict__ de gcc par exemple), c'est à dire celle du C fait par des vrais, des développeurs du noyau, qui n'ont pas peur de se balader en tongs en hiver à Helsinki.

    Le fait de donner plus de précisions au compilateur sur la gestion de la mémoire, comme on le ferait avec les directives du compilateur en C permet au contraire plus d'optimisations out of the box (comme on dit).

    • [^] # Re: Performances

      Posté par  . Évalué à 9. Dernière modification le 28 septembre 2022 à 10:28.

      Il y a les bound check qui peuvent faire qu'un programme Rust tourne moins vite il me semble. Je n'ai pas lu le code donc je ne sais pas si c'est ça. Mais c'est une piste.

      EDIT: « […]performs almost as well as the existing C driver. The difference, Hindborg said, is that the C driver has already been highly tuned, while the Rust driver has not; it should be able to get to the same level of performance eventually »

    • [^] # Re: Performances

      Posté par  (site web personnel) . É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.

      • [^] # Re: Performances

        Posté par  . Évalué à 5.

        En l'occurrence, le NVMe va chatouiller les 200Gbps, et avec des usages comme le NVMe-oF, oui, ça compte.

        Et à ce niveau, c'est la qualité du dissipateur de chaleur qui va faire la différence, et la rouille, ça dissipe mal ;).

    • [^] # Re: Performances

      Posté par  (site web personnel) . Évalué à 8. Dernière modification le 28 septembre 2022 à 11:44.

      Qu'est-ce qui permet de dire que ce serait lent ? J'ai beau aimer Java et le C, je vois pas ce qui en Rust ferait que c'est plus lent qu'en C…

      La maturité des compilateurs ?

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Performances

        Posté par  (site web personnel) . Évalué à 2.

        Ici, je pense plutôt à un algo moins optimisé qu'en C.

        "La première sécurité est la liberté"

      • [^] # Re: Performances

        Posté par  (site web personnel) . Évalué à 2.

        La maturité des compilateurs ?

        Rust utilise LLVM en backend, donc il a le niveau d'optimisation et la maturité de C et C++ pour la partie backend. Ça se voit assez bien sur le programming language bench game

        https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html

        • [^] # Re: Performances

          Posté par  . Évalué à 5.

          Il me semble que certaines passes de llvm étaient loin d'être optimales pour rust. Plus exactement que la transcription de rust vers le format/langage pivot de llvm était difficile à faire.

          Dis autrement rust utilise llvm, mais si le backend est aussi mature que le projet llvm lui-même le frontend est une nouveauté construite pour rust (pas from scratch, mais on est pas à la maturité de backend).

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Performances

      Posté par  (site web personnel) . Évalué à 5.

      Qu'est-ce qui permet de dire que ce serait lent

      Principalement le Bound checking: Le fait de vérifier qu'un accès se fasse bien dans les limites d'un vecteur, d'un tableau, d'un itérateur a un coût en terme d’exécution. C'est un problème que le C n'a pas vu que tous les accès mémoires se font en mode YoLo sans aucune vérification.

      Rust a aussi une forte tendance à copier/bouger les choses en mémoires car c'est une manière de contourner les limitations du Borrow checker sans utiliser RC / ARC (du comptage de reference). Ça a un impacte en terme de performance, même si probablement minime comparé au C.

      • [^] # Re: Performances

        Posté par  . Évalué à 10. Dernière modification le 28 septembre 2022 à 23:03.

        Principalement le Bound checking

        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  (site web personnel) . Évalué à 6. Dernière modification le 29 septembre 2022 à 12:00.

          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  . Évalué à 4.

            A noté que je dis C++ car C++ tend déjà a être plus rapide que du C.

            C'est un peu hors-sujet mais je suis curieux, sur quoi se base cette affirmation ?

            • [^] # Re: Performances

              Posté par  (site web personnel) . Évalué à 10.

              Les principale raisons sont:

              • L'inlining qui est beaucoup-beaucoup plus agressif et puissant en C++ du au système de template: Ca permet de retirer des appels de fonctions là où ils ne sont pas utiles. Le prix a payé par contre c'est les temps de compilation.

              • Le système de type beaucoup plus puissant (lambda functions, Generics, strict aliasing) qui donne au compilateur les mains libres pour des optimisations là où un compilateur C aurait jeté l'éponge car il serait déjà dans une soupe de pointeurs void*.

              Ces raisons sont plutôt bien illustrée par (C) qsort vs (C++) std::sort

              https://www.geeksforgeeks.org/c-qsort-vs-c-sort/

              https://martin-ueding.de/posts/qsort-vs-std-sort/

              • [^] # Re: Performances

                Posté par  (site web personnel) . Évalué à 9.

                Et avant que j'oublie: J'en rajouterais une autre plus récente: constexpr. constexpr En C++14/17/20 qui permet de garantir qu'une fonction est exécutée à compile time.

                Tout ce qui est fait à compile time n'est plus à faire au runtime. Faire la même en C demande généralement de faire de la generation de code: c'est chiant, c'est casse gueule et ça ne se fait généralement que si c'est strictement nécessaire.

                Un bon exemple de ça est la bibliothèque pour regex d'Hana qui détruit la majorité de la concurrence en terme de performance:

                https://github.com/hanickadot/compile-time-regular-expressions

                • [^] # Re: Performances

                  Posté par  . Évalué à 3. Dernière modification le 29 septembre 2022 à 17:58.

                  Merci pour cette réponse complète et les lectures proposées. Je relirai les articles à tête reposée pour mieux comprendre.

          • [^] # Re: Performances

            Posté par  . Évalué à 2.

            Ç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 .

            Si je ne me trompe pas l'opérateur en C++ te donnera toujours une valeur. En cas d'accès incorrect ça peut être la porte d'entrée pour une attaque. En Rust tu as une interruption du programme donc la pire attaque possible c'est un deny of service.

            • [^] # Re: Performances

              Posté par  (site web personnel) . Évalué à 5.

              Si je ne me trompe pas l'opérateur en C++ te donnera toujours une valeur. En cas d'accès incorrect ça peut être la porte d'entrée pour une attaque. En Rust tu as une interruption du programme donc la pire attaque possible c'est un deny of service.

              Les accès operator[x] en C++ sont l'équivalent de get_unchecked en Rust.

              Dans les deux cas, c'est unchecked et sans interruption. Dans les deux cas, un accès out of bound est une porte d'entrée pour une attaque, même en Rust.

              https://doc.rust-lang.org/src/core/slice/mod.rs.html#398-400

              La différence est que dans le cas de Rust, tu dois explicitement déclarer le call en unsafe: c'est donc explicite et visible. Là où ça sera plus subtile à voir en C++.

              • [^] # Re: Performances

                Posté par  (site web personnel) . Évalué à 4.

                Petit exemple sur godbolt: https://godbolt.org/z/6Wfe17r8o

              • [^] # Re: Performances

                Posté par  . Évalué à 1.

                Les accès operator[x] en C++ sont l'équivalent de get_unchecked en Rust.

                Donc pour le bound checking C++ et Rust sont peu ou prou équivalents.
                La différence pour se joue dans le fait que tu dois ajouter à ton compilateur C++ un linter qui t'interdit d'utiliser l'opérateur [] sauf si tu l'as explicitement désactivé localement.

                On pourrait utiliser le mot clé unsafe pour désactiver localement le contrôle du linter. :-)

  • # Le driver du GPU Apple M1/M2 progresse vite

    Posté par  . Évalué à 3.

    Le statut https://nitter.net/LinaAsahi/status/1575343067892051968: Gnome, KDE, YouTube utilisable.
    Incroyable de réaliser ça aussi vite.
    Par contre ils préviennent que les pilotes sont loin d'être prêts pour faire du jeux vidéos.

    Sinon je vous déconseille de cliquer sur la vidéo, la voix est insupportable..

    • [^] # Re: Le driver du GPU Apple M1/M2 progresse vite

      Posté par  (Mastodon) . Évalué à 4.

      C'est juste complètement inregardable cette vidéo. Entre l'affreux avatar qui prend la moitié de la place et cette voix robotique suraiguë et à peine compréhensible…qu'est-ce qui lui passe par la tête de pondre des vidéos pareilles?

  • # c'est parti pour la 6.1

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8aebac82933ff1a7c8eede18cab11e1115e2062b

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.