Testresultat från Nvidias Arm-processor läcker

Du har helt rätt om SVE2. Geekbench 6 använder inte SVE2 alls. Däremot använder GB6 SME vilket enligt Arm är en utökning till SVE2, något som är en sanning med modifikation då M4 har stöd för SME men man har inte stöd för "vanliga" SVE2 (non-steaming SVE mode).

Oavsett, huvudpoängen är att det finns ett par deltester, främst "Object Detection" som kanske inte är väldens bästa test då det påverkas brutalt mycket av huruvida SME/AVX512-VNNI finns eller ej (testet "Photo Library" använder också dessa instruktioner, men där är det långt mer modest skillnad).

M3 (som saknar SME) vs M4 (som har SME) i det specifika testet, i genomsnitt är M4 20-25 % snabbare än M3

Zen3 (som saknar AVX512-VNNI) vs Zen4 (som har AVX512-VNNI)

Som tur är ger en ökning på 250 % i ett enda deltest bara ett utslag på ca 5 % högre totalpoäng.

Du har också rätt i att Snapdragon 8 Elite saknar både SVE och SME, vilket gör uppdateringen från Snapdragon X till Snapdragon 8 Elite än mer imponerande. De tog verkligen sjumilakliv rakt över, vilket då framförallt inkluderar vanlig skalär kod som trots allt är långt viktigare för normalanvändaren (SME/AVX512-VNNI har absolut nischer där de är värdefulla, men det är rätt smala nischer som hantering av relativt små ML-modeller, blir de större är GPGPU överlägset).

Det är nästa generation Oryon som tar klivet över till ARMv9.

Det finns absolut en hel del resultat som dels är testade på märkliga sätt, ofta med orimligt låga resultat som följd. Finns och rena fabriserade resultat, typiskt med orimligt höga poäng (ett sätt att uppnå det är att få GB6 att se en OS-klocka som går för långsamt).

Men tror du själv att en Zen5 på 3,0 GHz skulle få ens i närheten några 3000 poäng när vi vet med säkerhet att samma Zen5-design får ca 3400 poäng vid 5,7 GHz (9950X) och när Ryzen AI 370 (som har samma 5,1 peak-frekvens som AI 395) får rätt samma 2800-3000 poäng?

Historiskt var det rätt stor skillnad mellan result från samma CPU körandes Windows och körandes Linux. Även idag finns en viss fördel för Linux i MT-testerna (rimligen för att Linux helt enkelt är bättre på att hantera det).

Men skillnaden i ST är i praktiken eliminerad, detta då man sedan GB5 bytte från att använda MSVC++ på Windows, Clang på MacOS och GCC på Linux. Clang och GCC ger i många fall bättre kod än MSVC++. I GB6 används Clang för alla OS (valet föll på Clang då det är den enda av de 3 som har bra och officiellt stöd på alla tre OS).

På det stora hela är GB6 en av de mer heltäckande benchmarks som också är relativt tillgänglig. Och till skillnad vad man tror är det en benchmark som snarare missgynnar Apple än gynnar dem. Missgynnar dem då många MacOS applikationer använder specifika finesser som Accelerate, GPGPU och media-acceleratorer "i verkligheten", men inget av det används här för att man ska få en någorlunda "äpplen mot äpplen..." jämförelse mellan CPUer/OS. Arm har innan de fick SVE2/SME inte heller gynnats då det som sagt finns tester som

Då har du bättre koll än de flesta. För sett flera som ställt just frågan vad Apple gjort för att få Arm att acceptera att man inte implementerat SVE2 trots att man har SME. Gissningarna har varit Apple dels har en exceptionell ställning hos Arm, dels att SME rätt mycket är en standardiserad variant av Apples AMX som de har i M1-M3 (men som bara går att använda från kernel-space, applikationer kan bara använda det indirekt via Accelerate).

Arms illustrerar SME så här i ISA-stacken vilket i.o.f.s. inte är i linje med SME specifikationen som säger att SME innehåller ett subset av SVE2 instruktionerna.

Ovan spelar i.o.f.s. ingen roll för de som bara kör program, whatever som gör det snabbt och effektivt duger.

Geekbench kommer typiskt med ett whitepaper som beskriver saker som vilken toolchain som används, en (i min smak med för lite detaljer) beskrivning av vad varje deltest gör, lista av vilka ISA-extensioner som används i varje test (om tillgängligt) samt högnivåbeskrivning av vilka bibliotek/ramverk som används.

Vidare har man lite information kring frekvens av cachemissar, branchmissar etc i de olika testerna. Här ser man att Clang-testet är speciellt, framförallt ST, då det står ut med att ha väldigt hög andel cachemissar och branchmissar. Det är på många sätt den "elakaste" lasten i GB6.

Object detection testar specifik en CNN för att upptäcka och klassificera objekt i bilder. Nätverket kallas MobileNet V1 SSD (Single Shot MultiBox Detector). Ramverket som används är PyToch. Detta är rätt populärt, man hittar en rad GitHub-repon som använder detta vid en sökning.

Är detta kritiskt för den genomsnittlige SweC-medlemmen där spelande ofta är huvudfokus? Knappast!

Men det är samtidigt definitivt inte en meningslös mikrobenchmark. Just fokus på "mobila enheter" gör att det kommer handla om små modeller och begränsad in/ut-data. Det gör inferens med CPU relevant (även om det framöver lär ersättas med NPU), så fort man skalar upp är GPGPU långt bättre.

Här håller jag helt med och detta är ett lysande exempel på varför Apple, mer än andra, faktiskt "drabbas" mer negativt av GB6 än andra: Apple har fler "custom kretsar" som väldigt ofta faktiskt används i "verkliga MacOS program".

AMX går som sagt bara att använda via Accelerate, Apple är väldigt bra att få in stöd av Accelerate i MacOS versionerna av t.ex. deras backend av PyTorch. GB6 väljer att undvika använda GPGPU, NPU (de har specifika tester för detta) etc i CPU-testerna, man vill ha en "råprestandajämförelse" enbart av CPU.

