AMD:s chefsarkitekt Mike Clark avslöjar Zen 5

På plus sidan kommer Zen 5 också bli Ryzen 5.

Zen 2 har reden en isp på över 200, intel måste jobbar hårt. Deras närmsta är 192 och långt ifrån krafttillbörligt.

IPC och klockfrekvens är dock inte samma sak.

???

Saker som cache och prefetch är ju totalt ortogonalt mot ISA. Av (tyvärr rätt få) benchmarks döma lär t.ex. Apples Monsoon och garanterat Qualcomms Centriq ha en minnes hierarki i nivå med AMD/Intels big-core x86.

Cache och prefetch är också totalt orelaterat till om man kör 32- eller 64-bitar (det både på x86 och ARM).

En nackdel med x86 är att man spikade minneskonsistensmodellen vid en tid när skillnaden i CPU- och RAM-hastighet inte var i närheten lika stor som idag och "multicore" betydde på sin höjd två kärnor. Man valde en modell som var vettig sent 80-tal / tidigt 90-tal, men som ingen skulle välja 2018. Detta kan man inte ändra utan att bryta bakåtkompatibilitet med system som har mer än en CPU-tråd!

Modellen ARMv8 använder (både för 32 och 64-bitars) tillåter betydligt mer spekulering utan att man för den delen behöver drivor med transistorer för att upprätthålla illusionen av en nästan helt sekventiell minnesmodell (som x86 har). ARM CPUer har tidigare varit sämre här därför att fokus enbart varit lågt pris och riktigt låg strömförbrukning, men nu när man också börjar designa "feta" ARM-kärnor så finns det faktiskt fler frihetsgrader för optimering inom ramen för ISA-specifikationen jämfört med x86.

Well, men då har RPi3 också en CPU-kärna som är mindre än en kvadratmillimeter på 16 nm... D.v.s. Cortex A53 är inte på något sätt jämförbar med "big" core x86 eller "big" core ARM.

Att peka på Cortex A53 och hävda att ARM har dålig prefetcher och lite cache är som att peka på Atom Bonnell (d.v.s. första Atom, den som satt i "netbooks") och hävda det samma om x86... Är milsvid skillnad mellan A53 och A75, och då är ändå A75 rätt enkel jämfört med M3, Centriq, Monsoon, Zen och Skylake sett till hur många transistorer den består av och dess teoretiska kapacitet.

Hur stor cache man har är bara en funktion av hur mycket transistorer man vill lägga på SRAM, vore ju rätt korkat att välja en mikroskopisk ARM-kärna och para den med en gigantisk cache.

Qualcomms Centriq är en server CPU, den har större "L0$" jämfört med AMD/Intels "micro-op cache" som är närmast jämförbar. Den har 64 kB L1I$ och 32 kB L1D$, d.v.s. samma som Zen och större L1I$ jämfört med Intel. L2$ är 512 kB, lika med Zen, större än Intels desktop men mindre än deras server. Sedan är L3$ upp till 60 MB, det är helt i nivå med AMD (men Qualcomm har till skillnad från AMD en monolitisk L3 -> svårare att designa men väsentligt snabbare kommunikation mellan alla kärnor).

De två första var ARMv7, d.v.s. 32-bitars ARM. Finns absolut en hel del hjärndöda designval i 32-bitars ARM. Grejen är att 64-bitars ARM är inte som x86_64 är mot x86, d.v.s. det är inte en utökning till 64-bitar utan Aarch64 är en helt separat ISA (vilket också gör det fördelaktigt att designa ARM-kärnor som överhuvudtaget inte stödjer 32-bitars ARM, det har så här långt bara Apple och Qualcomm gjort).

AMDs använde Cortex A57, en design som inte på något sätt var tänk att konkurrera med "big-core" x86 sett till dess mikroarkitektur. Den stora skillnaden med Qualcomm Centriq, Apple Monsoon och Samsung M3 är att de har en mikroarkitektur med samma kapacitet (i Apples fall faktiskt högre kapacitet) jämfört med AMD/Intels big-core x86.

