Vlákno názorů k článku
Ovladač pro Intel Software Defined Silicon bude v Linuxu 6.2
od mad - Servery a serverova cpu maj zivotnost 3-5 let,...
-
Servery a serverova cpu maj zivotnost 3-5 let, prumer spis ke trem. TCO je cim dal vic dane energetickou ucinnosti, a ceny energii jeste stoupaji. V dobe kdy se virtualizace posouva ke kontejnerum a horizontalnimu skalovani, a v serverovem bussiness nastupuje uz treti arm64 generace s vyrazne lepsi energetickou ucinnosti nez amd64, nastupuje opensource risc hw, firmy typu amazon si srv farmy na arm64 sami vyviji, Intel zkousi tuhle ekonomickou revoluci v prodeji/pronajmu hw ?
Licence na feature sety amd64 cpu pusobi jako ten uplne posledni hrebik do rakve intelu. Jakoze bez licence to zere a topi stejne ale nektere veci pocita jeste pomaleji ? WTF ?
-
Každá hvězda jednou spadne... Otázkou je kdy. :)) Každopádně jak Intel fungoval a funguje, tak přes ty prsty měl někdo fláknout už dávno, v tomto případě jejich pícha je jejich pád.
Další na řadě je Nvidia....A co si budem nalhávat, můžu nastat situace, kdy ARM jednoho dne nahradí celý AMD64, který je víceméně prošpikovaný chaosem certifikací...
-
Jako souhlasím, že tohle je divná věc, ale ta argumentace ..
"virtualizace posouva ke kontejnerum a horizontalnimu skalovani"
Vždyť to jsou tři úplně odlišné a navzájem těžko zaměnitelné věci.
"vyrazne lepsi energetickou ucinnosti nez amd64"
Už předchozí 64 core EPYCy maj TDP 3-4 W na jádro. To není vůbec zlý a docela bych si vsadil, že výkon na W bude pořád lepší než u Gravitonu 2.
-
Ta zivotnost je ako kde ale urcite vseobecne nieje blizsie k 3 rokom. Praveze sa viacje predlzuje.
Pri velkych firmach je dost dlha. Ked sa pozriem na com mi bezi moja instancia na AWS, tak ta zivotnost je uplne niekde inde.
ARM je pekna vec ale x86 ma stale velky podiel. A ako uz napisal kolega predomnou, tak ani s tou energ. efektivitou to nieje take ruzove.
Velke firmy si vlastne CPU vyvijaju hlavne z toho dovdu, ze je to pre nich financne zaujimave. Nie, zeby stavajuce CPU od AMD a Intelu boli zle.
Jendoducho sa im to oplati.
Na risc HW si este pockame. -
x86-64 má stále velký podíl jenom ze setrvačnosti.
V cloud se to změní poměrně rychle, neboť většina dnešního SW běží na VM jazycích nebo open-source, který je už na aarch64 kompilovaný. Obě možnosti relativně snadno portovatelné (i když jiný memory model některým méně důsledným programátorům vrásky nadělat může).
Na firemním hardware to bude ještě chvilku trvat, bo výrobci prostě nejsou. A navíc jeho množství je relativně malé, aby podíl energie měla na TCO z hlediska všech nákladů firmy dostatečný vliv, aby se tím někdo zabýval.
Cloud firmy mají vlastní CPU, protože jsou drasticky efektivnější ohledně výrobních nákladů i spotřeby. AWS tvrdí, že performance-per-watt je o 60% vyšší než u x86-64 - to už docela stojí za to, ne?
-
Těch 60 % je ale na jejich službách, kde to mohou optimalizovat z obou stran. S výkonem v reálném světě, tedy že to CPU vezmu, strčím ho do datacentra a nasadím na něj náš stack, to podle mě moc společného nemá.
S těmi open source projekty a podporou ARM to není tak horký jak by se mohlo zdát. Kromě toho, že mimo AWSko není dostupný pořádný hardware, tak stačí jeden projekt, který není podporovaný nebo dostatečně optimalizovaný a je to stopka pro celý stack. Tohle potrvá ještě dlouho.
-
Služba je jenom SW, který běží na HW. Nejsou zásadní rozdíly mezi specifickými AWS servisy a běžným aplikačním SW, kteří píšou ostatní. Samozřejmě, storage oriented budou extrémně závislé na výkonu IO, něco na paměti apod., ale jinak je to obecný HW.
Ohledně podpory - viz výše - drtivá většina aplikací je dneska v různých VM (obvykle JVM, běžně Python), u kterých JIT už danou architekturu podporuje a ty mají poměrně malé závislosti na pár knihovnách, které vyžadují speciální optimalizaci a ta je typicky už dokončena. Určitě existují knihovny pro multimedia, data science, machine learning apod., ale těch, které nejsou portované dostatečně efektivně bude minimum a jejich využití ještě menší. Tipnul bych si, že nejvíc pozadu můžou být multimédia, ale to je celkově nezajímavé. Případně místo "není to tak horké jak by se mohlo zdát" prosím protipříklad.
Stopka pro celý stack to rozhodně není, typicky běží části aplikace stejně na různých konfiguracích.
-
Je to docela zásadní rozdíl, když můžu ovlivňovat vývoj jak SW tak HW a když optimalizuju kód na pár vybraných sestav a ne na všechny.
Na co mám dát protipříklad, když si žádný nedal? Já třeba hodně používám Bitnami, protože maj moc pěkně udělané helm charty a mám taky na stole 6x RPi4 ARM64 Kubernetes cluster. Bitnami má ARM64 podporu jen pro base image, ale většina aplikací podporu nemá, takže na tom clusteru dělám spoustu věcí ručně, i když bych na amd64 nemusel. To se mi fakt nevyplatí.
Compute nody zpravidla běží na jednom typu hardwaru. Nedokážu si představit v žádném projektu, na kterém jsem pracoval, že budeme míchat ARM64 s amd64 na fyzickém hardwaru a to i kdyby takový HW byl dostupný. Na tom AWSku to jde krásně, ale pokud mám na jednu mašinu tisíce kontejnerů nebo stovky VMek, tak hodit do toho vidle druhou architekturou je škálovací peklo. Dokážu si představit, že to jde třeba u projektů orientovaných na storage, ale ani tam se to nevyplatí, protože toho výkonu zpravidla není potřeba nějak moc a CPU bude marginální položka na účtu. Pipeline pro druhou architekturu už nikoli.
-
Ten kód je generický a předtím stejně dobře běžel na x86-64 jako teď na aarch64. A těch typů servisů je tolik a tak rozmanitých, že o nějaké optimalizaci HW na SW nemůže být řeč. Opravdu nemají na každý typ service jinou architekturu, liší se pouze v nastavení IO, množství paměti a procesorů (zjednodušeně).
Protipříklad může být ten Bitnami. To je ale jenom package manager, samotný SW to podporuje. To, že nemají podporu pro aplikace, ale jenom base image, je trochu zvláštní, ale jejich politiku neznám. Většina lidí asi spíš použije standardní distribuci, nainstaluje java a pár balíků, na kterých závisí, hodí do nějakého containeru a tím to končí.
Compute nody - ano, když je hardware už daný, tak se použije. Já mluvil o situaci, kdy se nahrazuje - ať už lokálním upgradem nebo v cloud, kde to jde lusknutím prstu. Na desítkách CPU to nemusí mít smysl, jakkoliv ten přechod může být bezbolestný.
-
koukám, že tady máme nový termín VM jazyk a ještě do toho zařadíš python, víš vůbec o čem píšeš?
ARM zatím nefunguje, ať už doma (ve svým DC, ne v obyváku) nebo v cloudu, lze nad tím provozovat pouze specifické optimalizované služby. Python je zrovna chybný příklad, to je jazyk, který na arm dělá naprosto nejvíce problémů ze všech mainstream jazyků, že ty to z praxe asi moc neznáš?
Ono i JVM dělá problémy, kódy nejsou optimalizované na lineární škálování a vše (např. snad veškeré Apache projekty) spíše jede na vertikálním, to jde proti myšlence ARMu.
RISC se ukazuje jako zajímavý problém v chápání jak psát SW, záměna 1:1 zatím nelze, výkon per watt klesá bez dodatečných optimalizací.
-
Python není VM, v aspektu interpretace kódu?
Ke zbytku - zjevně je dost zdrojů, které ukazují, že aarch64 exceluje téměř všude, včetně článků a videí přímo na AWS, testech Phoronix a Apple M1, který drtí původní x86-64 i s překládaným kódem z x86-64 do aarch64 (a s dramaticky nižší spotřebou). A viděl jsem osobně dost projektů přemigrovaných na aarch64, přechod bezproblémový, výsledkem byl typicky vyšší výkon na podobné konfiguraci a měly i závislosti na Apache projektech (nasazení na 8-64 CPU serverech ve stovkách instancí). Takže prosím citace pro ty tvrzení.
Jak uvádí Kate níže, i mimo cloud už existují servery, i když ne tak rožšířené. Dokonce i druhý nejrychlejší superpočítač je aarch64.
-
Mě by zajímaly nějaké detaily k "dost projektů přemigrovaných na aarch64".
Já jsem třeba teď na velkém ecommerce projektu, kde je nějakých 50 služeb napsaných v Go a PHP. Dokážu si představit, že začneme migrovat. Nedokážu si ale představit, co by to v současné chvíli přineslo pozitivního. Tooling kolem ARM fakt není stejně dobrý jako u x86.
Museli bychom:
* Zmixovat dvě architektury v kubernetes clusteru
* Kvůli tomu upravit TerraForm u všech projektů, aby se náhodou x86 kód nedostal na ARM node a obráceně
* To samé vyřešit u všech služeb, co nejsou naše
* Připravit build servery pro CI
* Dělat druhou sadu testů pro novou architekturu
* Strávit spoustu času, abychom zjistili, jestli to jede alespoň stejně a pokud ne, tak strávit hromadu času fixovánímA teď ta sranda - vývojáři musí vyvíjet pro architekturu, která není stejná jako jejich lokální hardware. Na Macu to možná fungovat bude, ale já třeba Mac nepoužívám a nechci ho. Na Linuxu najednou musím složitě debugovat v nějakém pomalém VMku nebo přes remote debugger.
Připomínáš mi lidi, co si myslí, že když se aplikace přepíše pod Lambdu, že najednou zmizí všechny problémy a bude to desetkrát levnější. Nevidí ale, že to prakticky zruší možnost debugovat problémy nebo dokonce si rozjet celý stack lokálně.
-
Migrace: e-commerce platforma, v rámci nejbližších týmů desítky microservisů, každý z nich na stovkách+ instancí.
* Microservisy běží nezávisle, takže i celý upgrade a deployment byl nezávislý na ostatních.
* TerraForm (nebo cokoliv) je stejně template-ovaný, ne? V době migrace se ostatně musí build-ovat pro obě platformy.
* Služby, co nejsou naše mě nezajímají, protože bod 1...?
* Druhá sada testů - testy zůstávají stejné pro všechny platformy...? Nebo jde o CI setup?
* Ano, ověření je vždycky potřeba. Ale to předpokládám dělají unit, integrační a performance testy v CI/CD pipeline...?Vyvíjeli jsme nadále na hardware, co jsme měli - aplikační kód je typicky platformově nezávislý a finální ověření probíhá na cílové platformě v rámci CI/CD. To je v zásadě "problém" bez ohledu na migraci - lidi používají Linux, Mac, Windows, x86-64, aarch64, ...
Lambda jsme debugovali lokálně taky. Ale souhlasím, že to není ono - radši kód rozdělujeme do business kódu a wrapper, který může být Lambda nebo klasický lokální servlet (případně vyměnitelné či přesměrovatelné messaging endpoints, či cokoliv, co je aplikovatelné pro danou službu).
Viz dříve - jsou situace, kdy je na to ten projekt připravený a migrace je téměř zadarmo, a naopak situace, kdy to vyžaduje velké úsilí, ať už kvůli omezením projektu samotného nebo závislostem a zvláště u menších věcí se to úsilí nemusí vyplatit. Ale vyjímečně jsou ta omezení kvůli existujícímu software nebo nástrojům.
-
KateStříbrný podporovatel
> mimo AWSko není dostupný pořádný hardware
Co Ampere Altra? Servery s tím nabízí třeba Hetzner.
-
KateStříbrný podporovatel
Musím přiznat že nebýt ceny, ty Ampere Altra workstations jsou hodně lákavé. :)
