::: AMD Zen Samlingstråd :::

Haswell är rätt rejält mycket snabbare än Ivy Bridge på flera områden, t.ex. så är den lägre klockade fyrkärniga Xeon E3 1245v3 snabbare än sexkärniga 4960X i matrisberäkningar

Haswell är också rejält mycket snabbare än Ivy Bridge i saker som har nytta av SMT (d.v.s. inte sådant som är ALU-begränsat som t.ex. Blender och Cinebench)

Det är ju >10 % IPC-förbättringar och i flera fall höjer Skylake ribban ett bra snäpp till.

Sandy Bridge var ett rätt stort steg upp från Nehalem/Westmere, säger inte att L1I$ förändringen är den stora orsaken men det är en del av det pusslet.

För servers, där Intel numera har 99,2 % av marknaden, är lyftet från Ivy Bridge till Haswell enormt. Inte lika stort som mellan Westmere och Sandy Bridge där det låg runt 100 % för servers, men Haswell är inte långt ifrån.

Är helt övertygad om att Zen inte kommer ha det minsta problem att dra runt spel, de är ju nästan helt begränsade av GPU och man lär gå till rätt gamla Intel i5/i7-modeller för att flaskhalsen ska hamna på CPU-delen.

Första har ju nackdelen att ge högre latens.

Andra är ju identisk med Sandy Bridge och framåt, den är även "write-back" precis som Intel sedan första Pentium. Fattar inte vad AMD tänkte när det gjort L1D$ "write-back" i Bulldozer!

L2-cachen blir det kritiska, det Intel lyckas med är att göra en L2-cache som har lägre latens än vad någon annan mäktat med än. Möjligen har Apples CPUer lika låg latens i cykler räknat, men de klockar ju inte i närheten lika högt.

Angående balans så håller jag till 99 % med, Zen ser balanserad ut så när på en sak: 4 ALU / 2 AGU. Det valet är inte så konstigt när man tänker på att Jim Kellers baby var faktiskt inte Zen, det var K12 (som tyvärr aldrig lär släppas nu då AMD droppat ARM-spåret). För en RISC är 2:1 mellan ALU och AGU rätt, för x86 är det lågt och brukar vara 1:1 då många operationer tar minne som argument (vilket inte är möjligt på en RISC).

Tanken var ju att Zen och K12 skulle köra med samma back-end och olika front-ends. Ryktet säger att Keller sa upp sig då han tyckte att AMD inte prioriterade ARM-spåret nog mycket och det var spåret han fann mest spännande.

För applikationer på skrivbordet tror jag inte 2:1 splitten kommer vara relevant, på servers kan det däremot spela en större roll då det finns rätt många applikationer som är väldigt minnesintensiva där. Är inte heller någon slump att Haswell har en pipeline dedikerad för "stores", en "stores" är lättare att göra än "load". Är inte heller en slump att två pipeliens kan göra både "load" och "store" och bara en är dedikerad till "store", normalt är det ungefär 2:1 för "load" mot "store" i serverapplikationer. Finns dock fall där det är närmare 1:1 och Haswell tar båda fallen lysande.

AVX används där det behövs, vilket inte är på skrivbordet eller i serverapplikationer som kör databaser och webbservers. Med tiden kommer det komma in även på skrivbordet, men om SSE är något att gå efter så tar det nästan 10 år innan det hittar in i sådan programvara i någon större utsträckning. AVX lanserades för ca sex år sedan.

L3-cachen blir också intressant, här har ju Intel lyckats designa en L3-cache som är relativt stor men ändå har en latens helt i nivå med de flesta andra CPUers L2-cache!

Det sagt: givet informationen vi har kring Zen i detta läge går det ju överhuvudtaget inte att göra någon vettig gissning kring prestanda. Ren magkänsla säger någonstans mellan Ivy Bridge och Haswell i IPC, sedan kvarstår frågan kring hur pass högt klockad den blir. Det enda som betyder något är frekvens * IPC.

Har nog aldrig sett någon tidigare försökt hävdat att kompilering är ett syntetiskt test... Skulle jag bara få AMD att publicera ett enda test för Zen så vore det just hur den står sig i kompilering jämfört med andra modeller. Kompilering är så pass heltäckande att det inte går att "fuska" på något annat sätt än att helt enkelt göra en bra CPU-design. Sett flera göra anmärkningen att SPECInt är totalt värdelöst så när som på kompileringstestet då i princip allt annat går att göra speciallösningar för på olika sätt.

