Názory k článku
Udržitelné programování s Rustem

A neměl by se tedy článek jmenovat udržitelné programování s C?

To záleží na tom, jestli člověka zajímá i obsah článku (odkaz ve zprávičce je) nebo se spokojí se zkratkou.

Na twitteru se kolem porovnání zveřejněného AWSkem strhl trošku flame war, ale mimo prázdných výkřiků že všichni jsou pitomci se tam objevili i celkem konstruktivní komentáře zabývající se rozdíly v kódu který pro test použili. Je s podivem že pro porovnání programovacích jazyků použili kousky kódu které se liší mnohem více než by bylo nutné. Vypadá to mírně podezřele. Ale jo, obecně ty výsledky sedí na další podobné benchmarky, plus mínus vycházejí podobně. Céčko na vrcholu žebříčku asi není překvapením, jen prostě vyměníte svůj čas jako programátora za strojový čas mašiny, ale Python naspodu mě hodně překvapil. To bych nepředpokládal.

Vazne? Uz i tady?

Sorry, ale Fortran neni 4x pomalejsi nez C, Typescript neni 7x pomalejis nez Javascript.

Opravdu mi unika jak se nedko na tyto data muze podivat a rict "jo, to vypada rozumne".

Typescript spotrebovava elektrinu pri kompilacii a type checkingu v IDE. Myslim, ze to moze byt dost podstatny diel energie, ktora sa pri “raw JavaScripte” nepali.

Ale to jen v případě, že to napíšete a pak jednou spustíte, ne? Když budu mít aplikaci co používá 10 tisíc lidí každý den, tak tohle bude naprosto zanedbatelné.

Pudl bude zakopaný v tom, že ty benchmarky jsou malé, jednoúčelové a vysoce optimalizované prográmky. Pokud by se člověk pokusil přepsat do C nebo Rustu nějakou větší aplikaci, tak nejen že to bude mnohem náročnější na údržbu, ale nejspíš ani to zlepšení energetické efektivity nebude tak zázračné.

A pak by se mělo započítat i to o kolik víc energie spálí programátor při vývoji a debugovaní v nízkoúrovňovém jazyce :-)

V čem vidíš problém u velkých aplikací v Rustu?

Neříkám, že je problém napsat velkou aplikaci v nízkoúrovňovém jazyce. Jen že to je víc kódu. A čím víc kódu, tím víc tam bude funkcí, které by zvládl optimalizovat i vysokoúrovňový jazyk (protože málokterá aplikace je celá CPU-heavy), takže ten rozdíl v efektivitě může vyjít úplně jinak než u malého benchmarku.

Jenže zrovna Rust má dostatečně silné abstrakce, psaí v něm je svižné, když nejsi úplný začátečník a má dobrou podporu pro refaktorizace apod. Jinými slovy, Rust není C.

Když má nějaký jazyk třeba JIT a tracing GC (nebo je nedejbože dynamicky typovaný), tak je v porovnání s Rustem úplně jedno, jak velká aplikace je.

Tak zrovna JIT u dlouhodobě běžících aplikaci umožňuje získat určitou výhodu nad Rustem. (Tím rozhodně neříkám, že ta výhoda v celkové bilanci musí vždy převážit…)

Tak ma napadá:

Prepisovať niečo do C-čka iba kvôli energetickej úspornosti? Prečo nie do assembleru?

Nasledne ten kód treba udržovať a ďalej rozvíjať ... nie?

Keď sa už bavíme o efektivite, tak v neprospech Javy hovorí aj to, že spotrebúva oveľa viac pamäte ako kompilované jazyky. Takže tým by sa ušetrilo možno ešte viac energie - je nutné vyrobiť a prevádzkovať (refreshovať) násobne viac RAM!

Sú aj iné dôležité parametre ako energetická účinnosť. Napr. spoľahlivosť, udržovateľnosť a pod.

Robím v oblasti priemyselnej automatizácie (SCADA systémy). Primárne v jazyku Ada, človek sa viac napíše ako v C-čku, na druhej strane kód je oveľa čitateľnejší (aj cudzí), bezpečnejší a mnoho chýb odchytí už kompilátor. Ďalšie runtime checky .. za cenu CPU výkonu - ale to každý akceptuje radšej ako nejaké padanie kvôli prepisovaniu pamäte za hranicou poľa. Takže tie checky nikdy nevypíname a sme za ne vďační.

