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

Trädvy Permalänk
Avstängd
Plats
falun
Registrerad
Apr 2002
Skrivet av Wh1spY:

Nu vet jag iof inte hur pass optimerad motorn är i Fallout 4, men jag instämmer med dig.

Skickades från m.sweclockers.com

Den är inge vidare och har hört det är samma som updaterats från 2006 som oblivion låg på då och är lite som mythbusters polish a turd och man kan få en bajs boll som är polerad och det glänser av den men i grund och botten är den fortfarande bajs

Uppskattar i övrigt spelet som är en av mina favoriter men det trådar riktigt dåligt och var samma med skyrim "samma motor " med

i3 6100 - MSI b150m pro-vd - 8gb 2133 ddr4 - GTX 950 GAMING 2G - z400s 120gb ssd - 1tb WD blue - Corsair 500w

Trädvy Permalänk
Medlem
Plats
127.0.0.1
Registrerad
Sep 2005
Skrivet av lord_vasagos:

Den är inge vidare och har hört det är samma som updaterats från 2006 som oblivion låg på då och är lite som mythbusters polish a turd och man kan få en bajs boll som är polerad och det glänser av den men i grund och botten är den fortfarande bajs

Uppskattar i övrigt spelet som är en av mina favoriter men det trådar riktigt dåligt och var samma med skyrim "samma motor " med

Okey jo jag anade nästan det, för precis som du säger så är Skyrim onödigt trögdrivet. Underbart spel men skulle behövt en bättre motor.

Skickades från m.sweclockers.com

Chassi: Cooler Master Silencio, Skärm: AOC AG271QX (16:9/2560*1440/1ms/144hz), GPU: GTX 1080Ti, CPU: Ryzen 1600X, HDD: 2TB , SSD: Kingston 480GB, PSU: Corsair TX V2 750W, Mobo: MSI X370 Krait, RAM: 16GB G.Skill Ripjaws @ 3200, Mus: Logitech MX Master & G400, Matta: Steelseries QcK Heavy, Tbord: QPAD MK-50, Hörlurar: Beyerdynamic DT770 PRO 80ohm, Superlux HD-668B OS: Win10Pro. AI: Roland Quad-Capture, Monitorer: Yamaha HS7 x2.
Citera när ni svarar! :)

Trädvy Permalänk
Medlem
Plats
Sthlm/Värmdö
Registrerad
Feb 2007

Flera kärnor är ju alltid välkommet. Så länge de når 5ghz med dagens IPC that is!

Gilla min Guide till sweclockers tävlingen! :D : #12510535

Min Sweclockers-låt som aldrig deltog i Jultävlingen. Enjoy! https://www.youtube.com/watch?feature=player_embedded&v=g7gof...

Trädvy Permalänk
Medlem
Plats
Jönköping
Registrerad
Jul 2009

Mitt köp av en 5820K istället för Skylake för 2½ år sedan känns helt rätt då det var samma pris på dessa.

Trädvy Permalänk
Medlem
Plats
Framför datorn
Registrerad
Nov 2013
Skrivet av veckans:

Snälla använd idTech till nästa Elder Scrolls/Fallout. Bethesdas egen motor är förhistorisk vid det här laget.

Gör dom motorn lika modvänlig som den nuvarande så gör det inget om Bethesda byter, men den är ett måste att kunna modda sina spel som man kan idag. 60 fps gränsen bör dom fixa också

Coca Cola missbrukare
AMD älskare
Katt älskare

Trädvy Permalänk
Medlem
Plats
Uppsala
Registrerad
Jul 2001
Skrivet av lord_vasagos:

Skulle nog gå att nå 5ghz stock speed idag och intel skulle kunna göra det men till kostnad av tråkig tdp och få cpu som går igenom mot i dag med lägre hastighet och skulle bli för dyrt men vänder man på det så har dom flesta telefoner 8 cores och en stationär pc skulle kunna ha löjligt många sånna kärnor och ryzen skulle säkert inte vara omöjlig att kyla med 32 kärnor och 64 trådar i 2ghz eller så

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.

