Id Software hyllar AMD Ryzen och lovar optimeringar för nästa spelmotor

AMD nådde ju 5 GHz Boost med Vishera, men TDP var som sagt inget man blev glad över, om man inte jobbade på Vattenfall möjligen (AMD levererade CPU:n med vattenkylning, men något kärnkraftverk för att driva den ingick tyvärr inte).

Annars tror jag kring 4 GHz är och kommer förbli "sweet spot" om man inte byter till något mer exotiskt material eller så. Dit nådde vi redan kring 2004-05 med Pentium 4 (3.8 GHz), och sedan dess har det hållit sig kring där (+/- några 100 MHz) och bara handlat om arkitektoniska förbättringar och fler kärnor.

Jag har erfarenhet av att skriva egna enklare grafikmotorer samt att analysera source code på dom kommersiella.

Att skapa en tråd är busenkelt men kan självklart innebära problem. Du skriver att din 6 kärniga processor inte får jobba som att det vore ett bevis på något? Det handlar om 99% av världens befolkning inte har haft mer än 4 kärnor, och att försöka skapa fler trådar än vad som finns tillgängligt på processorn KRÄVER prestanda eftersom det är dyrt att hoppa mellan trådar som den då blir tvungen att göra. Så varför skulle då dom lyfta ett finger för din 6C/12T prolle när resterande av världens befolkning tappar prestanda istället?

För att du har en target på 30 fps oftast för konsolerna. Och vill du pressa mer än 30 fps så går ändå inte det för att grafikkorten i konsolerna är sämst och bottleneckar sedan länge. Så varför skulle utvecklarna lägga tid på att skriva fler trådar när det ändå inte är processorn som bottleneckar?

@Sveklockarn: Alla kan ha fel, de hade fel då, betyder inte att de har fel nu.
Men visst var det ett jädra uttalande.

Vet inte vad du grinar över, Id Software vet vad dom snackar om, det är ett ganska självklart utsägande, att spel och spel motorer kommer stödja fler kärnor, finns ju redan idag spel som är bra optimerade för fler kärnor och det kommer ju inte bli färre framöver, så tycker att deras utsago stämmer ganska så bra med vad som komma skall.

Ryzen 5 är en riktigt grymm CPU till ett vetigt pris.

Intel i5 är inte ett bra val idag, jämfört med Ryzen 5.

Denna video visar ganska bra vad Ryzen har att erbjuda!

Vet inte om folk har märkt det, men CPU:er har inte klättrat uppåt i frekvens sådär brutalt de sista 3-4 åren, minst. Därav av de får fler och fler kärnor.

Dessutom gör man spel efter en typisk dator som 90% av den potentiella kundkretsen har ett par-tre år framöver, inte exempelvis en i7-6950X, eller Ryzen 1800X.

En icke rekursiv fibonacci är ju trivial och har funnits lika länge som den rekursiva. Däremot är den icke-rekursiva ett exempel på en algoritm som är sekventiell, d.v.s. det finns ingen möjlighet att köra den parallellt (vilket kvittar för den är ändå överlägset mycket snabbare än en parallell rekursiv version).

Edit: icke-rekursiv fibonacci med C++11 är trivial

#include <tuple>

uint64_t fib(int n)
    {
    uint64_t f1 = 0;
    uint64_t f2 = 1;

    for (int i = 0; i < n; i++)
        {
        std::tie(f1, f2) = std::make_tuple(f2, f1 + f2);
        }

    return f1;
    }

OK. Visa då den teoretiska beräkningen av "span" och "work", om jag inte räknat fel så är just

work: log(n)*n (rätt uppenbart att detta är fallet, tidskomplexiteten är just O(log(n)*n) så 100 % säker att denna är rätt).
span: 2*(n-1) (har jag gjort fel är det här, men den kortaste sekventiella delen lär vara att köra merge steget + köra ena rekursiva anropet, det andra rekursiva anropet går parallellt så är inte den av "span").

Har du inte hört talas om "work" & "span" finns en översiktligt genomgång t.ex. här. Grejen är att det är OMÖJLIGT att få en större "speedup" än work/span, vilket betyder att det är omöjligt för merge-sort (förutsatt att jag räknat rätt) att se en boost på mer än ~10 för 10 miljoner element oavsett hur många kärnor du har till förfogande.

Posta gärna ett exempel på merge-sort som skalar bättre än 10x, har tillgång till en dual E5 2699v4 (totalt 40 kärnor och 80 CPU-trådar) som vi kan provköra algoritmen på.

