Google öppna för både AMD, Intel och ARM i serverhallen

Jaha

.

känns som denna artikel var lite konstig framför allt Rubriken men vad vet jag ;). borde de inte vara att Google väljer AMD nu för de är bäst, men kan tänka sig intel eller ARM om de är be bättre alternativet i framtiden.

Mjae, brukar bli så att datacenter låser sig in på det som är bäst/har bäst pris just fast i flera år.

Det här är ju bra då man inte låser ner sig i någon plattform och garanterar inkomst för Intel/Nvidia/ARM/AMD utan att de behöver anstränga sig, något Intel levt på väldigt länge.

Att o framtiden inte överväga alla alternativ vid inköp, oavsett bransch vore direkt tjänstefel i den verklighet jag lever i 🤔

Google nämner ju faktumet att man slipper konvertera något till ARM som en väldigt stor fördel om man läser själva pressreleasen. Men hur stor faktor är det egentligen i val av outsourcing av Scale-out applications? Känns som att @Yoshmans vishet behövs igen. *Tänder stora lyktan med en Yoshman-logo och riktar den mot natthimlen*

Vi går från hårdvaruinlåsningar till mjukvaruinlåsningar.
Med det menar jag att allt fler lösningar kan köra på vilken hårdvara som helst, men man använder sig av plattformens unika mjukvarulösningar. Vilket innebär att fast man hårdvarumässigt ej har låst sig till något så gör man det mjukvarumässigt. Så en lösning från Azure är ej alltid lätt att flytta till Googles, Amazon etc.
*edit*
Lite samma sak är det med Android/ios. Det är inga hårdvarumässiga konstigheter att få de båda att kunna köra varandras applikationer med riktigt bra prestanda och allt.
*edit*
Googlade det finns några emulatorer. De är ej populära och den stora anledningen är att behovet ej är stort, då det inte finns många plattformsunika måste ha appar på dem.

Absolut, rubriken kan sammanfattas som "Googles inköpsbeslut tas av proffs, inte fanboys"

Haha, exakt så.

Såg inte taggning p.g.a. @Yoshmans...

Fördelar med x86

Det är en fördel med x86 p.g.a. att Intel så länge varit totalt dominant inom den här typen av applikationer. "Ingen" kommer migrera till ARM64 om det inte finns ett par rejäla fördelar.

Oavsett vad man gör är det princip som att spel utvecklade med Unreal Engine eller Unity "borde" fungera på en lång rad OS. Ändå ser vi rätt ofta att titlar bara lanseras för Windows. Även om det likt de flesta skale-out applikationer är en rätt låg tröskel finns ändå en tröskel i form av primärt testning och hantering av buggar som bara "råkade" vara osynliga på andra plattformar.

Största problemet på serversidan m.a.p. ARM64 är Windows. Har inte riktigt förstått varför man skulle vilja köra Windows på en en server och än mindre varför man skulle vilja plåga sig själv att köra det i datacenter då det allt mer är synonymt med Kubernetes Docker/OCI-containers vilka båda är saker som bygger på Linux-specifik teknik.

AWS har kommet längre där, man använder numera ARM64 i alla deras system just för infrastruktur, de kallar den plattformen "Nitro". Nitro hanterar all deras nya system, oavsett om de kör Xeon, Epyc eller Graviton 2 baserade instanser. Microsoft verkar också börja i den änden, men har också nämnt att "tjänster" och kommer vara de som migreras först.

Fördelen med detta är att man som kund egentligen inte bryr sig om vad tjänster körs på, kvittar om de använder x86_64, ARM64 eller röksignaler. Enda som spelar roll är pris alt. pris/prestanda.

Porta till ARM64

Det skrivet: hur svårt det att migrera? Har själv väldigt svårt att se riktigt vad problemet är om man inte sitter väldigt hårt fast i Windows. Microsoft verkar jobba hårt på ARM64 nu, framförallt .NET-core fick rejäl prestanda boost under senaste året, man kan i.o.f.s. se glaset halvfult: om man kunde skruva upp prestanda allt från tiotals procent till heltalsfaktorer säger det en del om vilket tågvrak .NET var tidigare för ARM64. Det positiva är att ramverk som NodeJS, de flesta JVM:er, GCC/LLVM-baserade kompilatorer sedan flera år tillbaka har väldigt moget ARM64 stöd.

