Snabbtest: Mass Effect: Andromeda med AMD Ryzen och Intel Kaby Lake

Nu kan det absolut vara så att någon enskild CPU-tråd blir flaskhals och det är orsaken till att spelet inte uppvisar någon skillnad i prestanda mellan 8C/8T och 8C/16T.

Men kan också vara så att spelet använder CPUn på ett sätt som så att SMT inte ger något för just Ryzen. Anledningen att SMT överhuvudtaget fungerar är för att det i många fall finns outnyttjade resurser i CPUn p.g.a. saker som beroenden mellan instruktioner, cache-missar etc.

Har man två instruktionsströmmar genom samma CPU-kärna löser man beroendeproblematiken, finns nu alltid minst två instruktioner som är helt oberoende då de kommer från olika instruktionsströmmar. Om en tråd "stallar" på en cache-miss kan ju den andra utnyttja CPU-resurserna under tiden.

Men finns också fall där SMT kan skada prestanda. Om redan en CPU-tråd är begränsad av någon specifik resurs, t.ex. L2$ eller någon viss ALU-pipline, så förvärrar man bara denna begränsning om man kör en till CPU-tråd som är begränsad av samma resurs (sista är viktigt, SMT är i princip alltid positivt om trådarna jobbar med vitt skilda saker).

Om SMT är positivt eller ej kan skilja rätt radikalt mellan olika CPU-modeller, även om det finns mer likheter än skillnaden mellan Zen och Core så finns det ett par saker som är väsentligt annorlunda. Här och här finns en rad mätningar på effekten av SMT hos Zen och Broadwell, finns ett par fall där effekten av SMT skiljer sig rätt ordentligt.

TL;DR detta kan vara ett exempel där SMT ger en boost för Core men inte för Zen. Svårt att veta utan att ha tester med 4C/4T och 4C/8T på Ryzen, vi vet ju att Core får en 15-20 % boost av HT i denna titel vid 4C.

Att mäta last på alla CPU-kärnor i spel kan vara rolig kuriosa, men resultatet är relativt värdelöst. Gäller inte bara spel, gäller alla multitrådade program. Att CPUn är totalt sett belastad till säg 25 % och ger resultat R betyder inte alls att man kan nå 4*R vid 100 % CPU-belastning. Är en läxa jag lärt mig den hårda vägen, när man hade en CPU-tråd fungerade sådana mätningar hyfsat väl (i alla fall till dess att CPU-frekvensen började bli dynamisk) men går inte alls att räkna så på SMP-system.

I båda fallen för ProjectCARS så är GPUn flaskhals nästa hela tiden. Rätt säker på att varken R7-1800X och i7-6950X ligger på 100 % CPU-last här, men ändå är CPUn till viss del en flaskhals då resultatet absolut varierar med CPU-kraft. Så om fallet du länkar skulle ändas till att ha en väsentligt starkare GPU går det inte alls att säga hur de två systemen kommer reagera.

Och för att återknyta till SMT ovan. Enligt detta ger ProjectCARS marginellt högre FPS med SMT avslaget på R7-1800X.

Visa innehåll

Dold text

fast man får mindre FPS-varians och antagligen en bättre upplevelse när SMT är påslaget.

Visa innehåll

Dold text

Angående IPC, Ryzen har komplicerat IPC jämförelser rätt ordentligt... Bulldozer-serien och Core-serien hade relativt snarlik relativ IPC oavsett typ av last, den stora skiljelinjen mellan dessa var hur de presterade i få-trådat vs fall när alla CPU-trådar används.

Är lite mindre skillnad i få-trådat vs vältrådat, men fortfarande så att få-trådade fallet relativt sett ger högre IPC på Core. Men nu är den också en rätt rejäl skillnad i relativ IPC beroende på om programmet jobbar med skalära flyttal (t.ex. Cinebench och Blender, här är det jämt skägg mellan Zen och Broadwell), skalära heltal (t.ex. spel, kompilering och web/office, här har Core ett övertag och Skylake har faktiskt 10-25 % övertag mot Broadwell) samt vektoriserade tal (t.ex. Matlab, Matematica och HPC, haswell och har ~100 % högre IPC här).

Detta syns t.ex. i TechPowerUps Ryzen 1800X test. Testat över kategorierna "Arithmetic CPU", "Media Encoding", "Productivity and Compression", "Rendering and Simulation" samt "Web Performance" varierar de individuella resultaten rätt radikalt.

Genomsnittet är nästan komiskt

Visa innehåll

Dold text

R7 1800X och i7-7700K prestera i genomsnitt identiskt över fallen listade ovan (spel är exkluderade, finns en separat jämförelse för det). Har aldrig varit så viktigt som nu att förstå vilka begränsningar ens eget datoranvändande har om man vill välja den optimala CPUn, gör man något krävande kan det vara en väldigt stor skillnad på att välja "rätt" och välja "fel" CPU!

Du kan inte mäta CPU-användning på det sättet. Svaret är simpelt, ta ett spel som nyttjar en kärna. Jämför sedan en CPU med en kärna på 2GHz och en CPU med två kärnor på 1GHz.
Systemet med single core kommer visa 100% och systemet med två kärnor kommer visa 50%. Vilket går snabbast?

Windows är notoriskt dåligt för att visa upp detta beteende i activity monitor, om du hittar en process som maxar en kärna kommer det se ut som att alla kärnor är lågt lastade, vilket inte är sanningen.

Vidare är spel inte enkla att parallellisera, det är inte som ett renderingsjobb där man kan klyva upp bilden i flera delar. Vissa trådar kommer kräva mer prestanda än andra, vilket gör att CPU-utilization inte är ett relevant mätetal, bara frametimes är, för det visar hur länge spelet låser och stannar.

Samtidigt är IPC kung nu och det kommer alltså inte att förändras så länge applikationerna inte är enkla att parallellisera, vilket spel inte är. Visst kan du dela upp det i olika uppgifter, men så länge en tråd är tyngre än de andra så är IPC kung igen.

Absolut, gör man det kan det finnas ett värde i fler kärnor mot att ha lägre IPC. Men vill man ha högsta prestandan väljer man hög IPC och stänger bakgrundsprogrammen.

I min tablet sitter det en fyrkärnig Atom, den kostade en bråkdel mot vad min gamla server med två cpuer kostade. Visst kan det kännas fräckt när man öppnar activity monitor eller ser maskinen boota, men sen ska den ju användas med.

Fast det är inte rättvisa jämförelser. En vettigare hade kunnat vara om du vill ha 600w platinum med lite ripple eller 1200w bronze med massa rippel. En vanlig SSD som presterar utmärkt vid QD1 eller en M2 som behöver QD32 för att gå om den vanliga SSDn.
Visst är det fräckt med överdimensionerade komponenter, men så länge ditt användarfall fungerar sämre är det bara tufft och inget mer.

Vad betyder ens "optimeras även för Ryzen"?

I princip noll av dagens program är på något sätt specialoptimerade för någon CPU-modell. Att handoptimera för specifika x86-modeller blev i det närmaste meningslöst i samma veva som de fick out-of-order execution (Pentium Pro för Intel och K6 för AMD).

Det som helt bestämmer om ett program fungerar väl på en viss CPU är typen av problem som är flaskhals i varje enskilt fall. Den enda typ av optimering som förekommer är att vissa program handoptimerats för SIMD (SSE/AVX), men även detta börjar allt mer hanteras automatiskt via bättre sätt att beskriva programlogik så att en kompilator kan generera SIMD-instruktioner på en nära optimalt sätt.

Vanlig C++/C#/Java är uruselt på att beskriva problemet på ett sätt så en kompilator kan avgöra om SIMD kan användas. För GPUer (som idag är princip är enormt breda SIMD CPUer) löste man detta via OpenCL och CUDA, men ingen av dessa är en jättebra match för SIMD på CPU (fungerar OK, men SIMD på CPUer har styrkor som inte kan utnyttjas i OpenCL/CUDA).

Exempel:
Cinebench - skalar perfekt med CPU-kärnor och är helt begränsat av kapacitet för skalära flyttal, optimal CPU-design är så många CPU-kärnor som möjligt med "bred" FPU. Zen är en perfekt match för dessa laster, vilket också syns i resultaten.

Kompilering - skalar nästan helt perfekt (minimal begränsning från I/O) och är helt begränsat av kapacitet för skalära heltal, optimal design är många kärnor (I/O blir i något läge den dominanta flaskhalsen, så skalar typiskt till 6-12 kärnor beroende på hur starka kärnor man har).

Spel - skalar med kärnor men inte alls linjärt. Är helt begränsat av kapacitet för skalära heltal (så länge GPU-delen inte är flaskhals). Hur väl spel skalar med kärnor beror till viss del på hur låg kostnaden är för core-to-core kommunikation

Matlab - nästan allt beskrivs m.h.a. matriser, en perfekt match för SSE/AVX och FMA.

Om du menar senaste version av Blender så infördes en del AVX-optimeringar, tidigare version använde nästan bara skalära heltal med lite vektoriserad SSE pudrat på toppen. Vet att Bulldozer-serien fick en väldigt bra skjuts i senaste versionen (mer så än Ryzen), vilket är rätt intressant. Men Haswell och senare fick också en boost, större boost än Zen, så numera är i7-6900K snabbare än R7-1800X i Blenders "Ryzen test".

Och det är ett lysande exempel på vilken typ av optimeringar som görs: man optimerar genom att dra nytta av specifika funktioner/utökningar för x86, man optimerar inte mot specifika CPU-modeller. Alla CPUer som implementerar AVX lär se en boost, vilket är betydligt mer värdefullt än att bara optimera för en viss CPU-modell.

Problemet i detta fall är att det fortfarande handlar om handskriven AVX via compiler-instricts, hade man använt lite moderna metoder hade man också fått en boost på ARM (via NEON) och POWER (via AltiVec). Tyvärr inte helt lätt att införa något sådant i existerande kodbas där man tidigare redan använt compiler-instricts för SSE optimeringar.

Skulle säga att moderna spelmotorer som skalar förbi dual-core använder i princip alltid någon form av "work stealing". Men en sådan design kan man i teorin stödja hur många CPU-trådar som helst, i praktiken kommer man ändå bli begränsad av att det finns serialiseringpunkter. Några exempel är att GPUer endast har en grafikkö, DX12/Vulkan låter vilken tråd som helst posta där men då det handlar om en delad HW-resurs måste access synkroniseras mellan trådar (DX12 gör det automatiskt, Vulkan dokumenterar att applikationen måste göra explicit synkronisering).

Hur väl spel kan skala med kärnor dikteras därför av hur lång tid man måste spendera i dessa synkroniseringsregioner, detta beställer p värdet i Amdahls lag. Att de spel som skalar bäst med kärnor har väldigt snarlikt värde på p ger en vink om att vi kanske inte kan förvänta oss jättemycket bättre skalning med kärnor.

Men redan idag får man ju upp till 20 % högre prestanda av att gå från 4C till 6C, upp till 33 % om man går från 4C till 8C. Det stora lyftet är, vilket också syns i resultaten, är att ovan ger en maximal boost på 50 % när man går från 2C till 4C. Alla dessa är om IPC och frekvens är konstant över alla fall.

Rent generellt kring multitrådning så är det rätt vanligt att de mest effektiva algoritmerna inte alls skalar bra med CPU-kärnor. Så man måste då ta beslutet om maximal effektivitet är prioritet (vilket betyder välj den bästa algoritmen även om det betyder dålig skalning med kärnor) eller om maximal total throughput givet tillräckligt med kärnor (vilket betyder att man äter upp CPU-kraft som skulle kunna användas av andra saker som kanske körs parallellt).