Názory k článku
Pokračuje portace GNU Coreutils do Rustu, některé nástroje jsou rychlejší

“kupodivu v některých případech jsou nástroje i rychlejší”

Proč “kupodivu”? Asi se dá čekat v průměru stejná rychlost (něco pomalejší, něco rychlejší, ale ne řádově). Důležitější mi přijde, že binárky jsou mnohem větší (na blogu je to rozebráno).

Ja tomu fakt nerozumim. nejaky 'head'/'tail' apod mohou mit kdyz jsou napsane dobre ve staticke podobe velikost v radu malych desitek kB. A na blogu se doctu:

It does however, bloat the binary by close to ***a megabyte***.
Other parsers such as argh have much smaller footprint, but don’t support things like “—arg=value”, which may make the compatibility story much harder.

Pripadam si, jako kdybych zil v nejake uplne odlisne paralelni realite, kdyz nekdo prijme aby systemova utilita mela megabajt ... a bylo to hlavne kvuli nejakemu arg parseru ...

Dockame se doby, kdy prehravac videa bude mit treba terabajtovy executable ? A kalkulacka bude treba gigabyte ? "

Rust linkuje hodně věcí staticky, klidně i C runtime, když člověk chce (na Windows chce, je na to zvláštní přepínač). Podobně je na tom Go. Tyto jazyky nemají ten luxus jako Swift, jehož knihovny jsou součástí OS (macOS).

31. 1. 2022, 12:01 editováno autorem komentáře

Swift je multiplatforní: https://github.com/apple/swift

To tady asi všichni víme, ale jen v případě macOS/iOS je jeho standardní knihovna součástí OS. Na Linuxu je to pořád jen takové demo, stačí si vypsat závislosti binárky na dynamických knihovnách.

Já bych to nedramatizoval. Nežijeme v době disket a 1 MB binárka není zas takový problém. Ale souhlasím s tím, že je záhodno tyhle věci výhledově řešit. A řeší se.

Nestačilo by prostě linkovat dynamicky více závislostí?

Obecně by to asi pomohlo. Ale pro prográmek, který "nic moc nedělá", bych si dovedl představit, že se to někde mezi kompilátorem a linkerem nějak prořeže. Celkem by mě zajímalo, co bude s tím zmiňovaným clapem, který prý ten bloat způsobuje dost zásadně.

Ono by to moc nešlo. Prakticky všechny standardní knihovny v rustu jsou nějakým způsobem generické, neboli je nutné je monomorfizovat a statické linkování je pak jediná možnost. Větší binárky jsou cenou za výhody Rustu proti C.

Tak aspoň ty negenerické věci. Já si taky nemyslím, že by to byl nějaký zásadní problém, ale ty technické aspekty jsou zajímavé.

Měl jsem za to, že staticky se linkují jen použité symboly ne? Nebo tam Rust narve celé knihovny?

Nezlobte se na mne ze to napisu takhle, ale v me realite je takovy pristup uplne zvraceny. Jde hlavne o to, ze ta 1MB binarka je pouzita na kazdem systemu, bude jich tam cela rada, takze je to zcela zbytecne zahozenych reknem 300 MB x pocet instalaci.

Nejsem uplne clovek vezouci se na modni "ekologicke" vlne, ale i tady vidim urcity smysl. Daleko vetsi ho ale vidim v rychlosti, on ten load 10kB vs 1MB je taky rozdilny.

Vemte si, ze kdyz treba pri behu nejakeho bezneho programu usetrite 2,5 sec, pouzije to za zivot tisickrat milion lidi (to neni az tak nerealne), tak jste usetril nekomu cely lidsky zivot.

Pokud je to naprosto jednoduchá utilita typu head, tak mi vysvětlete, k čemu ten velký binární kód využije.

Když je tak strašně rychlá, tak tam bude ~ 95% kódu, který CPU nikdy neuvidí. Ale tak jestli se to už řeší, tak už si asi někdo všiml, že tady něco "smrdí".

Těch 95% kódu je částečně kontrola chyb, která se použije jenom občas, a částečně taky kód, který je tam v C taky, akorát se linkuje dynamicky a proto není "vidět".