Ryzen 7 1800X, Asus Prime X370 Pro, 16 GB DDR4 3200 C14, Asus GTX 1070, 2 TB SSD + 4 TB HDD, Win10
Mitt Ljudmoln

Trädvy Permalänk
Medlem
Plats
127.0.0.1
Registrerad
Sep 2003
Skrivet av Jackbob:

Jag är väl medveten om det. Min poäng är att även din tyngre tråd är tyngre än dom andra så är det extremt ovanligt att denna tråd är så sekventiell att den inte kan delas upp i ytterligare små trådar. Anledning till att det finns inte görs idag är ju av pga det jag skrev tidigare.

Skickades från m.sweclockers.com

Jag vet inte om du har erfarenhet av riktiga spel/program utöver studier, i vilket fall är det oerhört mer komplext än att bara skapa trådar hit och dit, oftast är det design, synkronisering samt delning av data som är de stora uppgifterna. Allt ska hinna uppdateras innan nästa intervall, grafiken, fysiken, ljudet samt nätverket skall synkas hela tiden utan spikar som kan resultera i buggar eller lagg. Man vill också minska overhead i form av cputid, cpucache och minne. Dagens spel är betydligt mer avancerade än för ett par år sedan.

Om flertrådning var så pass lätt så skulle den redan finnas där, min fem år gamla 3930k har knappt fått sträcka på benen med sina 6 kärnor.

1: Intel i7-3930K | 32GB Corsair Dominator GT | Asus Rampage IV Extreme x79 | 2 x 1080 GameRock Premium 8GB | 2 x Samsung Pro 840 512GB | Corsair AX1200i | BenQ XL2411 24" / W1070 135" | Bose QC25 | Windows 10 Pro x64 | HTC Vive |
2: Intel Core i7-4700HQ | 32GB RAM | Intel HM87 Express | GTX 780M | 17" | Windows 10 Pro x64 |

Trädvy Permalänk
Medlem
Plats
Norrlands skogar
Registrerad
Mar 2014
Skrivet av Dalton Sleeper:

Jag vet inte om du har erfarenhet av riktiga spel/program utöver studier, i vilket fall är det oerhört mer komplext än att bara skapa trådar hit och dit, oftast är det design, synkronisering samt delning av data som är de stora uppgifterna. Allt ska hinna uppdateras innan nästa intervall, grafiken, fysiken, ljudet samt nätverket skall synkas hela tiden utan spikar som kan resultera i buggar eller lagg. Man vill också minska overhead i form av cputid, cpucache och minne. Dagens spel är betydligt mer avancerade än för ett par år sedan.

Om flertrådning var så pass lätt så skulle den redan finnas där, min fem år gamla 3930k har knappt fått sträcka på benen med sina 6 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?

Trädvy Permalänk
Medlem
Plats
127.0.0.1
Registrerad
Sep 2003
Skrivet av Jackbob:

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?

Om det så vore så behöver dom inte öka på trådarna än på 10 år, både AMD och Intel kränger på med quadcores ett bra tag framöver. Folk köper quads då spelen inte utnyttjar mer, vilket resulterar i att processortillverkarna säljer mestadels quads, vilket resulterar i att speltillverkarna optimerar för quads.

3930K kostade 5k för sisådär 6 år sedan, varför måste man vänta på AMD's motsvarighet, för samma pris dessutom, 2017?

Man anpassar ju trådningen beroende på systemets antal kärnor, det kostar mer för företaget att utveckla och är inte helt lätt, men nån gång måste man ta steget. Alltså samma arbete fast på färre trådar, det rullar nog på betydligt fler trådar i de modernare spelmotorerna, bara att dom inte är lika tidskritiska.

Nu har jag inte läst vilka typer av optimeringar ID tänkt sig, men vi får hoppas på bättre skalning över 8 cores.

