::: AMD Zen Samlingstråd :::

Såg det klippet nyss. Men det verkar som om 1700 (utan X) är den bästa då den överklockade tempen är klart lägre än de andra i hans test

Edit:
Fick uppdatera mitt köp igen . Lade till 1700 istället för 1700X

Spel skiljer sig på en väldigt fundamental punkt mot saker som Queen-chess, 7-zip, kompilering och det mesta andra tester för heltal. Återkommer till det.

Kan först nämna att jag känner mig rätt mycket mer bekväm i att göra utsagor kring spel, saker som kretsar runt operativsystem, webservers och parsers då det är alla saker jag jobbat eller jobbar med programvaruutveckling kring. Har under senare år jobbat väldigt mycket med utveckling av program som INTE är "embarrassingly parallel" men där man ändå vill dra nytta av multi-core, har utvecklat väldigt många framgångsrika algoritmer kring just synkronisering så borde förstå detta område rätt väl (alt. ha extremt tur att lyckat göra rätt utan att förstå varför...).

Är däremot ingen hejare på schack, kan nätt och jämt reglerna och har än mindre skrivit en schack AI. Fick därför gå på beskrivningen av vad Queen-chess testar, där stod det att testet var en bra indikator på kvalité av branch-predictor. Att det är mycket villkorad körning i en AI är uppenbart även för mig, vad jag däremot inte kunde bedöma är om det faktiskt finns en mönster i dessa villkor som en CPU kan lära sig. Här borde jag kanske tänkt tillbaka på tiden som spelprogrammerare (men det ligger ~15 år bakåt i tiden för min del...), spel AI är ett exempel på något där CPUer normalt inte kan förutspå hopp för man vill ha ett relativt stort mått av slumpmässighet här!

Visade sig att Queen-chess absolut är något som testar villkorade hopp på en extremt nivå. Gillar sådana tester då de ger en renodlad bild av en specifik detalj. De är däremot inte representativ för någon form av genomsnittlig prestanda. Detta, ihop med vetskapen att det är en AI samt det du visar att det även skalar perfekt med antal CPU-kärnor, visar dock väldigt bra vad Queen-chess faktiskt testar

Visa innehåll

Dold text

Det är ett perfekt test av branch-misprediction-penalty! SMT är lysande i fall där man får mycket "stalls", i det läget blir hela CPU-kärnan underutnyttjad vilket betyder att det finns massor med prestanda att använda för en extra CPU-kärna (detta är ett fall där POWER8 rimligen krossar Ryzen och Core med sina 8 trådar per kärna).

Vad detta visar är att Ryzen är precis lika bra som Core att hantera felspekuleringar, vilket tyder på att den effektiva längden på kärnans pipeline är väldigt snarlik mellan dessa designer. Var just då spel ofta innehåller relativt mycket villkorade hopp som inte kan förutsägas som Nintendo valde en CPU-design för GameCube, Wii och Wii-U som inte ens försökte förutsäga hopp utan den var optimerad för att ha extremt låg branch-misprediction-penalty i stället (vilket tyvärr gjorde designen hopplös att klocka högt).

Men tillbaka till spel. Vad är den fundamentala skillnaden här? Spel kan använda många CPU-kärnor men de är absolut inte "embarrassingly parallel"! DÄR ligger en enormt viktig skillnad jämfört med nästan alla andra saker som testas då det betyder att kostnaden för att synkronisera jobb mellan CPU-kärnor blir en väldigt relevant faktor. Detta är precis vad jag jobbat väldigt mycket med senaste åren, d.v.s synkroniseringsbiten inte spel.

Rätt säker att jag även kan förklara varför Ryzen tappar mot Core i DX12, men skulle vilja se lite mer tester här innan jag slår fast något allt för säkert här. Även detta har med synkronisering att göra.

