Nvidia: "Moores lag är död – grafikkretsar kommer ersätta processorer"

Han är bara sur över att Tesla ska byta från dem till Intel

Självklart försöker han spetsa till det och i det generella fallet är han helt ute i spenaten med sitt påstående om att GPU kan ersätta CPU.

En GPU är extremt effektiv på problem som uppfyller kraven

• latens är relativt oviktigt

• bandbredd är väldigt viktigt

• problemet är dataparallellt, d.v.s. man har massor med indata där en (gärna relativt dyr) transform ska appliceras och varje indata resulterar i en separat mängd utdata

• transformen som appliceras är lika eller nästan lika för all data som behandlas av en viss "warp" (grupp om 32 trådar i Nvidias GPUer)

För att ge en liten fingervisning om exakt hur effektiv en GPU är jämfört med en CPU på problem som matchar ovan kan man notera att ett GT 1030 (en 30 W TDP GPU för < 1000 kr) matchar rätt bra kapaciteten hos ThreadRipper 1950X (en 180 W TDP CPU för 10k).

Notera också att det kvittar om det handlar om flyttal eller heltal då dagens GPUer från Nvidia, AMD och Intel kan alla hantera både och. Men framförallt för Nvidia är allt hårdoptimerat för 32-bitars heltal/flyttal, så jämförelsen ovan gäller bara 32-bitars tal.

GPGPU

GPGPU har funnits i ca 10 år nu. Det används en hel del på superdatorer, men det har gått väldigt trögt för "vanliga" PC. Verkar ändå som det börjar hända lite saker den senaste tiden, Blender får allt bättre GPGPU stöd, allt fler bild- och film-redigeringsprogram får allt mer GPGPU stöd. Detta är bra specifikt då vissa uppgifter passar en GPU, även relativt enkla GPUer springer ju förbi de snabbaste HEDT CPUerna här!

Ersätta CPU

Att helt ersätta CPUn med något som liknar en GPU har ju redan hänt. Var inte riktigt med på exakt hur Xeon Phi används i praktiken, det man oftast sett på bild är denna CPU i form av ett PCIe-kort.

Grejen är att Intel har lagt ned tillverkningen av Xeon Phi "co-processor", det då nästan ingen köpte detta i form av ett PCIe. Det som används av en rad top-500 superdatorer är i stället system där Xeon Phi CPUn kör hela OSet, inklusive all I/O.

Även om man får massor med GFLOPS ur ett Xeon Phi system och att Nvidia säker håller på att bygga något liknande med sina GPUer lär det inte vara ett hot mot traditionella CPUer. En Xeon Phi kan ha upp till 72 kärnor och totalt 288 trådar (4 trådar per kärna), prestanda per tråd är alltså bedrövligt så en Xeon Phi är hopplös som desktop CPU (fast går rent tekniskt att använda den som desktop CPU).

Andra typer av problem

Många problem på skrivbordet är strikt sekventiella, de fungerar uselt på en GPU och enda parallellism man kan extrahera ur dessa är den som moderna CPUer får via ILP (Instruction Level Parallelism). Är ILP som moderna CPUer utnyttja för att öka "IPC", d.v.s. antal instruktioner som utförs per cykel och kärna.

Andra typer av problem är de där man har många oberoende uppgifter, men där de olika uppgifterna skiljer sig åt (man gör olika transform på indata). Dessa kallas uppgiftsbaserad parallellism och även moderna GPUer har visst stöd för detta är de inte i närheten att matcha moderna multicore CPUer på denna punkt.

Dataparallella problem som är latenskänsliga passar inte heller bra för GPU, här är ett område där SSE/AVX är den optimala lösningen. Andra fall där SIMD är bättre idé jämfört med GPU är de där man ofta växlar mellan seriell och parallella uppgifter, egentligen en form av latenskritisk last då det i teorin skulle gå att köra med en GPU men i praktiken skulle vinsten med parallellism ätas upp av kostnaden för att hoppa mellan CPU och GPU.

SIMD finns på i princip alla större CPU-designer, t.ex. ARM har sitt NEON. Så en annan fördel över GPU är "install base", alla x86 tillverkade de senaste 10 åren har stöd för upp till SSE4.2 så program skrivna mot det fungerar ju på väldigt många system.

Använder man Nvidias CUDA (deras miljö för GPGU) är man bunden till Nvidias GPUer. Nu finns även OpenCL, men det behandlas rätt styvmoderligt av Nvidia + efter att nu använt både OpenCL och CUDA begriper jag varför CUDA dominerar. På tekniskt nivå är det så mycket enklare att jobba med CUDA, lättare att få till bra prestanda och långt mindre boilerplate-kod jämfört med OpenCL för att göra samma sak. Utvecklingsverktygen i CUDA är också betydligt mognare. "Öppet" betyder ingenting om det är dyrare att använda och ger sämre resultat

