Vlákno názorů k článku
Google oznámil procesory Axion s architekturou ARM pro cloudové služby
od Pan Kachna - A co se třeba soustředit na optimalizaci kódu...
-
To je sice dobrá otázka, nicméně úplně vykloubený přístup.
Vám se zdá normální vytvářet stále výkonější CPU protože jsou programy špatně vytvořené?
Například u aut se spotřeba řeší a zamýšlíme se při růstu 0,2L/100km a u programu, který má ekvivalent spotřeby 100L/100km to neřeší ani při 1000L/100km. -
Před 12 lety jsem měl na tohle téma diskusi s mym nadřízenym v tehdejší práci. Já jsem zastával názor, že by se měly psát optimalizované aplikace a ideálně v nativnim kódu. Ale dnes to vidim jinak a smym exbosem souhlasim. Jeho pohled byl/je ten, že psaní v nativnim kódu znamená horší přenositelnost a složitější vývoj, zatimco JS aplikaci v Reactu dneska splácá kde kdo a kromě webu to může s malym úsilím poslat i do Google Play.
Nechci tvrdit, že JS/React(/Native) je ideální. Pointa je, že bez téhle a podobných technologií by spousta sw nevzniklo, případně by uměly polovinu věcí, než které dneska umí.
-
Přesně. Je to přesně tak. I když ne přímo tak, že "aplikaci v Reactu dnes splácá kde kdo" -- ono jednou věcí je něco "splácat" a druhou věcí je vyrobit to tak, aby to bylo udržitelné a spravovatelné a zrovna v JS si špatný vývojář velmi snadno vyrobí podstatně větší peklo než třeba v C# a zvlášť v Reactu, který je past vedle pasti v podstatě by design. (Btw, něco v něm píšu denně roky a myslím si to čím více ho znám; to kdyby mě chtěl náhodou někdo napadnou pro zaujatost.)
-
Tak a tento přístup mi připomíná ty studenty co na koleji těžili crypto, protože elektřinu platil někdo jiný. To se to vyvíjí, když tu spotřebu zaplatí uživatel!
A tady jde právě vidět ten rozdíl v cloudu. Pokud si platíš za železo, tak chceš aby to zvládlo co nejvíc věcí a nejednou to, že je něco pomalé už je velký problém a na optimalizace se ten budget najednou najde! A v případě firem jako je Google, MS, atd.. které mají v podstatě miliony serverů, tak tam se neefektivita kódu projeví celkem rychle a počítá se třeba v desitkách milionů dolarů měsíčně, možná i stovkách, když jde o něco zásadního.
A teď k těm cloud providerům. 60% úspora může znamenat obrovskou konkurenční výhodu, rozhodně to není něco co bych podceňoval.
-
cituji ze zprávičky
až o 50 % vyšším výkonem a až o 60 % vyšší energetickou účinností než srovnatelné instance současné generace založené na platformě x86.
Tady očividně energetická efektivita byl jeden z hlavních důvodů.
Odkud bereš informaci, že jsou programy špatně vytvořené a potřebují kvůli tomu čím dál více výkonu?
Naopak na straně serverů v posledních letech se databáze právě zaměřují na čím dál lepší výkony, máme tady vektorové multi instrukce instrukce, začínají se používat i 512 bitové, máme tady v Linuxu nové api io_uring pro levnějšímu přístup na disky, máme tady nativní instrukce pro kompresy dat v paměti, aby se ušetřila paměť.
-
radekmStříbrný podporovatel
> Odkud bereš informaci, že jsou programy špatně vytvořené a potřebují kvůli tomu čím dál více výkonu?
Srovnáním s jinými programy. Třeba když mám dva podobné programy, co dělají podobné věci a jeden používá více paměti a cpu než druhý, tak mi přijde špatně napsaný.
Nebo třeba, když jeden program dělá mnohem víc než druhý, ale používá více paměti a cpu. Což je třeba případ mnohých webových stránek. Zobrazují jen statický obsah, ale paměti a cpu spotřebují jako nějaká hra, která 60 krát za s překreslí celou scénu.
-
to je asi dost povrchní porovnání. Někdy program bere víc paměti, protože prostě může a ne, že musí. Až paměť začne docházet, začne si jí interně čistit, typický příklad jazyků s dynamickou alokací paměti a ukládáním objektů na heapu.
A ano, optimalizace spotřeby paměti stojí čas a úsilí, často při to i znamená vyšší nároky na CPU či síť.
Webové stránky a javascript to je úplně něco jiného. Jestli si projdeš běžnou webovou stránku, zjistíš, že dnes naprosto podstatné množství paměti a zdrojů berou reklamy, přednačítají se dopředu do paměti, přehrávají se videa, trackuje se každý pohyb myší a stisk klávesnice.
-
SinuhetStříbrný podporovatel
Já tento pohled sdílím. Když si vezmu MS Teams, to je takový do očí bijící příklad, tak podobnou funkcionalitu zvládal kdysi třeba Skype, a potřeboval k tomu 30 MB paměti. A i ten mi přišel docela rozežraný třeba proti ICQ.
Právě teď mi MS Teams žere 470 MB paměti, a to jsem ho vůbec nepoužil, protože mi nezobrazuje chatovací okna (chyba); a používám tak druhou instanci ve webovém prohlížeči. A nemám pocit, že by byl zrovna desetkrát schopnější než ten Skype.Ale čert vem paměť, ta je levná a je jí dost. Horší je, že ty Teams jsou subjektivně na novém HW pomalejší než tehdy Skype na Pentium IV.
Za mě je to důsledek toho, že zatímco paměť a procesorový čas jsou levné, zvlášť ty uživatelské, lidi jsou drazí. Optimalizace databází a dalšího otevřeného softwaru často dělají firmy, které platí i ten výpočetní výkon, a vyplatí se jim zaměstnat nějaké lidi, než dokupovat další hardware. To je něco, co je pro uživatele MS Teams nesmyslné, i kdyby to šlo. A používat je budeme, i kdyby byly ještě dvakrát tak náročné. Akorát bychom víc prskali.
-
Nj. ale on se s tím zvyšuje i využitý výkon, poptávka po DC roste, protože roste počet aplikací a jejich potřeby na výpočty/data.
Není to dávno, když jsme měli poloprázdné racky, protože jsme přešvihli 10kW na rack nebo jsme se dostali na hranici sálu (cca 400 - 700 kW). Dneska už běžně máme rack 100 % plný a to ikdyž se bavíme o výpočetních clusterech s GPU. Prostě se toho tam vejde víc.
První 1PB cluster, který jsem dělal byl rozmístěn do 8 racků (to je přes 300 úček!), dnes to dám do půlky racku (cca 20 úček), celkova spotřeba je dokonce ještě poměrově lepší, 1/20 proti stavu před 15 lety.
Proč by se DC zmenšovalo, když je poptávka? To nedává smysl. Ikdyž už mám postavený sál na 500 kW nedává smysl tam mít 200 kW a prázdné uličky.
-
Podle mě si hodně lidí ani nedokáže představit v jakém rozsahu se cloud používá. Poptávka po cloudu roste, hlavně různé úložiště a na to navázané služby. Úspora třeba 50% znamená pro toho providera mnohem víc zákazníku na to dané data centrum, takže i mnohem víc peněz a samozřejmě konkurenční výhodu, pokud může nabídnout levnější služby - a tady se nemusí jednat o desítky procent, i jen 5% levnější než konkurence může pro nějakou firmu znamenat obrovskou úsporu.
Já jsem se už setkal v práci s obrovským storage nad 100 PB a věřím tomu, že za pár let bude storage v jednotkách EB taky celkem běžná záležitost. Já se teď setkávám i s tím, že cena za zpracování takového 100 PB datasetu se taky může vyšplnat celkem vysoko a začíná to být problém. Na druhou stranu ty data prostě rostou a porostou i dál.
-
radekmStříbrný podporovatel
Někdy i levnější. Někdy se to stejně musí zoptimalizovat, protože je to v praxi nepoužitelné, a zoptimalizovat nějaký slepenec může být mnohem složitější.
-
vyšší.
Ono to není z mého pohledu lepením kódu, ale tím, že to prostě neřešíš, používáš jazyky, kteří si sami řeší správu paměti a nedělají to příliš efektivně.
Reálně dnes řeším problémy, kdy máme čímdál více dat, nad kterými se dělá analytika, tady pak je těžké rozhodování, napsat algoritmus na PCA nebo median, který bere málo paměti zase znamená často násobě prodloužit čas výpočtu.
Parsování obrovských xml/json exportů je opět těžké dělat s malou spotřebou paměti.
BGP tabulky se nám už to běžných pamětí hraničních routerů nevejdou, takže se musí věnovat tomu je nějak osekat.
Transkódovat 4K video streamy z bezpečnostních kamer není vůbec žádná hitparáda, když nemáš dost paměti, taháš to zejména pamětí, aby to šlo dělat realtime, to i v případě, kdy si k tomu pořídíš GPU.
A nakonec za mě asi největší důvod, kašle se na to. Před 20 lety, kdy začal valgrind, byli jsme z toho unešení, daleko jednodušší ladění než psaní probů v dtrace, najednou člověk měl přehled a viděl. Dneska, když se v týmu zeptám, co to je valgrind, je ticho. Memory profilling či zadání na spotřebu paměti/cpu člověk jen tak nevidí a honí se vše přes lepší HW.
-
nargStříbrný podporovatel
> Memory profilling či zadání na spotřebu paměti/cpu člověk jen tak nevidí a honí se vše přes lepší HW.
Mno, tenhle aspekt vývoje má dvě věci:
- napsat dobře optimalizovaný a zároveň (pro každého) čitelný kód se mnohdy vylučuje
- hardware je levnější než pár MD člověka který to umí, chce to dělat a baví ho to -
KateStříbrný podporovatel
Přijde mi, že zrovna tyhle ARM platformy naopak dost vybízí k efektivnímu kódu. Sice to má obří počet jader s nízkou spotřebou, ale výkon jednoho jádra není v porovnání třeba s Epyc nic moc.