M4 Max vs AMD Ryzen AI 395 Max är i GB6 vs PugetBench ett målande exempel på hur det kan ge lite skev bild.

CPUn i M4 Max är i runda slängar ~30 % snabbare ST och ~20 % snabbare MT i GB6. Trots det är den ~60 % snabbare i Pugets PremierPro CPU-test och ~45 % i Photoshop CPU-testet.

För specifika use-case måste man kolla just detta use-case. Idag är datorplattformarna så pass hetrogena att populära områden kan vara kraftigt accelererade av dedicerade funktioner.

GB6 är en bra, skulle säga den bästa, eller kanske minst dåliga, vi har idag om man vill ha en fingervisningen hur två CPUer står sig mot varandra i genomsnitt när man är förvisat till att enbart förlita sig på CPU-kraft.

Tvärtom. Om målet är att få en fingervisning av CPU-råprestanda vore det direkt förödande om ett abnormt resultat i ett specifikt test skulle ha kraftig påverkan.

En stor kritik mot SPECint/SPECfp genom åren har varit att denna benchmark är så viktig PR inom servervärlden att alla CPU-tillverkare, historiskt i alla fall, lade stora resurser på att hitta kompilatortricks + "speciella instruktioner" för att påverka resultat.

Flertalet deltester här har genom åren helt "pajats" på det sättet, vilket gjort att värdet av denna benchmarks ifrågasatts ibland. Värt att notera där att deras kompilatortest, som baserar sig på GCC, är ett deltest som aldrig "pajats" på det sättet. Högt resultat där har alltid gett bra resultat i övriga SPECint tester.

Kollade inte meta-data, där avläst frekvens står. Men kollande ett tiotal resultat med liknande totalpoäng (som också låg i linje med vad Notebookcheck fick) och valde ett av dessa. Det är tyvärr inte speciellt ovanligt att metainformationen kan vara lite iffy.

Rätt uppenbart att rapporterad CPU-frekvens är fel för N1x fallet också, annars har vi en utmanare till M4 på gång!

Ett stort problem med enskilda GB6 resultat är att det finns en lång rad sätt att generera avvikande resultat.

Att bara söka efter ett resultat för en viss CPU-modell och använda det kan bli rejält fel. Kan inte hävda att jag har en superlösning här, bästa jag kommit på är att utgå från vad någon källa jag litar på uppmätt och helst använda deras länk (tyvärr postar nästan ingen av tech-sidorna läkar till sina resultat ).

Det SweC använder i artikeln är ett resultat jag inte hittar att någon review av 395 AI Max fått, de har fått där jag nämnde. Om det var en Linux/Windows sak, varför är då Intel 285 HX rätt mycket spot on i vad SweC rapporterar med vad Notebookcheck fick (de testar tyvärr bara på Windows)?

När man då har en idé var resultatet "borde" ligga på får man söka upp ett par stycken resultat som ligger på den nivån, kolla att de ser ut att vara hyfsat samstämmiga i deltesterna. I det läget har man med någon form av rimlig sannolikhet ett "representativt resultat".

En sak, som på något sätt ändå passar på SweClockers, man kan göra för att påverka resultat tillräckligt för att vara fullt mätbart i GB6 är att kyla ned sin laptop innan testet. Det ger ju ett nonsensresultat, i alla fall om man inte sitter utomhus på vintern och jobbar... Så att gräva fram enskilda resultat med "extra högt resultat" är att be om att använda manipulerade resultat.

Vi verkar ju ändå vara överens om att det man får ut ur en benchmark som GB6 är ändå inte en absolut sanning. Det är en fingervisning om CPU-prestanda relativt andra. Vad man kan säga om N1x är att den

• Är ett signifikant steg upp från var standard Arm-kärnor historiskt legat

• Man är nu på samma nivå som AMD/Intel/Qualcomm senaste generation mobilplattformar för PC, det är för jämt för att kunna säga att någon är konsekvent bättre än den andra.

• Det är ingen tyvärr ingen M4 (och i praktiken går man upp mot M5), Apple spelar i nuläget i en egen liga och vore superkul om fler når den nivån!

N1x har inte 20st Cortex X925 kärnor. Den har 10st Cortex X925 kärnor och 10st Cortex A725 kärnor.

Cortex A725 är inte optimerade för maximal prestanda, de är optimerade för maximal perf/W och har en design-target på <=1W per kärna peak-effekt! D.v.s. de är mer lik Apples "små kärnor" än Intels E-kärnor.

GB6 ST prestanda för Cortex A725 är luriga att hitta. Hittade ett par reviews av Mediatek Dimensity 8400 (som har 8st Cortex A725), de har en ST-poäng på ca 1600.

Cortex A725 är en modern variant av Cortex A78 som sitter i bl.a. Nintendo Switch 2. IPC verkar ha öka rätt lite genom åren på denna serie, fokus har varit att öka perf/W och med det kunna öka frekvens vid samma 1 W peak-design target.

SMT är vettig i de flesta serverfall. SMT är ett plåster för de flesta desktop-klient fall då en nackdel med SMT är att man ofta offrar en del ST-prestanda och man offrar en del latens.

På server är total kapacitet ofta viktigare, högre sådan och man kan sälja/köra fler molninstanser.
På desktop så är ST långt viktigare än MT givet var vi är, d.v.s. 8 kärnor eller mer är rätt standard. Föredrar icke-SMT + "E-kärnor" på desktop, E-kärnorna fyller rätt mycket samma funktion som SMT utan nackdelarna med högre latens!

Det skrivet: N1x är som sagt ingen M4 sett till CPUn. Undrar om Nvidia ens bryr sig så mycket om CPU-kraft mer än att de fattar att man måste ligga på motsvarande nivå som andra Windows/Linux-plattformar för att vara med i matchen.

N1x huvudgrej är en högprestanda SoC med Nvidia GPU, d.v.s. en plattform med CUDA-stöd, bra Linux/Windows-stöd. Om den är "OK" eller "fantastisk" kommer hänga främst på hur GPUn presterar i denna plattform.