Spel är inte på något sätt ett avvikande värde. Tittar man på JavaScript, som är primärt heltal då själva virtuella maskinen är enbart heltal men i testfallen använder JS-programmen i vissa fall skalära flyttal, så ligger ju Zen strax under Sandy Bridge i IPC. Tittar man på enkeltrådprestanda (d.v.s. IPC * frekvens) ligger faktiskt Ryzen lite mer efter Kaby Lake än vad Piledriver låg efter Sandy Bridge. I IPC är dock skillnaden mindre då Piledriver var högre klockad medan Kaby Lake är högre klockad idag.

Visa innehåll

Dold text

Det som lyfter Ryzen i heltal, vilket också var helt väntat givet designen, är att man har 8 kärnor samt att SMT i de flesta fall ger en större boost än på Core.

För heltal verkar enkeltråds-IPC ligga strax under Sandy Bridge.
För heltal verkar multitråds-IPC för sådant som är "embarrassingly parallel" ligga på Ivy Bridge nivå (och just i detta fall är det hyfsat stor skillnad i IPC mellan SNB och IVB, den senare fick en del förändringar i front-end som boostade just detta fall).

Om man tittar bakåt i denna tråd är detta precis vad jag förväntade mig efter att man presenterade Zens mikroarkitektur. Är ändå positivt överraskad av Ryzen då IPC i sig är irrelevant, det som spelar roll är IPC * frekvens och frekvensen hamnade högre än vad jag själv trodde!

Men kanske dags för de som hävdat att Intel bra latat sig erkänner att de kanske inte var helt rätt ute. Intels och Apples CPUer har en heltals IPC som fortfarande är generationer före alla andra. Det finns en hård gräns för hur mycket IPC som kan extraheras ur en enskild instruktionsström, dessa två företag kan lägga obscena resurser på FoU men de ligger idag väldigt nära den teoretiska gränsen för IPC med skalära heltal. Det "positiva" (om man vill se det så) är att övriga lär närma sig med tiden då ledarna är väldigt nära väggen nu!

22 GB/s CCX<->CCX bandbredd kommer tydligen från AMD och nämndes vid GDC, länk. Och om man som mig inte begriper franska.

22 GB/s är inte en fix gräns, utan den faktiska bandbredden är exakt samma som bandbredd per kanal mot RAM då hela Infinity Fabric delar klockdomän med minneskontroller.

22 GB/s är då DDR4 2667MT. Jag skriver alltid MT (megatransfers) och inte MHz då klockan för DDR är halva denna siffra.

Att Infinity Fabric delar klockdomän med RAM kan nog också förklara varför det är så pass struligt att köra RAM på riktigt höga frekvenser, är inte bara RAM-bussen man klockar upp!

AMD visade upp denna bild på GDC

Den förklarar också varför latens mot RAM är relativt hög, högre än Core-serien med som använder RAM med samma timings. Minneskontrollen sitter inte i CPUn, den är kopplad till Infinity Fabric.

Varje CCX är en klient till Infinity Fabric. Varje access mot RAM måste därför gå både till den andra CCX-klinent samt RAM och faktiskt latens blir tyvärr latens av det anrop som tar längst tid. Man gör i alla fall båda anropen samtidigt, rent logiskt vill man egentligen först fråga den andra CCX om det ligger cache där, annars gå mot RAM.

"In practice, a memory access for the processor does not take place in isolation. When the processor needs a data, it will begin by querying its cache hierarchy to see if the data is up-to-date. If this is the case, it will be read directly and no memory request will be made. The double partition of the L3 of Ryzen complicates things however. When a data is required, and after checking inside the CCX, the core will send two requests simultaneously, one to the other CCX, and the other to the memory controller. The two operations take place simultaneously (waiting for the response of the other CCX would be much too penalizing), but they impose an additional cost. AMD engineers have confirmed that we probably need to look at this side to explain the latency, even if the manufacturer has remained rather vague."

Latensen mellan CCX blir därför samma som mot RAM, det finns ingen dedicerad CCX<->CCX kommunikation utan Ryzen är verkligen två st 4 kärnors CCX som delar RAM.

Är också detta som nog gör att L3$ latens inte blir korrekt i AIDA. Ryzen har inte 16 MB L3$, går inte ens att göra ett syntetiskt fall där en kärna ser 16 MB L3$. Man har 2x 8 MB cache, så när AIDA mäter latens måste den vara medveten om att L3$ ska behandlas som 8 MB.

