AMD avslöjar fler detaljer om arkitekturen Zen 2 på 7 nanometer

Adored Tv var rätt på det:
https://images.anandtech.com/doci/13547/1541532227330.JPEG

Har de? De lovade 40% högre prestanda från Piledriver. De fick nästan 50%. De lovade 5-10% bättre prestanda med Ryzen 2. Man fick nästan 15%. Faktum är att AMD har levererat mer än de lovat vid både Ryzen 1 och lanseringen av Ryzen 2.

Tycker iof. att redan idag så ligger 2700X på överkomliga priser med tanke på vad man får.

Det gör det. Vet redan nu at min 2700X kommer ligga ute till försäljning när jag lagt vantarna på min "3700X", eller vad det kan tänkas att den får för namn Så gött att kunna uppgradera och behålla moderkortet

9900X kommer den garanterat att heta!

Förstod inte vad AMD höll på med när de släppte första generationen Epyc, man hade testat samma design ett antal år tidigare i sin dual-chip Magny cours Opteron och resultatet då blev på det stora hela identiskt med resultatet nu.

Vad man har nu är "chiplets done right". En I/O-krets som hanterar RAM, PCIe etc och har kopplingar mot CPU-kretsar är en välbeprövad design. Det är i sak en tillbakagång till "front-side bus" samt en "north bridge".

Det faktum att också Intel sagt att man också kommer gå till en sådan design ihop med deras superklister EMIB

Visa innehåll

från Intels Technology and Manufacturing Day sommaren 2017

pekar ju på att även de tror på en sådan design.

Fördelen med en integrerad minneskontroller är lägre latens. Givet hur mycket AMD pratade om HPC och datacenter ser jag inte en återgång till en front-side bus och en off-die minneskontroller som ett gigantiskt problem. Bandbredd är viktigare än latens där.

Är inte alls lika övertygad om att designen är optimal för skrivbordet. Inte heller säkert att man kommer använda en sådan design för skrivbordet för det stod "Zen 2 base Epyc processor" på sliden där man visade detta

Visa innehåll

Dold text

Kul att man lägger resurser på att kunna köra AVX instruktioner i full hastighet, det är exakt vad man sa med att flyttalsdelarna numera är 256-bitars. Misstänker att vissa som hävdar att "inget använder AVX" kommer ändra åsikt inom kort

Att man tar SIMD på allvar är viktigt, rätt övertygad om att användningen av detta kommer öka rätt mycket framöver då det (nästan 20 år efter att SSE introducerades) numera finns ett enkelt och standardiserat sätt att använda SIMD optimeringar i egen kod utan att ta till assembler.

SIMD används redan väldigt inom maskininlärning, HPC och andra områden. Men där används det i form av bibliotek, har fram till väldigt nyligen varit relativt svårt för enskilda programmerare att utnyttja tekniken på ett mer generellt plan.

Även om Cannon Lake / Ice lake får AVX-512 så verkar det som Intel stannar på 256-bitars data-väg i konsumentprodukter. Så där kommer Zen2 dra jämnt med Intels modeller sett till kapacitet per kärna och per cykel. Ger dock inte så mycket för demonstrationen med C-ray som värdemätare på flyttalskapacitet på servers, C-ray använder överhuvudtaget inte SSE/AVX så man tog där helt bort Intels fördel med att serverkretsarna har 512-bitars SIMD data-väg.

Oroväckande lite nämndes om heltalsprestanda. Är ju där Zen ligger efter Skylake i IPC och heltalsprestanda är långt viktigare för majoriteten av det vi gör på skrivbordet (och server, fast då maskininlärning blir allt viktigare där flyttas även prestandafokus från heltal till SIMD).

Det enda som nämndes kring saker som påverkar heltalsprestanda var "bättre branchpredictor" (säg en CPU-release där detta _inte_ varit en av förbättringspunkterna) samt större mikro-op-cache.

Större mikro-op-cache är nog ändå viktigt för Zen. Av någon anledning har man valt en 64 kB L1I$ som är fyra set-associativ i Zen, en sådan design möjliggör inte parallell uppslagning av L1I$ data och TBL (64 kB / 4 = 16 kB och måste vara <= 4 kB för att parallell uppslagning ska vara möjligt, vilket det är för L1D$ då den är 32 kB och 8 set-associativ).

Sett någon förklaringen att man försöker kompensera designvalet av L1 instruktions-cache med mer aggressiv prefetching. Finns fall där det inte verkar fungera så bra, man faller efter Skylake rätt mycket, och andra fall där det fungerar riktigt bra. Större mikro-op-cache borde kunna minska fallen eller i alla fall lindra fallen där det fungerar dåligt då saker som ligger i mikro-op-cache i princip helt kan hoppa förbi "front-end".

En annan fördel med större mikro-op-cache är att front-end bara kan avkoda upp till fyra x86 instruktioner medan "back-end" i Zen (som förutom bredden av flyttalsdelen verkar se rätt lika ut) har totalt 10 pipe-lines (två minnesportar, fyra heltalsportar och fyra flyttalsportar). Intel har motsvarande problem i att front-end har lägre kapacitet (upp till fem x86 instruktioner per cykel) än mikro-op-cachen, men å andra sidan har man lite färre portar (fyra minnesportar och fyra heltals/flyttalsportar).