Men som Linux-användare hoppas jag ändå att det också blir en riktigt fin ARM64-baserad plattform sett CPU-prestanda, superkul att se att både Qualcomm och Arm båda nu har CPU-plattformar som kan utmana den åldrande x86-tekniken.

Absolut, har redan sagt att jag hade fel här.
Får bära en extra hög virtuell påvemössa då jag gjort samma misstag två gånger, rätt mycket på samma sätt och antagligen kikat på samma sökträffar.

Kollade igenom GB6 whitepaper och inget test alls använder SVE2, däremot använder 2st SME (och AVX-VNNI/AVX512-VNNI på x86).

Enda relevanta poäng här är att det finns ett deltest som kan få en väldigt stor boost i det fall dessa instruktioner används.

Uttryckt på det sättet, helt korrekt. Folk har gjort reverse-engineering på Apples AMX.

Ändå i praktiken helt irrelevant då statistiskt sett ingen kommer utnyttja tekniken utanför Accelerate i "riktiga program".

Det potentiellt relevanta i kontext av GB6 som jämförelse mellan M1-M3 och t.ex. M4, Nvidias N1x, etc. är att i praktiken kommer M1-M3 prestera bättre på det som "object detection" testar då det finns väldigt liten anledning att inte använda Apples NumPy/PyTorch backend om man kör på MacOS. Men det gör inte testet på något sätt värdelöst, framförallt inte då detta är unikt för M1-M3.

GB6 är ju tänkt att jämföra "ren" CPU-prestanda och en högst rimlig gräns att dra då är att bara använda standardinstruktioner i respektive ISA. Vilket gör detta än mer ironiskt att vissa kallar GB6 för "apple-bench", det är inte en benchmark som positivt gynnar dem (tvärtom).

Det är en nischfunktion. Men hela poängen med att ha ett 20-tal olika tester är ju att få ett stor bredd på vad som testas, vilket är en förutsättning för att kunna få en någorlunda rimlig siffra på "hur presterar denna CPU-modell relativt andra CPU-modeller i genomsnitt?".

Ja, AMX verkar i grundmodellerna av M1-M4 vara uppdelat i två kluster. En för P-kärnorna och en för E-kärnorna, där likt SMT arkitekturtillståndet är duplicerat till varje fysisk kärna men AMX-HW delas.

Total irrelevant information för de som bara vill få ett grepp om hur en CPU presterar i förhållande till andra.

Som sagt, GB6 använder inte (och lär aldrig använda) AMX då man i CPU-testet verkar försöka undvika att använda OS-specifika funktioner så långt som möjligt. AMX är i praktiken bundet till MacOS/Accelerate.

Sen går det att argumentera för att 5 %, om vi istället jämför Zen3 (som saknar AVX512-VNNI) och Zen4/5 (som båda har AVX512-VNNI) inte alls visar hur absolut fantastik lyft detta kan ge i "verkligheten" om man bara råkar göra saker där det spelar roll. Har ett konkret fall (kombo av .NET8/Python+PyTorch) där 14900K/5950X/M3 Max (de CPUer vi råkade jobba på) i de flesta fall presterade rätt likvärdig, men vid träning/inferens av små ML-modeller var M3:an helt plötsligt x3 snabbare (kombo av AMX+MacOS verkar hantera detta lite mer effektivt).

Detta säger bara att en siffra kan bara beskriva så mycket. Och givet hur mycket "specialfunktioner" som läggs in i moderna system så kommer en aggregerad "prestandasiffra" antagligen bli allt mindre relevant.

Bryr man sig om CPU-renderingprestanda, kompilering, ML-inferens, etc, kolla det specifika deltest som testar detta. Då du nämner M3 och M4, de är väldigt närbesläktade men ändå ser man rätt stora skillnader i prestandaskillnad mellan olika deltester.

GB6 använder Intel i5-12500 som base-line. Man har på den mätt IPC för varje deltest, det är ett span på 1,1 till 3,9 i IPC. Det visar att prata om "genomsnittlig IPC" går absolut att göra ur ett statistiskt perspektiv. Men det är bara ett genomsnitt över de saker GB6 valt att ha med, vilket i.o.f.s. verkar tillräckligt bra för att både Intel och AMD biland använder det som referens när de lyfter fram generationsökningar i IPC.

Det är absolut ingen exakt siffra, så uttalande om "X+1 har 16 % högre IPC mot X" är egentligen nonsens då det helt beror på val av applikationer. Men GB6/SPECint/SPECfp har ändå visat att de trots allt ger en rätt bra "mellan tummen och pekfingret" indikation på vad en CPU ligger relativt andra.

Att Nvidia N1x får 3096 ST betyder inte att den är snabbare än en Intel/AMD CPU som får 2980 poäng. Det är så nära att de ur alla praktiska hänseenden är lika snabba, det kan däremot finnas relevanta skillnader i specifika fall. Som t.ex. kompileringsprestanda per kärna.

En källa är fel. En källa som har visat sig få resultat som inte avviker från andra.

Klicka för mer information

Videocardz får också rätt mycket det jag använde ovan

Visa mer

Exakt, detta är det verkliga problemet med GB6: deras databas har lite väl hög "märkliga" resultat och finns inget vettigt sätt att filtrera på saker som "ge mig bara denna version, inga överklockade resultat, etc".

Run-to-run variance i GB6 är väl under 5 % i en vettigt kontrollerade miljö, inte där problemet ligger. Problemet ligger i att många resultat är gjorda under helt okända förhållanden, vissa är på olika sätt fabricerade.

Kan man inte köra alla resultat själv är det bästa därefter att använda resultat från källor som gör kontrollerade tester. Vilket inkluderar de flesta tech-siter som gör CPU-reviews.

Sure det kan man göra, men vad är poängen?

Vad man realistiskt kan använda den här typen av siffror till är att säga saker som

M4 har högre ST än alla andra CPUer just nu, i nästan allt. Man kan inte säga med exakt hur mycket, rimlig noggrannhet är med ±10 %.

