Vlákno názorů k článku
Rust Coreutils 0.8 jsou zase rychlejší, projdou téměř 95 % testů od forth - Kolikrat vic pameti to zabira oproti C? 4x?...

Ono je těch kritérií daleko víc, a některá holt jdou proti sobě. Dalším kritériem třeba může být to, aby se aplikace snáz ladila nebo měla lepší chybové zprávy. To, aby binárka byla co nejmenší, je taková akademická diskuse. Ona by se ta binárka dala zmenšit třeba také odstraněním málo používaných funkcí. Nebo ruční optimalizací a třeba psaním v assembleru (teoreticky). Bylo by to správně? Nebylo. Protože to kritérium velikosti není absolutní kritérium.

Myslím, že jsi zde jaksi nepochytil, ze zde se jedná o kompilaci pro uživatelské použití. Koncový uživatel nebude nic ladit, tam jsou debug symboly k ničemu. Jiná situace je u vývojářů.

Platí 1. A 2. I za cenu rychlosti výsledného kódu? Protože u některých optimalizací je potřeba dělat rozhodnutí mezi jedním a druhým. Pokud vím, Rust by default prioritizuje rychlost kódu

Pokud jde o defaultní nafukování binárky přihozením debug symbolů, tam se shodnem. V Release profilu by to bylo lepší bez, ostatně většina projektů je v nastavení buildu stripuje.

8. 4. 2026, 08:45 editováno autorem komentáře

Kritérium rychlosti - jistě, proto píši "za jakou cenu".
Debug (symboly) - jasně.
Prioritizace rychlosti v Rustu - aha, díky.
Release - tak jsem to právě myslel.
Díky.

Taky jsem si s uutils-coreutils po přečtení této zprávičky poprvé včera hrál, předtím jsem to nikdy nezkoušel. Funguje to překvapivě docela v pohodě a multicall binárka (jako v busyboxu) může být pro spousty nasazení výhodou. Stejně jako je další výhoda, že to rovnou funguje i na Windows bez další posixové překladové vrstvy (cygwin, msys atp.).

Ale k tomu jak co optimalizovat. Podobně jako tu zmiňovala Kate, tak jsem si to také zkoušel sestavit s profilem release (~ 14 MB) i release-small (~ 9 MB).
Který stripuje binárku a nastaví opt-level v kompilátoru na "z".
https://doc.rust-lang.org/cargo/reference/profiles.html#opt-level
Což mimo jiné (asi práh pro nějaký inlining) vypne i auto-vektorizaci cyklů.

Tak mě jen zajímalo, co to udělá.
https://pastebin.com/raw/xRc4tKMA
A ano, byť to zmenší výsledný soubor, tak v určitých workloadech to podle předpokladu výrazně sníží výkon.
Výjimkou pak je hashování s sha512, kde to zmenšení opakujícího se kódu (i bez těch typických vložených věcí na zarovnávání při auto-vektorizaci) vede ke zvýšení výkonu na konkrétním CPU a mnohem lepšímu využití cache.
A paradoxně, ta zmenšená multicall binárka nevede k nižšímu peak RSS.. načítá si to stránky podle potřeby.
Pro orientaci jsem tam přihodil i standardní GNU coreutils a statický busybox, byť oba jsou kompilovány jiným kompilátorem (GCC z distribuce) a busybox pravděpodobně nebude řešit všechno to třeba wc z coreutils.

Takže za mě pokud vyloženě není zásadní omezení úložiště (např. router nebo nějaké IoT zařízení), tak bych neoptimalizoval rovnou pro velikost. A stejně u těch embeddovaných zařízení bych spíš použil ten busybox, který je tak od začátku míněný a obsahuje mnohem víc nástrojů než jen ty z coreutils.

pak je to rozkopírovaná ta samá binárka, proto to má všechno stejnou velikost.

Hardlink znáte? Užitečná věcička.

Pche, rozkaz znel jasne - utilita s rezavou brasnou nesmi projet!

Ano, jen mi jeho použití v takovém případě přijde taky dost divné.

Jo je to rozkopirovane aby se nereklo ze oddil pro / je mcc velky.
Nekdo to povazoval za dobry napad.
Jednou si precteme zpravicku ze novy Rust usetril gigabajt mista.
Je videt ze verze 0.8 uz narostla z 10 mb co pouzivam na 14 mb.
Zajimavy pristup misto vic programu mit jeden co v prvnim parametru si precte co ma vlastne delat.
Takze vsechno bude zabirat stejnou velikost pameti.
I kdyz i ta C verze me ukazuje naprosto silene hodnoty...