Även om Linpack är ett benchmark så skulle jag inte kalla de för syntetiskt. Man använder just detta test för att designa superdatorer för HPC då det är väldigt representativt för verklig prestanda. Sedan är resultaten jag postade tagna med Intel MKL, ett bibliotek som många använder i applikationer som jobbar med matriser eller signalbehandling.

Sunspider är absolut ett dåligt syntetiskt test om man ser det som en test av webbläsarprestanda. Sunspider, Octane samt Kraken är däremot alla riktigt bra tester för att ge en vink om generell prestanda i applikationer skrivna i JavaScript/NodeJS vilket är en allt viktigare plattform på servers och i "molnet".

Angående turbofrekvensen, jämför då 3770K (3,9 GHz turbo) och 5775C (3,7 GHz turbo) alt. kompensera för frekvensen, det är >10 % högre IPC. L4-cachen i 5775C har i princip noll effekt i dessa tester (snarare negativ då 2 MB av L3 används för snoop-information för L4 så man har bara 6 MB L3 mot 8 MB på 3770K).

Det måste vara viktigare för AMD att lyckas i datacenter och servers än att göra det på skrivbordet med Zen då det förra är både mer lukrativ och till skillnad från den senare fortfarande en växande marknad.

IPC ökning de senaste tio åren är högre än de tio år du hade innan, det som ökade prestanda innan dess var nästan uteslutande högre frekvens. Och IPC ökningen de senaste tio åren är bara pinsam om man använder t.ex. spel som måttstock då dessa, men där är ju inte CPU-delen flaskhals så en värdelös måttstock.

Skylake har högre bandbredd mot L2, vilket till viss del kan kompensera för lägre associativiteten.
Här är ändå min huvudpoäng: visst kan det fungera helt OK med att inte kunna köra TLB uppslagning parallellt med L1I$, men resultatet är en högre effektiv latens jämfört med huvudkonkurrenten.

Detta ska bli intressant att se effekten av. AMD har aldrig tidigare haft en x86 modell där inte load/store vs ALU varit 1:1. Intel har så vitt jag kan dra mig till minnes haft en modell med 3:2 splitt av ALU vs load/store (PII till Pentium M), annars har det varit 1:1.

Effekten av detta är i alla fall garanterat noll i tester som Cinebench och Blender då båda dessa är begränsade av att man endast har två flyttalspipeliens som kan göra add/mul. Framförallt Cinebench verkar väldigt hårt begränsad av detta då den får väldigt liten boost av SMT.

Lite intressant att man ändå har 2x load och 1x store kapacitet. Gissningsvis har man detta för att kapa toppar efter en cache-stall för designen kan inte upprätthålla mer än totalt två minnesoperationer per cykel.

Varför känns 2:1 lite klent? Tänk bara på denna C++ rad

    this->foo += bar;

Finns rätt många rader med motsvarande logik i typiska program, vad behövs för att köra detta?
En load, en addition och en store, om vi antar att foo inte har offset noll behövs också en adressberäkning (lea). Gissar att lea även kan köras av ALU-pipes, såg det nämnas någonstans att just denna instruktion kan hanteras i AGU (vilket även är fallet på Intel där man till och med har en separat pipeline för adressberäkningar).

Min gissning är att första förändringen man kommer göra på Zens pipeline i framtiden är att addera en ren store-pipeline. Två pipelines som kan göra load/store plus en som kan göra store matchar den design de redan har mot cache och en ren store-pipeline är mycket enklare då store:s inte behöver "snoopa" andra kärnors "store-buffer".

Såg det på ett par forum, det är ett rykte så "källa" blir ju lite svajigt. I ett av fallen var kommentaren från någon som hävdade att hen vid tillfället jobbade på AMD med just detta.

Sedan kanske värt att reda upp lite kring vad Keller faktiskt gjort: han har rimligen inte designat K7 då han började ungefär ett år innan den kretsen först lanserades. Han jobbade faktiskt bara ett år på AMD under den tiden, då var han chefsarkitekt för K8 samt medförfattare av AMD64. Första K8 modellen lanserades två-tre år efter att han slutande, vilket stämmer bra med ryktet att hans arbete med första generations Zen redan var färdigt när han slutade förra året.

