AMD lanserar Ryzen 5 7600X3D – exklusivt för Microcenter i USA

Känns inte som att det är en CPU en gamer köper ändå. man vill gärna ha 8 kärnor till spelen idag. Men det finns väl ett gäng 7800X3D med defekta kärnor som de vill kränga iväg som 6-core.

Idag kanske det må vara så, men om ett år eller liknande är ju dock frågan?...

Lite just det jag tänkte på, att alla kanske inte har den möjligheten och därmed vill "framtidssäkra" för ett par år framåt och då kanske 6 kärnor inte är tillräckligt. Idag ja, men om ett år?...

Nej nej, det förstår jag att det inte händer mycket på något år... det jag mer syftade på är att med tanke på att det finns 8+ kärniga CPUs idag, så kanske fler spelutvecklare börjar optimera för just det. Och då kanske det inte är det bästa/bästa investeringen att köra på en 6 kärnig idag och att man kanske inte har möjligheten att uppgradera kortare än vartannat år eller liknande. Mer så min tankegång går

Dessa är det nog ganska begränsad tillgång på. Alltså kisel som efter lyckad tillverkning som inte når upp till kraven på 7800X3D, de flesta sorteras bort innan de behöver bli en sån här produkt. Det är därför den blir regional. Liknande har hänt många gånger i Kina och på andra platser

Om behovet av 8 kärnor uppstår om2-3 år kan du ju byta till en beg 9700x eller 9900x rätt billigt. Alternativt köra på framtidens motsvarighet och även få en förhoppningsvis stor boost per kärna. De allra flesta spelarna klarar sig fint med ryzen 5 eller core i5.
Däremot tycker jag det är dags för amd att öka ryzen 5 till 8c16t och ha 6c12t till ryzen 3 istället. Men det lär inte hända så länge de säljer bra.

Hade varit nice om de uppdaterade ccdn till 10c/20t så kunde de ändra hela stacken

Eller bara ta zen 4/5 C Och göra en x3d cpu av dem som har 16 kärnor per ccd.

Precis vi ser ju att Xbox 360 (2005) med sina tre kärnor var en lyckad konsol, ofta var ju Xbox versionen av spelen mycket bättre än den på PS3 trots att den hade 7 kärnor (6 för spel).
Viktigaste är ju att det är enkelt för utvecklarna att nyttja kraften. För programmerarna är människor och människor är lata samt har begränsat med tid att utföra arbetet på.
Det är ganska troligt att det är enklare att optimera mot få trådar.
Sen med One mot PS4 var det ju i stort sett samma grejer och i grunden, då var det istället ps versionen som oftast/alltid gav en bättre upplevelse eftersom den hade bättre gpu.

Jag menar som tillverkare.. Om jag har bara några få exemplar. Så klart väljer jag en säljare.

Svårt att parallelisera? Ja!
Inga stora steg i framtiden? Skulle snarare säga att det är tvärtom.

Vi står faktiskt inför ett paradigm-skifte med dataorienterad programmering och ECS (Entity Component System) som resulterar i att det blir lättare att skriva parallelliserad kod. Men visst huvudtråden förblir ändå en begränsande faktor, eftersom arbeten måste startas och synkas med den, detta för att det är enbart huvudtråden som får ha åtkomst att göra ändringar i minnet.

Men när programmerare väl vänjer sig vid dataorienterad programmering, så kan vi förvänta oss ändå ganska enorma framsteg.

Här är ett eget exempel på vad man kan åstadkomma med ECS på en 16-kärning Ryzen 5950x.

Bifogar även en bild from HWMonitor som visar hur effektivt mitt demo nyttjar ALLA kärnor och trådar på CPU:n.

Amerikanerna har lyxiga priser, MicroCenter hade nyligen en kampanj där man kunde köpa 7800X3D och valfritt B650 moderkort för 240 dollar… *Cries in 4400kr för bara 7800X3D*

Ryktet säger väl att AMD kommer öka kärnorna när zen6 lanseras.

Det ryktas om att toppmodellen får 32 kärnor.

Smalt use-case skulle jag inte direkt säga. DOTS, eller mer fundamentalt, Dataorienterad Design/Programmering är inte så mycket en teknik som det är ett helt annat koncept och sätt att programmera och utveckla mjukvara. Den fundamentala aspekten av det är att man skriver kod som ligger väldigt nära CPU:n och kan därmed mer effektivt nyttja cache-minnet, vilket i sin tur betyder mindre läsning/skrivning till RAM-minnet.

Kort och gott, det är en paradigm precis som Objektorienterad programmering, men där fokus ligger på att prioritera prestanda i realtids och data-intensiva applikationer.

Nu har jag inte knåpat med DOTS på nästan ett år, men sist jag höll på så hade man ganska nyligen officielt släppt DOTS och gjort om en hel del grejer. Vilket gjorde det till ett mindre helvete att försöka lära sig, då 99% av guider och läroverktygen som fanns, var utdaterade.

Men som exempel på hur det skulle kunna användas i ett spel som GTA6, så skulle man faktiskt kunna befolka en stad på riktigt. Dvs att varje NPC är beständig och fortsätter att utföra sina rutiner, medan du själv är i en helt annan stadsdel. Med mer komplex AI så öppnar det för intressanta möjligheter, tex du skulle kanske vara snäll mot någon random NPC och kanske du oväntat får hjälp någong gång när du blir anfallen. Är du istället taskig så kanske han springer och samlar ett gäng kompisar som anfaller dig längre fram. Det viktiga är att datan kan organiseras så att den får ett väldigt litet avtryck i minnet, och kan effektivt bearbetas.