xxx@xxx:~/Stažené$ /usr/bin/time -v /usr/lib/cargo/bin/coreutils/rm smaz.txt > /dev/null
    Command being timed: "/usr/lib/cargo/bin/coreutils/rm smaz.txt"
    User time (seconds): 0.00
    System time (seconds): 0.00
    Percent of CPU this job got: 75%
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00
    Average shared text size (kbytes): 0
    Average unshared data size (kbytes): 0
    Average stack size (kbytes): 0
    Average total size (kbytes): 0
    Maximum resident set size (kbytes): 6900
    Average resident set size (kbytes): 0
    Major (requiring I/O) page faults: 0
    Minor (reclaiming a frame) page faults: 377
    Voluntary context switches: 1
    Involuntary context switches: 1
    Swaps: 0
    File system inputs: 0
    File system outputs: 0
    Socket messages sent: 0
    Socket messages received: 0
    Signals delivered: 0
    Page size (bytes): 4096
    Exit status: 0
xxx@xxx:~/Stažené$ /usr/bin/time -v /usr/bin/rm smaz.txt > /dev/null
    Command being timed: "/usr/bin/rm smaz.txt"
    User time (seconds): 0.00
    System time (seconds): 0.00
    Percent of CPU this job got: 100%
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00
    Average shared text size (kbytes): 0
    Average unshared data size (kbytes): 0
    Average stack size (kbytes): 0
    Average total size (kbytes): 0
    Maximum resident set size (kbytes): 2048
    Average resident set size (kbytes): 0
    Major (requiring I/O) page faults: 0
    Minor (reclaiming a frame) page faults: 86
    Voluntary context switches: 1
    Involuntary context switches: 0
    Swaps: 0
    File system inputs: 0
    File system outputs: 0
    Socket messages sent: 0
    Socket messages received: 0
    Signals delivered: 0
    Page size (bytes): 4096
    Exit status: 0

rm bude zrat skoro 4x vice.

> Zajimavy pristup misto vic programu mit jeden co v prvnim parametru si precte co ma vlastne delat.

A busybox znáte (naprosto stejný princip)? Ona ta logika těch shell příkazů má hodně společného kódu. A taky se to dobře kopírovalo do ramdisků a systémů s rozbitým fs.

A ted museji pri nadavani na novoty zacit nadavat na prastare reseni...

Jo je to rozkopirovane aby se nereklo ze oddil pro / je mcc velky.
Z čeho soudíte, že je to rozkopírované a že to nejsou hardlinky?

Nekdo to povazoval za dobry napad.
To už před mnoha desítkami let.

Zajimavy pristup misto vic programu mit jeden co v prvnim parametru si precte co ma vlastne delat.
Stejně to mají třeba sha*sum a sha*hmac, Pokud máte v systému nainstalován vim, příkaz vi spouští ve skutečnosti vim bez jakýchkoli parametrů a ten si stejným způsobem zjistí, že byl spuštěn jako vi.

(Tohle platí pro RedHatí distribuce, jiné to mohou mít jinak.)

BusyBox už byl zmíněn. Zkrátka se to občas používá, není to žádný vynález Rustu. Ale hlavně že jste si zanadával.

Nerikal jsem ze to nejsou hardlinky. Z ceho soudite ze jsem to rikal?

A ano mate pravdu, jsou to hardlinky. Overil jsem to. I kdyz jak to zjistit, je uz mimo me znalosti. Fyzicky je to na disku jeden soubor i kdyz to ukazuje neco jineho.

To ze slepis vice programu do jedne binarky je stale zajimavy pristup.
To ze to ma BusyBox nebo jiny priklad na tom nic nemeni.
V cem spociva ta argumentace?
To ze to ma BusyBox z toho dela bezne reseni?
Odted si na steamu stahnu jednu binarku pro vsechny hry? To neni divne protoze to ma BusyBox?
Asi ne co?

Zanadaval jsem si a pomohlo to.. :D Fakt, neironicky.

Ja nadaval na velikost kterou to zere v RAM.
Logicky program co musi jeste zjistit co vlastne ma predstirat, zda je holka nebo kluk sezere o nejaky bajt vice...
I kdyby mel nejaky kod co jde sdilet, stejne ruce a stejne nohy, a velikost univerzalniho reseni nebude mit 4 ruce a 4 nohy, stale bude vetsi jak specializovany program.