Kan verka lustigt att Skylake kan ha högre IPC trots smalare back-end, förklaringen där ligger med stor sannolikhet i att Core-serien har en central schemaläggare så man kan plocka upp till 8 mikro-ops ur en kö med upp till ~100 element medan Zen har en distribuerad schemaläggare där varje port kan plocka micro-ops ur en lokala kö med upp till ~14 element.

I fall med lite mer snedfördelad mix på instruktioner eller lite haveri i minnesportarna p.g.a. mycket cache-missar är en central schemaläggare mer effektiv. En distribuerad schemaläggare drar dock mindre ström och är väsentligt enklare att designa.

@Yoshman:

Anandtech påstår att PCIe inte ligger i det klustret, utan på varje CPU-chip.

https://www.anandtech.com/show/13560/amd-unveils-chiplet-desi...

Jag tycker att det verkar konstigt av många skäl, men tyckte att det var värt att påpeka.

I sammanhanget Intel och avkodningsbredd: Intels avkodare kan spotta ur sig totalt 5 uops. Om den komplexa dekodern får en x86-instruktion som blir 3 uops, kan det bara bli ytterligare två x86-instruktioner avkodade den cykeln, och bägge dessa måste vara sådana som bara ger en uop. AMD är lite mer flexibla här. Intels uop-cache kan också bara leverera 6 uop per cykel, och det går inte att blanda mellan cache och dekoder. Det borde dock gå att få till en svit av kod som exekverar 6 instruktioner per cykel, men tester visar att det nästan aldrig funkar, koden trillar ner på 4 i bredd. Således har Intel en annan flaskhals. De gissningar jag har sett pekar mot att bandbredden i rename är begränsad till 4 operationer per cykel, så det går bara att hålla de där 6 operationerna om 4 av dem kan ”svetsas” (uop fusion) så att det blir fyra par.

Skickades från m.sweclockers.com

Vad som är teoretisk maximal "sustained rate" är i fallet x86 rätt ordentligt irrelevant då man i praktiken väldigt sällan når över 2 x86 instruktioner per cykel i verkliga program. Högsta jag någonsin uppmätt i genomsnittlig IPC är 3,1 för Skylake och 2,2 för Zen (micro-benchmark i Python mätt med respektive CPUs "performance counter" så det ska vara ett exakt mått på x86 instruktioner per cykel i genomsnitt).

Precis som du skriver är avkodarna mer flexibla i Zen, tre av fyra avkodare i Skylake kan bara hantera instruktioner som resulterar i en uop (men dessa är i.o.f.s. väldigt vanliga i praktiken). Så flaskhalsen verkar inte ligga i avkodaren.

Dock rätt säker att heltalsberäkningar i ett skriptspråkt som Python inte är "best-case" för Zen om man vill maximera IPC-siffran. Givet hur back-end ser ut i Zen borde man få maximal IPC om man blandar heltalsberäkningar med en "optimal" mix av flyttal (där får man nog testa sig fram). Värdet av en sådan mätning kan man i.o.f.s. ifrågasätta, skulle knappast bli ett vettigt program utan bara ett sätt att maximera IPC.

Det faktum att båda designerna kan färdigställa (retire) upp till åtta uops per cykel (i Intels fall upp från fyra i Broadwell) pekar på att enda relevanta sättet att öka genomsnittlig IPC nu är att försöka få så mycket som möjligt gjort när dispatch-kön/köerna är full/fulla (vilket kan bli fallet efter olika former av back-end stalls).

Men sen finns ju numera Apples A12 att kika på. Uppenbarligen är det möjligt att skruva upp flödet genom front-end rätt ordentligt, men är fullt möjligt att det bara går på en lite vettigare designad ISA än x86...

En väldigt sannolik förklaring till varför man kanske inte lagt så mycket krut på heltalsdelen i Zen2 är ju att man redan är rätt nära taken för vad som är möjligt givet typisk x86 kod. Det är en horribel ISA som man redan lyckats baxa väsentligt mycket längre än vad nog något hade gissat för ett par årtionden sedan.

Innan 64-bitars ARM / RISC-V fanns alltid räddningsplankan att alla då existerande ISA hade rejäla grodor, så på det stora hela var ingen direkt överlägsen. Definitivt inte mer överlägsen än vad Moores lag kunde släta över på relativt kort tid... Men haveri av Moores lag och datacenter CPUer med väldigt många kärnor blottlägger verkligen svagheterna i x86 (icke-optimal minneskonsistensmodell för multicore, kärnor som tar onödigt mycket transistorer p.g.a. extremt många instruktioner som har variabel storlek, etc)!

PCIe på CPU-delen känns inte helt optimalt, men är trots allt mindre viktigt än att man nu fixat till en vettig RAM-konfiguration. 4 NUMA-zoner per socket som Epyc Naples hade var helt enkelt en nischprodukt, man hade aldrig kunna ta några större marknadsandelar med den designen.

PCIe på CPU-delen kanske ger en vink om att desktop-versionen av Zen2 kanske ändå kommer i en variant med integrerad minneskontroller? Tror en klar splitt här mellan desktop och server är att föredra. Servers vill ha massor med bandbredd och kan i många fall bättre handskas med lite högre latens. Desktop är nästan alltid primärt latensbegränsat, fördelen med integrerad minneskontroller är just lägre latens.