Då Nvidia N1x, AMD Ryzen 395 AI Max, Intel i7 285 HX alla är väl inom ±10 % ska man nog inte hävda något annat än att de är likvärdiga. Det betydligt inte att de är likvärdiga på allt, i specifika fall skiljer det helt klart mer än 10 % vilket då kan vara relevant.

Absolut, alla verktyg som försöker sammanfatta något så komplex som CPU-prestanda i en modern CPU ger bara en fingervisning.

Däremot skulle jag vilja hävda att om ett specifikt deltest råkar testa just det man själv har som viktigt fall så är resultatet i det deltestet en betydligt mer träffsäker indikation på vad man kan förvänta sig.

Fast nu drar du ändå långt större slutsatser än vad som man faktiskt kan se från de testerna.

Ja, i fallet Zen 5 ser man just det resultat. Det går inte att generalisera till att "SMT är så här bra".

Intel hävdade att genom att överhuvudtaget inte ha stöd för SMT i kisel så kunde man öka perf/W med 15 % i Lunar Lake. D.v.s. SMT har en negativ kostnad i för energieffektivitet i de fall där man inte använder "andra tråden" i en CPU (vilket för normalanvändaren på dagens >=6 kärnors CPUer är i klar majoritet av fallen).

Sen givet att vi kommenterar en artikel om Nvidia N1x och pratar om Ryzen 395 AI Max och M4 som alla har som alla har CPU/GPU-unified RAM och "stark iGPU" som huvudfiness, hur är det ens relevant hur Blender presterar på CPU?

395 AI Max får ca 417 poäng i Blender benchmark med CPU, den får 1375 poäng på GPUn

Här är ju där vi lär se N1x starkaste kort. För även om det inte är någon M4 Max sett till CPU, så är det fullt möjligt att den kan slå M4 Max GPUn på fingrarna i t.ex. Blender som inte verkar vara superkrävande vad det gäller RAM-bandbredd.

M4 Max får ca 470 poäng på CPU i Blender Benchmark, den får 5200 på GPU.

Gissar att N1x får svårt att nå 400 poäng på CPU här, däremot får RTX 5070 (N1x har lika många CUDA-kärnor, men klart lägre RAM-bandbredd som 5070) 6200 poäng!

SMT har absolut ett värde, det primärt på servers. SMT hade ett värde även på desktop när det var 1-4 kärnor, värdet när även laptops regelmässigt får över 10 kärnor känns rätt tveksamt. Framförallt om det Intel hävdar inte är total goja.

Inte en helt ovanlig kritik. Den bottnar i att man totalt missförstår vad det Geekbench försöker vara ett representativt benchmark för.

GB6 är nog det närmaste som finns idag till att vara det SPECint/SPECfp är för servers, fast för desktop.

I SPEC-rate (deras motsvarighet till GB MT-tester) kör man ett enkeltrådat fall per CPU-kärna. Enda som kommer hindra skalningen där är eventuella begränsningar i HW från frekvensskalning, RAM/cache-flaskhalsar etc.

Ett högst relevant test för ren server. Det typiska sättet att skala där är att hantera många samtida transaktioner, där varje transaktion typiskt är enkeltrådad.

Väldigt få desktop-applikationer uppför sig på det sättet. Kompileringar av stora C/C++/Rust projekt är ett noterbart undantag (.NET verkar inte alls skala lika med kärnor bra även när man har projekt med tusentals filer, å andra sidan kompilerar det typiskt x10 snabbare än motsvarande C++ räknat per fil, Go kompilerar ännu snabbare räknat per fil...).

Vad GB6 testar i MT fallet är hur en applikation som använder flera CPU-trådar för att lösa en uppgift (vilket är väldigt typiskt desktop fall) skalar över kärnor. För att se att den skalning man visar nog inte är helt galen kan man jämföra med t.ex. TechPowerUp som testar ganska många "verkliga" applikationer.

9700X har 33 % fler kärnor jämfört med 9600X, men den har "bara" 13 % högre prestanda i de applikationer som TPU testar
https://www.techpowerup.com/review/amd-ryzen-7-9800x3d/27.htm...

Tar vi SweC mätningar får 9700X 16372 poäng medan 9600X får 14665. Det ger en ökning för 9700 på 12 %.

TPU har nog bästa suite:en av icke-speltester på nätet. Tyvärr testar man bara x86 desktop, finns varken laptop x86 eller icke-x86 CPUer

Om man kan mäta själv är det ju inget problem. Huvudproblemet med GB6 är inte att testerna suger eller att inte skulle vara reproducerbara. Har testat GB Linux vs Windows på några av mina system, bl.a. 5950X, och där skiljde ~1 % i ST-testerna (Linux var den snabbare, det repoducerbart så _viss_ fördel finns). För specifika deltest skiljer det upp till ca 5 %, det är trots allt olika ABI på x86 i Windows och Linux (där Linux har en ABI som "känns" vettigare, t.ex. fler argument går i register).

Största problemet är att det är enkelt att se hur stor variation det är med samma CPU-modell, extra mycket så för CPUer som används BYO.

Nu har jag inte tillgång till just Ryzen 395 AI Max, om det blir en ny x86 CPU i närtid är det absolut en av de jag kan tänka mig då den är speciellt byggd för ML (M3 Max är löjligt dyr, enda som gjorde en värd pengarna var specifikt hur bra den är för ML).

Poängen var: testet visar vad SMT ger specifikt för 395 AI Max givet att AMD redan gjort valet att spendera transistorerna på SMT.

Vad vi inte kan veta är hur mycket mer ST-prestanda samt hur mycket mer perf/W som skulle ha varit möjligt om man inte ens spendera transistorer på SMT.

Intel hävdar att för Lion Cove handlar det om ~15 % högre perf/W i ST-fallet om man inte ens spenderar transistorer på SMT. Man kan självklart inte förutsätta att det är 15 % överallt, men med väldigt nära 100 % säkerhet kan man säga att det går att vinna prestanda och/eller energieffektivitet i fallen där en CPU-tråd per kärna används genom att helt skippa SMT.

För en server är i de flesta fall vinsterna med högre total kapacitet ändå värt SMT. AMD är numera rätt ensam om att behålla SMT på laptop CPUer. Inget bevis, men nog ändå sannolikt att i alla fall någon av de andra har koll på vad de gör.

SMT är absolut en bra teknik, vi lär även se det används i ARM64 servers framåt. Nåde SMT2 och SMT4 har historiskt används i ARM64 server-kretsar, dock innan man istället började skruva upp out-of-order fönstret brutalt och när man märkte att det extrahera väldigt hög ILP på det sättet. Intel verkar ju hoppas på något likande med APX.

Allt färre verkar se det som en bra teknik specifikt för desktop-laster, då främst mobila enheter.

Se ovan, menade det inte alls som att "det ger 15 % oavsett mikroarkitektur". Generaliseringen man kan göra är att genom att inte ens offra kisel på SMT kan man få högre ST, hur mycket beror självklart på mikroarkitektur och även egenskaper i ISA (som hur "snäll" den är i att ge möjlighet till hög ILP).

Hur mycket SMT ger är högst beroende av mikroarkitektur. Första generationen Atom hade SMT och där gav tekniken enorm utdelning. Inte för att det var en fantastiskt mikroarkitektur, utan tvärtom för att det var en hopplös långsam in-order design som inte alls fixade att mata sin backend fullt ut med en tråd. Caviums ThunderX2 (tidig ARM64 server CPU) hade ett värde av SMT4 av likande orsaker, den prestanda ändå rätt bra om alla trådar användes.

Det finns absolut tricks man kan göra för att maximera effekten av SMT. Som jag förstod NXPs PowerPC kärna e6500 fungerade den väldigt likt hur Zen 5, där blev det väldigt bra för SMT (och det är ju ett tag sedan) så det lär ju fungera minst lika bra idag givet den extra erfarenhet som finns.

Sen är även två separata decoders av allt att döma egentligen mer ett plåster än "det är bästa idén ever". Intel har två decoders i Crestmont och man gick till tre decoders i Skymont. Anledningen där är inte SMT, E-kärnorna sakar ju det, utan för att maximera ST-prestanda. Att man har flera decoders (som jobbar på att avkoda olika delar, från ett jump-target och framåt) är för att det kostar färre transistorer att ha 2/3st 3-wide avkodare än en som har samma totala kapacitet. Kostanden för ökad bredd ökar snabbare för x86 än för ARM64 p.g.a. komplexiteten i avkoding, en 8/10-wide avkodare är i genomsnitt bättre än 2st 4-wide men det ska vara en rimlig kiselkostnad också.

Poäng här: man kan absolut göra "smarta" och väl avväga optimeringar. Det är fortfarande till stor del ortogonalt mot om man vill designa för maximal total kapacitet (där är SMT otroligt kraftfullt) eller om man vill maximera ST per kärna (där Intel hävdar att man kan få en signifikant fördel genom att helt utelämna SMT).

Alla Arms CPU-kärnor, inklusive Cortex X925 och A725 som används i Nvidia N1x är optimerade för klient-laster och de har valt att skippa SMT. De har med X925 och gått samma väg som Apple med extremt out-of-order fönster, uppenbarligen fungerar det givet att N1x (som vi inte exakt vet frekvens på, men det pratas om 3,7-3,9 GHz) håller jämna steg med AMD/Intels senaste trots betydligt lägre frekvens.

SMT har absolut sina poänger, det är dock ingen silverkula och personligen tycker jag det allt mer verkar vara en belastning för desktop.

Om man använder sin laptop som byggserver och/eller för HPC-laster, absolut då är SMT värdefullt.

Det är dock inte normalanvändningen. 395 AI Max är ju precis som Nvidia N1x och Apples Pro/Max serie en krets som förväntas förlita sig på sin GPU i de flesta laster som skalar väl med kärnor.

Både Nvidia och AMD har ju pekat på att snabb CPU kan spela en viktig roll för att hålla GPUn matad. Och sen finns det saker som inte passar GPGPU, Nvidia tycker tydligen det kan behövas 10+10 kärnor, Apple upp till 12+4 och AMD 16C/32T även i laptop.

Sådant finns absolut! Men det är rätt ovanligt och specifikt N1x succé lär nästan bara hänga på hur bra GPU-delen är + CPU-delen är "i nivå med Intel/AMD".

Alla dessa systemkretsar är ju superspännande. N1x kan ju faktiskt också bli något som till och med slår GPU-delen i M4 Max på fingrarna, det vore hel-häftigt! (Även om den i praktiken gå mer upp mot M5 Max, men ännu bättre om det blir ett race!).

TL;DR
Håller helt med dig om att SMT är en lysande teknik, det finns absolut saker man kan göra i mikroarkitektur som är bättre/sämre för SMT.

Men anser att SMT allt mer är något som passar bäst för servers. Det finns bättre saker att spendera kisel på i desktop-CPUer när de redan har 10-16 och snart >40 kärnor (om vi ska tro ryktena kring t.ex. Nova Lake).

Vad skulle han säga? Inte precis så att Intel sa något överhuvudtaget mer än "SMT tar väldigt lite kisel och är energieffektivt" (vilket ÄR sant, men det finns fler nyanser) fram till att de faktiskt gjorde en produkt där de plockat bort SMT.

Det vore korkat att dissa existerade produkt, en C-level person kommer självklart vara fullt medveten om det.

Jo, man kan med väldigt nära 100 % säga att det skulle gå att allokera de transistorer man idag använder för SMT till att istället öka ST-prestanda och/eller öka perf/W ST. Frågan är hur mycket, här är det fullt möjligt att utdelningen blir rätt låg p.g.a. val man gjort i mikroarkitekturen.

Intel har som sagt droppat SMT både i Atom (Bonell -> Silvermont) och nu även i Core (Redwood Cove -> Lion Cove)

Inte i sig själv öka OoO-fönster, öka ILP genom att öka längden på genomsnittlig critical path.

En observation man kan göra mellan Cortex X925 och Zen5 (då vi använt den som exempel) är att något gör att den förra ser ut att prestera rätt likvärdigt i absoluta termer räknat per kärna, det trots att den senare är klockad ca 28 % högre¹.

Tittar man på mikroarkitektur för en del moderna P-core CPUer, här Zen 5, Lion Cove (de har väldigt snarlik IPC), Cortex X925, M4 samt E-core Cortex A725 (E-core i N1x) och Skymont (E-core i Arrow Lake).

Visa innehåll

P-Cores

Visa innehåll

E-cores

Så är det ändå lite anmärkningsvärt hur lika perf/cykel är i all 3 x86-designer samt hur lika de också är i X925 och M4, det trots att det helt klart finns noterbara skillnader.

Gjorde lite tester med Linux "perf" igår för att se om det gick att hitta enkla förklaringar. Körde igenom senaste 3 åren av AoC (har löst alla dagar utan några tricks som är ISA-specifika, de åren använde Go, Python samt Rust så lite variation i språk). Enda jag fick ut av det var: i genomsnitt kördes (retire) ca 10 % fler instruktioner på x86 jämfört med ARM64, kan förklara en del men inte de 25-30 % högre perf/W vi ser X925/M4 har över Zen5/Golden Cove.

Här är det också extra intressant att när Chips-and-cheese testade Skymont i Lunar Lake (den saknar access till L3$, tyvärr testade man inte Skymont i Arrow Lake som har L3$ access) mot Zen5C i Ryzen 370 visade det sig att de presterar i stort sätt identiskt i SPECint 2017, Skymont är dock 10 % högre klockad (3,7 GHz mot 3,2 GHz).

Inget bevis, men känns ändå som både x86 och ARM64 P-designerna pushar mot en rätt hård gräns av något slag. Bara det att den räknat i perf/cykel ligger ca 25-30 % högre för ARM64.

Det Intel lyfter fram med APX är att det ska leda till färre load/store-operationer (fler register, lika många som ARM64), leda till färre hopp (mer villkorade instruktioner, ARM64 har långt mer saker än CMOV) och det jag tror kanske är den viktigaste poängen, möjlighet för instruktioner att inte påverka flagfältet (det är som att programmera MT med globala variabler, inte bra...). Kollar man med compiler explorer ser man att väldigt få av aritmetiska operationer i ARM64 uppdaterar flaggor (är likt APX valbart per instruktion ARM64).

Hittar tyvärr inga forskningsartiklar kring teoretisk ILP/critical path jämförelse mellan x86_64 och ARM64, finns en som kikar på ARM64/RISC-V (med slutsatsen att detta två ISA ofta har liknande maximal ILP, blir spännande att följa RISC-V framåt).

Min gissning är ändå att det är här ARM64 har sin fördel mot x86_64. Om det stämmer går det också förklara varför SMT är mer värdefullt på x86 jämfört med ARM64. För kikar man på Phoronix testet du länkade ovan, vinsten SMT ger för Zen5 i genomsnitt lyfter den totala mängden jobb kärnan gör per cykel till ungefär där X925 redan når med 1 CPU-tråd. Är ju lättare att hitta ILP i två oberoende strömmar än i en. Dock alltid bättre att få motsvarad

¹ Det om vi tar de värden som rapporteras i GB6 som gospel, de är inte nödvändigtvis korrekta, för 395 AI Max vet vi ändå att den har 5,1 GHz max, eller 5,2 GHz med PBO vilket är vad de flesta resultat också rapporterar. GB6 rapporterar 4,05 GHz för N1x, vilket är högre än någon tidigare Cortex X925 men ändå inom rimlighetens gräns.

Om bilden ovan är rätt är den inte 12-wide, den är maximalt 8-wide (8 uops kan levereras från MUX, det från två front-ends som var för sig kan leverera upp till 6-uops).

Sen är det även här noterbart att även micro-op-cache är något med både för- och nackdelar. Även Arm valde en tid att använda sig av micro-op-cache, fram till Cortex X3. När man sedan gick "very-wide" tog man bort den, verkar inte finnas något värde i det läget (Apple och Qualcomm har inte heller någon uop-cache på sina 8-10 wide front-ends).

Intel har också valt att INTE ha en uop cache på Skymont, den har samma kapacitet efter MUX som Zen5 på 8 uops. Slutligen noterbart att Lion Cove må ha högre kapacitet på denna punkt, men det verkar inte ha gett någon större utdelning i verkliga applikationer.

TL;DR är ändå hur lika perf/cykel är i flera olika mikroarkitekturer när man ser den som två grupper, ARM64 (med den högre perf/cykel) och x86_64. Inte alls galet att misstänka att det finns ISA-specifika begränsningar som sätter nivån. Vilket i sig är intressant givet att så pass namnkunniga personer som Jim Keller sagt: ISA spelar liten roll, viktiga är mikroarkitektur. Känns som det var sant, men inte längre är det.

Historiskt har det finnits en högst relevant prestandaskillnad mellan Windows och Linux i GB körandes på samma HW. En klar majoritet av den skillnaden kom från att man använde olika kompilatorer på Windows (MSVC++), Linux (GCC) och MacOS (Clang).

Den skillnaden är nu borta då man i GB6 använder samma version av Clang oavsett OS. Och testade ju på en dator jag faktiskt kan kontrollera, min desktop 5950X. Med en miljö jag faktiskt kontrollerar och kunder säkerställa att allt HW-relaterat var identiskt så skilde det ~1 % i ST-testerna mellan Windows 11 och Ubuntu 24.04LTS (till Ubuntus fördel).

Kikade man på specifika deltest fanns lite större variationer, upp till 5-6 %. Vissa var (konsekvent) snabbare på Linux, andra på Windows. Vilket inte heller är konstigt då ABI skiljer och det verkar som ABI i Windows är bättre för vissa fall och ABI för Linux i andra. Så var är kontroversen här?

Huvudproblemet med GB6 är specifikt deras databas, där finns en hel del "märkliga" resultat. Tester gjorda under kända och kontrollerade förhållanden är reproducerbara och i GB6 ST är skillnaden orsakade av OS så pass små att det knappast påverkar en utsaga av typen "presterar X ungefär lika bra som Y?".

På en mobilplattform är skillnader som t.ex. power-plan (som mycket väl kan skilja i sin default mellan Windows och Linux!!!) långt mer signifikanta för GB6 än vilken OS som används.

Angående rant:en på slutet. Fallet Apple/AMX är faktiskt lite noterbart då det är, vad jag känner till, enda gången någonsin där Arm tillåtet någon utöka instruktionsuppsättningen på en "application Arm CPU" utöver vad Arm själv tillhandahåller. För ARMv8-M är det tillåtet via "Custom Datapath Extension" om man har license för det, men finns inget motsvarande för ARMv8-A vad jag vet.

Men å andra sidan inte heller svårt att se fördelen för Arm här. AMX verkar av allt att döma rätt mycket samma sak som SME, så man jobbade väl helt enkelt ihop med Apple kring att utveckla det.

"Ljuger han"? Well, att inte säga hela sanningen är rent tekniskt inte samma sak som att ljuga och är just det förra jag hävdar han gör här.

För gör ett trivialt tanke-experiment: SMT må ta relativt små resurser i anspråk, men du tror på alvar att Zen 5 är en sådan perfektion i sin design att om AMDs ingenjörer fick lägga motsvarande transistorbudget på att öka ST-prestanda skulle de inte lyckas öka prestanda alls? Det är ju orimligt, alltså skulle det gå att använda resurserna annorlunda.

Men p.g.a. av redan tagna beslut och än mer av det faktum att man vill använda samma CPU-kärna både på desktop och server så är det säkert fullt rationellt för AMD att ha SMT!

Inte med på vad du vill visa här. Diskussionen har väl ändå inte handlat om vem som "vinner" mest i all-thread prestanda, utan huruvida det vore möjligt att öka single-thread genom att skippa SMT.

Att få mer "boost" från SMT är som sagt inte nödvändigtvis en effekt av lysande mikroarkitektur. Den CPU-design som med råge vinnit mest på SMT i Intels fall är första generationen Atom, det p.g.a. att den var helt oförmögen att effektivt fylla sin rätt magra backend från en CPU-tråd.

Se ovan. Ärligt talat är det utöver vad man faktiskt ser i de program man kör rätt irrelevant hur man delar upp resurserna. Men, har läst Chips-n-cheese analys av både Lion Cove och Zen 5. Kring detta nämner man bl.a. detta (det baserat på tester de gjort, inte gissningar från slides)

"A large number of core resources need to be reconfigured when a core switches between 1T and 2T mode. Doing so almost certainly involves stalling the already running thread until enough entries in core structures have been freed up. In the example above, the reorder buffer (ROB) is a statically partitioned resource when both SMT threads are active. When the thread 1 wants to start running code, the renamer would need to stop sending new instructions for thread 0 into the backend until thread 0’s ROB utilization drops to 224 or fewer entries."
https://chipsandcheese.com/p/amds-ryzen-9950x-zen-5-on-deskto...

Tja, en sak är t.ex. att ha en 8-wide decode istället för 2st 4-wide decode. Och även här, säger inte att Mark Clark ljuger när han hävdar att en tråd kan använda båda decoders i Zen 5, räcker ju med att det finns ett enda specialfall där det är sant för att hans utsaga ska vara sann.

"Unlike AMD Zen 5’s clustered decoder, all eight decode slots on Lion Cove can serve a single thread."
https://chipsandcheese.com/p/lion-cove-intels-p-core-roars

"Turning off the op cache limits a single thread to 4 IPC, as expected."
https://chipsandcheese.com/p/disabling-zen-5s-op-cache-and-ex...

"Zen 5’s frontend has a 8-wide decoder, arranged in two 4-wide clusters. It’s AMD’s first clustered decode implementation, and differs from clustered decode in Intel’s E-Cores in that a single thread appears unable to use both decode clusters together."
https://chipsandcheese.com/p/amds-ryzen-9950x-zen-5-on-deskto...

I det generella fallet är Zen 5 4-wide i decode när en tråd är aktiv medan Lion Cove är 8-wide (det senare antagligen p.g.a. Intel ansåg det vara värt att spendera de transistorer man inte spenderade på SMT på bl.a. avkodning).

Det betyder inte på något sätt att AMD gjort ett dåligt val. Tvärtom lär det vara mer optimalt med två st 4-wide decoders om man optimerar för SMT än en 8-wide. För Intel gäller det omvända då de helt enkelt istället valde att skippa SMT.

Om inte ovan duger lär inget jag med rimliga medel kan uppbringa någonsin övertyga dig

Hmm, Intel sa inte heller något om att man kan prioritera annorlunda för efter man gjort det valet. Det känns ju helt självklart, varför skulle AMD/Intel/Apple/etc av någon anledning säga något annat än nuvarande strategi är den de anser vara den bästa? Om de inte själva trodde det vore det väl ändå korkat att inte köra på den man faktiskt tror är det bästa?

Absolut! Fast ser det långt mindre intressant att glo på Intel och AMDs diagram mer än "de skiljer sig på flera punkter, ändå noterbart hur pass nära de ändå ligger i perf/cykel"!!

Och än mer i kontext av denna artikel är det än mer noterbart att Qualcomm, Arm och Apple nu också har mikroarkitekturer som har flera icke-triviala skillnader i mikroarkitektur men ändå ligger de hyfsat nära varandra i perf/cykel (Apple är i första hand något före då de just nu kan klocka sina designer något högre).

Framförallt är det intressant att notera att det är ett rätt stort gap i perf/cykel mellan x86_64 gänget och ARM64 gänget. Vore väldigt spännande om någon kunde ge en bra förklaring till varför det finns en så pass stor skillnad!

