Názory k článku
Microsoft přepisuje části Windows do Rustu

Co v tomto je pre užívateľov? Je to pre MS, aby sa im lepšie spravoval kód. Na funkcionalitu to asi nebude mať vplyv.

OS bude bezpečnější.

pokud je kod v rustu o tolik rychlejsi, nez ten puvodni kod v c/c++, tak s tim kodem v c/c++ bylo neco hodne spatne, protoze neverim, ze by kompilator c/c++ byl tak vyrazne horsi nez kompilator rust.

26. 4. 2023, 15:19 editováno autorem komentáře

Kompilátor C++ nemá o kódu tolik informací jako kompilátor Rustu, jazyka navrženého pro podchycení různých problémů už v době komplikace. Proto má méně možností k optimalizaci (i nesmyslný záměr v kódu musí být správně proveden).

EDIT: Věřit nemusíte, ale oni mají výsledky svých měření černě na bílém.

26. 4. 2023, 15:46 editováno autorem komentáře

Kazde dalsi win jsou nejmene 100% rychlejsi nez ty predesle ... prave podle tech "cerne na bilem" pindu od M$.

U kernelu bych jim to i věřil. Problém je v tom, že v MS jedna ruka neví, co dělá ta druhá a jakékoliv zlepšení výkonu na nižších úrovních se daří dokonale vykrátit, ne-li obrátit naprostými kopičinami v user space.

Ono je sice hezký, že přepisují window manager v Rustu, ale pokud vzápětí někdo, nejlépe nějaký diversity hire, do shellu hodí widgety v Electronu, tak to nakonec příjde vniveč.

27. 4. 2023, 16:28 editováno autorem komentáře

bez prezdivky ...> Ten nade mnou ti to vysvětlil. Koneckonců kvalita kódu kernelspace/u­serspace je dost rozdílná i v Linuxu (lowlevel funkce vs. desktopová prostředí a grafické aplikace).

> Ryuzaki: Ono je sice hezký, že přepisují window manager v Rustu, ale pokud vzápětí někdo, nejlépe nějaký diversity hire, do shellu hodí widgety v Electronu, tak to nakonec příjde vniveč.

Proto si lidi vracejí původní Command Prompt, Notepad, Taskbar, Kalkulačku, ... Startují okamžitě a nemají specifické problémy (např. všemu novému ve Windows 11, včetně např Správce úloh, se rozhodí rozměry oken při přecházení mezi různými DPI, např. notebook doma a RDP na PC v práci).

Jejich výsledek ale nepotvrzuje váš předpoklad, že je to kvůli kompilátoru/vlas­tnostem Rustu. Stejně tak to mohli přepsat do moderního C/C++ a možná by to dopadlo stejně. Kdo ví? Každopádně s Rustem mají víc paměťových garancí. Čas ukáže, jestli to byl krok správným směrem.

27. 4. 2023, 09:48 editováno autorem komentáře

Tak nějak. Navíc Rust používá LLVM, původní kód byl přeložen MSVC, to je další faktor. Popravdě nevím, jak by dnes dopadl “souboj” MSVC vs. LLVM, byť jen v C++.

Do moderního C? Tak to asi ne.

A tím si chtěl říct co? Počet znaků vs množství informace jsou u tebe docela v nepoměru.

27. 4. 2023, 16:53 editováno autorem komentáře

Proč ne do moderního C? Neříkám, že by to byla moje volba, ale představitelné to je.

Je toho mnohem víc. Pro začátek bych se vyvaroval názvu C/C++ a vůbec spojování C a C++. Moderní C se nijak zvlášť neliší od klasického, kromě toho, že v roce 2011 přibyla do standardní knihovny podpora vláken. Moderní C++ dejme tomu od verze z roku 2017 už toho umí docela dost nějak civilizovaně vyjádřit, ale s Rustem je to naprosto nesrovnatelné.