Proc neni ve zpravicce ze Core Rust 0.8 bude brat o 40% vic RAM nez starsi verze?
Tohle se radsi zminovat nebude? Je to automaticke ze nova verze bude vetsi?

Proc tam neni, ze si konecne muzeme zkompilovat novy Core Rust 0.8 sami, abychom dosahli puvodnich hodnot? Jak me nekdo navrhoval.. .)

Neironicky, cim me prepis Coreutils na Rust vlastne pomuze? Cim me to ma nadchnout? Co usetrim? Jakym problemum se vyhnu? Proc nemam rici svuj nazor na to kolik to zere.

Odpovim si sam.
Me Rust prinese jen problemy a vyssi zatez na hw.
Pomuze to asi jen tem co pisi programy, ze jim to usetri v necem praci.
A to tolik, ze jim to stoji za to protlacit to.

A ten COMMAND.COM je asi lepsi priklad nez BusyBox.

Ok, BusyBox ma byt coreutils reseni pro embeded systemy? Nevedel jsem. Uz chapu proc byl zminen.

Nerikal jsem ze to nejsou hardlinky. Z ceho soudite ze jsem to rikal?
Z toho, že jste psal, že je to rozkopírované.

I kdyz jak to zjistit, je uz mimo me znalosti.
Tak, že si vypíšete číslo inode. Třeba přepínačem -i u ls.

V cem spociva ta argumentace?
V tom, že to není nic specifického jenom pro coreutils v Rustu. Prostě se to někdy používá, z různých důvodů.

Ja nadaval na velikost kterou to zere v RAM.
Což ale nejspíš nezjistíte. Resp. ono je otázka, co znamená „žere RAM“. Nahraje se to do paměti při použití jedné utility, a pak už to tam je při použití jiné utility, takže se to nemusí načítat z disku. Je to „žere RAM“, když v té RAM je volné místo? A když to ve výsledku znamená, že se ty další utility spustí rychleji?

Proc neni ve zpravicce ze Core Rust 0.8 bude brat o 40% vic RAM nez starsi verze?
Třeba proto, že to není pravda? Protože, jak píšu v předchozím odstavci, neexistuje jeden pohled na to, co to je „brát RAM“. Možná když spustíte jednu utilitu napsanou v C a tu samou napsanou v Rustu, budete mít zabrané o 40 % RAM více tou utilitou v Rustu. Ale když spustíte 3 utility v C a ty samé 3 napsané v Rustu, budou zabírat o 40 % více ty utility napsané v C, protože budou v RAM nahrané všechny 3, zatímco ty utility v Rustu budou v paměti ve skutečnosti nahrané dohromady jen jako jedna utilita. A teď zabírají o 40 % víc ty utility v Rustu nebo ty v C?

Neironicky, cim me prepis Coreutils na Rust vlastne pomuze? Cim me to ma nadchnout? Co usetrim? Jakym problemum se vyhnu?
Musí to pomoci zrovna vám a hned teď? Co když to pomůže vývojářům těch utilit – což ve výsledku bude znamenat, že se tomu bude někdo věnovat víc, opraví více chyb a přidá více nových funkcí. Nepomůže vám to pak?

Takze o 40% vetsi Rust binarka nez predchozi nevezme o 40% vic RAM?

Nezabere o 40% vice mista na disku?

Fakt to neni pravda?

Bez ohledu jak je to resene. Zda je to v pameti jen jednou jako nejaky daemon (jako command.com). Nebo je to jednou jako nejake sdilene stranky.

Rekl bych ze by se ta zpravicka zminila kdyby zmenili reseni jak tohle funguje.

Proc se do toho mota C binarka? Ta na tohle fakt nebude mit vliv ne? Bude mit vliv na velikost toho Rust souboru pocet spusteni utility v C? .)

Ale asi chapu ze jste to spatne pochopil/formuloval a chcete se bavit o tom ze Rust by mohl byt v nejakych pripadech stale celkove setrnejsi na RAM nez C i kdyz ted pribral. To bych rad take videl.

Kdyz mam RAM tak ji mam pouzivat? Kdyz mam penize, tak je mam protocit? The spice must flow?
...a nebo ne, ma, to delat s mirou? Vedet za co je rozumne dat ty prostredky? Je to mazani souboru? To misto, kde to mam roztocit? Mozna ze budu chtit smazat dva soubory a necekat u toho?