Mätning av latens för L1$, L2$ och RAM borde däremot vara korrekt.

Finns det inte syntetiska benchmarks för skalära heltal? För att svara på den frågan måste man inse att det är ungefär som att ställa frågan: finns det inte exempel på hur man räknar matematik?

Svaret är absolut ja, finns massor med sådana benchmarks. Problemet är att flaskhalsen för skalära heltal är extremt mycket mer varierad jämfört med skalära flyttal och vektoriserade flyttal/heltal.

De fall som är mest äpplen mot äpplen är de fall som skalar perfekt med CPU-kärnor, d.v.s. de fall som "embarrassingly parallel". Några sådana är 7-zip, Win-RAR och kompilering.

Men spel och de flesta desktop-program som kan utnyttja många CPU-trådar är INTE "embarrassingly parallel", så ovan är ingen bra indikator på vad man kan förvänta sig där.

Samma sak gäller "multi-taskande". Det ligger någonstans mellan dessa två fall. LinusTech hade ju något fall som kallades för "heavy multitasking" och där låg E-serien i topp, var en bit ner till R7-1800X som bara låg en hårsmån före i7-7700K.

Multi-tasking är något som inte alls skalar så väl med CPU-kärnor som visa i denna tråd försöker påskina. "Heavy multitasking" fallet är onormalt CPU-bundet, i lite mer normala fall (d.v.s. fall som är mer I/O-bundna) kommer antagligen i7-7700K hamna i topp då högre enkeltrådprestanda normalt gör att I/O-enheter kan presterar något närmare sin maximala kapacitet.

@Yoshman: Just trådfördelning över CCX verkar lite lurigt precis som dom testar på anand, då dom kör 8+8 och håller dom separata i belastning så ökade prestandan ganska mycket (förutsatt belastning kunde delas i 8+8). När windows då pingpongar trådar mellan kluster så kommer det bli prestandatapp jämfört med att hålla tråden kvar inom samma kluster, också visat i tråden där.

Grön stapel är enskild CCX användning på Ryzen

Många som testar draw calls på Ryzen med HLSL instancing från nVidia och tycker att det presterar skit men där har man lite samma problem, om jag på min 2600k forcerar HLSL att bara använda två fysiska kärnor (två trådar som används av programmet) så ökar min fps en smula (23->24fps, 1ship 16000 rocks, instancing off)), på Ryzen ökar det med praktiskt taget det dubbla när man forcerar till två fysiska kärnor inom samma kluster.

Frågan är då hur pass mycket som kan göras för att förbättra hur trådar fördelas över hårdvaran med ny mikrokod/uefi/drivare/winpatch?

Vill bara meddela att mitt asus crosshair VI hero är brickad och att det inte var mitt fel. Helt plötsligt när jag skulle starta upp datorn i morse kom det upp i dos att bios mitt uppdateras fast jag inte ens var inne där! Jag väntade i 20 min inget hände, värsta skumma glitchen.

Var tvungen stänga av datorn, när ja sedan satt på den igen var den stendöd. Testade resetta cmos, tog ut batteri osv. Inget hjälpte.

Pratade med inet idag dom ska skicka ett nytt men sjukt irriterande. Vill egentligen inte ha ett till asus hero om dom är så buggiga.

Skickades från m.sweclockers.com

@SectionX2: Har inte Asus någon form av nöduppdatering av UEFI? du laddar ned UEFI, ger det ett visst namn lägger upp det på en sticka och bootar med sticka i.

edit 17500 inlägg, tjoho, jag har inget liv!

edit 2
Kapitel 3.11.3, sidan 3-28.
http://dlcdnet.asus.com/pub/ASUS/mb/SocketAM4/CROSSHAIR-VI-HE...

Va fan, mitt gjorde exakt likadant!
Asus, vad håller ni på med..?

@SirMacke: va i helvete. Detta borde bli en sweclockers nyhet.