AMD:s chefsarkitekt Mike Clark avslöjar Zen 5

Innan folk får huvudvärk av namnet så... Fundera ett slag. I Asien är Tetrafobi vanligt då "fyra" på många språk låter väldigt likt ordet "död", och det är klart att man inte vill ha det som ett produktnamn.

Själv ser jag fram emot arkitekturer, vilket namn det än blir. Har 1700 nu, och kommer uppgradera vid varje ny generation. Helst med samma moderkort då det är sjukt smidigt

Jag tycker du ska göra ett försök!

Du tycker inte att det är en smula löjligt?

Detta är varför x86 kommer få det rejält svårt nu när ARM-kretsarna är i nära "big-core" x86 (ARMs Cortex A75), helt i nivå (Samsungs M3) och till och med förbi (Apples Monsoon) sett till mängd arbete utfört per klockcykel.

Att det tog väsentligt mindre tid att validera enkla ARM-kretsar jämfört med "big-core" x86 förvånande knappast någon, det som är intressant att se är hur pass mycket snabbare validerings-steget fortfarande är nu när de mest avancerade ARM kretsarna är helt i nivå med "big core" x86.

Är i.o.f.s. lite svårt att veta exakt hur länge Samsung och Apple haft sina designer "logiskt" klar innan de når marknaden. För Cortex A serien är det trivialt att se då ARM bara gör den logiska designen, sedan måste olika tillverkare realisera detta i verkligt kisel och där ser vi fortfarande <12 månande (Cortex A75 presenterades juli 2017 och den finns nu implementerat och validet i kisel hos produkter som skeppas).

Både AMD och Intel har sina x86 designer "logiskt" klara över ett år innan vi ser dem på marknaden. AMD är ju uppenbarligen "klar" med både Zen2 och Zen3, det innan vi ens fått ett släpp på Zen+!!! Är exakt samma sak för Intel, strategiska kunder har haft fungerande Ice Lake under rätt lång tid redan.

Tyvärr är ARM kontrollerat av ett enda företag, så sett ur den aspaketen är det egentligen värre jämfört med x86 (där det ändå delas mellan AMD och Intel). På lång sikt håller jag därför tummarna för RISC-V, men är övertygad att ARM kommer börja pressa ut x86 från bärbara datorer.

Esset x86 sitter på börjar allt mer att tappa värde, detta ess är Windows hårda beroende på x86. Microsoft jobbar ju aktivt med att försöka komma ur det håra beroendet på x86 (det kommer ta tid, men är möjligt givet tillräckligt med tid). Tidigare var även kompilatorer och liknande sämre på andra plattformar, här har Apples enorma investering i LLVM gjort att framförallt 64-bitars ARM har lysande stöd sett ur den aspekten.

Om de jobbar med Zen5 är de rimligen "klara" på samma sätt som ARM är "klar" med en design när de presenterar den. D.v.s. designen är klar på logisk nivå, men finns kanske ingen verkligen implementation i kisel än (vet inte hur det är fallet för Zen3 gällande implementation k kisel, men det är ju normalfallet för ARM Cortex).

Har också pratas om att en orsak till att x86 var chanslös på mobilsidan var just att det inte gick att hänga med ARMs utvecklingstakt, valideringssteget pekades då ut som den stora skillnaden.

Borde kanske varit lite mer specifik då. Håller med om att 32-bitars ARM både har rejäla för och rejäla nackdelar, på det stora hela skulle jag säga att det är lite hugget som stucket jämfört med x86_64 (som trots allt är ett hyfsat fall framåt över 32-bitars x86).

Men Aarch64, d.v.s. 64-bitars ARM som lanserades 2011, är en av idag två näst intill "perfekta" ISA givet vilka krav som ställs från moderna C, C++, Java och C# implementationer. Övriga ISA är definitivt inte alls lika bra match, det är speciellt sant om man försöker skriva multitrådade program likt t.ex. spel.

ISA betyder inte allt, mikroarkitektur är väsentligt viktigare (och mikroarkitektur är egentligen hyfsat frikopplad från ISA). ISA har dock viss påverkan, så allt annat lika så kommer en Aarch64 (eller RISC-V som är den andra "perfekta" ISAn) i praktiken prestera upp till kanske 30 % bättre.

För tio, femton år sedan hade upp till 30 % fördel varit irrelevant. Dennard scaling + Moores lag hade ätit upp den skillnaden på mindre än ett år, d.v.s. räckte med en fördel i processorteknik för x86-tillverkarna för helt kompensera för detta (och man konkurrerade då inte mot Aarch64 och RISC-V).

Ju närmare vi kommer ISA och frekvensväggen, ju viktigare kommer andra fördelar bli. Upp till 30 % prestanda-boost är något som idag mycket väl kan ta 5-10 år att nå via mikroarkitekturputsningar om man startar från de bäst presterande x86 mikroarkitekturerna.

Edit: länken du postar visar att Qualcomm kunde med deras första försök på en Aarch64 server CPU göra något som ligger väldigt nära Intel i enkeltrådprestanda och i flera fall är snabbare i fall som skalar nära nog perfekt med kärnor (vilket inte är helt ovanligt på servers). Än mer imponerande när man lägger in att Qualcomms CPU äter runt 50-70 % av Intels effekt (som drar ungefär lika som AMDs matchade Epyc, Qualcomms CPU är ovanpå det något billigare än även AMDs)...

Finns fortfarande jobb att göra, men de ställen där Qualcomm är efter säger man ju i artikeln konsekvent är de saker som är skrivna i Go och där man (man == Google) ännu inte skrivit ISA-optimerade rutiner för t.ex. krypto (både ARM och x86 har idag speciella instruktioner för att AES och liknande, i ARM-fallet använder Go just nu en generell C++ implementation).

Mindre tillverkningsteknik slutade ge automatik sänkning av strömförbrukning och därmed höge frekvenstak sedan "breakdown of Dennard Scaling" hände någonstans vid 65 till 45 nanometer.

Man har efter det gjort trick som FinFET och en rad andra saker. Det är alltså detta som kompenserat för att strömförbrukningen annars ökat vid krympningarna. Tyvärr måste man nu hitta på nya "trick" vid varje krympning, det har resulterat i enorma kostnadsökningar av utveckling av nya noder.

Mindre tillverkningsteknik betyder att man kan stoppa in fler transistorer. Det kan användas på lite olika sätt, både AMD och Nvidia utnyttjade t.ex. detta till att designa om Pascal/Polaris för högre frekvens. D.v.s att dessa kan klockas högre har väldigt lite att direkt göra med övergången till 14/16 nm och väldigt mycket med att man specifikt designade för högre frekvenser (lär vad AMD själva säger om detta i deras Vega whitepaper, tror det finns något liknande i Polaris whitepaper).

"One of the key goals for the “Vega” architecture was achieving higher operating clock speeds than any prior RadeonTM GPU. Put simply, this effort required the design teams to close on higher frequency targets. The simplicity of that statement belies the scope of the task, though. Meeting “Vega’s” substantially tighter timing targets required some level of design effort for virtually every portion of the chip."