Haswell kommer vara fyra år gammal när Zen lanseras, anser du att det är en krets som är obsolete idag?

Som jag skrev innan, AVX är irrelevant för applikationer på skrivbordet och många serverapplikationer. Men program som Matlab och andra där man jobbar mycket med matriser har absolut stöd för AVX redan. Anledningen är att man får en signifikant boost av prestanda så det är värt besväret. På det stora hela är det ändå nischmarknader, AMD kan inte sikta på allt direkt med Zen och flyttalsapplikationer som kan vektoriseras är en akilleshäl för första Zen-generationen.

Det man undrar om Zens L3 är om det är en LLC som täcker alla kärnor eller om det är ett sektion per fyra kärnor som die-shot pekar mot... Detta är relevant av flera skäl.

Om alla kärnor delar en LLC kan denna också används som "snoop-filter" vid cache-missar, man kan ha en bit per kärna som talar om huruvida det minnet någonsin varit cachat på en viss kärna. Det kan ge "false-positivs" men om biten inte är satt för någon annan kärna än del lokala så vinner man latens då man inte behöver invalidera andra kärnors L1D/L2.

Vidare är en LLC som delas av alla kärnor kritiskt för att relativt effektivt kunna kommunicera mellan kärnor. Jaguar-kretsen som sitter i PS4/XBO är väldigt asymmetrisk på denna punkt då det finns två grupper om fyra kärnor som delar L2 men de två grupperna har ingen delad cache. Det skiljer en ungefär en faktor tio mellan att peta på en cache-line som ligger inom samma block (som delar L2) och en som används av någon kärna i det andra blocket.

För servers är det ett mindre problem då man typiskt har väldigt många saker som sinsemellan är oberoende, så hög latens på det sättet är ingen katastrof. De applikationer på skrivbordet som faktisk kan använda flera CPU-trådar, t.ex. spel, måste tänka rätt mycket på att hålla allt som behöver dela något inom kärnor som delar LLC.

Om det är en L3 per fyra kärnor så skulle jag säga att den fyrkärniga Zen-modellen känns som det vettigare valet på skrivbordet. Eller ja, den är nog det vettigare valet oavsett bra den kan klockas högre då väldigt nära 100 % av alla desktopanvändare klarar sig mer än nog med fyra kärnor (majoriteten har absolut inga problem med två kärnor + HT även om man gör rätt avancerade saker).

@Enigma: hoppas också man får lite mer kött på benen kring Zen denna vecka. Notera att jag inte säger något absolut om hur Zen presterar, för givet det vi vet idag går det överhuvudtaget inte att göra en vettig gissning.

Faktum är att vi egentligen inte kan säga något om L2-cachen heller, vi har ingen aning om dess bandbredd i praktiken och vi har ingen aning om dess load-to-use latens (som är 10-11 cykler för Intel och typiskt 20 cykler eller mer för i princip alla andra designer).

Själv får jag inte en "warm fuzzy feeling" av AMDs val av "läckta" benchmarks, de har en historia av enorm cherry-picking... Det här är min favorit, FX-8150 är tydligen 56 gånger snabbare på något jämfört med i7-2600...

Eller den där Fury X var snabbare än 980Ti på i princip allt

Råder inga tvivel om att Zen är ett rejält lyft över förra generationen, men än så länge går det överhuvudtaget inte att säga hur den i genomsnitt kommer presterar mot Intel och då främst Kaby Lake som tydligen fått 18 % högre IPC om man ska gå på det resultat som "råkade" läcka (självklart cherry-picking från Intels sida).

Åter igen: man ska aldrig extrapolera från en punkt, vare sig det är produkter från AMD, Intel, Nvidia eller till och med självaste Apple.

@Enigma @Yoshman

@Jonathanknet: där har vi nörd-porr på hög nivå!!!

Blev så till mig att bara var tvungen att skapa en liten jämförelsetabell. Går absolut inte att säga med någon större precision hur Zen kommer presterar från en sådan tabell, men nu börjar man ändå kunna skönja en hyfsad mellan-tummen-och-pekfingret känsla. Mitt stalltips står nu än starkare att i genomsnitt hamnar IPC mellan Ivy Bridge och Haswell, men lutar nog att det är närmare Haswell än Ivy Bridge numera.