Det riktigt intressanta är att man även visar att man kan utnyttja den kapaciteten i praktiken. Aarch64 har egenskaper som gör den bättre lämpad för riktig "bred" back-end jämfört med x86, d.v.s. den har kapacitet att nå högre IPC i praktiken (och vi börjar redan se det i Apples fall, möjligen även Qualcomms)!

Råder inte längre några tvivel om att vi kommer inom kort ha ARM CPUer som i absoluta tal presterar bättre än de snabbaste x86 modellerna. Däremot får vi se om Microsoft lyckas bryta Windows totala beroende på x86, lyckas man blir det svettigt för AMD/Intel och misslyckas man lär det under väldigt lång tid finnas en plats för x86 på skrivbordet!

@Chrisj: Nej så sant, jag mindes frågan som vad som ökar prestandan. Såg att frågan var klockfrekvensen sedan. My bad.

Ju mer cache desto mer data kan CPUn har "nära till hands" och slipper hämta från RAM eller sekundärminnen.

ISA säger väl ingenting om storlekar på cache. Hastighet på cache eller vilken litografi som ska användas? Cache är dyrt och man kan i teorin göra världens bästa arkitektur men får ändå prestandaproblem om man har för lite cache.

Du höll väl på med ARM programmering och borde väl sett i en del ARMv7 och ARMv8 datablad att det står att t.ex. L2 cachet är valbart för tillverkaren brukar det väl stå?

Nu blev jag intresserad! Berätta gärna mer om hur spekuleringen fungerar i ARMv8!

Poängen här är ju att t.ex. en RPi 3 skulle prestera rätt mycket bättre bara med lite mer cache minne. Även atom och "Pentium" och "Celeron" har ju oftast fått lida på cache-sidan. En del Pentium och Celeron är dessutom exakt samma kärna som Core modellen.

Korrekt!

Också sant.

Och vad hade du tänkt dig att de skulle valt för annan design 2014? A57 var väl det senaste som fanns då?
T.ex. A75 kom väl så sent som förra sommaren?

Jo det blir spännande tider framöver

Tack för ett intressant svar

Nej. Det är detta jag menade:

Som du ser står det ett spann för cachestorlekar och beroende på vad man ger processorn så påverkar det prestandan rätt mycket. Valde bara en ARM cpu på måfå men det står för de flesta (om inte alla)

Eller här att cache storleken på L2 är mellan 512kB till 2MB

På A75an får kretstillverkaren inte längre välja size på I$ och D$. Där jag hittade bilden står det att L2 kan vara 256/512kB

Cortex A55 och Cortex A75 är exempel på konkreta implementationer av ARMv8.2. Dessa konkreta implementationer har självklart även en specifikation för mängden cache.

Däremot säger ARMv8.2 absolut ingenting om hur mycket cache det ska finns, 0 kB är en lika korrekt implementation som en där man har 1 TB cache. Det var min poäng.

Vidare så skulle all cache i världen ändå aldrig göra modeller som Cortex A53 och A55 speciellt snabba, dessa implementationer är "by-design" endast fokuserade på låg kostnad, extremt låg strömförbrukning och obefintlig kretsyta. En "in-order" design kan av en rad skäl aldrig uppnå speciellt hög IPC, poängen med dessa 2018 är att de är extremt simpla -> billiga (dock är A53/A55 med råge de snabbaste "in-order" CPU-designerna som någonsin skapats).

Många associerar ARM med låg prestanda då detta var den enda typen av kretsar som designades körandes ARM, det är inte alls sant längre. Vidare, 32-bitars ARM ISA innehåller idioti som gör det relativt komplicerat att designa riktigt "breda" och högpresterande kretsar. Detta har man ju löst i Aarch64 då den ISAn i praktiken har lika mycket med 32-bitars ARM att göra som x86 har att göra med t.ex. PowerPC, d.v.s. det är två helt separata ISA (vilket också är orsaken att vi bara ser de riktigt högpresterande ARM-kretsarna hos de som enbart stödjer Aarch64).

ARM Cortex A53, ARM Cortex A73 och Apple Monsoon är tre exempel som alla implementerar ARMv8 men de gör det med extremt olika kapacitet, olika storlek på cache och i slutändan med extremt olika IPC / absolut prestanda.