1: Intel i7-3930K | 32GB Corsair Dominator GT | Asus Rampage IV Extreme x79 | 2 x 1080 GameRock Premium 8GB | 2 x Samsung Pro 840 512GB | Corsair AX1200i | BenQ XL2411 24" / W1070 135" | Bose QC25 | Windows 10 Pro x64 | HTC Vive |
2: Intel Core i7-4700HQ | 32GB RAM | Intel HM87 Express | GTX 780M | 17" | Windows 10 Pro x64 |

Trädvy Permalänk
Avstängd
Plats
falun
Registrerad
Apr 2002
Skrivet av Pepsin:

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.

Haha nä dom tar lite och kyla dom i 5ghz är inte kul och har klockat även äldre 8120 till 5ghz på alla 8 kärnor och det blir VARMT samma 2600k eller 2700k vart med varmt men 5ghz går där med men amd är faktiskt enda som tagit sig dit out of the box

Jag tror med runt 4ghz är ganska lagom och dom flesta cpu går svalt och har sin bästa consumtion vs prestanda spot i dom regionerna även FX som med undervolt kunde ligga under 95tdp från 125 orginal trots en oc på några hundra mhz och även intels modeller har gillat/gillar den nivån

Sen har dom blivit effektivare och en p4 om det var möjligt att klocka den till 10ghz hade antagligen haft tungt mot tagens cpu ändå så det har hänt saker men bästa scenariot vore om mjukvaran trådar riktigt bra rakt igenom och man lägger sig på en sweet spot och köper extra cores efter behov istället för att stirra på mhz

i3 6100 - MSI b150m pro-vd - 8gb 2133 ddr4 - GTX 950 GAMING 2G - z400s 120gb ssd - 1tb WD blue - Corsair 500w

Trädvy Permalänk
Medlem
Plats
Sollentuna
Registrerad
Aug 2007

Men asså. Både ps4 och xbox ond har åtta kärniga processorer. Varför görs inte detta redan? Utvecklarna som bär ansvaret för låg fps snarare än konsolen hårdvara?

Skickades från m.sweclockers.com

Dator: Fractal Design 650w modulär - Piledriver FX8350 + Arctic Cooling Freezer Xtreme Rev 2 - 4x2 gb Corsair Dominator 1866 mhz 9-9-9-24 - 1x 500 gb sataII, 1x640 Western Black Caviar, 1x Crucial m4 128 GB SSD - Fireface UCX (ljudkort) - SAPPHIRE Radeon HD7870GHZ (överclockat) - ASUS någonting lite över medelklass, 3 st 120mm chassifläktar Windows 8.1 x64

Trädvy Permalänk
Medlem
Plats
Norrlands skogar
Registrerad
Mar 2014
Skrivet av hwasser:

Men asså. Både ps4 och xbox ond har åtta kärniga processorer. Varför görs inte detta redan? Utvecklarna som bär ansvaret för låg fps snarare än konsolen hårdvara?

Skickades från m.sweclockers.com

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?

Trädvy Permalänk
Medlem
Plats
Jönköping
Registrerad
Aug 2011

Som PC-spelare bör man nog inte ta Id[iot?] Softwares uttalanden på alltför stort allvar med tanke på att de redan 2011 gjorde klart att "PC är inte den primära plattformen" för dem längre.

http://xkcd.com/386/
http://readthefuckingmanual.com/
http://en.wikipedia.org/wiki/Megahertz_myth

”Alltså vad är det med grafikkortsmakare och bokstaven X? Det är precis som med dansbandsmusiker och bokstaven Z.”

Trädvy Permalänk
Hjälpsam
Plats
Karlskoga
Registrerad
Jan 2007

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

