AMD utvecklar ARM-baserad systemkrets

Hoppas detta är Zen-backend med ARM64 front-end.

För det kommer i så fall kasta mer ljus på en väldigt intressant fråga: hur stor del i att både AMD och Intel idag ligger en bra bit efter Apple (M3/M4), Qualcomm (Oryon 1/2) och Arm (Cortex X925) i perf/Hz kan förklaras med x86-64 vs ARM64 och hur mycket kan förklaras med att Intel/AMD helt enkelt inte längre hänger med i design av mikroarkitektur.

Förutom skillnad i ISA är en annan viktig skillnad här att Intel/AMD släpper ny mikroarkitektur ca varannat år, de tre andra släpper en ny mikroarkitektur ungefär dubbelt så ofta.

Är inte alls säker att en Zen 5 med ARM64-frontend skulle matcha t.ex. Cortex X925 i perf/Hz. Även om AMD (likt Intel) ökade bredden i mikroarkitekturen senaste generationen ökade ARM64-gänget den långt mer. X925 är 10-wide, Zen 5 är 4+4-wide (i praktiken 2x 4-wide där full bredd bara kan utnyttjas fullt ut när båda SMT-trådarna är aktiva).

Kika på Skymont. Det är en modern mikroarkitektur för X86. Det finns hopp Lyckas de sedan städa bort skräpet (X86S) och lägga till fler register och ALU-instruktioner som inte petar på EFLAGS (APX) finns förutsättningarna för att dra nytta av en bredare mikroarkitektur. Det gör det å andra sidan ännu viktigare att kompilera om all kod och om man ändå skall kompilera om...

Kika på Skymont. Det är en modern mikroarkitektur för X86. Det finns hopp Lyckas de sedan städa bort skräpet (X86S) och lägga till fler register och ALU-instruktioner som inte petar på EFLAGS (APX) finns förutsättningarna för att dra nytta av en bredare mikroarkitektur. Det gör det å andra sidan ännu viktigare att kompilera om all kod och om man ändå skall kompilera om...

ser tendenser på detta med, och arbets bördan sker på en dator man kopplar upp sig till, eller skickar iväg "arbets order" till en starkare maskin i server rummet eller till en maskin park i molnet ex.. mycket sker så redan nu för mig på jobbet.

kan se en utveckling/push för detta för privatpersoner oxå så småningom längre fram, men ABSOLUT inget jag själv är intreserad av.

Underbart trevlig nyhet! 👍👍👍👍

ARM är så överlägset x86 redan i dag på extremt många områden, och blir grymt spännande att AMD kommer ta sin kunskap och teknik på området (de har ju redan i dag dödat Intel på x86-sidan med enorm framgång, och kommer nog kunna göra enormt bra ifrån sig på ARM).

Det fina med RISC-V är att det inte bara är tekniskt intressant – det är också en chans att minska vårt beroende av amerikansk, proprietär teknologi.

ARM Holdings ägs huvudsakligen av SoftBank Group Corp., som innehar 87,8% av aktierna. SoftBank Group är ett japanskt multinationellt företag med huvudkontor i Tokyo, Japan.

AMD (inte Mac) som dödar Intel.

AMD Ryzen är ju helt överlägsen Intel Core på många viktiga områden och applikationer.

Arm är från 1985. x86 från 1978. Inget av dem är nytt.

Om jag inte minns fel så jobbade Jim Keller på en ARM SoC samtidigt som de utvecklade Zen.

Som tidigare sagts så är 64-bittars ARM från 2011 och en annan arkitektur än 32-bittars ARM. Första chippen kom dock ett par år senare, och stödde både 32-bit och 64-bit ARM.
Men alla nyare smartphones, Apple- och Windows-datorer med ARM är helt och hållet 64-bit.

Intel 8086 i sig var en vidareutveckling av 8080 från 1974, för att täcka en lucka i marknaden medans Intel höll på att utveckla iAPX 432, som sedermera var ett misslyckande för att den var både komplex, dyr och långsam.