En analogt exempel på hur man kan välja att implementera något helt korrekt på logisk nivå utan egentligen alls implementera det på HW-nivå är AVX i alla AMDs kretsar (Jaguar, Bulldozer-serien och Zen). Dessa kretsar kan köra alla AVX instruktioner. Däremot är ju en av huvudpoängerna med AVX att använda 256-bitars register för högre kapacitet, men Zen et al. har bara kisel för 128-bitars så prestanda är exakt den samma med SSE (128-bitar) som med AVX (256-bitar).

Så en ISA specifikationen säger bara vilka instruktioner som en implementation måste kunna köra, den säger noll om hur dessa ska prestera.

Jo traditionellt har det väl varit så.

Men på senare tid har väl snarare minskning av tillverkningsteknik endast minskat strömförbrukningen och således värmeutvecklingen. Möjligheten att öka klockfrekvenserna har visat sig vara svårt? Dels på grund av den minskade kiselytan som ska kylas men även möjligtvis andra problem.

Jag är ganska säker på detta varit på tapeten för några år sedan gällande Intel. Därför jag tog upp det, samt att jag har ett vagt minne av att det var arkitekturförbättringar kring Zen där man fixade de svagaste länkarna så att säga som skulle möjliggöra detta.

Är rätt bra insatt i ARM, men främst för inbyggda-system och inte servers. Av de benchmarks och de artiklar som skrivits om Qualcomms Centriq verkar ju många se den som en rejäl utmanar till Intel i datacenter.

Caviums ThunderX2 verkar vara lite mer nischad mot "exascalers" och HPC, sett att bl.a. Cray utrustat vissa av deras toppmodeller med ThunderX2 så rimligen står dessa modeller sig rätt bra där (men HPC är något jag bara läst om, inte jobbat med).

Skulle ändå säga att Windows är "tillräckligt bra" för vad majoriteten använder det till, föredrar personligen *NIX på servers fast gett upp hoppet om "year of the Linux-desktop" så där får det bli Windows eller MacOS

Ändå kul att det börjar hända lite på serversidan, de "gamla" drakarna som t.ex. POWER och SPARC är i praktiken irrelevanta idag. Trist för AMD att de nog kommer få det väsentligt svårare att plocka andelar jämfört med om det bara stått mellan Intel och deras 99 % av datacenter marknaden (många skriker efter en vettig konkurrent här), Intel kommer tappa andelar men inte alls säker att de nu kommer tillfalla AMD utan Qualcomm, Cavium, Ampere Computing, m.fl. som satsar på 64-bitars ARM kommer slåss om den biten.

Nej men du måste ändå hålla med om att cachestorleken ökar prestandan

Kort svar: normalt sett, ja!

Längre svar:

Inte nödvändigtvis därför det finns en motsatsförhållande mellan storleken på en cache och dess svarstid. Ofta är svarstiden extremt mycket viktigare för prestanda jämfört med "hit-rate", framförallt på en "in-order" design som har väldigt begränsade möjligheter att göra något vettigt medan den väntar på en tidigare instruktion.

Ovan kan idag tyckas vara en självklarhet, men det har det nog bara varit de senaste ~10 åren. Största orsaken är nog att det var ett icke-problem tidigare, gick helt enkelt inte att bygga speciellt stora cache:ar innan transistorerna blev riktigt riktigt små, SRAM tar allt för mycket plats.

När Intel introducerade Nehalem var det många som bestämt påpekade hur korkad designen var då man minskat L2$ från ett par MB i Core2 till endast 256 kB i Nehalem, vilken idiot hade kommit på den idén? Det man helt missade var att denna förändring gjorde att latensen för L2$ kunde halveras p.g.a. detta och kritiken försvann rätt snabbt när man såg resultaten.

Så som allt annat, det är en avvägning. Ingen cache är förödande för prestanda, det oavsett CPU. Är allt för stor skillnad mellan RAM-hastighet och den hastighet moderna CPU-kärnor behöver data. Dock finns det en optimal avvägning mellan storlek och latens, exakt vad detta är beror på tänkt arbetslast, mikroarkitektur etc.

Men Ryzen "2" använder inte DDR2.