Názory k článku
Knihovna zlib-rs napsaná v Rustu je rychlejší než ta původní v C

Pardon, ale klasicka zlib je na tom vykonove zoufale. Nicmene jeji vyhoda je, ze jde prelozit fakt hodne starymi kompilatory a funguje na obskurnich systemech.

Zajimalo by me porovnani s libdeflate, ta byla uz pred nekolika lety rychlejsi nez zlib nebo zlib-ng.

> zlib-rs je ale podla benchmarku rychlejsi ako zlib-ng.

Malinko.

Je otázka, zda je u komprese velikost výstupů stejná. Například libdeflate s úrovní komprese 6 komprimovala stejně jako zlib-ng s úrorvní komprese 9, ale rychlostně byla libdeflate více jak 4x rychlejší.

Bohuzel ta Rusti knihovna je plna unsafe kodu, takze nevidim moc vyhod oproti bindingum odzkousene zlib-ng nebo potencialne vykonejsi libdeflate.

aspoň jde snadno zjistit, že tam je ten unsafe kód

A nezáleží take na tom jde ty unsafe jsou? Jestli jen kvůli dodržení (blbě navrhnuteho?) zlib api a nebo i uvnitr kvůli nevím čemu? Ta druhá alternativa by mne trápila mnohem víc.

Unsafe je skoro to všude i mimo C API. Jednak se tam používá C-style práce s pamětí. Např.

// zero initialize the memory
let prev = prev.as_ptr(); // FIXME: write_bytes is stable for NonNull since 1.80.0
unsafe { prev.write_bytes(0, w_size) };
let prev = unsafe { WeakSliceMut::from_raw_parts_mut(prev, w_size) };

A druhá věc je, že se tam používají SIMD instrukce jako např. AVX 2, které Rust neumí volat v safe kódu. Takže pak ty výkonné implementace jsou v podstatě celé jenom unsafe kód. Viz třeba adler.rs

Díky za odpověď.

Z tohoto + z README mi přijde, že autor vzal kód zlib-ng a snažil se jej ± 1:1 přepsat do Rustu. A kde to nešlo přímočaře vyřešit bez toho, použil unsafe. A co z toho plyne?

1. Dobré vědět, na čem jsme.
2. V zásadě by to nemuselo být horší než předloha.
3. Pokud se tomu bude věnovat dál, snad ty unsafe věci zredukuje nebo nějak rozumně zawrapuje. Možná během toho najde i chyby v původní implementaci.

Ad SIMD – to je jen otázka rozumného wrapperu, který bude unsafe, ale půjde rozumně zkontrolovat.

>>> Rusti knihovna je plna unsafe kodu,

To je fuzzy termín, dajte nejaké metriky, že koľko, čo a ako. Vážne ma zaujíma pohľad experta. Ak je unsafe kód dobre vyčlenený a testovateľný, tak to nebude big deal. Ak je to prelezené ako rakovinou, potom je to horšie, asi tak na úrvni C, len rýchlejšie. Tak ako?

27. 2. 2025, 15:11 editováno autorem komentáře

Ten Rust je rychlejší proto, že má lepší kompiler nebo je ta knihovna lépe napsaná?

Spíš to druhé, ale Rust tomu dovede dost pomoct.

Osobne by som povedal, že oboje. Momentálne som v rust začiatočník a môj kód je diplomaticky povedané - nie najlepší. Ale beží to ako namydlený blesk. Ak knižnica používa paralelizmus, v C sa všetko musí nemotorne oprogramúvať, v Rust je to transparenté. Robím to cez Rayon a ten musí mať nejaké triky pod kapotou, nejak tie thready múdrejšie manažuje, než by som to robil sám. A aj v ostaných veciach asi bude dôvod, prečo je tá kompilácia tak strašne pomalá (robí to asi viac, než -O3 v gcc). Mám asi tušenie, že čo, len nechcem trepať, budú o tom lepšie materiály niekde.

Nelze generalizovat.

Je nutno si uvědomit, že binding v Rustu znamená, že celou tu C knihovnu narvu do unsafe, takže jsem si vlastně nepomohl.

U bindingu mám výhodu kódu ověřeným časem. V případě, že nemám v plánu nějak optimalizovat a vrtat se v tom, to bude naprosto dostačující.

