::: AMD Zen Samlingstråd :::

Det vore ju onekligen lite underligt om AMD släppte en ZEN2 som var sämre än den första

Kom från en i5 4670k@4.4 ghz och har precis börjat spela lite efter ett par dagars tinkering. Har bara provat Playerunkown's Battleground, men herregud vilken skillnad i flyt. Det är ett helt annat spel med flera cores/threads.

Har ju diskuterats om att Ryzen skulle fungera sämre i DX12 med Nvidias grafikkort.
Verkar inte gälla speciellt Ryzen, utan även för Intel med många kärnor, med senare drivrutiner skalar inte grafiken med fler än fyra.
Tidigare skalade grafiken med fler kärnor, även om den överlag fungerade sämre i DX12, det verkar som att en del av Nvidias optimering var att begränsa skalningen till fyra kärnor.

https://forums.anandtech.com/threads/ryzens-poor-performance-...
I praktiken har detta väldigt liten betydelse eftersom nästan alla spel är GPU-bundna inte CPU-bundna, men det kan hjälpa till att förklara vissa testresultat.
Och i praktiken tjänar även en i7 6900k på senare tids optimering.

Lite sent svar, har varit bortrest ett tag...

Notera "North Bridge Clock" för i7-7700K, finns ingen "north bridge" sedan Core2 men verkar som AIDA64 listar ring-bus frekvensen i detta fält. Verkar faktiskt som i7-6600K och i7-7700K har samma ring-bus frekvens och därmed samma frekvens på L3$. Så latens per cykel är lägre för Intel.

Sedan är det helt irrelevant att räkna om latens till en annan frekvens. Kolla Apple, de har 3 MB L2$ och i cykler matchar den Kaby Lake (12 cyklers latens). En 3 MB cache matchar alltså en 256 kB cache sett till antal cykler, har ju hävdat att storlek och latens står i motsatsförhållande! Det är absolut möjligt att ha lägre latens i cykler om man inte designar för en väldigt hög frekvens, RAM är ju ett väldigt bra exempel på det där latens i cykler har tickat uppåt med tiden. Dock har latens i wall-clock-time legat rätt konstant och det är den viktiga parametern.

Vet inte hur mycket jag litar på mätningar kring cache, kolla in resultatet TomsHardware fått (och där konstaterar man att de stämmer med AMDs officiella siffror, däremot säger Intel inte mer än att latens beror väldigt mycket på saker som accessmönster och liknande)

Har skrivit ett eget program som mäter cache/RAM bandbredd (random access pattern, annars plockar ju bara prefetchen det hela), testat på en i7-6770HQ (modell med eDRAM). Får lägre värde för L1$ jämfört med AIDA64, men får ~370 GB/s som läs-bandbredd i L3$ (vilket är rätt mycket högre än AIDA64). Kan få liknande siffror som AIDA64 om jag använder 128-bitars mov:es (SSE) i stället för 256-bitars (AVX). Men både Linux och Windows standardbibliotek använder ju AVX för saker som memcpy() (förutsatt att man flyttar tillräckligt stora block) på modeller som har det, så "rätt" siffra får man ju med 256-bitars moves.

Och viktigast: alla latensmätningar man ser mäter ju bara en enda aspekt, "load-to-use". D.v.s. latens för en cache-hit. Skrivit minst en gång (antagligen flera gånger) i denna tråd att "load-to-use" latensen påverkas inte av att cache-designen är inkluderande kontra icke-inkluderande.

Ryzens cache-design (L3$ är icke-inkluderande med avseende på lägre nivåer) är en fördel för sådant som är "embarrassingly parallel" då den effektiva cache-storleken blir större.

Intels cache-design (L3$ är inkluderande med avseende på lägre nivåer) är en fördel för program där trådar måste kommunicera med varandra då L3$ kan användas som ett snoop-filter och latens för att skriva till en adress någon annan kärna nyligen läst/skrivit till blir klart lägre. Detta är med största sannolikhet orsaken till varför i7-6900K tenderar att skala bättre än Ryzen 7 i program som inte alls skalar perfekt med CPU-kärnor, men där man ändå har viss skalning (t.ex. spel).

Ingen cache design är alltså konsekvent bättre/sämre, de är optimerade för olika användarfall. Just detta diskuteras i denna väldigt intressanta pod-cast med David Kanter (antagligen den mest kompetenta CPU journalist som finns just nu). Kanter verkar också hålla med mig på en punkt som stöts och blötts väldigt mycket här: för de flesta desktop-laster är färre snabbare kärnor > fler långsammare.

Konkret exempel som nämns: man spöar inte Apples CPU genom att sätta ihop två 10-kärniga Mediatek SoCer, man kan bara spöa Apples CPU genom att bygga en snabbare två-kärnig modell. Fast det är så svårt och dyrt att ingen realistiskt kommer lyckas med det inom överskådligt tid (långt svårare att öka IPC jämfört med att öka antal CPU-kärnor). Övertygad om att Apple kommer gå om Intel i IPC, inte med jättemycket och man kommer inte kunna klocka lika högt i närtid. (ARM64 är inte magiskt, bara lite bättre designad jämfört med x86, i slutändan finns samma gräns där i form av: det finns en begränsad parallellism i varje instruktionsström och man är redan väldigt nära denna gräns).

Jag vet inte om det postats och orkar inte gräva igenom tråden (alla postar ändå videos om och om igen i 3 trådar eller så) men jag kom på random över ett spel som inte ofta är med i benchmarks, Rocket League... Alla snackar om DX11 vs DX12, men inte så många går på DX9 titlar.

Konspiration eller är Nvidia drivrutiner verkligen *så* dåliga?

Fan kan dom inte komma med Vega än, suck... Matchar det ett 1080 köper jag ett direkt och en Ryzen. Men sittar man på ett 1060 idag är det ju meningslöst.