Kromě toho uvažovat, že větší kód musí automaticky znamenat pomalejší program je chybná představa.

Já to beru jako trade-off. V mém světě většina lidí nežije tak, aby do poslední sekundy vyždímala ze svěřeného času úplné maximum. Určitě je žádoucí optimalizovat, snižovat paměťové nároky apod. Na druhou stranu, pokud má člověk na počítači aktivně využívaný přehrávač HD videa, moderní mnohagigabytové hry a nevím co ještě, těch 300 MB se prostě ztratí. Čímž - opět - neříkám "neřešme to".

"tak jste usetril nekomu cely lidsky zivot"

Toto sumarizovanie cez obrovskú populáciu je nezmyslom. V skutočnosti jednotlivec ušetrí za celý život 1000*2,5 s = cca. 42 minút, čo stratí jedinou cestou z práce v zápche spôsobenej nejakou banálnou nehodou.

Nemyslim, ze to je nesmysl, lidsky cas ma pro nas vsechny podobnou hodnotu, je-li podobna jeho kvalita.

Se zacpami umim udelat akorat to, ze se je pokusim objet, presunu jizdu na jiny cas, nebo zvolim jinou formu. Jinak to patri do kategorie "nelze s tim nic udelat".

U IT mam zatim pocit, ze s tim stale neco lze delat, i v domacich podminkach asi muzu po vecerech nakonec prepsat cele coreutils na podobu kterou chci.

Toť otázka. Ono 1 MB není mnoho, zejména z pohledu "co to zabera na disku", ale třeba "zhruba pětinásobek" po načtení do RAM už může být znát - na objemu i na rychlosti. (Tohle by už mohlo mít vliv i na spouštění různých shell-scriptů: načítání většího objemu může celkem snadno smazat o něco rychlejší běh.)

Ano, zcela teoreticky. Ve skutečnosti spouštíme dlouhá léta běžně skripty psané třeba v Pythonu a problém s rychlostí náběhu fakt aspoň já osobně nepozoruju. A samotný interpret má u mě přes 5 MB.

A teď konkrétně jeden bumrlíček v Rustu:

> time ./rg

real 0m0.006s
user 0m0.002s
sys 0m0.004s

Velikost binárky je 27 MB.

A ted si to preskalujte ze takova aplikace bezi na serveru. Stokrat za vterinu se to spusti.

binutils se bezne pouzivaji v shellskriptech, ja je obvykle spoustim ruzne v cyklech, casto je to prikaz ktery zapisu primo v cmdline. casto na lowend HW typu ARM SBC.

Stokrat nic umorilo osla.

1MB na jednej binarke a nazbira sa to... Bude o 10-200MB vetsi image. Co normalne nevadi, ale pri Embeded zariadeniach alebo RPI uz hej.

Na prostredia kde je to problem je busybox.

ani autorům to není jedno, proto spolu s testy denně i grafují velikost binárek. Pracovat na redukci se ale dá až máš nějaký kód, který můžeš redukovat.

Samozřejmě nikdo nechce mít 100MB jen coreutils na disku (pokud jsou samostatně).

I C bylo ve své době obrovské proti asm kódu. Doufám, že s rustem takový skok nezažijeme a řešení se najde.

Ono to není jako tenkrát, když začínalo Céčko, z několika důvodů.

Kód Rustu je obvykle bezpečnější než kód Céčka, protože je modernější a třeba nepodporuje NULL a neinicializované proměnné.

Rust také díky abstrakci přináší menší množství bezpečnostních chyb.

Negativum Rustu je zejména vyšší velikost kódu, což se ale může do budoucna zlepšit, zejména po optimalizaci kompilátoru a zlepšení klimatu pro běh.

A také, směr Assembler Céčko měl hlavně za úkol odstranit závislost kódu na hardware, což se podařilo, ale zhoršil se výkon výsledného kódu. Směr Céčko Rust nepředstavuje běhový handicap, spíše naopak, a zlepšuje se abstrakce. Lepší abstrakce může do budoucna přispět k ochotě analyzovat a optimalizovat kód.