U reimplementace mám výhodu, že se můžu opřít o Rust, a nebezpečný kód minimalizuji na čitelnou úroveň. Nevýhoda je v tom, že je to práce, která se musí udělat a vyplatit. Taky jako u každého nového kódu tam můžu nasekat nové chyby.

Pokud jsem příspěvek pochopil dobře, tak autoři si věřili, že se ten kód dá optimalizovat, a chtěli se pochlubit úspěchem.

Tedy důvod, proč zvolit zlib-rs je rychlost. Není důvod si myslet, že by bezpečnost byla nějak výrazně různá.

Tak ako tu uz bolo spomenute, nejak uplne nechapem tomuto telocviku a titulku.
Priamo na githube pri zlib-rs pisu ze vychadzali z zlib-ng, cize budu +/- vykonnostne porovnatelne. To ze je vykonnejsia ako zlib sa asi da ocakavat, ako tu uz bolo spomenute, povodna zlib nie je na dnesne pomery napisana najoptimalnejsie a podporuje vela kompilerov a platforiem - to je dan za vykon. Toto riesi prave zlib-ng. Ak pouzijem zlib-rs s bindingom, kde tak isto na svojom githube tvrdia ze benefit je vyssia bezpecnost, tak som tam kde som bol. Ak to pouzijem v ramci rust projektu tak asi ok.
Tak trochu mi pride ze sa spravil hype okolo rustu , ako svojho casu okolo javascriptu/node. Pritom jazykov ktore boli a vlastne aj su fajn len to pohnojili kompilerom a ekosystemom je habadej. Keby Sun nebol taky nenazrany a kratkozraky tak by Java mohla byt niekde inde, keby Google nebol za Go a netlacili by to len ako backend alternativu tak by sa z toho mozno stal zaujimavejsi jazyk, keby MS nespravil .Net ako truc podnik Sunu/Jave tak by mohol byt daleko zaujimavejsi. Keby niekto oprasil Pascal a spravil k nemu poriadny kompiler (aj ked FreePascal je celkom fajn) tak by sme mohli byt inde (Delphi/Lazarus celkom vymakane RAD) atd...

Sun skrachoval na .com bubline, nie na vlastnej pažravosti.

Po krachu Javu prevzal Oracle a ten nie je známy ako motor inovácii, práve naopak.

Na com skrachoval Sun by sa dalo polemizovat. Staci sa pozriet na ich HW, Sun Ultra a co stali napriklad len take sietove karty, co boli de facto brandovane 3Com karty, napoveda, tie od Sunu stali 10x tolko. A aj ten ich Solaris nebol ziaden zazrak. Jedine co mali bola Java a preto sa jej tak drzali az si sami podpilil konar.

>>>A aj ten ich Solaris nebol ziaden zazrak

Na ten som práve počul spievať ódy, mal na tú dobu unikátne vlastnosti. A AFAIK je to certifikovaný UNIX. Ich servery sa predávali ako riešenia so Solarisom. Nedá sa polemizovať, prečo skrachoval Sun, lebo skrachoval kvóli .com bubline, na ktorú doplatili aj iné HW firmy. Bolo kopec second-hand HW po skrachovaných startupoch a nový HW nikto nekupoval.

> Javu prevzal Oracle a ten nie je známy ako motor inovácii, práve naopak

Nebudu řešit obecný obraz Oracle, nicméně přijde mi, že za Sunu se Java rozvíjela mnohem pomaleji než za Oracle. Sun vyvinul až Javu 6 a velkou část Javy 7. Od Javy 8 dál mám pocit, že se to hýbe více.

A to nepočítám GraalVM, který spadá do ekosystému, ale není to přímo věc jazyka.

Sledujem Javu od Javy 1.3, lebo vtedy som s ňou prišiel do kontaktu. S každou verziou boli nové vlastnosti. Potom bola java 7 a na dlhý čas to celé zaspalo. Teraz Oracle len dobieha rozbehnutý vlak. Je kopec famóznych programovacích jazykov.

