Názory k článku
Google oznámil procesory Axion s architekturou ARM pro cloudové služby
-
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.
-
Se me uplne teda nelibi trend, ze si kazdy velky provider dela svoje kremiky - to vypovida jedine o stavu trhu, kde neni konkurence. Takze tu mame Google, Amazon, Microsoft .. a vsichni ostatni co musi pouzivat konkurence neschopny komoditni hw od Intelu ci AMD.
A to vse jen v duchu toho, ze vse musi byt sluzba, ktera se da hlavne zpenezit opakovanymi platbami.
Jsem zvedavej kdy prestanou vyrabet toaletak.. aby se dala udat sluzba vytiracu na subscription :D
-
Nj. je taková doba, donedávna všichni používali Ampere (mimochodem ten si může koupit kdokoliv pokud nechce x86), pak se trhl MS se svým Cobalt a AI klonem, teď zase Google. AWS je v tom už dlouho, Oracle zatím jede na Ampere. Ale neboj, i náš Seznam si chce dělat vlastní.
Naštěstí si všichni kupují základ od ARMu, takže instrukční sady jsou vesměs kompatibilní, jediný, kdo se utrhl je Apple, ale ten naštěstí už nedělá servery.
-
Apple M3 je zpětně kompatibilní s původním Cortex-A7x, pokud vím. Má pár věcí navíc - volitelný TSO model kvůli podpoře x86 a pár speciálních instrukcí, částečně kvůli JS, částečně x86.
ABI může být skutečně jiné (rozdíly na https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms ), nicméně stejně Linux binaries budou mít jiné knihovny, takže je to celkem jedno. Tedy, až na zbytečnou práci pro vývojáře kompilátoru, ten původní standard je rozumný a nebyl důvod ho nepoužít.
-
Tak Asashi linux je fakt hloupej příklad, protože aby vůbec fungoval tak se víceméně psal od začátku a jakýkoliv nové linuxové jádro se musí upravovat a nedostaneš všechna jádra....
Asashi linux se hlavně ladil a psal dost dlouhou dobu....
O tom, že se AMD utrhl s tímto slyším poprvé.. protože takhle jede už dlouuuhou dobu.... takže senzace opět z ničeho... -
Praveze tu je konkurencia(ak sa bavime CPU).
Ti velky provdieri su taky velky, ze sa im oplati vyvijat vlastny HW vratane CPU.
To zaroven vytvara konkurenciu aj pre tradicnych vyrobcov ako AMD/Intel.Komoditny HW nieje konkurencne neschopny HW. Tu ide aj o to, ze sa im to aj financne oplati a aj z pohladu nezavilosti je to pre nich zaujimave.
Aj v inych segmentoch, ked firma rastie, tak si postupne sama vyraba/supportuje veci namiesto toho aby ich outsorucovala. Hlavny motiv je, ze sa im to oplati a vedia si to lepsie zoptimalizovat pre svoje potreby.
To presne sa deje v tomto pripade.Google je velky, vie co potrebuje, tak si navrhol CPU podla svojich potrieb.
Subscription je uz ina tema a ten ma vela firiem be zohladu na velkost.
Keby si bol SW firma, tak to robis tak isto.
Ako by si si chcel zabezecit prijem? Pri jednorazovom predaji licencie musis ziskavat vzdy novych klientov/zakaznikov pricom vyvoj aplikacie nekonci vydanim produkcnej verzie.
Aj predym sa platil subscription/support ale bol tam rozdiel, ze nie kazdy si ho musel platit.
Kupil si si verziu a ak si nepotreboval support, tak si si ho neplatil. Ti, co si ho platili, tak dotovali tych, co si ho neplatili aby SW firma mala peniaze na dalsi vyvoj.Ono to ma (pre mna) jednu vyhodu. V minulosti, ked som potreboval nejaky SW jednorazovo, tak smola alebo hladat craknutu verziu. Dnes si ho viem predplatit na potrebnu dobu.
-
Interni uzavreny "bastl", bude samozrejme vzdy levnejsi - jednak google nemusi platit team pro psani verejne varianty dokumentace (stejnym zpusobem setri i cinani na svych SoC), a pak nemusi krmit obri team na verejny support - na tohle uz prechazi znacna rada spolecnosti, ze kdyz nejsi velky zakaznik, tak f*ck off, nebavime se s tebou.
Tim subscription jsem myslel v tomto pripade SaaS - u googlu si nemuzu koupit jejich hw jednorazove a provozovat pak sve veci uz dedikovane (a la vps), vzdy ti vnuti nejaky druh cloudove instance a pokud nemas dostatecnou abstrakci, tak tam proste svoji sluzbu nedas. Neni to uz nativni zelezo bohuzel..
Je to rozdil jako vlastnit klasicke auto nebo jezdit elektro taxikem. Ano, vetsina lidi by prezila s moznosti vyuzivat ten taxik.. ale ten trh se serverama pak vypada, ze elektricky auto si nekoupite. Muzete si ho uzit jen ve forme taxiku. Coz je to, co me vadi.
-
Nechapem tvoje rozhorcenie.
Vyrabaju to pre svoje potreby/pre svoj usecase, tak preco by mali nieco zverejnovat a riesit s tebou.
Ten HW nebol stavany na to aby si si ho vedel kupit, pouzivat svoje sluzby priamo na tom zeleze. Na to mas na trhu iny HW a vyrabat taky HW by sa im tak neoplatilo. Preto nechapem tvoju nespokojnost.Ten priklad s tymi autami je zly. Oni nevymysleli iny typ auta ale upravili si existujucu koncepciu auta pre svoje specificke potreby(taxi). Vyhodili pre tento ucel nepotrebne veci, pridali/zamenili/zoptimalizovali specificke veci pre dane pouzitie.
Vyrobili taxi, ktore nieje homolgizovane na ine pouzitie/na bezne pouzivanie. Preto si ho vies uzit len vo forme taxi.
Nic nenormalne/nemoralne/.../nieco nad cim by si sa mal rozhorcovat. -
pokud lijí peníze do vlastního HW, který je jen pro ně, nelijí je do dodavatele, který může dodávat celému trhu. Vytváří tím bariéru, snižují nabídku na trhu a uvazují si tím zákazníky, kteří nemohou snadno přejít jinám.
Celkové náklady na vývoj arm CPU přes více těhle megaspolečností mohou být pak vyšší, zejména pokud těch společností s vlastním HW bude více. To ekonomice snižuje přidanou hodnotu.
Na druhou stranu se tím akceleruje vznik odborníků a je takhle možné vyškolit více lidí s dostatečnými zkušenostmi na návrh CPU. Diverzifikuje se riziko zranitelností.
Eliminace konkurence je ale už vidět teď, když člověk přejde na arm a upraví si svoji architekturu, najednou si uzavře dveře před spoustou menších cloud poskytovatelé. Pokud Ampere tímhle příjde o většinu zakázek, dostupnost armu na servovém trhu se může výrazně snižít.
-
Podle mě to je v pořádku a konkurence je potřeba.
Google nevyvynul novou architekturu, ale jen micro-architekturu. To znamená, že SW zkompilovaný pro AArch64 tam poběží tak jak třeba na Apple HW. Na druhou stranu protože znají ten use case tak ta micro-architektura může být optimalizovaná pro typický cloud workload. Což pro každého může být něco jíného a třeba se najsou oblasti, kde se to nevyplatí.
