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).