AMD Ryzen 7 1700 | Vega RX 64 Super | 64 GB Corsair @2933 MT/s | https://valid.x86.fr/fgqnte | Stockkylaren | Bitfenix Whisper M 750W.
AMD FX8350 | Polaris RX 460 4 GB | 32 GB Kingston ECC | https://valid.x86.fr/0q5pkm | Cooler Master V 700W.
HTPC | https://valid.x86.fr/ez1zxw |

Trädvy Permalänk
Medlem
Registrerad
Jan 2013
Skrivet av Sveklockarn:

Som PC-spelare bör man nog inte ta Id[iot?] Softwares uttalanden på alltför stort allvar med tanke på att de redan 2011 gjorde klart att "PC är inte den primära plattformen" för dem längre.

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!

Trädvy Permalänk
Medlem
Plats
Uppsala
Registrerad
Aug 2015
Skrivet av anon159643:

Inget förvånande att utvecklare optimerar sina produkter efter vad för typ av hårdvara som deras användare kör med. Det är inte för inget som få spel görs för Motorola 68000 idag..

Det ryktas att en i7 7740K snart ska släppas, men den kan Intel ta och stoppa upp någonstans.. Säkerligen en bra cpu, men uppgradera från i7 7700K?

Jag tror de flesta pratar om att dagens spel inte presterar bättre på en flerkärnig processor än en med bara 4 kärnor, där varje kärna är snabbare. Angående vanliga program så ser jag påstående lite som de som säger att man ej behöver ha ett bättre grafikkort än Nvidia 8400 för spel, ja kanske för de spelen som ni kör med tänker jag..

Jo fast, en Haswell-E bör ju tekniskt sätt prestera likt en Haswell om kärnorna är klockade lika. Och så långt efter är inte entusiast marknadens processorer, särskilt inte nu när Ryzen är här med 6-8 kärnor som Intel inte har på mainstream plattformen. Det kommer bli spännande, oavsett om AMD gör en stor comeback, eller om Intel slår ner dom, kommer vi få intressanta, och bättre produkter.

PC #1 CPU: R5 1600 @3.8 Motherboard: B350-A PRIME GPU: EVGA 1080 Ti
PC #2 CPU: i7 3770K @4.2 Motherboard: P8P67 GPU: AMD R9 290X

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jan 2008

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.

|[●▪▪●]| #Lekburk#: Ryzen 3700X >-< GB-X570-AE >-< 16GB DDR4 >-< MSI GTX 1070 >-< 970 EVO 1TB SSD>--
--< Stock Cooler >-< FD Define R4 >-< Seasonic F.+ 650W >-< Acer XF270HUA >-< AOC Q2778VQE >--
#Servering#: Ryzen 1700@3,6GHz >-< Prime X470 Pro >-< 16GB DDR4 >-< GTX 1030 >-< 970 EVO 500GB SSD >--
--< Stockkylare >-< Antec P182 >-< Silver Power 600W >-< Samsung 245T |[●▪▪●]|

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av Jackbob:

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?

Skapa trådar är busenkelt, att använda dem på ett sätt som faktiskt ger ökad prestanda är långt ifrån trivialt.

Här är två väldigt simpla fall som också går att analytiskt beräkna teoretisk maximal parallellism:

Beräkna ett fibonacci direkt från den rekursiva definitionen. Detta är ett extremt ineffektivt sätt att beräkna detta, det är inte poängen, poängen är att ha ett trivialt exempel med brutal teoretisk parallellism. Algoritmen är

function fib(n) if n <= 1 then return n else x := fib(n - 1) y := fib(n - 2) return x + y end if end function

Varje rekursivt anrop av fib() är helt oberoende av andra anrop -> massiv mängd potentiell parallellism.

Givet tillräckligt många CPU-kärnor är det teoretiskt möjligt att köra denna algoritm ~1.62^n/n gånger snabbare. Så för n=45 kan man utnyttja upp till 5,9 miljoner kärnor. Men testa att ens få detta att skala speciellt bra till 8 kärnor i praktiken, framförallt om byggstenarna är explicita trådar... (Finns betydligt enklare metoder att utnyttja flera kärnor i just detta fall, kan absolut få detta att skala väl till 8 kärnor men det är INTE genom explicit trådning, får ca x7,9 speedup med 8 kärnor med en E5 2690 med n=45).