25. 2. 2022, 19:38 editováno autorem komentáře

To s tou pamětí je trefný postřeh, nevím jak datová centra, ale energetická náročnost RAM (refrešování) bývala důvodem, proč iPhony mívaly paměti poměrně málo. Z toho pak vyplynulo, že Apple nechtěl na iOS tracing GC, aby aplikace nežraly té paměti moc (na macOS ObjC tracing GC volitelně mělo). Teď už to asi hraje menší roli, ale Swift má taky jen ARC.

Když už se píše v Adě, proč místo kontrol za běhu (runtime checks) nepoužít SPARK? Ten běhové chyby vylučuje a je to v podstatě Ada (rozumná podmnožina).

SPARK je super, ale použiteľný pre embedded systémy a podobne. Má dosť silné obmedzenia (teraz hovorím z pohľadu SCADA systémov - do tej "rozumnej podmnožiny" sa bohužiaľ nezmestíme). Pekné je, že sa dá kombinovať SPARK / ADA (niektoré procedúry/funkcie môžu byť SPARKové, s overenou korektnosťou, zvyšok ADA).

SPARK/ADA sa použila aj pri programovaní študentských cube-satov:
https://blog.adacore.com/ten-years-of-using-spark-to-build-cubesat-nano-satellites-with-students

https://www.youtube.com/watch?v=YlnfyToUwv4

Tu:
https://youtu.be/YlnfyToUwv4?t=461
píšu, že majú cca 10 tisíc riadkov kódu. Ok, my máme vyše 2.5 milióna (bez prázdnych riadkov a komentárov).

Tu:
https://youtu.be/YlnfyToUwv4?t=89
hovorí o tom, že z 12 univerzitných CubeSatov sa ozvali po vypustení iba 4, z nich dlhodobe (vyše 2 rokov) fungoval iba ich SPARKový. Ostatné boli programované v C-čku a jeden z nich pošiel v priebehu dňa, druhý do týždňa a tretí vydržal 4 mesiace.

Záleží na aplikaci. V praxi u databázově orientovaných aplikací, kterých si myslím, že minimálně hodně ne-li většina, se mnohem víc energie spálí na: a) chybějících indexech (ať jednoduchých nebo složených), bordelu v databázi (bavíme se o úrovních normalizace), špatné konfiguraci operačního systému - huge pages, transparent huge pages, atd atd, neoptimálně nastavené virtualizaci - nikdy bych nevěřil, co dokáže neoptimálně nastavený proxmox. Nějaký Python nebo Java pak hraje naprosto zanedbatelnou roli.

Ako hovoríte.
A pokiaľ je aplikáciou nejaká sociálna sieť alebo online hry, tak môže byť, že v konečnom dôsledku väčšina času (strojového / ľudského) je spálená zbytočne.

Ale s tým optimalizácia kódu ani výber programovacieho jazyka nič nespraví :)

Jo, ta omezení jsou drsná. Ale jsou i jiné možnosti, jak se vyhnout chybám za běhu, třeba verifikace přes typy.

To jednak není pravda a jednak nám nesahej na naše svobody. Socialismus už jsem zažil, děkuju.

26. 2. 2022, 09:36 editováno autorem komentáře

Nejudržitelnější způsob docházky do práce je pěšky. Nebo na kole. Bez ohledu na vzdálenost, počasí nebo kvality komunikací.
K testu jsme požádali specialisty na přežití v divočině a vrcholové sportovce a závěry jsou jasné.

Jasně, že to je aktivistický blábol. Ve starých dobrých časech, kdy se do programování netlačili genderisti a podobné existence, by debata byla o úspoře energie a tedy nákladů. Což znamená totéž, pouze to nezní hloupě.

Programování je vůbec celé rasistické a homofobní, i bity chtějí být nebinární! :)

Vícestavová elektronika tu už taky byla, co se pamatuju.

Pro nebinární stavy tu máme qubity :-)

To je zas moc :)