Vidím to podobně. Zkoušel jsem si s tím nicméně trochu hrát a stáhnul jsem velikost binárek cca na 700-800K (pomocí LTO, optimalizace generovaného kódu na velikost a cargo-strip). Chtěl bych zkusit výrazněji stáhnout velikost některé utility (konkrétně nejspíš yes) pomocí zrušení závislosti na uucore a hraním s konkrétními implementačními detaily (parsování argumentů apod.).

A koneckonců, ten projekt je zatím ve verzi 0.0.12, což je dost raná verze.

Výkon předělávek klasických utilit psaných v Rust je často lepší z principu - už proto, že jsou ty implementace nové a reflektují vývoj v oboru za ty desítky let od uvedení GNU ekvivalentů. Ať už se to týká využívání paralelizace nebo různých nových algoritmů. Navíc mi přijde, že spousta těch utilit psaných v C se docela slušně brání refaktorizaci a větším změnám, které by je mohly posunout dopředu.

Rust jako záminka k modernizaci. Jsem pro :)

Nejde ani tak o Rust. Jde o to, zda budeme umět, aspoň u těchto celkem triviálních utilitek, s rozumným úsilím zreplikovat původní funkčnost a nevrtat se pořád v legacy kódu.

Laskavý čtenář si dosadí svůj oblíbený jazyk. V tomto případě jde náhodou o Rust :)

Vidím, že Rust trumfuje i C++ co se velikosti binárek týče :)

Jistě, standardní knihovna C++ se většinou linkuje dynamicky.

K binárkám v Rustu existuje celá extra stránka v dokumentaci, jak je zmenšit, je tam dlouhý seznam triků (LTO, stripping apod.). Podobně se dá zmenšovat i binárka, kterou generuje Go (ale to tam má aspoň kompletní GC, metadata pro reflexi a podobné věci). Ale nevím, proč to někdo řeší při dnešních velikostech CPU cachí.

Standardní C++ knihovna se dynamicky vůbec linkovat nemusí, je tam celkem dost balastu, který se při statickém linku zahodí. Rust na tom vlastně není o moc líp než to zatracované C++ :)

Muze nekdo kvalifikovany odpovedet, proc je nemozne vytvorit moderni nahradu za C, ktera by produkovala stejne male binarky? Je mozne Rust nejak osekat?

31. 1. 2022, 15:17 editováno autorem komentáře

Ono to je možné. Třeba Swift generuje malinké binárky. Jeho standardní knihovna je linkovaná dynamicky (před stabilizací ABI měla aplikace, která dohromady nic nedělá, klidně i desítky MB).

U Rustu by to šlo jistě osekat, ale zřejmě to není priorita (čti: nikoho to nepálí, řeší se důležitější věci).

Je dnes tak velký problém velikost binarek?

Není.

Na embedded ano. Ne každý počítač je PC s velkým diskem a hromadou RAM.

Existuje třeba Zig. Problém spatřuju v tom, že C je pro spoustu lidí moc low level, takže "moderní C" by de facto nebylo vůbec žádné C.

Už prosím žádné další “moderní C” :/ Bohatě stačí C++, Rust a Go (každý ve své doméně).

No já bych raději obětoval C++. ;) Zig je podle článku, který jsem četl, dobrý prostředek pro kroskompilaci Rustu.

Protože moderní jazyk bude mít moderní typový systém, kde se kód instancuje a optimalizuje podle typů parametrů a dalších okolností (agresivní inlining, mutační vs konstantní ukazatele apod) a to se prostě dynamicky linkovat nedá. Navíc moderní jazyk nemá za cíl produkovat co nejmenší kód, ale co nejbezpečnější a co nejrychlejší. Tam, kde skutečně jde o malý kód (mikrokontroléry apod) má smysl i nadále používat C. U reimplementace "cat" je to ale opravdu jedno, resp. důležitější jsou tu jiná kritéria.

Solidny jazyk so solidnym prekladacom spominane zalezitosti riesi uz v case prekladu.