På förra jobbet fanns en helt utvecklingsplattform, kompilator, IDE, grundläggande bibliotek etc. som bara hade stöd för x86, dock både för Windows och Linux. Det handlade om åtskilliga miljontals rader kod, utvecklat i allt från C, C++, Python, Perl (horror), TCL (horror) och Java. Tog en utvecklare några dagar att få igång det på Linux/ARM64. Åter igen: även om det var lätt så var det faktiskt överhuvudtaget inte möjligt att köra på ARM64 innan någon gjorde ett jobb.

Jobbar med UE4 för tillfället, att utveckla på Windows/x86_64 för att sedan köra på t.ex. Android/ARM64 eller iOS/ARM64 fungerar riktigt bra förutsatt att man faktiskt testar målplattformarna. Har aldrig haft några problem att köra privata projekt på ARM, är mer jobb att gå mellan OS än att gå mellan CPU-arkitekturer på samma OS.

Lies, damn lies and benchmarks...

Sen angående det som står i artikeln: är det ingen som reagerar på att en Zen3 Epyc på något rimligt sätt skulle vara mer än 50 % snabbare än Cascade Lake Xeon? Själv kändes jämförelsen mot ARM64, som jag antog var Graviton 2 (vilket Googles eget dokument verifierade) väldigt "oväntad".

Ibland kan det vara bra att läsa vad som faktiskt jämförs... Google har dels annan definition av vCPU än AWS, man jämför system med 32 st vCPU vilket i praktiken betyder att Google kör 32 Epyc kärnor utan SMT mot 16 st Xeon kärnor med SMT, så totalt 32 trådar.

Vidare nämns att man såg oväntat hög ökning av SPECInt rate prestanda när man använde AMDs kompilator. Tycker SPEC är en riktigt bra benchmark. Vad man måste ha koll på där är att SPEC-årestanda är ett så viktigt beslutsunderlag att alla större tillverkare av servers tokoptimerar sina kompilatorer specifikt för SPEC. Har hänt åtskilliga gånger genom historien att man "knäck" en eller flera deltester i bemärkelsen: prestanda blir helt orimligt hög i just SPEC, något som inte alls återspeglas i "generell" prestanda.

Google skriver detta

"Note that we also tested with GCC using -O3, but we saw better performance with -Ofast on all machines tested. An interesting note is that while we saw a 56% estimated SPECrate®2017_int_base performance uplift on the t2d-standard-32 over the m6g.8xlarge when we used AMD's optimizing compiler, which could take advantage of the AMD architecture, we also saw a 25% performance uplift on the t2d-standard-32 over the m6g.8xlarge when using GCC 11.1 with the above flags for both machines.

Notera att om man kör med "-Ofast" så kan man få "oväntat" resultat (i många fall fungerar det ändå, men måste testas från fall till fall så är inte helt optimalt "default" val)
Dokumentation från clang/LLCV (AMDs kompilator är en fork av LLVM)
" -Ofast Enables all the optimizations from -O3 along with other aggressive optimizations that may
violate strict compliance with language standards."

Bl.a. Phoronix brukar testa olika kompilatorer mot varandra, när de ställer Intels kompilator mot GCC ser man inte i närheten av dessa skillnader. Intels kompilatorer brukar ge en viss boost i vissa applikationer, t.ex. de riktade mot HPC, men för många "vanliga" program skiljer det typiskt några enstaka procent och GCC vinner ungefär lika ofta som Intels kompilator.

Ovanpå är det rätt sällan, utanför just HPC, som någon faktiskt bygger om alla programvara. Ska man få vettiga SPEC siffror ska man göra precis det t.ex. AnandTech gör: använda samma kompilatorer för alla system!

Geekbench har också visat hur pass mycket kompilatorn kan påverka. Innan version 5 användes olika kompilatorer på Windows, MacOS och Linux. Att resultatet ofta blev Linux > MacOS > Windows hade långt mindre med skillnader i OS än skillnader i att Linux använde GCC, MacOS använde LLVM och Windows använder MSVC++. Nu är det långt mer jämförbar prestanda på samma system över system då man använder LLVM för alla OS i Geekbench 5 (GCC har ingen bra Windows port, LLVM har lysande stöd i Visual Studio och är standardkompilator för MacOS/iOS och Android).

Alla betalar inte listpris

Givet vad google säger kring att de är öppna för andra leverantörer och givet att de prissatt sina vCPU (som alltså är en fysisk x86_64 kärna, får känslan att man valt att stänga av SMT) rätt aggressivt mot AWS/Azure vCPU (som på x86 alltså är en CPU-tråd, det är en CPU-kärna på ARM då Graviton 2 inte har SMT) så låter det väldigt mycket som AMD använder Google som referenskund: d.v.s. Google har fått brutala rabatter här!