Uprimne... aby C chtelo 2 MB nebo Rust 7 MB, pro KONZOLOVOU utilitu co maze soubor vam prijde normalni?

To bude urcite existovat i pripad kdy C binarka neco zvladne a Rust uz ne jen proto ze te volne RAM bude malo.

PS: Prepsani C do Rustu jen proto, aby to bylo v Rustu me fakt tezko pomuze. Jedine ze C programatori jsou na vymreni a budou jen ti co pisi v Rustu (i kdyz to by zpusobilo jen delsi prodlevu nebo od zakladu nove reseni, misto prerodu). Nepodporuji ani prepis do Forthu, ze to bude "mensi" (nelaka vas mit program mensi nez kdyby to bylo psany v asm?). Nepodporuji ani prepis do Asm, ze to bude "rychlejsi" (ono by to bylo i mensi nez C, uz jen pro tu bolest to psat v Asm by se volilo jednoduche reseni).Nepodporuji ani prepis do Rustu, ze to bude "bezpecnejsi". Tady se prepisuje neco, aby se idealne dosahlo puvodniho stavu.

Takze o 40% vetsi Rust binarka nez predchozi nevezme o 40% vic RAM?

Nezabere o 40% vice mista na disku?

Fakt to neni pravda?
Čemu přesně jste na mém komentáři nerozuměl? Pokud je pro vás tak těžké to pochopit, spočítejte si, kolik vám na disku zabírají všechny ty C utility, které nahrazuje ta jedna binárka. A teď můžete mudrovat nad tím, co zabere víc místa na disku.

Proc se do toho mota C binarka?
Když píšete „o 40 % víc“, asi to s něčím porovnáváte. Předpokládal jsem, že s tou původní utilitou psanou v C.

Kdyz mam RAM tak ji mam pouzivat?
Jo, kvůli tomu si lidé RAM pořizují a platí za ni, aby ji používali. Teda občas se v diskusi objeví někdo, kdo se kochá tím, kolik má prázdné RAM, ale otázka je, zda to myslí vážně.

Ale klidně si tu RAM udržujte prázdnou pro strýčka Příhodu. A nezůstával bych jen u toho – pokud máte pokoj, který má třeba 25 m², namáčkněte se do 4 m² a zbytek pečlivě udržujte prázdný a žádným způsobem ho nevyužívejte. Protože to je nejlepší způsob, jak pokoj využít – nijak ho nevyužívat, nebo ne?

Vedet za co je rozumne dat ty prostredky?
Ty prostředky za RAM jste už vydal. Teď ji můžete buď využít, nebo – vlastně žádné nebo nemáte. Autoři operačních systémů totiž nejsou padlí na hlavu a RAM využijí. Třeba pro různé cache.

Uprimne... aby C chtelo 2 MB nebo Rust 7 MB, pro KONZOLOVOU utilitu co maze soubor vam prijde normalni?
Když ony toho ty konzolové utility obvykle dělají mnohem víc. Podívejte se, kolik má takové rm přepínačů a co všechno to může dělat.

To bude urcite existovat i pripad kdy C binarka neco zvladne a Rust uz ne jen proto ze te volne RAM bude malo.
Můžete přemýšlet o tom, zda jsou autoři BusyBoxu opravdu takoví hlupáci, když pro něco, co je určené pro malé systémy, zvolili právě tenhle přístup jedné všeobjímající binárky.

Jinak ano, teoreticky může nastat případ, že budete nějaký kód pouštět na kapesníku, kde bude miniaturní paměť. Pak tam ale nebudete spouštět žádný Linux, natož abyste si tam dal jeden nebo dva nástroje coreutils a nic jiného.

Prepsani C do Rustu jen proto, aby to bylo v Rustu me fakt tezko pomuze.
Ano, vám nepomůže nic.

Jedine ze C programatori jsou na vymreni a budou jen ti co pisi v Rustu
A nebo to, co jsem psal v předchozím komentáři. Že spravovat ten nový kód bude jednodušší, takže to bude ochotno dělat víc lidí.

nelaka vas mit program mensi nez kdyby to bylo psany v asm?
Ne, vůbec. Já používám počítače, a ty mají řádově víc paměti, než kolik mají tyhle utility. Dokonce i kdybyste to pouštěl na hodinkách nebo na kalkulačce, pořád tam budete mít podstatně víc volného místa. Takže ušetření možná pár procent RAM mne fakt vůbec nezajímá.