Rust nemá jen garance neporušení paměti, ale i hromadu dalších garancí, které umožňují další optimalizace. C++ přidává do kódu obrovské množství zcela zbytečných operací, které pak horko těžko při optimalizacích zase vyhazuje. Rust spoustu věcí nemusí díky pečlivě navrženému datovému modelu vůbec řešit.

Z toho lze usuzovat, že Rust se bude v optimalizaci mnohem snadněji i do budoucna zlepšovat. Není s ním tolik práce. Je mnohem víc value-oriented než C++. Tak uvidíme, co z toho ještě vyplyne.

Pavel Šimerda

Rust taky “vyhazuje” zbytečně operace. Navíc optimalizaci obstarává LLVM, to s jazykem jako takovým nesouvisí.

Ono přepisovat kód (klidně do stejného jazyka ve vyšší verzi) obecně má výhodu, že člověk na to koukne z nové perspektivy a zkušeností. To pravděpodobně mělo větší význam než "jiný kompilátor". Zlí jazykové dokonce říkají, že každý program po úspěšném napsání a otestování, by se měl zahodit, napsat znovu a pak je teprve dobrý.

Tomu sa hovorí prototyp na zahodenie a je to bežný prístup softvérového inžinierstva. Koniec hlásenia rádia Jerevan.

Proč Rádio Jerevan? Je to v podstatě pravda :)

Rust není v principu rychlejší než C, C++ nebo třeba Go. Rychlost ale ovlivňuje hodně faktorů, i kdyby byl ten přepis 1:1, tak například použitý alokátor apod. Bez podrobnějších informací to nejde posoudit. Navíc po tak dlouhé době bych čekal, že šlo spíše o refaktoring, včetně například použití lepších algoritmů, co my víme.

Rust je v principu rychlejší než C/C++, protože Rust řeší problémy s aliasingem, kterými trpí C/C++. Borrow checker v Rustu zaručuje, že existuje pouze jedna mutable reference na objekt, v C/C++ tato garance není.

Rust překladač nemusí invalidovat žádné proměnné v registrech při zápisu přes referenci (pointer). V Rustu je zaručeno, že mutable reference není aliasem na žádný jiný objekt.

C/C++ překladač musí při zápisu přes pointer invalidovat všechny proměnné stejného typu v registrech a znovu je načíst z paměti. C/C++ se to snaží řešit pomocí strict aliasing rule a restrict keyword, ale to je jen polovičaté řešení, v Rustu je to prostě navržené lépe a funguje to i bez obezliček typu restrict keyword.

To ovšem přinese v typickém program zrychlení nula nula nic, význam to má jen u numerických výpočtů apod. Nehledě na to, že to překladač Rustu ne vždy používá, podle verze překladače a verze LLVM to občas vypínají (protože “miscompiled code”). Takže teorie hezká, ale vesměs na<math>imag(log(-1))</math>kaču.

To je nesmysl, co píšeš, každý program zapisuje do paměti, nejenom při numerických výpočtech.

Oni to mají narozdíl od tvých dojmů změřené, podle typu benchmarku je nárůst výkonu 0 až 5%: https://github.com/rust-lang/rust/issues/54878

To je nárůst výkonu "zadarmo", programátor nemusí nic dělat, nemusí řešit strict aliasing rule (a jestli ho náhodou neporušuje), nemusí nikde psát restrict jako v C/C++. Všechno za něj narozdíl od C/C++ zajistí Rust překladač.

Ano bylo to občas vypnuté, ale problém nebyl v Rustu, ale v LLVM. Tu miskompilaci se vždy podařilo navodit i v ekvivalentním C kódu. V C kódu na to nikdo nepřišel, protože se restrict v C používá minimálně, nikdo to ručně nepíše. Překladač Rustu to automaticky nacpe všude.

Pamatuju si ze jsem resil bug v ANTLR. Java byla 2x rychlejsi nez Ccko anebo C++. A pritom to C++ pouzivalo brutalni metaprogramovani vcetne inline virtualnich funkci. Nakonec se ukazalo ze:

- Hashovani v Jave je ruchlejsi nez custom hash fce v Cecku
- V obrovskem C++ kodu je tezke uhlidat kolikrat se predava string referenci a kolikrat se kopiruje.
- Nejvetsi problem byl ale v tom, ze jsem musel vymenit podminku: "if(a() && b)" za if(b && a()).

Stacila jedna jedina radka a cely kod v C++ ze zrychlil 5x.

J doplním, že v C++ se dá již používat std::string_view.

Hezké. Tohle je problém všech (mikro)benchmarků, je tam myriáda faktorů, které ovlivňují výsledek, ten zmíněný hash, alokátor, implementace běžných věcí ve standardní knihovně atd. V Rustu (nejen) stačí použít Mimalloc jako globální alokátor a taky to hned vypadá jinak.

Není Rust jen vrstva nad C++? Nepřekládá to ve finále zase c++ kompiler?

Ne, Rust je vrstva nad LLVM, stejně jako C++ je vrstva nad LLVM. Obojí je tedy na stejné úrovni.

Není, je to plnohodnotný jazyk, jen používá LLVM jako backend (a vzniká verze pro GCC).

Problém už je v tom původním tvrzení, že kód v rustu je o 15% rychlejší než ekvivalent v C++. Jenže nikdo už nenapsal o jaký konkrétní kód se jedná, jaký compiler byl použitý, a jestli se opravdu jednalo o ekvivalentní kód. Takže spíš by se dalo napsat, že LLVM v tomto konkrétním případě vygeneruje o 15% rychlejší kód než MSVC, kterým určitě kompilujou ten kód v C++. Nějak nevěřím, že na kompilaci Windows komponent používají clang.

To je jak ty benchmarky na Phoronixu, kdy se pro Windows použije MSVC compiler a pro Linux Clang, a pak se dělají závěry, který OS je rychlejší...

Navíc když už někdo něco přepisuje, tak je velká šance udělat to líp, což může znamenat i rychlejší výsledný kód.

27. 4. 2023, 22:00 editováno autorem komentáře

Jde o jejich konkrétní ekvivalentní kód konkrétní aplikace/knihovny. Samozřejmě pokud je kód beze změny, tak není důvod ho překompilovávat, tj. ta procenta obsahují v sobě vylepšení kompilátorů za tu dobu, to ano. Nicméně i tak jde o zlepšení - výhody bezpečí Rustu *a přesto* to není pomalejší (a v rámci příležitosti měli důvod to překompilovat). Jinak Visual Studio nabízí i LLVM/clang, možná dokonce od nějaké verze defaultně?

Jenže jak to oni měli zkompilované nikdo neví, to je ten problém těchto tvrzení - není možné je nijak ověřit.

Přepisem do Rustu se rozhodně nic nezkazí, ještě si tam zapnou Mimalloc (to je taky od MS) a můžou jásat, jak jim to svižně běhá.

Ano, stačí použít alokátor napsaný v C a hned to bude o něco rychlejší :)

Tak MSVC je poměrně dobrý překladač, jen občas hapruje STL (oproti třeba libc++), už jen alokátor je extrémně pomalý.

Jo, Regions. To je právě v tom insideru.

A tech novych chyb co u toho vzniknou…

A tech starych, ktere se znovu zjevi jako ten fenix.

Je zde rozumný předpoklad, že jich bude méně, než v omylu jménem C++.

Některé druhy chyb Rust umí odchytit celkem dobře (paměť, sdílení dat při souběžnosti…). Akorát nemá RTTI (stupidní Any se nepočítá), ale to často nevadí. Přepis do Rustu dává většinou smysl, když na to je čas, a bývá to i zábava :)

po precteni:

Rust se také dostal do jádra Windows, vzniknul první syscall napsaný v tomto jazyce.

jsem premyslel zda uz fakt nepresli na linuxovy jadro