Teoretisk mängd parallellism är HELT dikterad av problemets natur. Ta ett annat trivialt exempel, merge-sort

function merge_sort(lst) if length(lst) <= 1 return lst else front_lst, back_lst := split_in_middle(lst) lst1 := merge_sort(front_lst) lst2 := merge_sort(back_lst) return merge(lst1, lst2) end if end function

De två rekursiva anropen till merge_sort() kan köras helt oberoende av varandra, teoretisk parallellism är däremot inte alls lika imponerande som ovan, ~log(n)*n/2/(n-1) där n är längden på listan som ska sorteras. Teoretisk parallellism att sortera tio miljoner poster är ~10.

I praktiken kommer detta överhuvudtaget inte skala speciellt linjärt till åtta kärnor, i detta fall av primärt två fall

  • att transferera posterna mellan kärnan kostar rätt mycket relativt beräkningen som utförs per element -> cache effekt

  • teoretisk parallellism på ~10 betyder ett "p-värde" i Amdalhls lag på runt 0,9 -> det är omöjligt att få mer än 4,7 speedup med 8 kärnor

Får ca x2,7 speedup med 10 miljoner element (slumpmässiga värden) med 8 kärnor på en E5 2690.

Spel är betydligt mer likt det andra fallet, d.v.s. mängden teoretisk parallellism som faktiskt finns ligger på kanske 10-20 och en spelmotor är långt mer komplicerad än exemplet ovan (som ändå är rätt svårt att få till riktigt bra, testa gärna).

Vad man i praktiken behöver är tillräckligt mycket något som brukar kallas "parallel slackness", d.v.s. om man har ett system med N CPU-kärnor vill man ha en teoretisk parallellism som ganska ordentligt överstiger N. Empiriskt verkar runt 10 vara ett lämpligt värde på slackness, så för att skala väl till 8 kärnor vill man jobba med problem som har minst 80 i teoretisk speedup.

För att nå dit med spel måste man rätt ordentligt ändra vad spelmotor faktiskt beräknar, för dagens spel är inte i närheten av att ha tillräckligt teoretisk parallellism att skala bra till 6-8 kärnor. Däremot är spel redan designade så att de kan utnyttja alla CPU-trådar som finns, men vinsten att gå från 4->6 eller 4->8 kärnor är väldigt liten.

Idag är vinsten så pass liten att den lägre frekvens 6/8 kärniga modeller har gör att de högst klockade 4-kärniga modellerna är toppvalet för spel. Den kortsiktiga "lösningen" är ju ändå rätt enkel, se till att även 6-8 kärniga modeller klockas lika högt som 4-kärniga. I det läget kommer även dagens spel köra lite snabbare med 6-8 kärnor.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Plats
Norrlands skogar
Registrerad
Mar 2014
Skrivet av Yoshman:

Skapa trådar är busenkelt, att använda dem på ett sätt som faktiskt ger ökad prestanda är långt ifrån trivialt.

Här är två väldigt simpla fall som också går att analytiskt beräkna teoretisk maximal parallellism:

Beräkna ett fibonacci direkt från den rekursiva definitionen. Detta är ett extremt ineffektivt sätt att beräkna detta, det är inte poängen, poängen är att ha ett trivialt exempel med brutal teoretisk parallellism. Algoritmen är

function fib(n) if n <= 1 then return n else x := fib(n - 1) y := fib(n - 2) return x + y end if end function

Varje rekursivt anrop av fib() är helt oberoende av andra anrop -> massiv mängd potentiell parallellism.