-Moores lag är död! Grafikkretsar är framtiden!!

*Släpper en re-brandad, 16 månader gammal GTX 1070 mid-range krets med marginellt bättre prestanda*

Precis som @RFRFRF nämner så skriver man i dagens läge inte program som använder explicit trådning, det specifikt då det blir helt orimligt att försöka anpassa sig till alla tänkbara CPU-konfigurationer. Antar här referensen är till dotnet "Thread Parallell Library", TPL. Tyvärr har MS lyckats messa upp detta en del då man använder samma namngivning (betydelsen för klassen "Task" är överlagrad) både för parallell programmering (som specifikt handlar om att utnyttja flera kärnor) och för asynkronprogrammering (som egentligen inte har något alls med multicore att göra, tvärtom är det ofta mer användbart i enkeltrådade fall).

Vad speltillverkare använder sig av är i grunden exakt samma teknik som TPL i dotnet, Executors i Java och mer HPC-inriktade ramverk som OpenMP/Cilk+.

I dessa beskriver jag som programmerare potentiell parallellism, d.v.s. jag har uppgiften att dela upp saker i enheter som kan beräknas separat. Ramverken ger sedan verktyg för att även kunna beskriva hur olika enheter beror av varandra. Ingenstans behöver jag bry mig om systemet har två CPU-trådar eller hundra CPU-trådar.

Detta matas in i en algoritm som kallas "work-stealing scheduler", det maskineriet är den enda del som bryr sig om hur många CPU-trådar systemet har.

I nästan alla lägen kan man styra ramverket till att använda färre än maximalt antal CPU-trådar, är användbart om man vet att just det specifika fallet inte har jättemycket parallellism. Att försöka använda för många CPU-trådar med begränsad faktiskt parallellism leder ofta till lägre prestanda eller att man drar mer CPU-kraft utan att det positivt påverkar prestanda (vilket är orsaken till att man inte kan kolla på CPU-last för att avgöra hur mycket kraft som "finns kvar").

Vi ser ju faktiskt att spel skalar ända till 10C/20T, i alla fall när man klockar ner CPUn till 2,8 GHz (som SweClockers gör i sitt "IPC" test). Grejen är bara att spel skalar väldigt dåligt med CPU-kärnor efter 3-4 st, samtidigt som spel skalar i det närmaste perfekt med ökad enkeltrådprestanda upp till punkten där GPUn tar över som primär flaskhals (som för PC ofta är så pass tidigt att de flesta moderna x86 CPUer inte är den primära flaskhalsen).

Dagens konsoler skalar rätt bra till de 6-7 kärnor som spelen använder (är 1-2 kärnor som är reserverade för systemet hos XBO/PS4), det då spelmotorerna gick över till "work stealing" i samband med PS3/360 (360 har tre kärnor och sex trådar).

På PC är CPU-delen så stark att den ytterst sällan är flaskhals + spel skalar långt bättre med ökad prestanda per kärna än med fler kärnor och fram till nästa torsdag har det varit så att de modeller med högst prestanda per kärna varit Intels 4C/8T modeller.

Uttalandet är helt rimligt för den delmängd av parallella problem som specifikt är dataparallella och där varje delberäkning utför samma (eller nästan samma) uppsättning instruktioner. GPUer är löjligt mycket mer effektivt jämfört med CPUer på detta.

Men det är ju bara en delmängd av alla problem som enkelt kan parallelliseras, som i sin tur är en delmängd av alla tänkbara problem man vill lösa på en dator.

Strikt sekventiella problem löses bäst på den CPU med högst enkeltrådprestanda.

Uppgiftsparallella problem (urtypsproblem på servers) löses bäst på CPUer med maximal aggregerad prestanda över flera CPU-kärnor.

Dataparallella problem med högre grad av villkorad körning löses bäst med SIMD (SSE/AVX på x86).

Ett exempel är beräkning av Mandelbrotmängden. Varje pixel kan beräknas helt i isolation, men antal iterationer beräkningen tar kan variera kraftigt mellan två angränsade pixels vilket kraftigt reducerar effektiviteten att utföra det med GPGPU (men är absolut fullt möjligt). SSE/AVX kan ändå används med bra effektivitet då bredden på en "wave-front" är 2-8 i stället för 32/64 (Nvidia GPU/AMD GPU) + SIMD generellt sett bättre hanterar fall där tiden att utföra beräkningen har hög varians (p.g.a. noll latens mellan SIMD-enheten och den "vanliga" CPUn).