Nepodporuji ani prepis do Rustu, ze to bude "bezpecnejsi".
Přičemž to vaše podporuji/nepod­poruji se v praxi projevuje akorát žvaněním v diskusi. No , já myslím, že je to úplně jedno, jestli něco podporujete nebo nepodporujete.

Tady se prepisuje neco, aby se idealne dosahlo puvodniho stavu.
Tak ještě jednou – ten původní stav je jenom začátek.

Mimochodem, vadí vám i samotné GNU utils? Protože i ty na začátku vznikly jako přepis něčeho, co už fungovalo – a mnohdy zpočátku také bylo cílem implementovat to samé, co implementují jejich vzory.

Aha takze jste to fakt spatne pochopil.
To ze uz v prvnim a pak v dalsim dlouhym prispevek kde bylo 50x videt ze ten Rust ma 10 MB binarku a nova ma 14 MB jste prehledl.

Alternativni nazev zpravicky muze fakt znit:
Rust Coreutils 0.8 jsou zase větší, oproti 0.2.2 zabírají o 40% více a stále neprojdou 5 % testů. Dočkáme se někdy C funkčnosti? :D

Gambarééé. Všichni jim držíme palce. Rust. Rust. Rust! .)

NAME
       rm - remove files or directories

SYNOPSIS
       rm [OPTION]... [FILE]...

DESCRIPTION
       This manual page documents the GNU version of rm.  rm removes each specified file.  By default, it does not remove directories.

       If  the  -I or --interactive=once option is given, and there are more than three files or the -r, -R, or --recursive are given, then rm prompts the user
       for whether to proceed with the entire operation.  If the response is not affirmative, the entire command is aborted.

       Otherwise, if a file is unwritable, standard input is a terminal, and the -f or --force option is not given, or the -i or --interactive=always option is
       given, rm prompts the user for whether to remove the file.  If the response is not affirmative, the file is skipped.

OPTIONS
       Remove (unlink) the FILE(s).

       -f, --force
              ignore nonexistent files and arguments, never prompt

       -i     prompt before every removal

       -I     prompt once before removing more than three files, or when removing recursively; less intrusive than -i, while still  giving  protection  against
              most mistakes

       --interactive[=WHEN]
              prompt according to WHEN: never, once (-I), or always (-i); without WHEN, prompt always

       --one-file-system
              when removing a hierarchy recursively, skip any directory that is on a file system different from that of the corresponding command line argument

       --no-preserve-root
              do not treat '/' specially

       --preserve-root[=all]
              do not remove '/' (default); with 'all', reject any command line argument on a separate device from its parent

       -r, -R, --recursive
              remove directories and their contents recursively

       -d, --dir
              remove empty directories

       -v, --verbose
              explain what is being done

       --help display this help and exit

       --version
              output version information and exit

       By default, rm does not remove directories.  Use the --recursive (-r or -R) option to remove each listed directory, too, along with all of its contents.

       Any attempt to remove a file whose last file name component is '.' or '..'  is rejected with a diagnostic.

       To remove a file whose name starts with a '-', for example '-foo', use one of these commands:

              rm -- -foo

              rm ./-foo

       If  you  use  rm  to remove a file, it might be possible to recover some of its contents, given sufficient expertise and/or time.  For greater assurance
       that the contents are unrecoverable, consider using shred(1).

AUTHOR
       Written by Paul Rubin, David MacKenzie, Richard M. Stallman, and Jim Meyering.

Mate pravdu ty parametry jsem prehledl. Uz mi je jasne proc to musi mit 2 MB nebo 7 MB pameti.

I to aby meli vsechny programy naprostou prioritu a kazdy vzal RAM co muze je spravny pristup. Prinejhorsim... si muzu koupit vice RAM ne? Pokrok nezastavis. Dnesni rm utilita neni to co rm utilita kdysi. To je jako srovnat kone a lokomotivu. Ze? .)

Proc se vlastne netlaci ten BusyBox misto te Rust verze? Nema lepsi technicke parametry?

Přejdi na Windows a budeš snad spokojený. To je nejlepší rada, jakou ti na rootu můžeme dát.

Jako ze cmd.exe ma pod pul mega?
To je dost bolestiva rada.
Je fakt, ze radsi akceptuji ten Rust coreutils... :D