Även med kompilator-trick och omdefinition av vCPU är det inte direkt imponerande ställt mot Graviton. Man måste komma ihåg att Graviton 2 bygger på Neoverse N1 som lanserades våren 2019 och den har en TDP ~100 W (64 kärnor) medan AMDs/Intels modeller som används här ligger i spannet 250-280 W!.

Ovanpå det förväntas Graviton 3 börja rullas ut i december, det med 40-50 % bättre IPC mot Neoverse N1 (beror lite på om man väljer Neoverse N2 eller Neoverse V1, Neoverse V1 har upp mot 100 % högre IPC för specifika laster som machine-learning).

Den jämförelse som Google publicerat är ju dock ren marknadsföringsmaterial för deras molntjänst(!), inget ställningstagande gällande vilken CPU-arkitektur som är bäst/snabbast.
Vad de jämför i grafen är ju vilken av tre molntjänster (varav två från konkurrenter) som ger bäst pris/prestanda för en kund, och visar att GCP Tau förstås då är överlägset.
Ur det perspektivet är det ju inte egentligen något direkt problem tjänsterna är tekniskt olika, tydligen får man betala mer för motsvarande prestanda hos "ej nämnd molnleverantör X", vilket var själva poängen i den jämförelse som Google publicerat.

Som jag upplever det uppstår själva problemet när Swec-artikeln förskjuter perspektivet från en jämförelse av tre molntjänster till en jämförelse av tre CPUer.

Som vanligt en intressant inblick! Jäkla typiskt att min vilja att vara grammatiskt korrekt istället ballade ur taggningen...

För molnleverantören är det ju viktigt vad deras kunder vill ha, och för kund är det ju rätt ofta av stor vikt vilken arkitektur det är åtminstone vad gäller de rena VM-tjänsterna.

Så vad gäller valet mellan Intels och AMDs x86-64 håller jag med dig, där har de väl ganska så fria händer att välja det som passar bäst för tillfället. Men om man ser på t.ex. ARM64-baserade lösningar så blir det ju oundvikligen ett alternativ som kunder får ta ställning till.

Tror de har ganska bra data och A/B test på alla arbetslaster de redan kör åt kunder. Kan kunderna få det billigare utan märkbara skillnader så är det nog inga som klagar. Många laster som lambdas eller docker bryr sig ofta inte om underliggande arkitektur, framförallt java-baserade grejer. Eller att de driftar egna tjänster som klusterdatabaser på sådana servrar där kunderna betalar för användning och inte exekverar själva

Därav att jag sa "åtminstone vad gäller de rena VM-tjänsterna".

Ja, det finns ju en massa förädlade tjänster där de kan välja själva (och säkert också gör det), men jämförelsen som den här artikeln hänvisar till gällde ju pris/prestanda för Tau VM (Compute Engine) kontra VM-tjänster hos konkurrerande leverantörer (inga namn nämnda, men det var väl, föga överraskande, AWS och Azure baserat på det finstilta).

Självklart är Googles primära mål här att lyfta fram sin egen tjänst. Men det är mer än så, jämför hur t.ex. Amazon och Microsoft lyfter fram vilken CPU som faktiskt används. Att man använder EPYC är front-center i Googles fall medan Amazon och Microsoft knappt nämner vad man använder, där fokuserar på vad som erbjuds och till vilket pris.

Vad jag reagerar på är hur Google väljer att göra detta. Nog för att man sällan kan lita på benchmarks som lyfter fram tillverkarnas egen förträfflighet, men här känns det lite väl vinklat.

För att ta än fler saker: är ingen slump att man testar 32 vCPU, trots att man i sitt material trycker på att man erbjuder instanser upp till 64 kärnor. Basfrekvensen för den EPYC CPU man använder här är 2,5 GHz medan peak-frekvens är 3,6 GHz. Vilken frekvens som används i praktiken varierar med antal aktiva CPU-kärnor, något som inte är fallet för Graviton 2 (inte heller Ampere Altra som också använder Neoverse N1 fast är upp till 30 % högre klockade) utan där är frekvensen densamma oavsett last.

Google har lägre priser än AWS och Azure för de är en mycket mindre spelare, men man får det låta som man har bättre HW. Tycker personligen Oracle är något man bör sky som pesten, är lite som att sälja sig till djävulen att befatta sig med dem, men de råkar vara intressanta att titta på här då de också erbjuder 3:e generationen EPYC (sedan mars i år), Cascade Lake Xeon samt även Ampere Altra!

