IMHO by se mělo hledět na čas a paměťovou náročnost rozbalování. Na cílovém zařízení mohou být omezené prostředky. Čas a náročnost komprese nejsou příliš podstatné, to se provádí ve neporovnatelně méně často (ideálně pro celou distribuci "jednou").
Mezi zvažovanými algoritmy nejsou nijak dramatické rozdíly na prostor, který stojí zanedbatelně málo. Takže pokud bych mohl hlasovat, pak bych vybral takový algoritmus (jak pro kernel, tak pro balíčky systému), který ušetří celosvětově nejvíc elektřiny na koncových zařízeních.
Watthodiny (z globálního pohledu) moc neuhlídáte, čas ano. Názorně: Mohu výpočet zrychlot dvakrát použitím čtyř jader místo jednoho. Časově to je zlepšení (rychlejší výpočet), energeticky z pohledu procesoru (dvojnásobná spotřeba) to je zhoršení. Jenže během celého výpočtu mi bude svítit displej, který má taky spotřebu. Ve výsledku i s displejem může vyjít úsporněji použít čtyři jádra.
Toto by se ještě dalo nějak pořešit, pokud řešíme software pro konkrétní zařízení (třeba konkrétní model telefonu nebo notebooku), ne pokud vyvíjíme třeba Ubuntu pro širokou škálu zařízení. Ale pak tu mohou být širší souvislosti: Restartuju router a čekám na to s rožnnutým displejem notebooku. Pak energetické výdaje za delší start se projeví u notebooku, tedy u zcela jiného zařízení. Vývojáři routerů těžko mohou vědět, kolik kdo bude mít zařízení takto čekajících na (re)start a jakou mají spotřebu.
Domnívám se, že by bylo možné měřit čas na jednom jádru a z toho odvozovat spotřebu. Paralelním během je pak možné dosáhnout o něco vyšší efektivity, nicméně její změření by mělo být na tom, kdo takovou změnu bude prosazovat.
Dál si dovolím odhadovat, že paralelním zpracováním se získá jak na čase, tak i na energetické efektivitě. Změřit by se to muselo, pokud bychom našli nějaký případ, kde bude podezření, že se to od sebe rozejde.
Přemýšlet o tom, že na router čekám s rozsvíceným laptopem je už mimo obor, který řešíme. Úvahami bychom mohli dojít k tomu, že zdaleka nejlepší by bylo nerestartovat a nemít laptopy. Jediné, o čem můžeme uvažovat je, když už startuje jádro, kolik to sežere energie.
Já jsem tím chtěl říct, že v reálném světě optimalizace spotřeby na daném HW bude typicky vypadat tak, že optimalizujeme čas i za cenu na první pohled neefektivních věcí (jako dvojnásobný speedup za čtyrnásobnou spotřebu CPU) a budeme doufat, že jsme se optimu co nejlépe přiblížili.
Ano, budou výjimky. Může jít o různé tasky na pozadí, to ostatně naznačuje i ARM big.LITTLE.
12. 6. 2019, 00:31 editováno autorem komentáře