I mitt projekt så begränsade jag mina entiteter till bara 3000, för att kunna skapa en så rättvis jämförelse som möjligt med vanliga GameObject NPC:er.

Edit: Bör också understryka att detta inte bara är rymdskepp som rör sig på måfå, utan en fulländad autonomisk styrningsmodell som flyger mot mål, undviker hinder och ägnar sig åt flockbeteende genom att konstant hålla koll på avstånd och rörelseriktningen av sina grannar (Vilket är där det snabbt kan bli väldigt tungdrivet i täta klungor) Hela den AI:n är då paralelliserad med DOTS/ECS genom att exekvera ett arbete för varje individuell NPC.

Okej det låter ju bra.

Data orienterad design och data orienterad programmering är två separata koncept. De kombineras typiskt i DOTS/ECS, men båda kan användas helt separat. Använder själv DOP hyfsat ofta, mer sällan DOD då tenderar ge ett resultat som inte är lätt underhålla i mer "normala" miljöer.

DOD handlar om att fysiskt placera data på ett sätt som blir effektivt att hantera på tänkt maskinvara. Är väldigt mycket detta burst-kompilatorn fokuserar på i DOTS/ECS.

DOP handlar om att separera representation av data (där man kan applicera DOD, men absolut inget krav) from hur man transformerar data (i.e. koden som gör beräkningar på någon data). DOP och OOP är två väldigt olika sätt att designa program. Man kan man använda OOP+DOD, vilket nog finns i vissa spel (hand-optimerad SoA).

Detta är ett typexempel på något som inte kommer fungera bra om man vill inte vill att hela staden ska mer uppföra sig som en svärm av insekter som i grunden följer samma algoritm. I.e. tekniken tillåter inte unikt beteende för väldigt många agenter!

En huvudingridiens i detta system är jobbet som burst-kompilatorn gör och det handlar primärt om att transformera data till SoA och därmed bygga logiken så den passar SIMD.

I detta fall är SIMD mindre om att öka peak-beräkningskapacitet. Spel (rent generellt program som använder objekt-orienterad-programmering i hög utsträckning) har typiskt väldigt låg genomsnittlig IPC p.g.a. väldigt oregelbunden minnesaccess.

Genom att applicera samma algoritm på väldigt stor mängd data som ligger ordnat "på rad" i minnet gör det trivialt för CPUn att förutsäga framtida minnessaccesser. Det är huvudorsaken till att man får en sådan enorm prestandavinst.

X3D CPUerna kan bara flytta det problem spel har en bit, men det finns fortfarande en hård begränsning i hur mycket data man har snabb access till.

Det man gör med burst behöver ingen stor cache, istället utnyttjar den i huvudsak lokalitet i tid + har ett accessmönster som ger CPUn maximal möjlighet att "gömma" latens för saker som dras direkt från RAM (så här lär 7700X vara lite snabbare jämfört med 7800X3D då en nackdel med stor L3 är högre latens mot RAM + 7700X klockar högre).

Just detta är ett exempel som fungerar lysande inom ramen för denna teknik. Varje agent aggerar "oberoende", men alla agenter använder samma algoritm vilket är en förutsättning för att det ska bli snabbt.

Gissar att ditt fall ser samma beteende som mitt exempel: även om man kan effektivt köra över många kärnor är det den klart mindre förklaringen till den enorma prestandan. Huvudanledningen är jobbet burst-kompilatorn gör, det tar problemet från "CPU väntar på data från L3$/RAM 99 % av tiden" till "data finns tillgängligt i L1$ lagom till när de behövs så länge bandbredden är nog".

Testade 4 olika kombinationer

• Enkeltrådat + ingen burstkompiler: <1 FPS

• Flertrådat (här var det 100 % på alla 32 trådar!) + ingen burstkompiler: 3-5 FPS(!!!)

• Enkeltrådat + burstkompiler: ~40 FPS

• Flertrådat (här verkar det räcka med 10 trådar/kärnor) + burstkompiler: ~60 FPS

Så huvudvinsten för "svärmbeteende" är inte användanet många kärnor, det är primärt DOD som fixar den extremt dåliga IPC man annars får med ett så pass stort "working-set", det är långt större än cache i CPU.

Trevliga med DOTS/ECS är att man kan använda de delar som "make sense" för det specifika fallet. Men effekten av att använda många kärnor är inte alls lika imponerande som effekten man får av DOD+burstkompiler (som långt mer handlar om SIMD + förutsägbart access-mönster av data).

Det lockande med att använda många kärnor är att det är MIMD, d.v.s. effektiv användning av detta möjliggör betydligt fler agenter med helt unika beteenden (men kommer inte skala till de nivåer man om man begränsar det till svärmbeteende).

TL;DR det är ett smalt use-cases (det accelererar svärm-beteende där många unika saker följer samma algoritm), men då spel är helt påhittade miljöer lär vi säkert få se väldigt spännande användning av tekniken!

Unitys job-system är nog en väldigt bra indikation kring varför färre starka kärnor nog alltid kommer vara att föredra i spel över många kärnor: av lite olika praktiska skäl måste varje "job" vara så befattat att det körs klart under innevarande frame.

Effektivt utnyttjande av många kärnor är enklare ju mer sällan man behöver kommunicera mellan kärnor. Så det optimala här är att lägga ut jobb som tar lite längre tid. Vid 100 FPS krävs minimum två synkroniseringar per CPU-kärna per 10 ms, i praktiken får man fler då det oftast handlar om betydligt fler jobb.

Spel är i behov av låg latens, vilket tyvärr står lite i motsats till effektivt utnyttjande av många kärnor.