• # Mouais

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

    La vidéo ne parle ni des avantages de rust par raport a C, ni de l'algo utilisé pour le scheduler en rust.
    Si l'algo utiliser n'est pas le mĂȘme, l'ordonnanceur aurait pu ĂȘtre codĂ© en js, avec ça VM dans le kernel qui exĂ©cute le code JS, et quand mĂ©me avoir un gain de performances.

    • [^] # Re: Mouais

      Posté par  . Évalué à 4.

      Il a l'air d'utiliser ça : https://crates.io/crates/scx_rustland

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

    • [^] # Re: Mouais

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

      Les rĂ©ponses Ă  tes questions semblent ĂȘtre dans ce dĂ©pĂŽt et sa documentation : https://github.com/sched-ext/scx/

      La connaissance libre : https://zestedesavoir.com

      • [^] # Re: Mouais

        Posté par  . Évalué à 9.

        Et je pense que la phrase importante est

        This doesn't mean that scx_rustland is a better scheduler but does demonstrate how safe and easy it is to implement a scheduler which is generally usable and can outperform the default scheduler in certain scenarios.

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

    • [^] # Re: Mouais

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

      En mĂȘme temps le but de ce code c'est de finir en code BPF pour ĂȘtre chargĂ© par le noyau. Avec notamment les contraintes qu'impose le BPF pour ĂȘtre utilisĂ©.

      Je ne suis pas spécialement convaincu que Rust ici ait une importance particuliÚre. L'algo est sans doute plus intéressant que le reste.

      • [^] # Re: Mouais

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

        Oui et non. Rust n'est peut-ĂȘtre pas directement Ă  l'origine des bonnes perfs mais cela debunk deux choses:
        * Rust est utilisable pour un ordonanceur sécurisé. C'est juste un langage mais il impose tellement de contraintes sécuritaire qu'il y a parfois des gens à dire que c'est trop complexe pour une tel utilisation.
        * Rust est performant. car mĂȘme en changeant d'algo, c'est impossible d'amĂ©liorer les perfs de Linux avec un code non performant. Javascript ou Java ne peuvent rien faire.

        C'est peut-ĂȘtre enfoncĂ© des portes ouvertes car Rust commence Ă  avoir fait ses preuves mais bon.

        Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

        • [^] # Re: Mouais

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

          Rust est utilisable pour un ordonanceur sécurisé.

          Qui en doutait sérieusement ? Je ne crois pas que des développeurs compétents aient des doutes à ce sujet.

          Rust est performant

          Pareil, qui en doutait ?

          C'est peut-ĂȘtre enfoncĂ© des portes ouvertes car Rust commence Ă  avoir fait ses preuves mais bon.

          Depuis au moins 7-8 ans les propriétés que tu cites sont largement connues et c'est pourquoi il y a une petite hype pour réécrire tout en Rust. Ce travail là ne démontre donc rien de nouveau.

          C'est cool que le gars ait fait ça, mais le fait que ce soit écrit en Rust n'apporte pas beaucoup d'information dans ce contexte, ni beaucoup de garantie supplémentaires car d'ailleurs la BPF apporte des contraintes également trÚs strictes. Tu ne peux pas faire n'importe quoi avec.

          • [^] # Re: Mouais

            Posté par  . Évalué à 3. DerniĂšre modification le 21 fĂ©vrier 2024 Ă  20:23.

            il y a une petite hype pour réécrire tout en Rust.

            Je ne suis pas bien au fait de l’état de la hype chez les dĂ©veloppeurs systĂšmes mais il me paraĂźt plus vraisemblable qu’il s’agissent d’utiliser Rust pour les nouveaux dĂ©veloppements, mais sĂ»rement pas de « tout rĂ©Ă©crire » en Rust. Que ce soit pour Linux ou pour d’autres logiciels Ă©crits actuellement en C.

            Ce que je vais dire est Ă  prendre avec des pincettes et tous les dispositifs de protection intellectuelle nĂ©cessaires, parce qu’encore une fois, mon expĂ©rience en la matiĂšre est insignifiante, mais c’est comme ça que je vois les choses, ce que je peux en dire en ma qualitĂ© de mĂ©ta-expert de renommĂ©e inter-rĂ©gionale.

            Rust, de par sa conception plus rĂ©cente que C (et pas qu’un peu !), prĂ©sente sans aucun doute des caractĂ©ristiques avantageuses par rapport au C, qui traĂźne une « dette » (notez qu’on dit "legacy" si on veut rester hype) faramineuse, inĂ©vitable Ă  son Ăąge vĂ©nĂ©rable. Mais ce dernier reste une rĂ©fĂ©rence absolue pour les langages de « haut-niveau » compilĂ©s. C++ n’a rien Ă  voir (aucun jugement de valeur mais l’approche est pour ainsi dire Ă  l’opposĂ© du C), et si Rust semble pouvoir Ă©ventuellement se revendiquer digne successeur de C, c’est assez rĂ©cent. Ce n’est ni Java/Scala, ni Go, ni Ă  ma connaissance aucun autre langage qui peut se targuer d’ĂȘtre au mĂȘme niveau de justesse en terme d’équilibre entre « langage de haut-niveau », et « langage au plus proche du matĂ©riel et sans fioriture telle qu’un ramasse-miette, orientation object ou autre paradigme d’une complexitĂ© excessive ». Nonobstant les avantages que chacun d’entre eux peut possĂ©der par ailleurs. C, un langage qui fait peu (tout ce qu’il faut mais pas plus), et qui le fait bien. Un langage exigeant qui ne fait aucun concession sur la performance pour disposer de fonctionnalitĂ©s destinĂ©es Ă  Ă©viter au dĂ©veloppeur de se fourvoyer.

            Je pense que l’article ci-dessous, datant d’il y a trois mois, bien qu’assurĂ©ment entachĂ© d’inexactitudes qu’il m’est malheureusement impossible de prĂ©ciser, dresse un Ă©tat des lieux relativement reprĂ©sentatif. État des lieux que je rĂ©sumerai de façon tout aussi relativement inexacte : « Rust dans Linux, on peut dire que ça a dĂ©passĂ© le statut d’idĂ©e Ă  discuter, mais pas encore atteint celui d’une Ă©vidence indiscutable. »

            https://www.zdnet.com/article/rust-in-linux-where-we-are-and-where-were-going-next/

Suivre le flux des commentaires

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