Se ovan: vidhåller fortfarande att för att optimera single-thread utan att tänka på transistorbudget ÄR en 8-wide avkodare i genomsnitt snabbare än 2st 4-wide. Även om de fungerar som i Gracemont/Skymont där de hjälper till även för en enskild instruktionsström.

Sen finns avvägningar. Framförallt på x86 tar en 8-wide avkodare definitivt mer transistorer än 2st 4-wide (eller 3st 3-wide som Skymont har). Kostande för att gå "brett" är mindre på ARM64 då alla instruktioner är 4-bytes, så för dem är det uppenbarligen fullt rimligt att köra en 10-wide.

Skrev jag det blev det fel, menade att det är två avkodare (tre avkodare i Skymont). Det är en front-end. Vad jag vet finns ingen hård definition av vad som är "front-end", men de beskrivningar jag sett verkar dra gränsen mellan front-end och back-end mellan rename (del av front-end) och ROB (del av back-end). Peak-kapacitet hos Zen 5 front-end är begränsad av max 8 uops i renamer.

Sure det finns både ISA-instruktioner som delas upp i fler uops och finns även det omvända att vissa kombinationer av ISA-instruktioner kombineras till färre uops. Det finns både på x86 och på ARM64, men nog ingen djärv gissning att det är mer 1:1 i ARM64.

IPC är väl egentligen rätt poänglöst mått när man jämför mellan två olika ISA. Enda som spelar roll är faktiskt prestanda.

Och åter igen, här är det högst intressant att notera att t.ex. N1x och Ryzen 395 AI Max presterar väldigt snarlikt, men den senare behöver rätt mycket högre frekvens för att nå dit.

Gjorde som sagt en mätning med perf som mätte "retired instructions", även om ARM64 gjorde samma beräkning på ~10 % färre instruktioner förklarar det bara en liten del av perf/cykel skillnaden mellan t.ex. N1x och Ryzen 395 som är runt 25-30 %.

Det är din tolkning, vad jag egentligt sagt är...

"The answer is yes, and it’s a great question to ask because I explain SMT to a lot of people, they come in with the notion that we don’t [and] they aren’t able to use all these resources when we’re in single threaded mode, but our design philosophy is that barring a few, very rare microarchitectural exceptions, everything that matters is available in one thread mode."

...notera det markerade. Det är hans joker som gör att man inte kan påstå att han "ljuger".
Men vad som är helt uppenbart är att i kod där uop-cachen är "kall" så är Zen5 begränsad till max 4 instruktioner per cykel. Något varken Skymont, Lion Cove, Oryon, M4 eller X925 är.

Vilket tar oss till mitt andra (av de totalt två påståenden jag egentligen gjort som är relevant här): om man skyfflade om vad transistorer används till i Zen 5 så skulle självklart även den kunna högre kapacitet i det fallet, vilket kanske bara skulle öka single-thread prestanda i väldigt specifika fall. Men det är möjligt, vilket är det påstående jag gjorde.

Värt att notera att när chips&cheese testade Skymont med sina 3st 3-wide, fast ingen SMT, så kunde man nå upp till 8 avkodade instruktioner per cykel. Motsvarande test gav bara 4 instruktioner på Zen 5, men två trådar aktiv kunde man nå 8 instruktioner. Det är bara olika optimeringspunkter, säger inte att AMDs är sämre. Tvärtom är det garanterat bättre för det man optimerat för!

Det handlar om skillnader i mikroarkitektur och hur man implementerar SMT vilket både påverkar effektivitet och kostnad för implementationen.

Absolut, det finns skillnader i implementation och optimering här. Det ändrar inte påståndet: jag föredrar en CPU-design som prioriterar prestanda per CPU-tråd, bl.a. för det är min fulla övertygelse att det är mest optimalt för desktop och bryr mig faktiskt väldigt lite om server/datacenter CPUer (behöver jag en sådan löser det sig och är sällan peak-prestanda är ett problem).

Därför jag historiskt gillade Intel/AMD, de var ST-leaders. Nu är Apple det, då föredrar jag dem. Kommer byta när någon slår dem på fingrarna, ser ju väldigt lovande ut både med kommande Arm Cortex X930(? på namn) och Qualcomms Pegasus (verkar vara namnet, inte Oryon 2/3).

Måste man verkligen veta exakt alla detaljer här?
Hävdar du alltså att Arm, Apple, Intel och Qualcomm som alla skippat SMT och där alla har 8/10-wide decoders, Arm gänget alla utan uop-cache, för sina P-cores alla borde snäppa upp och kolla på the one true design från AMD? Alla dessa har högre ST-prestanda per cykel, även om det är lite sanning med modifikation för Intel (Golden Cove har marginellt bättre heltalsprestanda, men lägre flyttalsprestanad i tester som t.ex. GB6, bl.a. p.g.a. avsaknad av AVX-512).

Det vore enklare för alla dessa att ha två st decoders med halva bredden, även om föredelen där inte är alls lika uttalad på ARM64 då alla instruktioner har samma längd och alltid ligger på en adress delbar med 4.

Tror du läser mitt påstående på helt galet sätt.

Kritiserar inte hur de designat Zen 5 front-end. Tvärtom är jag helt övertygad att det är en mycket bra design givet deras designmål där SMT är en högst vital del.

Men ser personligen det som en svaghet i designen när t.ex. Cortex X925 i N1x har samma perf/cykel på en enskild tråd som Zen 5 har på två trådar ihop. Ser ingen fördel för Zen 5 här om samma sak vore möjligt där. Mitt påstående är dock bara att "man skulle kunna pushat ST lite mer i Zen 5 om man droppat SMT och lagt de transistorerna på annat håll".

Är helt medveten om att x86_64 ser ut att ha mer grava ILP-baserade begränsningar så det är antagligen inte alls realistiskt att nå X925-nivå även om man helt tog bort SMT. Intel kom ju definitivt inte dit (fast Inte står rätt djup i skiten just nu, blir Nova Lake en flopp blir det nog att hala Intel-flaggan för dem...).