Tror ingen associerar Oracle med lågt pris, men som molnleverantör är de allt annat än en storspelare och deras priser är ännu lägre lägre än Googles (de måste ta marknadsandelar i ännu större utsträckning än Google). Så Googles

"The Tau virtual machines are the "best price-performance in the industry for scale-out applications,""

är i då en direkt lögn. De är definitivt billigare än AWS och Azure, men det är inte bästa pris i industrin.

För de enklaste A1 instanserna (vilket är deras Ampere Altra instanser) tar man överhuvudtaget inget betalt. AWS har liknande deal för de enklaste M6g instanserna (Graviton 2), inte helt fritt men man "får" ett par hundra CPU-timmar per månad.

Fast det är naturligtvis ren marknadsföring för ARM64, mer interessant är Oracles jämförelse mellan Ampere Altra, 3:e generationen Epyc samt Cascade Lake Xeon. Det ger en helt annan bild än Google och till skillnad från Google använder Oracle samma kompilator (GCC, vilken är den man använder för sin egen Linux-distron som erbjuds i deras moln) för alla tre system samt man kör "riktiga" applikationer.

I dessa siffror ser man också att Intel har ännu större frekvensspan, de är ju snabbast av alla när endast 2 vCPU används för att senare allt mer falla efter. Ampere Altra lider lite av att man bara har 32 MB L3$ för totalt 80 kärnor, det är en brutalt liten cache jämfört med framförallt EPYC. Det är i.o.f.s. något som blir trivialt att skruva upp i kommande generationer.

Klicka för mer information

Visa mer

Det hade inte varit Oracle om de haft en prissättning man faktisk begriper, och då är det inte lätt att fatta vad saker egentligen kommer kosta när man använder AWS/Azure/Google... (Enda man kan verkar kunna vara säker på att det blir dyrare än man tänkt...)

I någon mening borde motsvarande kostnad mot Googles "A 32vCPU VM with 128GB RAM will be priced at $1.3520 per hour for on-demand usage in us-central1" bli 32*0,01+0,0015*128 = $0,512 per timme, det för något som ger bättre prestanda om man använder riktigt stora instanser.

Ja, det är PR för Googles tjänst men tycker ändå SweC vinkling har en klar poäng för känns som Google inser att det är flera saker på ingång som kommer vara bättre än vad de, trots priskrig, just lanserat. Annars borde de överhuvudtaget inte sagt något om det.

Tycker även deras definition av övriga marknaden är rätt sned, man jämfört enbart mot AWS som är den självklara marknadsledaren och därmed har privilegiet att komma undan med högre priser.

Sen är det självklart vad jag skriver kraftigt färgat av min egen övertygelse här. Tycker det är så smärtsamt uppenbart hur tekniskt mycket bättre ARM64 är. Tror allt för många överskattar problematiken att byta ISA, även om man absolut kommer stöta på patrull om man sitter hårt fast i Windows-världen. Önskar därför företag som Ampere Computing allt framgång, lyckas de och andra som vågar släppa sargen och satsa på något lite mer modernt är jag övertygad det även kommer andra marknader till gagn.

Förhoppningsvis satsar allt fler också på RISC-V, för inte helt lyckat om Arm blir vår tids x86 på skrivbordet (även om det är en förbättring mot de två företag vi nu har som i praktiken kan erbjuda high-end x86)...

Om jag skulle läsa in något i att de tydligt påpekar att deras tjänst är baserat på "3rd Gen AMD EPYC" så är min förmodan att det kan ha varit en del av prissättningen när de köpte dessa AMD-prylar.

Jag upplevde snarare att Swecs vinkling om något var ett resultat av att helt okritiskt gå i "fällan", istället för att faktiskt läsa vad det står i jämförelsen.
Dvs, att Google jämfört pris/prestanda på sin molntjänst med konkurrerande molntjänster. Ingen jämförelse av hårdvara.

Det kan mycket väl stämma, jag ifrågasätter mest att artikeln verkade tolka detta som en jämförelse av hårdvara. På den punkten anser jag att det var ett lätt naivt misstag av Swec att svälja betet.
Du har säkert helt rätt i att det finns brister även gällande jämförelsen med andra molntjänster, det känns dock som en separat fråga som jag väljer att inte blanda mig i.

Min känsla är iaf att detta är resultatet av att Google går AMD till mötes genom att de när de i sitt marknadsföringsmaterial gör en jämförelse av molntjänster där de själva förstås vinner (det är ju helt väntat, oavsett vilken leverantör som gör detta) då samtidigt belyser att de använder AMDs senaste CPUer (utan att faktiskt säga något om hur dessa presterar jämfört med något annat).