Citat:
AMD has already demonstrated Broadwell-level IPC and memory latency characteristics, and Intel simply can't seem to match those clock speeds in an eight-core, sixteen-thread part.
Comparing what we know about Zen to Agner Fog's excellent description of Intel CPUs' internals, I've identified several areas in which Zen is clearly superior to every Intel CPU from Sandy Bridge to Skylake. In many of these areas, Intel has not bothered to change the key figures through that period. They've put more effort into improving the iGPU - which no self-respecting enthusiast ever uses if he can help it.
Hen drar rätt stora slutsatser baserat på två officiella benchmarks
Citat:
The first advantage Zen has is in the front-end. I'm going to get technical here, and show you the figures directly:
Skylake has a 32KB L1 I-cache, is restricted to 16 bytes per cycle for conventional fetch, and can produce a maximum of four µops from four instructions per cycle.
Redan Athlon64 (möjligen redan Athlon) kunde göra fetch på 32 bytes. Läser man vad Agner skriver om Intels designer så nämns aldrig 16 bytes fetch som en begränsning.
Skrev ett litet skript som räknar ut genomsnittlig längd på instruktioner i en rad program. 3,8 verkar vara en rätt vanligt längd vilket skulle kunna göra detta till en begränsning om dessa saker gäller
genomsnittlig IPC är nära 4 (här pratar vi x86 instruktioner och inte uops), i praktiken ligger program mellan 1,5 (många serverprogram) till 2,5 (desktop-program med väldigt hög cache-hit-rate)
i princip obefintlig hit-rate i loop- och mikroop-buffers
instruktionerna är väldigt långa men ändå inte hanterade via mikrokod, här ligger den stora orsaken till att detta sällan är en flaskhals trots att x86 instruktioner kan vara upp till 15 bytes
Citat:
It also has a 1536-entry µop cache which can also deliver a maximum of four µops (all from a single aligned 32-byte region of the instruction stream) per cycle, and a much smaller 64-entry "loop buffer" which can deliver 4 µops per cycle with no alignment restrictions. Most of these details are identical between Skylake and Sandy Bridge, though the latter has a yet-smaller loop buffer. The very existence of the loop buffer shows that Intel's µop cache itself doesn't give perfect performance in practice.
Han verkar missa poängen med varför det finns en specifik "loop buffer", det är inte främst prestanda utan ström. En träff i "loop buffer" tar mindre ström än en träff i "mikro-op cache" som tar klart mindre ström än gå via hela front-end.
Citat:
By comparison, Zen has a 64KB L1 I-cache, can fetch 32 bytes per cycle conventionally (this is the throughput of all cache ports in Zen), and can produce four ops from four instructions per cycle. (This means Zen has a decode advantage if the average instruction size exceeds 4 bytes.) It also has a "large" op cache (exact size unknown), which can deliver up to six ops per cycle, and apparently no separate loop buffer (suggesting that AMD are confident in the main op cache's performance). Additionally, AMD's "ops" often correspond to two of Intel's "µops", combining a memory load and an ALU operation.
Det sista är ren spekulation, det var sant för Athlon (som hade tre pipelines som både hanterade AGU och ALU). Vad jag vet har AMD har aldrig sagt något om sitt mikro-ops i Zen. Att kombinera ld+alu i Zen känns ju rätt udda då de använder olika pipelines (AGU mot ALU), enda rimliga att något sådant hanteras som två separata mikro-ops.
Zen har en dubbel så stor L1I med samma load-to-use latens som Intel. Däremot "glömmer" han att nämna att L1I i Zen är "4-way" vilket betyder att varje "way" är 16 kB vilket är större än page-storlekens 4 kB -> latensen är i praktiken något högre än Intels 32 kB "8-way" (4 kB per "way") då man inte vet om det är en L1I träff innan TLB resultatet är tillgängligt på Zen men det vet man på "core" då virtuella och fysiska adresser inte skiljer sig i de nedre 12 bitarna (2^12 = 4 kB) och 12 bitar är med 4 kB stora "ways" tillräckligt för att helt avgöra vilken cache-line som motsvarar vilken fysisk adress (är "ways" större måste man ha TLBn för att mappa virtuella adressen man använder för att slå upp till motsvarande fysiska).
Citat:
I'd also like to focus on AMD's claim of a "large" op cache. Intel's 1536-entry cache, if we assume it is 100% utilised and corresponds to one instruction per entry, could only be functionally equal in size to their "small" L1 I-cache if the average instruction length were over 21 bytes - which is impossible in the x86 architecture (since maximum instruction length is defined as 15 bytes). Agner Fog's analysis also reveals that for long instructions, Intel's µop cache needs multiple entries per instruction.
Här kan absolut AMD ha en större uop-cache, men i detta läge är storleken en total spekulation då man explicit sagt att man inte tänker ge information om denna detalj (i alla fall inte innan release).
Citat:
So I'm confident in saying that AMD's op cache is functionally much larger than Intel's µop cache - and that means Zen will deliver its full 6 ops per cycle more often than Skylake can deliver its full 4 µops per cycle. I think this is particularly important when SMT is in use, as the effective ILP is typically doubled under SMT.
6 uops per cykel kan absolut vara en flaskhals i vissa lägen när SMT används, men lär inte vara speciellt vanligt.
Skylake kan precis som Zen leverera 6 uops per cykel, men är ingen jätteskillnad i enkeltrådfallet (där ligger rimligen begränsningen i att det är svårt att hitta tillräckligt med oberoende instruktioner att köra varje cykel). Däremot har Skylake runt ~20 % högre IPC än Haswell när båda CPU-trådarna används, en skillnad mellan dessa kretsar är just peak-uops per cykel (men finns rätt många fler skillnader).
Citat:
Moving on to the back-end:
Skylake, like all P6-family CPUs, uses a set of "dispatch ports", each of which is attached to a specific subset of the available execution units - only one µop can fit through each dispatch port per cycle. Skylake in particular has eight dispatch ports, four of which are dedicated to load-store traffic (permitting two loads and one store per cycle), leaving the remaining four for all the ALU, FPU, branch and SIMD µops. At first glance this seems like a rather cramped arrangement, but it matches up with the maximum 4 µop per cycle throughput of the front-end, and most µops have a choice of two or more dispatch ports with the correct type of execution unit.
Zen has a more flexible arrangement IMHO. FPU and SIMD instructions are separated from the rest at an early stage, and go into their own four-pipe dispatch unit, where they don't compete with ALUs any more. Memory transactions have two pipelines, permitting two loads or one load and one store per cycle - less than Intel, but perfectly adequate. There are also four ALU pipelines, which I believe is where branch instructions also end up. That makes ten dispatch ports in total, of which eight are available for computation rather than memory traffic.
Visa mig fallet där man blandar skalära heltal med vektoriserade flyttal, det fallet är absolut ett problem för Core.
GCC-patchen pekar på att Zen har två pipelines för vektoriserade flyttal och två pipelines för vektoriserade heltal (dessa verkar också hantera shuffle/blend funktioner som behövs för både vektoriserade flyttal och heltal).
Här är Intel uppdelad så att vektoriserade uppgifter använder tre utan fyra portar, samma portar vare sig det är heltal eller flyttal. En ALU-port är i princip dedicerad för att hantera hopp+bitshift. Motsvarade detaljnivå finns inte för Zen än, så här drar väldigt mycket slutsatser helt utan detaljer.
Även här "glömmer" man att nämna att det blir någon cykel extra latens med den uppdelning AMD kör med (man hade ju samma i Bulldozer). I praktiken lär det inte spela någon roll då det bara påverkar flyttal och flyttalsintensiv kod är normalt ALU-begränsad, inte begränsad av latens och branchprediction.
Citat:
Since AMD can deliver six ops per cycle from the op cache (or, with two threads, potentially a combination of the op cache and conventional decoding), that means Zen can run all the FPU pipelines or all the ALU pipelines, together with both the load-store units, at sustained full capacity. That's something Intel's designs can't do; they can only run one of FPU, ALU or load-store at sustained full capacity with zero capability left over.
Helt sant. Zen har högre "sustained rate", samma som Skylake. Problemet är återigen att extremt få program når IPC över 2,5 så man är begränsade av helt andra saker än hur många uops som kan levereras till "back-end".
Vidare "gömmer" man nämna att det är inte direkt från front-end instruktionerna levereras, först gå de in i en dispatch-kö och här är den riktigt stora skillnaden mellan Zen och Core.
För heltalsdelen har Zen 6 st dispatch-köer, alla med djup 14. D.v.s. front-end måste direkt gissa vilken pipeline som först kommer bli tillgänglig då man bestämmer pipeline vid överlämning från front-end till back-end. Detta kallas "distributed scheduler".
I core fallet går alla uops in i en samma kö för alla dispatch-portar, den kön är 60 djup i haswell, 64 djup i broadwell och 97 djup i skylake. Ökat djup på denna är nog den största orsaken till ökad IPC mellan modellerna, broadwell är ju identisk med haswell i front-end och back-end förutom detta (två extra instruktioner stöd också). IPC skiljer mindre än 5 % mellan haswell/broadwell, vilket inte är så konstigt då det är minimal skillnad i ködjup.
Denna kö scannas sedan varje cykel och upp till 8 ups kan påbörjas (en per port). Detta kallas central scheduler. En fördel över distributed scheduler är bättre nyttjandegrad av back-end. En nackdel med central scheduler är att den är mer komplex och därför drar mer ström.
Citat:
Intel does retain two slight advantages relative to Zen: first, the slight memory-op advantage above; second, Skylake can execute two simple 256-bit AVX operations of the same type per cycle, whereas Zen can only do one (dividing it into two 128-bit halves). So Intel might still be able to win, by a substantial margin, on some carefully-selected benchmarks. However, I think Zen will show better or at least equal performance on a broad range of real-world tasks, and probably at a much lower price.
One thing is for certain, Summit Ridge will completely eclipse all of the old K10 and Bulldozer-family CPUs out there. I hope you've all been saving your pennies.
Kul val av ord: "slight memory-op advantage". Har man enbart load-ops så är det jämnt skägg, men är rätt ofta 2:1 mellan load/store och då är det 100 % fördel på denna punkt för Haswell (store ger två uops, en för adressberäkning och en för att skriva data till store-buffer. Samma gäller Zen, gissar dock att store-data utförs i någon av de 4 ALU-pipenes för att avlasta de två AGUs).
Men låt oss se när testerna kommer vem som gissat "bäst".
Min gissning är att det han skriver är helt sant om man ändrar lite.
Zen kommer vara snabbare per cykel än Haswell/Broadwell i vissa benchmarks, men Haswell/Broadwell kommer i genomsnitt vara snabbare (tror största fördel blir skalär heltalsintensiv kod).
Gissar också att Zen kommer se en större boost av SMT, andra designer med SMT och distribuerade scheduler har i alla fall gjort detta. D.v.s. det kommer vara större skillnad i enkeltrådade fall (där ger en central scheduler störst fördel), Zen kommer relativt sett klara sig bättre när alla trådar är aktiva.