Aha takze jste to fakt spatne pochopil.
Ne, nepochopil jsem to špatně. To pouze vy nevíte, jak fungují hardlinky a jak funguje správa paměti v Linuxu.

I to aby meli vsechny programy naprostou prioritu a kazdy vzal RAM co muze je spravny pristup.
Nic o prioritě jsem nepsal. Ano, aby každý program použil tolik RAM, kolik potřebuje, je správný přístup. To, že něčemu vůbec nerozumíte, není důvod, abyste to kritizoval.

Víte, jak by vypadal váš přístup? Dneska program načte data „z disku“ rychle, protože jsou nakešovaná v RAM. Vy byste chtěl, aby je program načítal pomalu z disku a vy byste na to čekal – ale během toho čekání byste se mohl kochat tím, kolik máte volné RAM.

To je jako srovnat kone a lokomotivu. Ze? .)
Spíš je to jako kdybyste se ptal, proč někdo v autě používá všechny převodové stupně, které tam má k dispozici. Vždyť se tím přece opotřebovává převodovka. A na jedničku se přece dá dojet stejně daleko, jako když používáte všechny stupně.

Proc se vlastne netlaci ten BusyBox misto te Rust verze? Nema lepsi technicke parametry?
Je omezený, nemá tolik možností jako původní nástroje. Proto vznikl – aby to byla malá implementace toho nejdůležitějšího použitelná na malých systémech.

Tady bude asi problém při použítí coreutils na nějakém SBC typu Rpi0. Myslím si, že to není nereálný scénář, kdy je potřeba krabička, která slouží nějakému účelu a jen režie OS ji sebere třeba 3/4 prostředků. To se vždy vytýkalo Win OS, že na běh systému spotřebovává moc prostředků. Za mě by OS měl vyžadovat co nejméně prostředků na běh, aby umožnil účelu pro které zařízení slouží maximum prostředků. V bytě je to srovnatelné se skříňkou, která má třeba 10mm tlusté stěny v C a v Rustu má 50mm tlusté stěny. U té C skříňky se musí kapku dávat pozor při stěhování aby se nerozklížila a ta v Rustu bude odolnější, ale otázka je co uživatel víc ocení jestli více prostoru, nebo bytelnost při stěhování?

8. 4. 2026, 07:33 editováno autorem komentáře

> Tady bude asi problém při použítí coreutils na nějakém SBC typu Rpi0.

Zároveň je ale potřeba uvědomit si, že ta single binárka bude zabírat konstantní stack size ať použiju jakýkoliv příkaz, takže ve výsledku ten rozdíl nemusí být oproti použití jednotlivých GNU nástrojů tak citelný. A ani extrém jako Rpi 0 není tak omezený. Lidi na tom běžně provozujou software v Pythonu.

Kdyz jsem se snazil divat na tu C verzi rm tak pokud jsem to spravne pochopil, je to jen parser vstupnich parametru a skutecnou praci nakonec to mazani udela po zavolani jadro.

Ale on i ten zdrojak kdyz nepocitam co to linkuje muze mit 373 radku:
https://sources.debian.org/src/coreutils/8.32-4/src/rm.c

nebo 445 v BSD:
https://github.com/openbsd/src/blob/master/bin/rm/rm.c

nebo 76 kdyz ignoruje nejake prepinace v BusyBoxu:
https://github.com/brgl/busybox/blob/master/coreutils/rm.c

Binarka ma u me 60072 bajtu.
Coz je docela dost, ale kdyz to vypada ze se snazi pouzivat pulku vsech knihoven tak to chapu.

Pri spusteni aby to smazalo jeden testovaci soubor si to ale v jeden moment najednou rekne ze potrebuje 2 MB. Nevim ktera cast to dela ani proc je to potreba.
Je to kuvli libc? loader? stack?

Vyzkousel jsem napsat minimalisticky program co maze jediny konkretni soubor

#include <stdio.h>

int main(void) {
    const char *filename = "./smaz.txt";
    if (remove(filename) != 0) {
        perror("Fail");  // + : No such file or directory
        return 1;
    }
    printf("Fertig!\n");
    return 0;
}

a ono si to nerekne o nic mene

/usr/bin/time -f "%M KB max memory" ./delete_file smaz.txt
Fertig!
1564 KB max memory

a to jsem nic neparsoval a neresil zadne LOCALE u ktere se rm rozdivoci.

Dalsi varianta... vubec nevolat libc...

