::: AMD Zen Samlingstråd :::

Å andra sidan tyckte jag du skrev att det skall vara fastlödning på Zen?
Hoppas att man kör fastlödning istället för sånt där "skit" till kylpasta som Intel använt i flertal av sina CPUs.

Bilden borttagen även från källan. Någon som vet varför?

Det, tillsammans med hur lika Zen och Core blir, ländar ju till frågan: Har AMD sålt en grafikteknik för någon teknik de lyckats implementera i både Vega och Zen? Kan det vara hemligheten?

Tycker du verkligen att AMD har iGPU-marknaden som i en liten ask? Vilket är det mest använda grafikkortet på stram? Intel iGPU. Vilket grafikkort används mest i bärbara datorer? Intel iGPU. Vilket är världens mest sålda grafikkort? ...

Jag håller nog inte med dig om att AMD är mest framgångsrika på den marknaden, utan Intel har lyckats utmanövrerad dem från sin egen marknad. Och vad gäller AMD:s överlägsenhet i prestanda vill jag minnas ett test på anandtech som visade att eDRAM mer än väl kompenserade AMD:s beräkningskapacitet och faktiskt slog AMD med DDR3. Det var i det testet det blev väldigt uppenbart att APU begränsas mest av minnesbandbredd. Jag sitter dock illa till, så jag hinner inte leta.

Slutlige vill jag påpeka att jag i grund och botten gör samma analys som swemerlin gällande i3K's vara eller icke vara, så skall jag förvänta mig samma bemötande?

För att byta ämne en kort stund, vad är det för chassi du tänkte använda? Jag är i liknande tankar kring ett Zen bygge men har inte börjat köpa hem ngt iom att jag inte vet riktigt vilket chassi samt färgtema det blir.

Det alla verkar missa är att AMD ökar 40 % från en nivå som ligger ~Athlon64/PentiumM, det är antika modeller.

Ingen förutom Apple har idag en CPU på marknaden med högre enkeltråd IPC än Sandy Bridge. Om det är så lätt att bygga en sådan, varför har så få gjort det då?

Och om det är så lätt, varför kommer inte Zen att ens ha en enkeltråd IPC högre än Haswell (tror det är väldigt nära 100 % säkert att så inte blir fallet)?

IBMs POWER8 har mer av allt jämfört med Haswell/Broadwell, ändå har Haswell/Broadwell Xeons högre enkeltrådprestanda. Men IBM får betydligt högre boost från SMT, så vid 3-4 trådar (CPU kan ha upp till 8 trådar) utför den mer per kärna än Intel.

Rätt säker att samma gäller för Zen. Det kommer vara mindre skillnad mellan Zen och Core när båda trådarna används i en CPU-kärna jämfört när bara en används. Orsaken är enkel, finns mindre outnyttjad kraft kvar i Intels fall och sett till antal ALUs och en rad andra saker är Zen och Haswell väldigt snarlika.

Det jag ville visa var att klock-for-klock (i3 6100 och i5 2500K har samma maxfrekvens) är den förra faktiskt snabbare, även i spel.

Om nu Zen får en IPC i nivå med Ivy Bridge kommer därför en något högre klockad Kaby Lake i3 faktiskt vara helt jämförbar med SR3 i spel. I de flesta andra desktop-laster kommer i3 vara bättre p.g.a. högre enkeltrådprestanda.

D.v.s. i3 och SR3 är direkta konkurrenter. Men hävdar absolut inte att de är det optimala valet för spel, till och med spelutvecklarna säger att idag är "sweet-spot" 4 högt klockade kärnor + SMT. Det matchar bra de 6 trådar spelmotorer typiskt är optimerade för. 6 trådar då det är antalet man kan använda i dagens konsoler.

Tror också att cache-designen i Zen är riktigt bra. Pekar bara på för just för lås, som är en väldigt viktig sak i många desktop-applikationer, så kommer Zen ha högre latens än Core.

I båda fallen lurar man ut via L3 vilken annan kärna som senaste använde låset (då i tillstånd "modified"). Så till den punkten är det lika snabbt.

Core har i det läget även värdet för cache-line, så kvar är att ändra tillståndet till "shared" och kopiera data.

Zen måste gå till L2 hos den kärna som senast använde låset och kopiera data till lokal L1/L2.

Om nu låset är olåst så kommer kärna nummer två skriva, då måste man invalidera cache-line för den andra kärnan.

För Core går man till L3, skickar en invalidate till andra kärnan (som då bara raderar sin L1/L2 kopia) och ändrar tillståndet till "modified". Sedan skriver man nya värdet till L1 (och sinom tid till L3)

För Zen går man till L3, skickar en invalidate till andra kärnan (som då också bara raderar sin L1/L2 kopia) och ändrar tillståndet till "modified". Så lika dit. Men för att skriva värdet till L1 måste man först hitta en cache-line i L3 dit man kan kopiera nuvarande data (som blir ett "victim") som ligger i L1/L2. Först när den kopieringen är klar kan man skriva ner värdet i L1/L2.

Vad det gäller cache-designen i allmänhet håller jag med om att man har lite olika prioritet.

Core är helt optimerad för maximal enkeltrådprestanda, man försöker sedan hantera SMT fallet med väldigt hög bandbredd då SMT kan dölja latens.