Givet tillräckligt många CPU-kärnor är det teoretiskt möjligt att köra denna algoritm ~1.62^n/n gånger snabbare. Så för n=45 kan man utnyttja upp till 5,9 miljoner kärnor. Men testa att ens få detta att skala speciellt bra till 8 kärnor i praktiken, framförallt om byggstenarna är explicita trådar... (Finns betydligt enklare metoder att utnyttja flera kärnor i just detta fall, kan absolut få detta att skala väl till 8 kärnor men det är INTE genom explicit trådning, får ca x7,9 speedup med 8 kärnor med en E5 2690 med n=45).

Teoretisk mängd parallellism är HELT dikterad av problemets natur. Ta ett annat trivialt exempel, merge-sort

function merge_sort(lst) if length(lst) <= 1 return lst else front_lst, back_lst := split_in_middle(lst) lst1 := merge_sort(front_lst) lst2 := merge_sort(back_lst) return merge(lst1, lst2) end if end function

De två rekursiva anropen till merge_sort() kan köras helt oberoende av varandra, teoretisk parallellism är däremot inte alls lika imponerande som ovan, ~log(n)*n/2/(n-1) där n är längden på listan som ska sorteras. Teoretisk parallellism att sortera tio miljoner poster är ~10.

I praktiken kommer detta överhuvudtaget inte skala speciellt linjärt till åtta kärnor, i detta fall av primärt två fall

  • att transferera posterna mellan kärnan kostar rätt mycket relativt beräkningen som utförs per element -> cache effekt

  • teoretisk parallellism på ~10 betyder ett "p-värde" i Amdalhls lag på runt 0,9 -> det är omöjligt att få mer än 4,7 speedup med 8 kärnor

Får ca x2,7 speedup med 10 miljoner element (slumpmässiga värden) med 8 kärnor på en E5 2690.

Spel är betydligt mer likt det andra fallet, d.v.s. mängden teoretisk parallellism som faktiskt finns ligger på kanske 10-20 och en spelmotor är långt mer komplicerad än exemplet ovan (som ändå är rätt svårt att få till riktigt bra, testa gärna).

Vad man i praktiken behöver är tillräckligt mycket något som brukar kallas "parallel slackness", d.v.s. om man har ett system med N CPU-kärnor vill man ha en teoretisk parallellism som ganska ordentligt överstiger N. Empiriskt verkar runt 10 vara ett lämpligt värde på slackness, så för att skala väl till 8 kärnor vill man jobba med problem som har minst 80 i teoretisk speedup.

Jag är bekant med både merge sort och fibonacci. Fibonacci är ju för det första ett extremfall där det till och med tog åratal innan det kom en algoritm som inte var rekursiv.

Merge sort går ju faktiskt utmärkt att skala för 8+ kärnor bara du har N som överstiger iaf hundratal. Och har du inte det så går sortering på en bråkdels sekund ändå.

Men oavsett så är det väldigt konstig jämförelse med en spelmotor. Detta är enskilda algoritmer som du jämför med tusentals(?) algoritmer som ska köras på en spelmotor, dessa går naturligtvis att parallellisera. Är det helt trivialt hur det ska göras? Nej inte alltid. Men som vissa i detta forum påstår att det skulle vara nästintill omöjligt att dela tusentals algoritmer på mer än 4-6 kärnor är ju fullständigt sagolikt fel helt enkelt. Och det är allt jag säger, inget mer.

Skrivet av Yoshman:

För att nå dit med spel måste man rätt ordentligt ändra vad spelmotor faktiskt beräknar, för dagens spel är inte i närheten av att ha tillräckligt teoretisk parallellism att skala bra till 6-8 kärnor. Däremot är spel redan designade så att de kan utnyttja alla CPU-trådar som finns, men vinsten att gå från 4->6 eller 4->8 kärnor är väldigt liten.