*
blir ett högre varje gång man har en lyckad s.k. macro-op fusion, vilket i praktiken är rätt vanligt då det händer t.ex. vid jämförelse följt av ett hopp villkorat på jämförelsen

Typ detta

    if (pred) {
         foo();
    }

¤
AMD har separat schemaläggare för heltal och flyttal, Intel har en som täcker båda.

#
gissning baserar det på denna bild där man har en box per heltalspipeline.

Visa innehåll

Dold text

Är inte alls orimligt då distribuerade schedulers i princip uteslutande används för ARM CPUer och andra strömsnåla modeller (som t.ex. Intels Atom). Än rimligare blir det när man tar i beaktande att "back-end" i Zen initialt även skulle användas i deras 64-bitars K12 ARM.

Fördelen med distribuerade scheduler är enklare att designa och strömsnålare än globala schedulers. Nackdelen är att beläggningen av alla tillgängliga resurser blir i genomsnitt lägre.

Även POWER8 använder distribuerade scheduler. Där är nog orsaken att kretsen är brutalt "bred" och skulle nog kostar allt för mycket transistorer med en global scheduler där. Här är jämförelsen med Hawell intressant då POWER8 har totalt 16(!) pipelines mot Haswells 8 men ändå får Haswell bättre IPC när endast en tråd används.

Edit: hade ju totalt missat det, trots alla Athlons, Athon 64 och Phenoms jag haft genom åren... Var ju distribuerande schedulers även i dessa vilket med stor sannolikhet även betyder att Jaguar har detta. Så för AMD är det bulldozer-serien som är undantaget på denna punkt (om nu Zen använder detta).

Edit2: efter gårdagens presentation är det nu klarlagt att det är en distribuerad scheduler. Så siffran 84 för Zens heltals/minnes-scheduler är egentligen sex stycken separata köer med en kapacitet på 14 var.

Känns som storleken på L2 kontra L3 är lite obalanserad i Zen givet att man nu kör med inklusive policy. När alla fyra kärnor i ett CCX jobbar så kommer ju L3-cachen bestå till 50 % av redundant information (det som ligger i L2). I en hierarki med inkluderande policy vill man normalt har rätt stor skillnad i storlek mellan nivåerna. Med exkluderande policy fungerar det helt OK att även ha samma storlek på två nivåer, något AMD historisk också haft.

Skönt att se AMD använda samma terminologi som Intel var det gäller micro-ops. Tidigare kallade AMD de interna instruktioner för "macro-ops" medan Intel kallade dem för "micro-ops". Än värre blev det när Intel kallar två x86-instruktioner som slagits ihop för "macro-op fusion" (en finess som kom med Core2).

Några nyheter, en väldigt överraskande kom ut från gårdagens presentation.

Det är inte inkluderande cache på Zen. Påpekade redan tidigare i tråden att storleksförhållandet mellan L2 och L3 kännes lite obalanserat för en inkluderande design, förklaringen är alltså att L3-cachen är en s.k. victim-cache för L2 (det som måste slängas ut ur L2 placeras i L3, när något hämtas från L3 in i L2 så tas det bort ur L3), precis som på alla tidigare AMD-designer med L3-cache.

Det som verkar vara inkluderande är L1 i L2, något som i så fall lite mildrar latensen vid cache-miss, räcker att endast undersöka (snoop:a) alla L2-cachar. Då L3 ändå inte delas av alla kärnor, den delas mellan fyra kärnor i ett CCX, skulle den ändå inte räcka som snoop-filter, men nu blir ju cache-missar även inom en CCX rätt mycket dyrare än på Intel.

Som jämförelse är Intels L1 och L2 inte strikt inkluderande då L2-cachen då skulle bestå av 25 % redundant information (L1I$ och L1D$ är båda 32 kB). Det påverkar ändå inte snoop-latens då L3 är strikt inkluderande av allt som ligger på lägre nivå (och L1/L2 tillhör endast en kärna), vilket betyder att en miss aldrig behöver titta i någon annan cache än den lokala L1/L2 samt L3 för att globalt avgöra att det ingen har den minnesadressen lagrad.

Rent praktiskt betyder detta inte jättemycket för arbetslaster som består av många helt oberoende uppgifter där man inte delar annan data än sådant som är "read-only" eller där data är "read-mostly" med en lås-strategi som inte består enkla lås som mutex eller liknande (dessa orsakar rejält med kors-CPU cache-koherenstrafik som kommer straffa designen i Zen).