Otázka je, o čem přesně se bavíme. Jestli o samotném jazyků, standardní knihovně, JVM, dalším ekosystému apod. Já reagoval jen na jazyk (proto jsem nezahrnoval GraalVM), tam od Javy 1.3 (s tou jsem dělal v souvislosti s J2ME) do Javy 7 přibyla hlavně generika. Jo, bylo toho trošku víc, ale IMHO nic významného. V Javě 7 nebyla ještě ani lambda, resp. šlo to řešit leda pomocí anonymních tříd, což jednak bylo ukecané a jednak mělo určitá omezení. Naopak od Javy 8 dál začaly chodit novinky. Lambda, moduly, různá zjednodušení. Přijde mi, že od Javy 6 je to o dost jiný jazyk.

Pokud se podíváme šířeji, GraalVM mi přijde jako dost zajímavá novinka. Podpora dalších jazyků, jejich interoperabilita, native-image. I kdyby to byla jediná novinka, přijde mi to dost.

Javascript je jazyk na houby, který má jediný benefit, vývojáře, kteří ho znají

Java je za zenitem, a své nástupce má: Kotlin, Scala.

Net je rybníček pro Windows, to nikoho nezajímá. C# je hloupý jazyk. To spíše F# je co k čemu.

Go je výborná alternativa pro aplikace, které se dříve psali v C/C++, byla a je poptávka.

Pascal, stejně jako Lisp a pod jsou prostě úkrok stranou, kdo by v tom dneska psal?

RAD (Delphi, Lazaurus, VisualStudio) je slepá ulička.

Jazyky a technologie se prostě vyvíjí jak zjišťujeme co je a co není dobrý nápad. Spiknutí bych v to nehledal.

Takze Visual Studio ktere je na prvnim miste v pouzivanych IDE je slepa ulicka? Zajimave. Pro zajimavost, pises ve vi nebo v nano?

Já docela dlouho i profesionálně používal obyčejný gedit a ještě déle Geany. Masivní IDE nejsou žádná nezbytnost.

Nejakou takovou statistiku jsem videl taky a byla zalozena na mnozstvi dotazu na stahnuti daneho IDE na google, coz mi neprijde moc vypovidajici.

Keď vypadol Majkrosoft Ažúr, tak polovica služieb nefungovala. Tipujem, že pre henten ich Klaud sa programuje práve na Visual Studiu. Môže to byť dosť masívne zastúpené.

Inak ak mám hovoriť z autopsie, tak väčšinou vídam rôzne deriváty Eclipse a Intellij. Môj brat je C++ vývojár a používajú vo firme Eclipse.

VisualStudio bolo pouzitelne vo verzii 6.0. Potom prisiel .NET a potreba MS ho pretlacit vsade (Java history). A preto sa rozhodli prepisat VS do .NETu. A odvtedy tu mame tento polorozbite relativne pouzitelne IDE. Na mensie projekty a .NET sa to pouzit da, ale na hocico vacsie a hlavne c/c++ je to konecna. Trochu tomu pomohla verzia 2022 ktora je prva 64bit, ale aj tak, nic nezvycajne ked VS vytuhne, debugger ma problem s vecsimi objektami/struk­turami, atd. Ale to sme uz odbocili od temy.
VS by potrebovalo prekopat, ale bohuzial nema moc konkurenciu (aspon na windowse) tak naco....

Kontext. Přemýšlet prosím.

Visual Studio si udělalo svou slávu na visuálním návrháři, proto se to ostatně jmenuje Visual. Problém je v tom, že ten návrhář jednak velmi rád padá, a druhak ti umožní přepnout do kódu, ten poeditovat a následně si s ním neporadí.

Jako IDE je samozřejmě normálně použávaný, o tom není řeč.

Pak jsem vlastně zapoměl na nejslavnější RAD (po Delphi): XCode. Ale s ním mám málo zkušeností a slyšel jsem, že ten visuálná návrhář se taky moc nepoužívá. Ale zde to není má zkušenost.

Nemyslím, že to by byl benefit JavaScriptu. Tím je spíš to, že je v každém prohlížeči. Co je příčina a co je následek nelze jednoduše říci. Ale jinak i JavaScript má jisté drobné výhody ve vztahu k prostředí, ve kterém obvykle běží. Jakkoliv bych v těch prohlížečích taky raději viděl něco podstatně rozumnějšího.