Idag är vinsten så pass liten att den lägre frekvens 6/8 kärniga modeller har gör att de högst klockade 4-kärniga modellerna är toppvalet för spel. Den kortsiktiga "lösningen" är ju ändå rätt enkel, se till att även 6-8 kärniga modeller klockas lika högt som 4-kärniga. I det läget kommer även dagens spel köra lite snabbare med 6-8 kärnor.

Och fortfarande, du missar min poäng fullständigt du också. Största anledningen till att det är så som du beskriver är ju för att alla spelföretag vill tjäna pengar, och det tar absolut längre tid att dela upp det i trådar, och tid är pengar som man säger. Och faktumet att förmodligen 99% av världens datoranvändare (nej det är ingen officiell siffra, min extremt grova uppskattning) har inte mer än 4 kärnor i sin dator gör att hela scenariot blir totalt kontraproduktivt.

Trädvy Permalänk
Medlem
Plats
Jönköping
Registrerad
Aug 2011
Skrivet av Ratatosk:

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

Jag är inte bitter, men jag ska aldrig stödja dem ekonomiskt igen.

Framförallt inte eftersom det yttrades av John Carmack som någon slags "ursäkt" till varför Rage hade allvarliga tekniska problem vid releasen. Kul att de gillar Ryzen, men det här uttalandet är bara fjäsk för PC-spelare, imo.

http://xkcd.com/386/
http://readthefuckingmanual.com/
http://en.wikipedia.org/wiki/Megahertz_myth

”Alltså vad är det med grafikkortsmakare och bokstaven X? Det är precis som med dansbandsmusiker och bokstaven Z.”

Trädvy Permalänk
Medlem
Registrerad
Okt 2005
Skrivet av Jackbob:

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?

För det första så finns det gott om spel som utnyttjar fler än 4trådar. För det andra så är det framförallt CPU-delen och inte GPU-delen som är flaskhalsen i konsollerna (speciellt för PS4). Och det är framför allt här som de har problem med FPS:n, och det är därför de bara har ökat upplösningen men behåller 30fps på Pro i de flesta titlar. https://www.google.se/search?q=ps4+cpu+bottleneck&oq=ps4+cpu+...

Man kan klaga på mycket men GPU:n i PS4 drar ungefär vad som är rimligt för formfaktorn/prisklassen, och vid release var den knappast utdaterad när det kommer till prestanda/w. Så där gjorde de ett bra val, även om man kan tycka att den är klen i jämförelse med annan hårdvara. Att slänga in en CPU med så låg singeltrådprestanda var dock kanske inte det bästa valet... Såhär i efterhand kanske det hade vart bättre att gå åt andra hållet, sandybridge etc håller ju fortfarande idag så kanske hade vart bättre att satsa på en stark CPU-del sen uppgradera GPU delen allt eftersom, för att hålla kompatibilitet mellan generationerna då grafik är mycket lättare att skala. Dock kanske det inte fanns nå bra alternativ från AMD? Är även därför jag är lite besviken på Pro/Scorpio. Hade hoppats på att de skulle vänta lite och köra en 16nm SOC med 4/8 ryzen och polaris direkt istället för att halta med den där hopplösa CPU-delen.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av Jackbob:

Jag är bekant med både merge sort och fibonacci. Fibonacci är ju för det första ett extremfall där det till och med tog åratal innan det kom en algoritm som inte var rekursiv.

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; }

Skrivet av Jackbob:

Merge sort går ju faktiskt utmärkt att skala för 8+ kärnor bara du har N som överstiger iaf hundratal. Och har du inte det så går sortering på en bråkdels sekund ändå.

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å.

Skrivet av Jackbob:

Men oavsett så är det väldigt konstig jämförelse med en spelmotor. Detta är enskilda algoritmer som du jämför med tusentals(?) algoritmer som ska köras på en spelmotor, dessa går naturligtvis att parallellisera. Är det helt trivialt hur det ska göras? Nej inte alltid. Men som vissa i detta forum påstår att det skulle vara nästintill omöjligt att dela tusentals algoritmer på mer än 4-6 kärnor är ju fullständigt sagolikt fel helt enkelt. Och det är allt jag säger, inget mer.

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.