A skutečně se ta energie spotřebuje ve výpočetních úlohách běžících v daných jazycích? Nebo spíš v externích závislostech (I/O operace, datastore, databázové operace ad.)? Minimálně v případě Pythonu bych o tom dost pochyboval.

Jaké si uděláte kritérium, takové to máte. A jelikož bylo potřeba aby to vyšlo pěkně, test probíhal čistě v matematických algoritmech. Jaké překvapení, že Python pohořel a nízkoúrovňový jazyk vše předehnal. Jakou to má souvislost se server aplikacema? Bůhví.

Prosím nešiřte informace o článku, který nemá žádnou vědeckou ani technickou úroveň. Viz např. https://twitter.com/_rsc/status/1496352325157457922

Navíc pro kód mimo hodně speciální nasazení jsou navíc mikro-benchmarky úplně mimo mísu, protože opravdu nebudu psát CRUD aplikaci ve Fortranu a nejspíš ani v C, ale řada podniků se rozhodne pro Javu, C#, TypeScript, možná Python nebo Ruby a ty progresivnější třeba Clojure/ ClojureScript.

Je to opravdu dětinská diskuze a mimo mísu. Malé zefektivnění ve Windows, Linuxu, Chromiu nebo přímo v jednotlivých jazycích budou mít nedozírně větší efekt. Lidi ale nebudou fluidně přecházet mezi aplikacemi, jazyky a operačními systémy, protože opravdu nejde jen o rychlost/ efektivitu běhu.

Jenom připomenu, co normální firma/ inženýr bude dělat, když je aplikace pomalá:
- Zamyslí se/ použije nástroje a naměří/ nebo aspoň nacítí si nějaká data. Většina aplikací je prostě pomalá a je celkem jasné proč. Např. příšerně neefektivní přístup k problému, tahání dat "ideálně" přes síť a ještě např. synchronním způsobem, vyhledávání, procházení velkého objemu dat, často zbytečně.
- Když našel úzké hrdlo, podívá se, jak by ho mohl opravit. Např. zredukovat problém, použít lepší algoritmus, dodat správný index do databáze, lepší dotaz, používat batching, cache, lepší knihovnu/ napsat si funkci lépe sám, lepší nastavení systému...
- Podívá se, jestli už je to lepší. Otestuje správnost.
- Případně opakuje a řeší další problémy.
Následující body v různém pořadí, podle problému, peněz, času a obecně možností:
- Když dojde k tomu, že to je jazykem, podívá se, jestli nemůže kritickou sekci vyčlenit do efektivnější implementace/ volání vyladěné knihovny/ systému. Podobně jako NumPy + Python, obcházení React.Js v kritickém místě apod.
- Lepší hardware/ víc hardware (např. load-balancing)
- možná úplně jiné uchopení problému potenciálně v jiném jazyce

Prostě nějaké přepisy jsou u větších projektů opravdu až na posledních příčkách TODO, když je výkon/ efektivita neuspokojivá. V drtivé většině případů se prostě jen dělají nesmysly, ten výpočet/ aplikaci možná ani nikdo nepotřebuje a dělá se to automaticky z historických nebo jiných pseudo-důvodů. Často se čeká někde na DNS, nebo je špatně nastavený systém/ chybí index/ dotaz je složitý a DB se nepomohlo jej schroupat efektivněji. Často chybí cache na již hotovou práci/ aby se zbytečně netahala. Je špatný algoritmus.

Možná výpočet přerušuje agresivní logging/ monitoring nebo něco, kde se draze přepíná kontext a výkon jde do háje. To už jsem taky zažil, systém nevykonával vlastně vůbec aplikaci, ale monitoring. Možná je pro webovou apku nevhodná knihovna/ framework nebo neefektivní implementace v prohlížeči (např. SVG vs PNG/ canvas/ WebGL). Prostě tento druh problémů.

Obecně, dobrý programátor/ inženýr má nějakou intuici, jestli je výkon dostatečný nebo ne. Když to splňuje explicitní/ implicitní zadání, tak nikdo kromě těch nejspecifičtějších/ největších nasazení výkon neřeší. V nejhorším se koupí o facku větší server/ osadí novější chip a jde se dělat něco, co má hodnotu.