Vlákno názorů ke zprávičce Udržitelné programování s Rustem od Pet - Tak ma napadá: Prepisovať niečo do C-čka iba kvôli...

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í :)