Däremot lär mer desktop-inriktade laster som normalt kräver mer interaktion mellan kärnor (om de överhuvudtaget är multitrådade). Så gissar att om spel någonsin blir CPU-begränsade så kommer Zen skala sämre med kärnor än Core-serien. Den har helt enkelt högre latens för att hantera data som både läses och skrives av mer än en CPU-kärna. Än värre är det när man går mellan CCX men inget detaljer kring hur kommunikationen hanteras mellan CCX nämndes.

En positiv nyhet är att flyttalsdelen och heltalsdelen kan påbörja instruktioner samma cykel vilket betyder att sett till "peak-rate" så kan Zen påbörja två minnesoperationer, fyra heltalsoperationer OCH fyra flyttalsoperationer samma cykel. Då framförallt flyttalsdelen är rätt asymmetriska så är det många saker som måste rada upp sig för att det någonsin ska hända. Är peak då designen maximalt kan leverera 6 mikro-ops och maximalt kan avkoda 4 x86 instruktioner. Men det kan hända efter en rejäl "pipeline bubble".

Vidare verkar det som Zen inte har två FMAC där man för separata MUL elller ADD kör med "halva" FMAC:en (så fungerar Intel och även Excavator om jag förstått rätt). Zen har i stället två MUL och två ADD i separata pipelines där två pipelines kan kombineras för FMAC stöd. I det läget ger inte FMAC högre kapacitet, utan det enda man vinner på att använda FMAC är högre precision då det inte sker någon avrundning till registerformat mellan multiplikation och additionssteget.

Så i arbetslaster som har någorlunda nära 1:1 med flyttalsaddition och flyttalsmultiplikation men FMAC inte kan används samt där man inte använder AVX så är flyttalskapaciteten i Zen högre än Skylake räknat per klockcykel. Valet av Blender som jämförelse ter sig allt mindre som en slump (det kör SSE2 vilket saknar FMA-stöd), AnandTech har också spånat lite kring varför man valde just detta test. Slutsatsen är typ att inget kan sägas om generell prestanda baserat på detta test då allt för många parametrar är okända och det är endast ett test.

Som redan nämns flera gånger i denna tråd så är flyttalsintensiva laster en nischmarknad, innan vi får lite känsla för hur Zen presterar i "normala" applikationer så är allt väldigt mycket spekulation än.

Angående @Kuufukuji fråga om SHA1/SHA256. Vad jag kan se så är det verkligen begränsat till dessa två då man implementerat Intels SHA1/SHA256 instruktioner som beskrivs här. Folk har visat att det är möjligt att med SSE/AVX öka hastigheten med i teorin en faktor 4(SSE)/8(AVX) och man kommer hyfsat nära detta i praktiken. SHA1/SHA256 instruktionerna ger klart större boost än en faktor 4/8, men de är då begränsade till just dessa två varianter.

Edit: I tråden kring AnandTechs sammanfattning av gårdagens presentation säger någon detta

Tyvärr ges ingen länk till sagda forskningsresultat, posta gärna länkar i denna tråd om någon hittar sådant.

Att program som har viss kors-CPU kommunikation inte kommer skala lika väl på Zen står klart redan när man ser CCX designen, men för skrivbordet är ju 4 kärnor fullt tillräckligt i en majoritet av fallen så påverkar ju bara modeller med fler än 4 kärnor. Skulle vara intressant att få en känsla för vad de olika cache policyvalen kan tänkas bidra med, även om det också blir extremt mellan-tummen-och-pekfingret innan vi ser jämförelser med verkliga program. Där finns dock påverkar även inom CCX.

Råder inga tvivel om att Zen är långt bättre än vad den ersätter, det som i alla fall jag tycker är omöjligt att säga givet den information vi har idag är: exakt hur bra/dåligt står den sig mot Intels aktuella produkter. Så väntar med tummen, ser dock inget som är en show-stopper så det kan absolut blir bra.

Zen kommer även ha lägre latens än Phenom, t.ex. har man en design av L1D$ som möjliggör lägre genomsnittlig latens än även vad som fanns i Phenom-serien. Även om latens i viss lägen är sämre än Intel kan man inte med informationen som finns idag säga hur relevant det är för prestanda i olika applikationer. Det kan visa sig vara ett icke-problem i många fall!