void _start() {
    const char *filename = "./smaz.txt";

    // syscall unlink (x86_64)
    __asm__ volatile (
        "mov $87, %%rax\n"       // syscall číslo unlink
        "mov %0, %%rdi\n"        // filename
        "syscall\n"
        :
        : "r"(filename)
        : "%rax", "%rdi"
    );

    // syscall exit (0)
    __asm__ volatile (
        "mov $60, %%rax\n"       // syscall číslo exit
        "xor %%rdi, %%rdi\n"     // exit code 0
        "syscall\n"
        :
        :
        : "%rax", "%rdi"
    );
}

pri kompilaci to selze pokud se neudela
gcc delete_raw_file.c -nostdlib -nostartfiles -static -o delete_raw
Mimochodem to ma 9 kb.

/usr/bin/time -f "%M KB max memory" ./delete_raw smaz.txt
392 KB max memory

Takze ty 2 mega jsou asi dan za libc.
I kdyz to testovani pomoci time je stejne divne, protoze kdyz jsem omylem testoval neexistujici binarku tak me to ukazalo spotrebu 1 mega. :D

Rusti verze to ma naopak, evidetne nenacte celou binarku do pameti ale jen co potrebuje.

/usr/bin/time -f "%M KB max memory" /usr/lib/cargo/bin/coreutils/rm smaz.txt
7032 KB max memory
xxx@xxx:~/Stažené/coreutils-0.8.0-x86_64-unknown-linux-gnu$ ls -l /usr/lib/cargo/bin/coreutils/rm
-rwxr-xr-x 115 root root 10832184 Oct 22 11:39 /usr/lib/cargo/bin/coreutils/rm
xxx@xxx:~/Stažené/coreutils-0.8.0-x86_64-unknown-linux-gnu$ /usr/bin/time -f "%M KB max memory" ./coreutils rm smaz.txt
6492 KB max memory

A nova verze i kdyz je vetsi potrebuje mene. Takze se realne zlepsili.

„Rusti verze to ma naopak, evidetne nenacte celou binarku do pameti ale jen co potrebuje.“

To bude nejspíš tím, že Linux obecně nekopíruje binárky přímo do paměti. Udělá mmap, takže máme v paměťovém prostoru nějaký soubor, který v paměti být může, ale nemusí. Když k té paměti budeme přistupovat, načte se potřebná část souboru (+možná něco navíc) do cache. Ale tam nemusí vydržet věčně – je-li málo paměti, tuto paměť může kernel uvolnit a použít na něco jiného. Je to levnější alternativa swapu, kdy při uvolňování paměti není potřeba nic zapisovat na trvalé úložiště, protože to tam už je.

A i proto je docela tricky měřit smysluplně spotřebovanou paměť. Když započítáme všechny cache, započítáme toho nejspíš příliš. Když nezapočítáme žádnou cache, počítáme se stavem, kdy je systém prakticky nepoužitelný. A když započítáme jen tu cache, co je v RSS, některé věci započítáme vícekrát, protože ty memory-mapped files může sdílet více procesů.

Ano o tom mluvím, I nejnovější Rpi zero 2 má 512Mb RAM a dost lidí na tom chce používat Python, který je náročný na RAM. Proto nebude mít radost z toho, že režie přepsaných GNU nástrojů do RUSTu mu sebere místo pro jeho Python projekt. Už vidím ten scénář, kdy na Rpi 0 běží nějakej Python projekt a po updatu systému a restartu najednou přestane běžet, protože nově update distra přešel na RUSTové nástroje a uživatelský projekt se nevejde do RAM. 10Mb RAM najednou bude otázka funkčnosti toho zařízení.

Předpokládám, že na takovém stroji nikdo nebude spouštět klasické Ubuntu s utilitami určenými pro plnohodnotné stroje.

Proto nebude mít radost z toho, že režie přepsaných GNU nástrojů do RUSTu mu sebere místo pro jeho Python projekt.
Pořád ignorujete, že pokud budete používat víc utilit (což je na unixových systémech běžné), můžete mít nakonec větší režii s těmi samostatnými utilitami. Protože bude muset být v paměti více utilit a zabraná paměť bude jejich souhrn. Zatímco ty Rustové utility jsou jedna binárka, takže i když jich bude spuštěných víc, bude to v paměti jenom jednou.

Nechce se mi řešit, jestli se dá Rustí binárka stripnout na úroveň 2MB. Možná jo, možná ne. Předpokládejme, že je to skutečně tak, že Rustí implementace má 7MB.

