Jestli to zdražení povede k tomu, že vývojáři OS a SW budou vytvářet méně rozežrané aplikace, tak je to pro většinu lidí win situace. I přes to, že to v kruzích hi-tech nadšenců může vypadat jako apokalypsa.
Spíš to ale bude jen drobné (byť i několikaleté) zhoupnutí na další cestě k orgiím marnotratnosti, neb nastavení skromnosti je třeba mít hlouběji v duši, než kam dosáhnou aktuální cenovky komponent.
Viac menej suhlasim, ze u vyvojarov moc netlacia na oprimalizaciu. Nasledujucu cast textu nebude mierena ako vyvracanie komentara, ale len akasi doplnujuce info, u ktoreho sa povie aj to B.
SW mozes napisat dvoma sposobmi ( polmi) :
A.) Setri sa co na co najviac zaplnenia RAM. Avsak na ukor vacsej zataze IO a CPU. To co si odlozi ba neskorsie pouzitie sa zahodi , a ked potrebuje v buducnu musi si to znova pripravit. Mnohe data si moze vypocitat za pomoci podmienok a vzorcov na zaklade vstupov. Coz viacej CPU.
B.) Setri sa IO a CPU ale na ukor zaplnenie RAM. Nerobi garbage na vsetky data, nehava si ich v RAM, pre buduce pouzitie, nemusi si to neustale pripravovat - zahadzovat. Namiesto toho aby pocital pomocou logicko matematickych operacii, da nacitaju rederencne data, ktore kezia v RAM a nasledne sa len matematicky spresnuju vyspetup, setri sa CPU.
Takze setrenie RAM nemusi nutne znamenat WIN situaciu. Ak SW je uz vyrazne optimalizovany na model B, tak uprava kodu blizsie ku modelu A, znamena vyssiu zataz CPU a IO.
Ak je aplikacia neoptimalizovana, tam to je uz ina vec. Je tam priestor ku zlepseniu. V opacnom pripade mas situaciu nieco za nieco.
Hmm, imho něco jiného je, když potřebujete zpracovat velké množství dat, které je velké proto, že prostě být menší nemůže. To jsou např. multimédia, žeano.
A něco jiného je, když máte např. relativně jednoduchý nástroj na zjištění SMART informací z SSD, provedení Secure Erase apod. a zjistíte, že ta 200+MB komprimovaná instalačka si s sebou táhne vlastní Javu a Chromajzlovitej prohlížeč. Tomu já říkám plýtvání místem a výpočetními prostředky. Jen proto, že byl někdo extrémně línej to udělat daleko efektivněji.
Tak jestli se zlepší tohle, budu rád, ale osobně bych si na to nevsadil ani zlomený eurocent.
Pre priklad aj jednoduchy sinus, kosinus mozte realizovat numerickym vypoctom ( rozkladom na taylorov rad ) : setris RAM ale nie CPU. Alebo mas tabulku referencnych hodnot prcitas udaj najblizsie dole a hore a spriemerujes. Setri CPU ale nie RAM. Cize ide o koncept, ktore maju rozne podoby.
Dalsia tema je rychlost vyvoja a nasledne aj naklady. Kde sa vyuzivaju rozne vrstvy abstrakcie, frameworky kde sa vyvoj lahsie vyvija, udrzuje. A tu je to tiez, nieco za nieco.
Samozrejme ze existuju aplikacie ktore moc neoptimalizuju. A potom to tak vyzera. Ale to nic nemeni na tom, mame aj vyvojarov , ktory maju optinalizovany SW a tak to je uz nieco za nieco.
A něco jiného je, když máte např. relativně jednoduchý nástroj
Na tohle se dá odpovědět poměrně jednoduše. Kde je poptávka je i nabídka. Proč někdo používá místo smartctl a hdparm nástroj, který potřebuje JRE a Chrome mi zůstane záhadou, ale asi není záhadou pro tvůrce podobných programů, když je po nich poptávka. ;-) :-D
RAM nebo CPU je takový školní everygreen.
Jenže kromě A i B je tady ještě celá abeceda postupů a opatření, která mohou šetřit jak CPU tak RAM i disk, i přenosové linky, ....
Někdy mi přijde, že už jedeme v několikáté iteraci "stroje ve stroji".
Jako tihle s Minecraftem v Minecraftu:
https://youtu.be/-BP7DhHTU-I?t=90
Je to pěkná hříčka a klobouk dolů, ale hlavně nás to, naštěstí, nenutí to hrát.
Což se o různých Discord/Slack/... věcech říci nedá.
Takže jsme kruhem zpět. Když to ty lidi bude víc zajímat, protože budou mít slabší stroje, tak bude i poptávka po optimálnějších řešeních.
Ve skutečnosti si myslím, že tenhle uzel je třeba sekat na více místech. Často lidi "nadávají" že je něco pomalé, ale málokdy tento hlas dolehne až k do kanceláří, kde se šikulové Maléhoměkkého domlouvají v s prodejci HW, co udělají, aby vydělali na nové jachty svým managerům. (* malá chvilka konspirace *)