Det är inte konstigare än att de flesta räknar aldrig ut den teoretiska maximala speedup de kan få givet deras problem. Man gissar och skjuter från höften. Är fullt möjligt att göra en modell för långt mer komplicerade program för att beräkna detta, är till och inte heller jättesvårt att lägga in egen instrumentering för att sampla fram "work" och "span" för just sitt fall.

Tror du någon modern spelmotor som skalar förbi två CPU-trådar utnyttjar flera kärnor genom att explicit skapa trådar vid lämpliga tillfällen?

Nej, en sådan design fungerar inte i praktiken. En sådan design skulle kräva att man handoptimerade för varje kombination av CPU-kärnor och CPU-trådar, totalt orimligt ur ett kostnadsperspektiv (och rent korkad design).

Vad man gör är använder sig av en "work-stealing scheduler" (vilket också är vad jag använde i båda fallen ovan för att parallellisera de två algoritmerna). En spelmotor som delar upp sina arbeten i oberoende jobb och hanterar dem via en "work-stealing scheduler" kommer automatiskt kunna dra nytta av hur många CPU-trådar som helst i teorin.

I praktiken kommer skalningen begränsas av spelets work/span kvot. Finns flera spel idag som visar viss skalning ändå till tio kärnor (d.v.s. om man jämför olika antal kärnor där alla kärnor har samma prestanda presterar 10C/20T bättre än 8C/16T, 6C/12T och 4C/8T). Dock är kvoten work/span relativt liten, vilket begränsar skalningen rätt kraftigt. Har gjort lite anpassningar av Amdahls lag mot genomsnittlig FPS i en rad spel, där ligger "p-värdet" (andel av programmet som kan köras parallellt i Amdahls modell, 1/(1-p) = work/span så dessa modeller hänger ihop).

Dagens spelmotorer skulle absolut kunna skala till både 8 och 20 kärnor. Dock måste man ändra upplägget i spelen på ett sätt som väsentligt ökar mängden CPU-cykler som spenderas i varje "jobb", man måste nog öka antalet oberoende "jobb" rätt mycket också. Gör man det ökar man work/span, vilket gör det möjligt att effektivt utnyttja flera kärnor.

Så vi är alltså överens men du vill ändå argumentera emot bara för sakens skull?

Personligen tror jag helt enkelt det bästa är att ändra GPUns renderingspipeline om man vill ha raytracing. Det tråkiga är ju dock tyvärr att det är svårt med minnet, mer eller mindre måste hela scenen in i videominnet för att kunna effektivt utnyttja raytracing och samtidigt så vill alla beräkningsenheter läsa från minnet på samma gång. Det kanske låter lite småkonstigt men det är egentligen bandbredd överlag som är största bottlenecken i dagens läge. Vi har bara valt tekniker som är väldigt bandbreddssnåla för att kringgå problemet.

Men det borde ju inte alls vara omöjligt att låta till exempel massor med CPU kärnor räkna ut rays i scenen och sedan bruteforca igenom alla beräkningar som inte kräver scenen med GPU. Men som sagt, skulle misstänka att det krävs en ny design av GPU för att det ska funka effektivt även det.

Skickades från m.sweclockers.com

Fast är vi överens? Det jag vänder mig mot är att spel skulle skala dåligt till 6-8 kärnor för att ingen har dessa. Dagens mest avancerade spelmotorer har en design som utan problem kan dra nytta av 8 kärnor. Att spel ändå ser väldigt liten vinst från att köra mer än 4C/8T beror främst på två saker

• sammansättning av den arbetslast som dagens spelmotorer jobbar med har inte tillräckligt med teoretisk parallellism för att en kunna skala väl till många kärnor

• spel på PC är nästan aldrig CPU-bundna, inte ens med moderna 4C/4T CPU-modeller. Så finns liksom ingen möjlighet att få bättre prestanda på något sätt

Sedan vände jag mig nog mot "att skapa en tråd är busenkelt". Uttalandet som sådant är ju inte fel, men moderna spelmotorer och egentligen alla moderna applikationer för multicore-system jobbar ju inte med OS-trådar som byggsten.

OS-trådar, så som de är definierade i Windows och POSIX, är faktiskt riktigt dåliga abstraktioner för att jobba med parallellprogrammering. OS-trådar kom till i en tid när multicore CPUer var något väldigt exotiskt, vad man egentligen var ute efter var "concurrent programming".

Så en OS-tråd är tyvärr två saker som på många sätt är ortogonala mot varandra, d.v.s. i vissa fall vill man bara ha det ena, i vissa fall den andra och ibland vill man ha båda.

För att ta fibonacci exemplet igen: detta är hur jag skulle skriva en variant som drar nytta av alla CPU-kärnor på ett system