Zen är helt optimerad för SMT-fallet. Att ha större L1I-cache och L2 är i detta läge en fördel då SMT gör att den effektiva cache-storleken kapas på mitten.

L1D är 32 kB och 8 ways av latensskäl. Varje "set" blir då 4 kB så man kan avgöra om det är en träff/miss innan man får tillbaka resultatet från TLB (då page-size är 4 kB).

L1I är 64 kB på Zen, men 4 ways. Det ger högre latens än Cores 32 kB och 8 ways då Zen inte kan avgöra om det är en träff/miss innan TLB resultatet kommer tillbaka. 64 kB skulle kräva 16 ways för att vara latensoptimerad, det drar för mycket ström. Men SMT kan dölja latens och en större L1I blir därför en fördel där.

Zen har 512 kB 16 ways i L3. Upp till Broadwell hade Intel 256 kB 8 ways men i Skylake minskade man till 4 ways (drar mindre ström) och dubblade istället bandbredd mot L3 (vilket drar mer ström, med antagligen en nettovinst i strömförbrukning då Skylake drar något mindre).

Zen och POWER8 har väldigt snarlik L1-L3 konfiguration. POWER8 är absolut optimerad för SMT-fallet, den får en hel del stryk av Core i enkeltrådfallet.

Storleken på 8-kärnor är väl ändå rätt lika mellan Zen och Broadwell? Ser också ut som de har väldigt snarlik fördelning av kiselyta mellan kärnor, L3 och "uncore". E-serien har något mer L3 per kärna och en större uncore, men är väl run ~200 mm^2 för 8 Zen-kärnor? Är ~250 mm^2 för 10 Broadwell-E kärnor, d.v.s. två fler kärnor och 9 MB mer L3 (tror de andra E-seriemodellerna bara är kapade varianter av 6950X, så alla har samma storlek).

Så skulle inte kalla Zen-kärnorna för "små". De är stora jämfört med 8 Cortex A57/A72 kärnor, de är gigantiska mot 8 Cortex A53 ;). De verkar vara ungefär som Intels Core-kärnor i storlek.

MSI har en roadmap som visar att deras första AM4-kort kommer i mitten av Mars. Vilket lite pekar på att det är då Ryzen släpps.
Fullkomligt efterblivet att Excavatorbaserade processorer funnits i över ett år utan några moderkort för dem ännu. Skvallrar lite om resursbristen. Det går inte att tjäna pengar om man inte har pengar i denna branschen.

Därför att spel inte tillhör gruppen applikationer som skalar linjärt med CPU-kärnor, här finns en hel del synkronisering mellan kärnor.

De flesta moderna spel använder en teknik som kallas "work stealing" för att sprida jobbet över CPU-kärnor.

Vet att jag nämnt detta tidigare, men är lite nöjd över vem jag i slutändan vann diskussionen över. Har vid läge diskuterat med en av Intels Core-HW-arkitekter om hur man borde kunna utnyttja HT just i saker som "work stealing". Han totalsågade idén med motiveringen: "det är inte det fallet vi designade HT för". Min förklaringen till att två trådar inom samma kärna delar L1 och kan därför kommunicera "gratis" hjälte föga.

Tog mig några veckor att skriva ihop ett tillräckligt stort proof-of-concept program för att vara säker på att det verkligen visade vad jag behövde visa. Resultatet blev exakt det jag försökte hävda att det borde bli. Kan inte påstå att personen var helt positiv till att bli överbevisad på "sin egen" design. Själv tror jag det bara visar att det finns en rätt stor klyfta mellan vad programutvecklare normalt förstår om HW-design och vice versa.

Väldigt många "smarta" finesser som lagts till i kisel har i praktiken varit värdelösa då de är hopplösa att programmera emot. Gissar att HW-designers är rätt trötta på krav från programmerare som är totalt orealistiska och bland säkert helt omöjliga att implementera i kisel.

För att komma tillbaka till huvudfåran: det finns definitivt program där fyra kärnor utan HT presterar extremt nära två kärnor med HT. I just fallet i3 6100 vs i5 2500 är naturligtvis också en kritisk komponent att den förra har kanske 20-30 % bättre enkeltrådprestanda.

Och just 20-30 % är lite "magiskt". Tror bl.a. Ericsson gjorde studier i multicore eras barndom kring när det är bättre att lägga transistorer på en till kärna kontra att lägga det på att höja enkeltrådprestanda.

Var just ~30 % man kom fram till, det för att gå från en kärna till två kärnor. För varje dubblering krävs i praktiken en mindre boost i enkeltrådprestanda för att det ska vara värt det. Det förutsatt att man jobbar med applikationer som kan skalas med kärnor, men som inte är triviala att skala (inte är "embarrassingly parallel").

Och är just denna grupp applikationer som skalar med kärnor, men som inte skalar perfekt där Core kommer ha en fördel med sin cache-design (TSX ger en ännu större vinst, så vi borde se en större skillnad i Linux då TSX alltid används där om det finns).

Exakt hur stor denna fördel blir vet vi inte. Jag gissar på: i praktiken väldigt liten skillnad (i icke TSX fallet) så länge man håller sig inom samma CCX. Mellan CCX finns inga detaljer, så går inte att säga något mer än att det kommer vara en större nackdel för Zen där.