Skrivet av Jackbob:

Och fortfarande, du missar min poäng fullständigt du också. Största anledningen till att det är så som du beskriver är ju för att alla spelföretag vill tjäna pengar, och det tar absolut längre tid att dela upp det i trådar, och tid är pengar som man säger. Och faktumet att förmodligen 99% av världens datoranvändare (nej det är ingen officiell siffra, min extremt grova uppskattning) har inte mer än 4 kärnor i sin dator gör att hela scenariot blir totalt kontraproduktivt.

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.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Plats
Norrlands skogar
Registrerad
Mar 2014
Skrivet av Yoshman:

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?

Trädvy Permalänk
Entusiast
Plats
Göteborg
Registrerad
Nov 2002
Skrivet av Yoshman:

...
För att nå dit med spel måste man rätt ordentligt ändra vad spelmotor faktiskt beräknar, för dagens spel är inte i närheten av att ha tillräckligt teoretisk parallellism att skala bra till 6-8 kärnor. Däremot är spel redan designade så att de kan utnyttja alla CPU-trådar som finns, men vinsten att gå från 4->6 eller 4->8 kärnor är väldigt liten.
....

Skrivet av Yoshman:

...
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.
...

@Jackbob:

Om spelmotorer slopar rastererings-renderaren till fördel för en raytrace-renderare där den använder t.ex. en bi-directional pathtracer algoritm som MLT, hade det varit en bra lösning tro på att utnyttja flera kärnor för spelsammanhang?

Ett exempel är Maxwell Render, en MLT renderare, som skalar till 95% på 32 core CPU.
Raytrace generellt brukar skala till en hög faktor runt 90% och uppåt.

Trädvy Permalänk
Medlem
Plats
Norrlands skogar
Registrerad
Mar 2014
Skrivet av SolidReactor:

@Jackbob:

Om spelmotorer slopar rastererings-renderaren till fördel för en raytrace-renderare där den använder t.ex. en bi-directional pathtracer algoritm som MLT, hade det varit en bra lösning tro på att utnyttja flera kärnor för spelsammanhang?

Ett exempel är Maxwell Render, en MLT renderare, som skalar till 95% på 32 core CPU.
Raytrace generellt brukar skala till en hög faktor runt 90% och uppåt.

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

Trädvy Permalänk
Hjälpsam
Plats
Karlskoga
Registrerad
Jan 2007

@Yoshman: Nackedelen med works stealing scheduler, som jag ser det, är att den inte kan förutse hur mycket kommunikation som behövs mellan objekten, de som har hög sådan läggs ju med fördel på samma kärna.
Att fördela ut de viktigaste objekten manuellt kräver inte så mycket, allt som krävs är en typ av tabell, fungerar utmärkt med en enkelt textfil.
De mer lågintensiva processerna kan Windows egen scheduler fördela.

AMD Ryzen 7 1700 | Vega RX 64 Super | 64 GB Corsair @2933 MT/s | https://valid.x86.fr/fgqnte | Stockkylaren | Bitfenix Whisper M 750W.
AMD FX8350 | Polaris RX 460 4 GB | 32 GB Kingston ECC | https://valid.x86.fr/0q5pkm | Cooler Master V 700W.
HTPC | https://valid.x86.fr/ez1zxw |

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av Jackbob:

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

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.

Skrivet av Ratatosk:

@Yoshman: Nackedelen med works stealing scheduler, som jag ser det, är att den inte kan förutse hur mycket kommunikation som behövs mellan objekten, de som har hög sådan läggs ju med fördel på samma kärna.
Att fördela ut de viktigaste objekten manuellt kräver inte så mycket, allt som krävs är en typ av tabell, fungerar utmärkt med en enkelt textfil.
De mer lågintensiva processerna kan Windows egen scheduler fördela.

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.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer