::: AMD Zen Samlingstråd :::

Tror vi alla är överens här: är absolut så att CPU-load ökar när FPS ökar, så långt är ju till och med YouTubaren som kör "Science Studio" med på noterna.

Finns spel där saker som fysik går på en fixed FPS (ett aktuellt exempel är Gears of War 4), men oftast skalar det med FPS och oavsett så ökar ju CPU-lasten när FPS ökar då mer data ska skickas till GPU ju högre FPS är.

Diskussionen handlar främst om CPU-delen måste göra mer om man ändra upplösning, där hävdar "Science Studio" (tror jag, var faktiskt helt med på vad ha sa till slut) bestämt att CPU-lasten ökar!

Men om man bara ändra upplösningen så ska ju CPU-delen skicka exakt samma information. I GPU är det faktiskt så att de tidiga stegen som jobbar med trianglar också gör exakt samma jobb, men de senare stegen som jobbar på fragment och pixels får enormt mycket mer att göra (1920x1080 -> 4k ger fyra gånger fler pixels).

Omvänt, när man minskar upplösningen men håller alla andra inställningar konstant kommer FPS öka vilket betyder att fler bilder måste renderas per tidsenhet, vilket då medför att CPU-delen måste jobba hårdare. Så tror att vi alla här är helt på samma sida kring detta!

Måste bara fråga: om Skylake/Kaby Lake, som jämför med Sandy Bridge har 30-35 % högre IPC för heltal, runt 20-25 % högre IPC för skalära flyttal, en bra bit över 100 % högre IPC för vektoriserade flyttal, har funktioner som omöjliggör buggar som Heartbleed, kan köra program i molnet på ett kryptografiskt säkert sätt på ett OS vars operatör du inte litar på, m.m. bara är en glorifierad variant av just Sandy Bridge.

Vad är då Zen? Hur är det då inte en glorifierad Excavator eller kanske än mer, en AMD version av Broadwell (som mer än Skylake enligt dig borde vara en glorifierad Sandy Bridge)?

Väldigt många av de saker som man stoppat in i Zen, som micro-op cache (kom i Sandy Bridge), speciell hantering av x86 stack-operationer (kom i Pentium M), ihop slagning av x86 instruktion sekvensen jämförelse-följt-av-vilkorat-hopp (mikro op fusion i Core2), instruktioner för att mer effektivt hantera godtyckligt stora heltal (kom i Broadwell), m.m är ju saker som Bulldozer-serien saknade men Core serien haft eller fått. OBS: detta är inte kritik mot AMD, det är tvärt om det absolut vettigaste man kunnat göra givet sin FoU-budget, d.v.s. titta vad andra gjort och implementera det som fungerar bra!

Det är svårt att se ett mönster i i3, i5 och i7 också.

i7 innehåller ju vad som helst, både medelmåttor och top-of-the-line.

Tror jag förenklade för långt då.

Naturligtvis ska man inte polla i all oändlighet, det är inte heller vad som sker i praktiken.

Tar man ett skolboksexempel på hur man implementerat ett enkelt lås ser logiken ut ungefär så här: gör en atomär kolla-om-låstet-är-öppet-och-i-så-fall-markera-det-låst (Compare And Swap), gör om detta till det lyckas.

Skulle någon implementera detta skolboksexempel (som är helt logiskt korrekt) i produktionskod så bör denne få betyget "needs improvment" i nästa performance review... En sådan implementation är en ren katastrof för en modern multicore CPU.

I stället har man fast-paths som pollar ett tag då det normala är att låset släps rätt snabbt, sedan kanske man gör lite annat innan man till slut lägger sig och sover.

Och här ligger förklaringen i varför det tar massor med fler CPU-cykler i fall när man hela eller nästan hela tiden hamnar i slow-path + när man väl lägger sig att sova tillkommer massor med overhead i form av kontext-switch, tiden för någon annan att väcka upp samt kanske viktigaste för multi-core system: när man vaknar upp kanske man kör på en annan CPU-kärna så data är cache-cold (vilket kan lägga på upp mot en faktor 100 på vissa minnesaccesser).

Plottar man t.ex. CPU-last mot antal paket som skickas per tidsenhet på en enhet som kan driva länken ganska precis i maxkapacitet så blir det allt annat än en rak linje.

Den är relativt rak upp till punkten när länken börjar bli flaskhals. Om en CPU-kärna orkar helt maxa länken så kommer normala drivarna börja kontext-switcha.

Tar vi nu och gör samma sak med två CPU-kärnor där båda skapar trafik kommer man se ett par saker:

• Man kommer gå klart förbi 50 % CPU-last per CPU-kärna innan man maxar länken, det faktum att två kärnor skriver till samma I/O-enhet ger rejält mycket högre kostnad för synkroniserings

• Om bara en OS-tråd driver lasten kommer det se lika ut som i första exemplet upp till att länken blir flaskhals, om vi antar att det finns lite annat som kör (behöver inte alls vara CPU-tungt) kommer tråden att hoppa mellan kärnorna och lasten kommer vara långt över 50 % för att hålla länken mättad p.g.a. kontext-switch-overhead etc

Och angående sova i C++, motsvarande det du visar ovan ser ut så här

std::this_thread::sleep_for(10ms);

Men det är "old-school" idag då det tvingar fram en kontext-switch. Idag skulle man schemalägga en asynkront händelse som triggar om 10ms och sedan göra något annat på samma tråd, detta är långt effektivare då man inte tvingar en OS-kontex-switch.

Efter Broadwell har Intel bl.a. introducerat Software Guard Extensions (AMD har något liknande med Secure Encrypted Virtualization, men där är man rökt om man inte litar på OS-kärnan, SGX kan skydda data även om OS-kärnan är i händerna på "fiende"). Kolla tråden där motsvarande AMD teknik nämns, det lyftes ju fram som något helt otroligt där. Specifikationen för AMDs teknik finns att läsa, jämför man den med SGX är de lika men SGX är lika bra eller bättre på varje punkt.

Har precis köpt en ny dator till jobbet, det enbart för att komma åt Memory Protection Extensions som introducerades med Skylake (fast köpte Kaby Lake då det är en U-serie CPU och vill ha den bättre prestandan). Skulle överhuvudtaget inte ens överväga att köpa en arbetsmaskin utan MPX idag, det borde ingen som jobbar med programmering i "native" språk göra då denna teknik gör det helt trivialt att hitta en av de elakaste klassen av buggar i språk som C och C++, minnesöverskrivningar och användning av friat minne. När MPX automatiskt hittar en sådan bug för första gången har redan CPUn betalat sig!

Bara från Skylake till Kaby Lake är prestandalyften ~20 % på laptops, över 30 % på Core M. För 15 W TDP och lägre är Haswell rätt trött mot Kaby Lake.

Rent generellt är Skylake den största prestandalyftet sedan introduktionen av Sandy Bridge. Många här bryr sig främst om spel och då blir så klart lyftet rätt litet då CPU-delen extremt sällan är flaskhals i spel, i alla fall när vi pratar 4C/8T modeller.

Vad är speciellt med Precision Boost, Extended Frequency Range, Neural Net Prediction och Smart Prefetch förutom själva namnet?

Precision Boost: hur är detta annorlunda än turbo boost? Skylake fick även speed shift som rejält sänkte tiden att nå max boost. Visst, AMD har 25 MHz steg och Intel har 100 MHz.

Extended Frequency Range: hur är detta annorlunda än vad Core M och U-serien gör när dessa kan köra frekvenser där kretsen drar en bra bit över TDP, de kan även hålla dessa frekvenser om kylningen tillåter (vilket syns i att samma CPU-modell kan presterar rätt olika i olika laptops). AMD har detta även för desktop, det är nyheten.

Neural Net Prediction: i grunden är detta ett fancy-name för branch-predictor, hur är det nytt?

Smart Prefetch: hela Core-serien har ju spekulativ prefetch, i Skylake är faktiskt L2$ på flera sätt simplare än tidigare (gjort främst för att minska strömförbrukning) men då L3$<->L2$ bandbredd ökat rätt mycket så kunde man mer än väl kompensera detta med aggressivare prefetch.

Core Mark? Enligt Core Mark ligger prestanda för FX-8370 någonstans mellan i7-2600K och i7-3770K, känns det representativt för vad fallet är i praktiken?

Just detta som är enda orosmolnet för Ryzen just nu. De resultat vi sett är helt valda av AMD, väljer man rätt fall så går det utan problem visa att FX-8370 presterar riktigt bra.

Är övertygad om att Ryzen kommer prestera riktigt bra i vissa klasser av program. Det som är make-or-break är dock är prestanda i heltalstunga program som inte är vektoriserade och där bara en tråd per CPU-kärna används, dessa kommer vara i klar majoritet. Framförallt om man har 8-kärnor då två trådar per kärna inte kommer användas av vare sig Windows eller Linux innan alla kärnor är aktiva på sin första tråd (går att skriva program som uppför sig annorlunda, men detta är normalbeteende).