Názory k článku
Budeme mít linuxové moduly napsané v Rustu?
-
Linuxové moduly lze psát v Rustu už teď. Upřímně řečeno, jsem velký fanda Rustu, ale tohle mi připadá celkem na nic. Jeden z hlavních přínosů Rustu, tj. prokazatelně bezpečná práce s pamětí, se v tomto případě neprojeví, protože každý modul, ovladač atd. pracuje s datovými strukturami vybudovanými a spravovanými v C v hlavním jádře. A těžko si umím představit, jak využívat další vlastnosti Rustu (traity, polymorfismus, paralelizaci apod) v jaderném kódu, kde veškeré volající funkce opět předpokládají sémantiku C. Lepší je používat Rust tam, kde se jeho výhody naplno projevují.
-
Ondra Satai NekolaZlatý podporovatelNějak se začít musí.
Moduly, pak postupně dál a dál a zvolna (za roky a roky) C omezit na nezbytné minimum. -
Jestli by v takovém případě nebylo lepší začít spíš u soběstačného kódu z centrálního jádra, který toho moc nesdílí se svým okolím. Např. takový plánovač procesů. Ten pracuje se složitými datovými strukturami a algoritmy, kde by Rust jistě znamenal přínos, a přitom by problémů s interoperabilitou bylo nesrovnatelně méně. I když je celkem jisté, že přes Linuse by se tohle nedostalo. Linus se už vyjádřil, že sice nemá nic proti Rustu jako takovému, ale do kernelu nechce zavádět žádné další jazyky.
2. 9. 2019, 09:46 editováno autorem komentáře
-
Ondra Satai NekolaZlatý podporovatel
Máš technicky pravdu, ale to by bylo zase větší riziko do začátku...
-
To je samozřejmě dneska stále jedna z nevýhod Rustu proti C/C++, ale ruku na srdce. Kolik těch architektur Linux DOOPRAVDY podporuje, potažmo v tom smyslu, že se na nich používá v produkci na komerčně relevantním hardware a někdo platí za jejich podporu? To bude amd64, ARM/Aarch64, POWER a perspektivně snad RISC-V. Na těch Rust dneska funguje. Je nutné si uvědomit, že je jen otázkou času, kdy podpora procesorů, jako SPARC, HPPA, m68k a spol. v Linuxu stejně odumře, takže stanovit, že u nových fičur jádra se s nimi už nepočítá by mě celkem nešokovalo.
-
Linux generuje větší obrat, než jakýkoli jiný OS, a jde do něj víc investic, než do kterého jiného SW. Je to samozřejmě eminentně komerční SW. Jeho cíl a smysl je především vyhovovat potřebám současných aplikací, ne obětovat konkurenceschopnost v zájmu jednoduchosti pro hobisty kteří se baví tím, že si někde opatřili vyřazený hardware z 80 let a snaží se ho na něm rozchodit.
-
Mozna ti to porad unika, ale Linux je otevreny SW. Zadny komercni subjekt ho nemuze vzit a naridit co tam ma bejt a co ne. Maximalne muze tlacit na Linuse, ze tam neco chce. To jestli podporuje HW z 80. let nema s komerci nic spolecnyho. To zalezi pouze na tom, jestli se najde nekdo, kdo tam tu podporu bude udrzovat.
-
Vždyť právě o to jde. Nikdo nikdy nikomu nezakáže provozovat Linux na HW z 80. let, ale je to na jednotlivcích, maximálně na malých skupinách které to dělají ze zájmu, zatímco pro Intel, AMD, ARM a IBM je životně důležité, aby Linux jejich systémy podporoval. Je celkem realistické si představit, že lidí ochotných udržovat Linux pro HPPA nebo SPARC bude ubývat (tak jak bude ubývat tohoto hardware ve funkčním stavu), a zároveň tato údržba bude čím dál tím obtížnější, jak komplexnost a nároky jádra narůstají a přirozeně budou dále narůstat. Linux už několikrát ukončil (a opět oživil) podporu pro m68k, postupně opouští podporu pro Itanium, a samozřejmě to tak bude postupně i s dalšími architekturami. Na straně vývojářů je logické a legitimní, že když někdo používá A zadarmo a mnohořádově víc lidí používá B a financuje přitom vývoj, tak se nové projekty budou vyvíjet a testovat prostě pro B a A se zohlední do té míry, do jaké nebude přinášet další komplikace nebo náklady - dál ať si ho podporují třetí strany, pokud jim na něm záleží.
-
"zároveň tato údržba bude čím dál tím obtížnější, jak komplexnost a nároky jádra narůstají a přirozeně budou dále narůstat."
To je dalsi omyl. Linux je ve svy podstate porad velmi jednoduchej a nenarocnej i diky projektu uCLinux, kterej se zameruje na maly zarizeni typu sitovy routery, IP kamery, hudebni prehravace, scannery, ctecky karet atd. To jsou zarizeni s maximalne par MB RAM a par MB Flash, vetsinou nemaj ani MMU a jsou jich miliardy od mnoha ruznejch vyrobcu. Podpora tehle malych architektur v dohledny dobe nikam nezmizi...
Na druhou stranu kdyz se vratime zpatky k Rustu. Nemyslim, si ze je nutny aby vsechny architektury ho podporovali, protoze nektery z nich jsou tak malo vykonny, ze crosskompilace je jedina rozumna moznost jak na ne Linux dostat... -
Pro kód co "za jízdy" pracuje s potenciálně nebezpečnými daty by to jistě mohlo dobré. Ostatně je zajímavé se podívat na politiku Mozilly ohledně nasazování Rustu. Mozilla Rust doporučuje v zásadě ve třech situacích:
1. Tam, kde se pracuje s nekontrolovaným inputem a u C/C++ by hrozily overflow, leaky, injekce apod.
2. Tam, kde přepsání existujícího kódu do Rustu může přinést znatelné zvýšení výkonu díky optimalizaci paměti, paralelizaci atd. jako to bylo u CSS podpory ve Firefoxu.
3. U zbrusu nových projektů
-
Ondřej KolínZlatý podporovatel
Jak souvisi rustove moduly linuxoveho jadra s electron based aplikacemi (pricemz virtualizace to vubec neni)?
-
Cim vyssi uroven jazyku tim vetsi praseni. Jednak kvuli tvorbe kodu neprogramatory a pak kvuli mnoho abstraktnim vrstvam. Neexistuje projekt, ktery by pouzitim vyssiho/komplexnejsiho jazyka nabyl na rychlosti nebo se zmensil. Low level asm/C v obou techto metrikach vede, ale poklada urcite naroky na tvurce programu.
-
Ondra Satai NekolaZlatý podporovatel
"Cim vyssi uroven jazyku tim vetsi praseni."
To je... odvazne tvrzeni.
"Neexistuje projekt, ktery by pouzitim vyssiho/komplexnejsiho jazyka nabyl na rychlosti nebo se zmensil."
Pomineme to, ze bezpecnost >> rychlost.
S touhle filosofii by se melo v kernelu zahodit i to C, ne? (Nemluve o tom, ze to tak ci onak neni pravda. Viz gecko vs servo. Samozrejme to neni zasluha _jen_ lepsiho jazyka, ale i toho, ze proste v tom lepsim jazyce se dalo snadneji napsat neco rychleho.) -
"Viz gecko vs servo"
Odkaz na test na 1 core a bez GPU mate? (a doufam ze se bude porovnavat kod stejneho stari - rekneme 6 ci 12 mesicu od doby vzniku kodu a ne nejaky desetiletim nabalovany balast).Bezpecnost je relativni - jazyk vam ho nezaruci. A pokud se jedna kvuli bezpecnosti treba i o jen primitivni kontrolu rozsahu pole, tak kazdy pristup musi kvuli ni provest boundary check? - tak to vime jak to dopadne s vykonem. A o tomto jsem mluvil - ze prechod na vyssi jazyk (treba prave z duvodu "bezpecnosti") bude znamenat pomalejsi sw.
-
Ondra Satai NekolaZlatý podporovatel
"Odkaz na test na 1 core a bez GPU mate?"
A budeme merit zavodni auta v konfiguraco bez benzinu a tazena konem?
"a doufam ze se bude porovnavat kod stejneho stari - rekneme 6 ci 12 mesicu od doby vzniku kodu a ne nejaky desetiletim nabalovany balast"
Aha. Takze ty jsi chtel priklad noveho projektu, ktery nekdo rovnou prepsal?
"Bezpecnost je relativni - jazyk vam ho nezaruci."
Ano. Ale pomuze.
"A pokud se jedna kvuli bezpecnosti treba i o jen primitivni kontrolu rozsahu pole, tak kazdy pristup musi kvuli ni provest boundary check?"
Ne, nemusi.
-
ZrzkaStříbrný podporovatelHmm ... Podle jakých? Ušitých na míru Rustu? Idiomatický Rust a idiomatické C? Neřekl bych. Každý napíše benchmark kde jeho favorit vyhraje a ten druhý to projede.
Prvně by se slušelo říci, že porovnávat Rust a C nedává moc smysl. V Rustu můžu napsat nachlup stejný kód jako v C a rychlost bude stejná. Porovnávat se dá leda tak idiomatický Rust s idiomatickým C. Ano, v tomhle případě je Rust v některých věcech rychlejší. V C mám dva ukazatele a překladač neví jestli to je jeden objekt nebo dva různé. C tedy musí být konzervativnější, ale Rust to ví a může optimalizovat mnohem agresivněji. Na druhou stranu, Rust je v některých věcech pomalejší. Sice zrychluje, opravuje chyby, ale stále tu máme dost problémů. Stačí se podívat na label:I-slow.
A to píšu jako velký fanoušek Rustu a někdo, kdo se Rustem už přes 2 roky živí.
-
v benchmarks game je to celkem vyrovnané, ty úlohy byly vymyšleny před vznikem Rustu.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html
-
ZrzkaStříbrný podporovatel
Na uvodni strance tech benchmarku je jich vylistovanych 10. Z toho v 6/10 vyhrava C a v 4/10 Rust. Jsem na mobilu, dalsi jsem nezkoumal a do zdrojaku nekoukal.
Nejdriv pises, ze je Rust rychlejsi nez C. Posleze, ze je to celkem vyrovnane.
Ja jen rikam, ze obecne tvrzeni „Rust je rychlejsi nez C“ neplati.
-
Smazaný profil
Ale implementace ne :P. Jde o to že zadání úlohy je jedna věc ale algoritmus a další věci jsou to oč tu běží. Jinak v tom co píšete spíš porovnáváte llvm vs gcc.
Asi před rokem možná dvěma, jsem strávil nějaký ten volný čas a ty testy co tam jsou jsem napsal v jazyku D. A světe div se vždy jsem dokázal napsat nejrychlejší verzi (a kolikrát i o více jak 30 procent) aspoň v jedné z implementací (ldc - llvm, gdc - gcc, dmd - dmc).
ČLÁNKY DO MAILU