uint64_t pfib(uint64_t n)
    {
    if (n < 2)
        {
        return n;
        }
    uint64_t x = cilk_spawn pfib(n - 1);
    uint64_t y = pfib(n - 2);
    cilk_sync;
    return x + y;
    }

Fast kör man denna kommer man märka att det går långsammare ju fler CPU-kärnor systemet har, så vad är fel??? Felet är att detta kommer försöka utnyttja allt för mycket parallellism (är ju som sagt teoretiskt möjligt med ~5,9 miljoner gångers "speedup" med n=45).

Och detta är bara ett av alla problem man måste brottas med för att effektivt få saker att skala väl. Lösningen här är att begränsa mängden parallellism som möjliggörs, t.ex. så här (använder mig av någon som heter Cilk+, finns bl.a. inbyggt gcc5.0 och senare, hade man utgått från OS-trådar som byggsten hade motsvarande blivit tusentals rader kod)

uint64_t sfib(uint64_t n)
    {
    if (n < 2)
        {
        return n;
        }
    uint64_t x = sfib(n - 1);
    uint64_t y = sfib(n - 2);
    return x + y;
    }

uint64_t pfib(uint64_t n)
    {
    if (n < 2)
        {
        return n;
        }
    if (n < PARALLEL_THRESH)
        {
        return sfib(n);
        }
    uint64_t x = cilk_spawn pfib(n - 1);
    uint64_t y = pfib(n - 2);
    cilk_sync;
    return x + y;
    }

Värdet på PARALLEL_THRESH får man leta fram empiriskt, i detta fall fungerar ~18-24 bra. Nu har man ett program som fungerar vare sig systemet har 1, 2, 8 eller 40 CPU-kärnor. Upp till 2st 8-kärniga E5 2690 skalar detta i princip linjärt givet tillräckligt stort värde på n.

Skalar även till 44 CPU-kärnor (är 2st gånger 22 kärnor i E5 2699v4, lätt att missa några ;), men "speedup" blir är "bara" strax över 30 då modeller med så många kärnor har rätt stor skillnad i CPU-frekvens när en kärna jobbar och när alla jobbar. Stängde man av frekvensskalning skulle man komma rätt nära x44 speedup.

Speltillverkare får naturligtvis också sitta och handjaga fram lämplig storlek på jobben som kan spridas ut. Gör man dem för små kommer man börja se negativ skalning med antal CPU-kärnor, i det läget är det 100% last på alla kärnor men uselt resultat. Detta vill man absolut undvika.

Gör man för få jobb blir det inte tillräckligt med teoretisk parallellism för att skala det hela. Här skulle man i någon bemärkelse kunna säga att spelen är optimerade för 4C/8T, tvivlar att man lägger speciellt mycket tid på att mikrooptimera efter att det fungerar bra med 4C/8T. Fast det som fungerar väl med 4C/8T fungerar också rätt bra med 8C/16T, så flaskhalsen lär ändå vara främst att spel helt enkelt inte har ett problem med tillräckligt mycket teoretisk parallellism.

Tänk "async compute"

Om två jobb inte kan köras asynkront så är det inte ens lönt att försöka köra dem på olika kärnor. Kan de köras asynkront har det per definition ingen kommunikation mellan sig.

Naturligtvis kommer det ändå krävas viss kommunikation mellan CPU-kärnor, det måste man ha i allt som inte är "embarrassingly parallel" (och spel är inte ens nära att vara "embarrassingly parallel"). Detta krav på kommunikation minskar den teoretiska parallellismen i programmet, men med en bra design går det ändå att skapa grupper av jobb där alla jobb inom en grupp är asynkrona och kommunikationen (synkroniseringen) sker när kan hoppar mellan grupper.

Du kan ju vända på det: om man inte kör work-stealing scheduler eller motsvarande, hur ska man på något vettig sett skapa något som fungerar på 2C/4T upp till 8C/16T (eller kanske till och med 12C/24T snart) på något vettigt sätt? Man kör ju work stealing scheduler även på konsolerna, det trots att antal CPU-trådar är helt fixat.

Den tekniken är helt enkelt otroligt tilltalande för utvecklare, det då lågnivå detaljer på cache-line nivå kan hackas av någon som verkligen förstår dessa detaljer (går även att utöka scheduler till att känna till SMT och liknande, utgår från att man gör detta redan), finns inte många som har den detaljkunskapen. De flesta har då en väldefinierad abstraktion att förhålla sig till, tyvärr är SMP-system full av "leaky abstraktions" så parallellprogrammering är svårt och dyrt då ett misstag ofta pajar allt.