Ještě ne, ale stay tuned :)

Kdyby to napsali v assembleru, maji zvyseni vykonu o 1000%.

Windows je ale multiplatformní, takže bys to musel napsat v assembleru pro všechny architektury CPU. Brácha např. provozuje Windows vedle x86 i na ARM, Itanium a Alpha.

Na ARMu mu poběží i verze pro amd64. Akorát trochu pomaleji.

"Trochu" víc, tohle není Apple. Navíc se sníží výdrž baterie na polovinu, na úroveň strojů s x86 (které zas nabízí kompatibilitu). Emulace ve Windows je totiž nekonečnou smyčkou vytěžující CPU na 100 % (stačí tedy mít trvale spuštěn jeden x86 program). Na Applu (Rosetta 2 pro macOS a Linux) a Alphě (FX!32) se program zkompiluje (Ahead-of-Time) do cílové architektury, takže vlastně spouštíš nativní binárku (ta samozřejmě běží o něco pomaleji než nativní program, protože jsou do kódu generované různé pomocné instrukce). Na Itaniu nevím, jak to funguje.

Já mám Surface s ARMem, takže to mám dobře změřené. Taková tragédie to není, ostatně třeba MSVC donedávna běhalo jen v emulaci.

Psát ručně asm pro moderní CPU není zárukou rychlého běhu.

Kdyby to psal v assembleru stejný počet lidí, nemají nic. Kdyby navýšili počet lidí adekvátně tomu, o kolik těžší je psát v assembleru, pravděpodobně by měly pomalejší kód. Protože kompilátory už jsou nějakou dobu v optimalizaci lepší, než i ti lepší programátoři. Samozřejmě že kdyby to psali ti nejlepší z nejlepších, dokázali by to v assembleru občas optimalizovat lépe (protože ti nejlepší z nejlepších by mimo jiné neměli problém nechat si to přeložit kompilátorem a použít jím vygenerované optimalizace) – akorát by to trvalo tisíc let, než by všechen ten kód ručně a ve špičkové kvalitě napsali.

Hmm, toho se při troše štěstí dočká jen Highlander.

Pokud jde o regulární kód, tak ten dneska v asm psát fakt nikdo nechce, ale pokud se jedná o SIMD, tak napsat lepší kód v asm než co vygeneruje compiler je celkem jednoduchá záležitost.

To jo, to je hračka, například pro AVX-512. Jen je smůla, že na GPU to stejně běží ještě efektivněji.

Protoze GPU nema task switch a potrebu odkladat desitky kilobajtu TSS, resp. je tam nejaka hw podpora pro prepinani threadu.

Az bude mit GPU podporu pro MMU, TLB, vyjimky/restart, paging a swapovani, a nabootuje Linux, tak muzeme srovnavat srovnatelne. Do te doby je gpu pouha jednoucelova hracka - resp takove nacancanejsi DSP (jestli si je nekdo pamatuje, at uz od ADI nebo TI)

Já mám zkušenost jinou - pokud se jedná o nějaké distributed věci, které jsou obrovské, je tam nějaký network overhead, atd... tak AVX-512 je jednoznačná volba - programuje se pro to skvěle, debuggovat se to dá taky hezky a jako bonus je to na každém commodity HW co má X86 architekturu (Xeon a nově i Epyc od AMD) - člověk si může rentnout obrovský cluster v podstatě bez limitu. S GPU je to mnohem horší - je to drahé a dostupnost v cloudu je hodně omezená, protože každý chce GPU na ML...

Já jsem se teda setkal s AVX-512 kódem pro kompresi/dekompresi dat, regex engine, JSON parsing, XML parsing, a různé další věci pro big data processing. Když je zrychlení oproti C třeba 10x a problém začne být network bandwidth, tak je práce v podstatě hotová.

Zde také k tématu: https://www.i-programmer.info/news/98-languages/16274-the-rise-of-rust-windows-11-.html