S čím přesně že máte problém?

- Že je to víc jak to v C? Ano, je to víc.
- Že se může stát, že C implemetace zvládne nějaký problém a Rustí ne, protože nedostatek paměti - ano, toto je matematicky možné. Pravděpodobnost je neměřitelná.
- Že se vám to nelíbí, tak ano, to se vám skutečně nemusí líbit.

A?

A?

A nic.

PS: Abych uvedl na pravou miru... ta binarka asi zmensit nakonec nejde. Neni to chyba prekladu. Uvadel jsem co me pise u obsazeni RAM pri volani. 0.2.2. ma 10 MB. 0.8 ma 14 MB. A nemyslim ze to jde zmensit protoze je to proste cele dohromady.

Mea Culpa ze jsem se ozval u clanku ze neni vse ruzove jak se prezentuje.

Rust je vysokoúrovňový jazyk, a většina z nás ani neočekává, že by aplikace přepsaná z C do Rustu byla stejně velká. A ve skutečnosti děkuji, protože pokud takto zděšeně popisujete, že se ta velikost zvětšila ze 2 na 14MB, tak je to vlastně dobrá zpráva. Bál jsem se, že to bude horší.

Dnes jsem optimalizoval prekladac, aby spojeni 3 tokenu bylo nekdy o jeden bajt a 3 takty rychlejsi. Asi ziji v jinem svete. Takze mam mit taky radost? Mohlo to byt horsi... hmm.

Asi zijes v jinem svete, no. CoreUtils halt nejsou o optimalizaci az na dren ale i o udrzbe a dalsich praktickych vecech, ktere ocividne mijis.

Bezne prochazim mezi embedded C, C++, Windows C#.
Ano jsou to uplne jine svety. A beda tem ktery se na vsechno divaji jednou optikou.

> ta binarka asi zmensit nakonec nejde

Právě jsem to sestavila s 9.1 MB binárkou, stačilo dát profil `release-small` místo `release` který je definovaný přímo projektem. S jakým profilem to sestavit je na tom kdo to balí.

Ale myslím že to zvládnu ještě zmenšit.

Jsem na 8.1, asi by se to dalo ještě zmenšit, ale nechce se mi tím trávit dopoledne :)

Hele, tyto multicall binárky mají své opodstatnění a nejsou vzácné, například ten busybox je velmi rozšířený, takže v rámci možností by se dalo říct, že je to běžné řešení. Ale jen tam, kde něco takového má smysl. U hry ze steamu to nemá smysl. Uvědom si, že třeba cp, mv a rm budou obsahovat velikou spoustu stejného kódu, kvůli stejné funkcionalitě. Proč mít tedy stejný kód na třech místech? Ta režie na začátku při rozhodování co vlastně mám udělat už je pak minimální a bude zcela zanedbatelná v okamžiku prvního čekání na diskové operace.

V každom riadku máte číslo 115, ktoré hovorí o počte hardlinkov. Ešte máte niekde jeden hardlink, ktorý je evidentne v inom priečinku, keďže vo vašom výpise ich je 114.
Väčšinou tam pri výpise iných adresárov máte 1.

> ... jsou to hardlinky. ... I kdyz jak to zjistit, je uz mimo mimo me znalosti.
> Fyzicky je to na disku jeden soubor i kdyz to ukazuje neco jineho.

Na to je 'ls -i', kdy hardlinkované soubory mají stejná nodeid, která se takto
vypíší úplně na začátcích řádků.

V mhoha případech by měl být i gzip a gunzip ta sama binarka, ale neověřoval jsem to.

8. 4. 2026, 06:34 editováno autorem komentáře

V mhoha případech by měl být i gzip a gunzip ta sama binarka, ale neověřoval jsem to.
Ano, je to jeden z mnoha příkladů. Akorát (alespoň na CentOS) se nepoužívá ten trik se čtením názvu příkazu, ale gunzip je skript, který spouští gzip s parametrem -d.

Rozstepit bit? Ja takto chapu qbit.

Podle mne je to trochu něco jiného. Tím „rozštěpit“ jsem myslel na nějaké diskrétní části, byla to narážka na „rozštěpit atom“. qbit je podle mne pořád jenom jedna nedělitelná informace, akorát to není diskrétní „ano“ nebo „ne“, ale jsou to oba možné stavy zároveň (a ve výsledku nás zajímá, jaká je pravděpodobnost těch dvou stavů).