Jim Keller är för övrigt helt inne på RISC-V nu. Han basar för Tenstorrent som gör RISC-V - baserade AI-chip. De licensierar också ut några rätt snabba CPU-kärnor till bl.a. LG. Dessutom sitter Keller i styrelsen för ett nybildad bolag med avsikt att utveckla RISC-V - CPU:er: AheadComputing, grundat av ingenjörer som sagt upp sig från Intel.
Det finns runt ett halvt dussin RISC-V - kärnor hos olika företag som i alla fall på papperet skulle kunna konkurrera med x86 och ARM idag, men det räcker inte bara med ingenjörskonst, utan det handlar om marknad: att hitta investerare som tror att chippen går att sälja innan de blir omsprungna.

Jim Keller är för övrigt helt inne på RISC-V nu. Han basar för Tenstorrent som gör RISC-V - baserade AI-chip. De licensierar också ut några rätt snabba CPU-kärnor till bl.a. LG. Dessutom sitter Keller i styrelsen för ett nybildad bolag med avsikt att utveckla RISC-V - CPU:er: AheadComputing, grundat av ingenjörer som sagt upp sig från Intel.
Det finns runt ett halvt dussin RISC-V - kärnor hos olika företag som i alla fall på papperet skulle kunna konkurrera med x86 och ARM idag, men det räcker inte bara med ingenjörskonst, utan det handlar om marknad: att hitta investerare som tror att chippen går att sälja innan de blir omsprungna.

Som tidigare sagts så är 64-bittars ARM från 2011 och en annan arkitektur än 32-bittars ARM. Första chippen kom dock ett par år senare, och stödde både 32-bit och 64-bit ARM.
Men alla nyare smartphones, Apple- och Windows-datorer med ARM är helt och hållet 64-bit.

Intel 8086 i sig var en vidareutveckling av 8080 från 1974, för att täcka en lucka i marknaden medans Intel höll på att utveckla iAPX 432, som sedermera var ett misslyckande för att den var både komplex, dyr och långsam.

Jim Keller är för övrigt helt inne på RISC-V nu. Han basar för Tenstorrent som gör RISC-V - baserade AI-chip. De licensierar också ut några rätt snabba CPU-kärnor till bl.a. LG. Dessutom sitter Keller i styrelsen för ett nybildad bolag med avsikt att utveckla RISC-V - CPU:er: AheadComputing, grundat av ingenjörer som sagt upp sig från Intel.
Det finns runt ett halvt dussin RISC-V - kärnor hos olika företag som i alla fall på papperet skulle kunna konkurrera med x86 och ARM idag, men det räcker inte bara med ingenjörskonst, utan det handlar om marknad: att hitta investerare som tror att chippen går att sälja innan de blir omsprungna.

Att skippa statusflaggor gjorde RISC-V enklare att implementera, nackdelen är att det är svårare att få ut bra prestanda. Behövs oftast ganska många fler instruktioner för att göra samma beräkningar som ARM64. Att simulera flaggor med register gör att dessa inte kan utnyttjas lika effektivt.

Statusflaggorna som sätts av icke-compare-instrktioner är bara skit. De skapar beroenden mellan instruktioner som egentligen är oberoende, men den senare måste sätta statusflaggan utifall den råkar vara relevant för en instruktion långt senare. Flaggorna ställer till det både på mikroarkitekturnivå och för kompilatorn. Det är värt att ta en extra compare-instruktion den gången man faktiskt vill veta om resultatet blev 0/positivt/negativt.

Ja, du kan konstruera fall där de implicit satta statusflaggorna gör att man slipper en instruktion, men du betalar priset för dem i generell kod där kompilatorn inte kan generera optimal kod och mer komplex hårdvara som måste hålla reda vilken instruktion som skall sätta statusflaggan. Det är inte helt trivialt i en superskalär out-of-order-arkitektur som kan köra sex till åtta instruktioner samtidigt.