Forum Övrigt Nyhetskommentarer Tråd Inlägg

Intel visar upp Clearwater Forest - Xeon med 288 E-kärnor

1 2
Skriv svar
Permalänk
Datavetare ★
●
Skrivet av jclr:

Nej inte alls. Det är stor skillnad i SIMD prestanda. En Zen 5 kan köra 4 512-bit instruktioner / cykel. För att komma upp i samma kapacitet på en M processor skulle den behöva köra 16 instruktioner per cykel, vilket den inte kan. Dessutom har M serien bara 4 SIMD ALUs, alltså exakt lika många som Zen 5 men 128-bit breda istället för 512. Det skiljer även i load/store kapacitet. Zen 5 kan läsa 2×512 bit, M 3×128.

Zen 5 kan läsa in 2×512 = 1024 bitar och utföra instruktioner på 5×512 = 2048 bitar per cykel.
M kan läsa in 3×128 = 384 bitar och utföra instruktioner på 4×128 = 512 bitar per cykel.

Gå till inlägget

I teorin: visst. I "praktiken", d.v.s. benchmarks som SGEMM har M4 klart högre prestanda jämfört med Zen 5 med AVX-512. Det verkar helt enkelt enklare att utnyttja fler "smalare" enheter än få "breda".

PyTorch har liknande beteende, men där har ju båda CPUerna specialfunktioner (AMX/SME och AVX512-VNNI) som kickar in så lite mer äpplen mot päron.

Edit: och det är bara att kika på Skymont (E-kärnan i Clearwater Forest) vs Zen 5 för att se att det inte så enkelt som att jämföra registerbredd och antal ALUs för vektoroperationer. I t.ex. matrisoperationer används FMA väldigt mycket.

Skymont må bara ha 128-bit intern bredd (men stödjer 256-bit operationer) fast den kan göra FMA i alla sina 4 pipelines medan Zen 5 bara kan göra FMA i 2 av 4 pipelines (har för mig samma gäller Lion Cove).

Senast redigerat
Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

I teorin: visst. I "praktiken", d.v.s. benchmarks som SGEMM har M4 klart högre prestanda jämfört med Zen 5 med AVX-512. Det verkar helt enkelt enklare att utnyttja fler "smalare" enheter än få "breda".

Gå till inlägget

Nu sprang du iväg ganska långt med målstolpen. Nu handlar det helt plötsligt inte om SIMD längre utan specifikt om matrismultiplikationer vilket M serien har en speciell accelerator för som ligger utanför kärnorna och som dessutom delas av kärnorna i samma kluster. Det är raka motsatsen till "Orsaken lär vara att M-serien har så pass många fler ALUs att den i praktiken kan kompensera för att varje instruktion inte har samma kapacitet." och " Det verkar helt enkelt enklare att utnyttja fler "smalare" enheter än få "breda".

Att M serien skulle ha fler ALUs för SIMD är något du har tagit helt ur luften. Det är lika många för både Zen 5 och M4, 4 SIMD ALUs. Så förklara gärna hur 4 är fler än 4 rent tekniskt?
Om argumentet är att M4 kanske kan köra en instruktion på alla fyra ALU samtidigt som Zen 5 bara har stöd för den instruktionen på två ALU så spelar det ingen större roll. 4×128 = 512 för M4 och 2×512 = 1024 för Zen 5, dessutom finns skillnaden i kapacitet mot L1 kvar också (3×128 vs. 2×512 load).

Skrivet av Yoshman:

Edit: och det är bara att kika på Skymont (E-kärnan i Clearwater Forest)

Gå till inlägget

Ska man vara petig så är det Darkmont i Clearwater Forest, men ja det är i princip en Skymont på Intel 18A. Det ser ut att finnas några få små skillnader som något lägre L2 latens t.ex.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Gtoxed:

Jaha endast E-cores... vad tråkigt, inte mycket man kan göra med dessa. P-cores ALL DAY EVERYDAY FTW!! <3

men visst, vill man host:a lite webbsidor så är väl e-cores bra, men f*n man vart ju besviken, 96 kärnig e-cores känns typ "wow vi satte ihop en del snapdragon elite prollar, kolla va coolt!" nee jag är inte imponerad, begränsad använding och du kommer inte kunna köra massa gpu:er i tandem heller utan att bli flaskhalsad. Intel kommer gå under med sina e-cores de fått pippi på.

Gå till inlägget

Lika bra att du vänjer dig. Framtiden är E-cores, eller iaf den mikroarkitektur som de använder. Att ha två helt olika mikroarkitekturer är på väg bort om ett par generationer. Nuvarande E-cores har väldigt bra prestanda i förhållande till fysisk storlek om man jämför med P-cores. Det finns alltså utrymme att t.ex. peta in bredare AVX10.2, skruva upp frekvens , SMT är på väg tillbaka, använda en annan konfiguration som 2 kärnor per L2 (kommande P).

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av jclr:

Nu sprang du iväg ganska långt med målstolpen. Nu handlar det helt plötsligt inte om SIMD längre utan specifikt om matrismultiplikationer vilket M serien har en speciell accelerator för som ligger utanför kärnorna och som dessutom delas av kärnorna i samma kluster. Det är raka motsatsen till "Orsaken lär vara att M-serien har så pass många fler ALUs att den i praktiken kan kompensera för att varje instruktion inte har samma kapacitet." och " Det verkar helt enkelt enklare att utnyttja fler "smalare" enheter än få "breda".

Att M serien skulle ha fler ALUs för SIMD är något du har tagit helt ur luften. Det är lika många för både Zen 5 och M4, 4 SIMD ALUs. Så förklara gärna hur 4 är fler än 4 rent tekniskt?
Om argumentet är att M4 kanske kan köra en instruktion på alla fyra ALU samtidigt som Zen 5 bara har stöd för den instruktionen på två ALU så spelar det ingen större roll. 4×128 = 512 för M4 och 2×512 = 1024 för Zen 5, dessutom finns skillnaden i kapacitet mot L1 kvar också (3×128 vs. 2×512 load).

Ska man vara petig så är det Darkmont i Clearwater Forest, men ja det är i princip en Skymont på Intel 18A. Det ser ut att finnas några få små skillnader som något lägre L2 latens t.ex.

Gå till inlägget

Enda relevanta är väl ändå vad effekten i praktiken blir? Och är väl ändå matris-operationer högst relevanta då det är ett av skolboks-exemplen där SIMD är väldigt användbart.

Och här ser vi ett av begränsningarna med att gå på "bredden". AVX-512 operationer drar väldigt mycket ström, här får man ge AMD rejäl cred då de hittat en klart bättre strategi än Intel för att hantera det:

Zen 5 minskar på IPC för AVX512 instruktioner om det kommer allt för många "på rad", Intel har i alla fall historiskt minskat frekvensen vilken även påverkar icke-SIMD negativt.

Den andra nackdelen med AVX512, och orsaken till varför de äter ström, är ju att dessa instruktioner kräver så pass mycket transistorer att man inte kan låta alla ALUs kunna hantera alla operationer. Zen 5 (och Intel Xeon med AVX512 stöd) har ju bara 2 st pipelines för vad som ändå är relativt grundläggande funktioner som multiplikation.

Skymont (och Darkmont) har rätt mycket 4st helt symentriska SIMD ALUs. Exakt vad Apple har är svårt att säga då det inte finns någon officiell information, där kan man bara notera faktiskt prestanda. Arm Cortex X925 har 6st 128-bit SIMD ALUs som är i stort sätt symetriska (alla kan göra FMA, men alla kan inte gör FDIV).

Prestandaökningen mellan Gracemont (2st 128-bit SIMD ALUs) till Skymont/Darkmont (4 st 128-bit SIMD ALUs) är definitivt signifikant i verkliga applikationer. Finns fall som når väldigt nära 2x (som är vad man får i teorin).

När Intel gått från 128->256->512 har det absolut kommit med en ökning i prestanda. Men är rätt sällsynt att AVX->AVX512 ger mer än 20-30 %, 50 % är fantastiskt och nära 2x är inget jag sett (men borde vara möjligt att göra ändå i syntetiska fall).

Det trots att det faktiskt i flera fall bara är 2 ALUs som hanterar t.ex. FMA, så ur den aspekten borde det vara hyfsat lätt att få bra utväxling.

Sen vet jag inte hur mycket man ska läsa in i ett enskilt fall. Men ändå noterbart att Arm Neoverse V1 (bl.a. Graviton 3) gick till (4st) 256-bit SVE och man sedan valde att backa till 128-bit i Neovese V2 (bl.a. Graviton 4 och Nvidia Grace), för att göra ökningen på "andra ledden" med att gå från 4st -> 6st 128-bit SIMD-ALUs.

Finns ju fall som inte är trivial att öka till större bredd. T.ex. beräkningar i 3D hanterad med homogena koordinater passar väldigt naturligt med 128-bit SIMD om man kör 32-bit floats och 256-bit SIMD om man kör 64-bit floats. Det blir lätt extra overhead om man vill gå till större bredd -> kommer inte bli någon perfekt skalning, medan det sannolikt är lätt att utnyttja flera SIMD ALUs vid samma bredd.

Som vanligt finns avvägningar och uppenbarligen har ingen facit. Nu när SIMD ändå används hyfsat mycket och de grundläggande möjliga permutationerna av arkitektur testas tycker i alla fall jag det ser ut som fler smalare SIMD ALUs verkar få bättre utväxling. Men finns absolut undantag, specifikt i hypade machine-learning fall går det att få väldigt bra utväxling på mycket stor bredd (vilket Intel har både AMX och AVX512-VNNI till och Apple/Arm har AMX/SME).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Enda relevanta är väl ändå vad effekten i praktiken blir? Och är väl ändå matris-operationer högst relevanta då det är ett av skolboks-exemplen där SIMD är väldigt användbart.

Och här ser vi ett av begränsningarna med att gå på "bredden". AVX-512 operationer drar väldigt mycket ström, här får man ge AMD rejäl cred då de hittat en klart bättre strategi än Intel för att hantera det:

Zen 5 minskar på IPC för AVX512 instruktioner om det kommer allt för många "på rad", Intel har i alla fall historiskt minskat frekvensen vilken även påverkar icke-SIMD negativt.

Den andra nackdelen med AVX512, och orsaken till varför de äter ström, är ju att dessa instruktioner kräver så pass mycket transistorer att man inte kan låta alla ALUs kunna hantera alla operationer. Zen 5 (och Intel Xeon med AVX512 stöd) har ju bara 2 st pipelines för vad som ändå är relativt grundläggande funktioner som multiplikation.

Skymont (och Darkmont) har rätt mycket 4st helt symentriska SIMD ALUs. Exakt vad Apple har är svårt att säga då det inte finns någon officiell information, där kan man bara notera faktiskt prestanda. Arm Cortex X925 har 6st 128-bit SIMD ALUs som är i stort sätt symetriska (alla kan göra FMA, men alla kan inte gör FDIV).

Prestandaökningen mellan Gracemont (2st 128-bit SIMD ALUs) till Skymont/Darkmont (4 st 128-bit SIMD ALUs) är definitivt signifikant i verkliga applikationer. Finns fall som når väldigt nära 2x (som är vad man får i teorin).

När Intel gått från 128->256->512 har det absolut kommit med en ökning i prestanda. Men är rätt sällsynt att AVX->AVX512 ger mer än 20-30 %, 50 % är fantastiskt och nära 2x är inget jag sett (men borde vara möjligt att göra ändå i syntetiska fall).

Det trots att det faktiskt i flera fall bara är 2 ALUs som hanterar t.ex. FMA, så ur den aspekten borde det vara hyfsat lätt att få bra utväxling.

Sen vet jag inte hur mycket man ska läsa in i ett enskilt fall. Men ändå noterbart att Arm Neoverse V1 (bl.a. Graviton 3) gick till (4st) 256-bit SVE och man sedan valde att backa till 128-bit i Neovese V2 (bl.a. Graviton 4 och Nvidia Grace), för att göra ökningen på "andra ledden" med att gå från 4st -> 6st 128-bit SIMD-ALUs.

Finns ju fall som inte är trivial att öka till större bredd. T.ex. beräkningar i 3D hanterad med homogena koordinater passar väldigt naturligt med 128-bit SIMD om man kör 32-bit floats och 256-bit SIMD om man kör 64-bit floats. Det blir lätt extra overhead om man vill gå till större bredd -> kommer inte bli någon perfekt skalning, medan det sannolikt är lätt att utnyttja flera SIMD ALUs vid samma bredd.

Som vanligt finns avvägningar och uppenbarligen har ingen facit. Nu när SIMD ändå används hyfsat mycket och de grundläggande möjliga permutationerna av arkitektur testas tycker i alla fall jag det ser ut som fler smalare SIMD ALUs verkar få bättre utväxling. Men finns absolut undantag, specifikt i hypade machine-learning fall går det att få väldigt bra utväxling på mycket stor bredd (vilket Intel har både AMX och AVX512-VNNI till och Apple/Arm har AMX/SME).

Gå till inlägget

Det var ditt påstående om ""Orsaken lär vara att M-serien har så pass många fler ALUs att den i praktiken kan kompensera för att varje instruktion inte har samma kapacitet." som jag korrigerade eftersom det inte har något med verkligheten att göra utan något du helt hittat på.

Jag förstår inte alls vad intel vs. amd strömhantering, andra arm processorer och allt möjligt annat som ditt "svar" handlar om på något sätt skulle vara relevant. Det påverkar inte på något sätt det faktum att M serien har exakt lika många SIMD enheter som Zen 5. Exakt vad apple har kan du enkelt ta reda på helt enkelt genom att kolla throughput på enskilda simd instruktioner. Om man räknar bort krypto så ligger de på 0.25 förutom div/sqrt som ligger på 1.

Om du nu vill jämföra med andra arm istället så har 2×512 bit FMA fortfarande högre kapacitet än 6×128 bit FMA. (dessutom högre L1 bandbredd). 4×512 FMA skulle behöva ännu högre bandbredd. 2×FMA + 2×FADD är däremot väldigt användbart för FFT.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av jclr:

Det var ditt påstående om ""Orsaken lär vara att M-serien har så pass många fler ALUs att den i praktiken kan kompensera för att varje instruktion inte har samma kapacitet." som jag korrigerade eftersom det inte har något med verkligheten att göra utan något du helt hittat på.

Jag förstår inte alls vad intel vs. amd strömhantering, andra arm processorer och allt möjligt annat som ditt "svar" handlar om på något sätt skulle vara relevant. Det påverkar inte på något sätt det faktum att M serien har exakt lika många SIMD enheter som Zen 5. Exakt vad apple har kan du enkelt ta reda på helt enkelt genom att kolla throughput på enskilda simd instruktioner. Om man räknar bort krypto så ligger de på 0.25 förutom div/sqrt som ligger på 1.

Om du nu vill jämföra med andra arm istället så har 2×512 bit FMA fortfarande högre kapacitet än 6×128 bit FMA. (dessutom högre L1 bandbredd). 4×512 FMA skulle behöva ännu högre bandbredd. 2×FMA + 2×FADD är däremot väldigt användbart för FFT.

Gå till inlägget

Fast även om det "bara" är 4st SIMD ALUs (vilket vi inte kan veta med säkerhet) så är påståendet fortfarande sant då analyser som finns pekar på att de är väldigt symetriska (precis som Cortex X serien och Skymon/Darkmont, en annan möjlighet för M4 är i.o.f.s. >4 ALUs som är mindre avancerade).

Geekbench visar nog det relativt tydligt då det finns ett deltest som använder AVX-512 om det finns, ett som använder AVX512-VNNI / SME om det finns och ett som "bara" använder AVX och NEON på ARM.

Har precis skaffat en U5 255H baserad NUC. Kör man igenom t.ex. GB6 en gång på de P-kärnorna (4st 256-bit ALUs, där instruktioner som FMA, MUL och liknande finns på 2 av 4) och en gång på E-kärnorna (4st 128-bit ALUs som är väldigt symetriska) så är Skymont E-kärnorna klart efter i avancerade saker som AVX-VNNI (de stödjer det, men är uppenbart att man inte spenderat jättemycket resurser) men presterar väldigt nära i "vanliga" AVX fall.

Och angående det sista: vad betyder teoretisk kapacitet om det ser ut så här i praktiken (9950X@5,7GHz vs M4@4,5 GHz)?

AVX512-VNNI vs SME (gissningsvis slår dessa i bandbreddsflaskhalsar, vilket får att M4 Pro dra iväg)

AVX-512 vs NEON, i teorin och om vi använder dina teoretiska siffror har Zen 5 här 4x högre kapacitet per cykel, ändå är den bara 5 % snabbare trots 27 % högre frekvens

AVX vs NEON, i teorin borde Zen 5 (och samma för Lion Cove här) vara 2x snabbare

Trots fördel av full AVX-512 bredd och 27 % högre frekvens är ändå inte 2/4 ALUs med AVX-512 snabbare än 4 (eller i alla fall 4st effektivt då det kan vara fler fast med restriktioner precis som Zen 5 har effektivt 2st ALUs i många fall) ALUs med 128 bit ALU.

Vidare kan Zen 5 göra upp till 2st 512-bit load per cykel, M4 kan göra beroende på vilken analys man tror 3 eller 4 128-bit load per cykel. Du verkar rätt insatt i SIMD-programmering: rimligen är det en klar fördel att ha större flexibilitet i sina loads då ett problem med att få SIMD effektivt är att ha data "i rätt ordning".

Lyftet mellan Zen 4 (som stödjer AVX-512, men är 256-bit internt) och Zen 5 (som är fullt 512-bit internt) är ju väldigt milt.

Tycker det finns rätt mycket som pekar på att fler "smalare" ALUs är mer effektivt än färre "bred" för SIMD. Men självklart är två ALUs med X-bitars bredd mer komplext än en med 2X-bitars bredd.

Frågan är var cut-off går, ställer man Skymont mot Lion Cove känns det som Skymont för väldigt mycket mer uträttat med sin transistorbudget och där är det i samma kapacitet för t.ex. FMA/FMUL (4st 128-bit vs 2st 256-bit). Skymont är i.o.f.s. i genomsnitt inte fullt lika snabb, men inte supermycket i det jag testat.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Fast även om det "bara" är 4st SIMD ALUs (vilket vi inte kan veta med säkerhet) så är påståendet fortfarande sant då analyser som finns pekar på att de är väldigt symetriska (precis som Cortex X serien och Skymon/Darkmont, en annan möjlighet för M4 är i.o.f.s. >4 ALUs som är mindre avancerade).

Geekbench visar nog det relativt tydligt då det finns ett deltest som använder AVX-512 om det finns, ett som använder AVX512-VNNI / SME om det finns och ett som "bara" använder AVX och NEON på ARM.

Gå till inlägget

Vilket trams. Naturligtvis finns det inga hemliga/dolda simd pipelines som ingen hört talas om. M serien är begränsad till 4 neon instruktioner som mest per cykel oavsett vilken kombination av instruktioner du väljer (med vissa begränsningar som t.ex. som division). 4 ALUs är inte många fler än 4 ALUs oavsett hur du försöker vända och vrida på det.

Om man tittar specifikt på FMA fallet och matrismultiplikation så har Zen 5 dubbelt så hög kapacitet i flops med "bara" två FMA pipelines jämfört med M. Du skulle inte kunna använda fler FMA (slöseri med transistorer) i vilket fall som helst om du tittar på förhållandet mellan flops och load/store. Däremot kan du använda hela simd kapaciteten i Zen 5 till tex FFT där två ALUer kör FMA instruktioner och två FADD. Alla int/logik funktioner finns på alla simd ALUs.

SME är en "extern" accelerator som alla 4 P kärnorna i en M4 delar på. Den använder dessutom 512-bitars vektorlängd. Alltså raka motsatsen till ditt påstående. Därför är de siffrorna inte alls relevanta.

Det brukar ofta dyka upp diverse fantasifulla påståenden om arm/apple processorer här men att 4×128 bitars neon är lika bra eller bättre än 4×512 bitars AVX512 pga av hemliga ALUs trodde jag inte skulle dyka upp.

Jag tror knappast vi kommer längre.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av jclr:

Vilket trams. Naturligtvis finns det inga hemliga/dolda simd pipelines som ingen hört talas om. M serien är begränsad till 4 neon instruktioner som mest per cykel oavsett vilken kombination av instruktioner du väljer (med vissa begränsningar som t.ex. som division). 4 ALUs är inte många fler än 4 ALUs oavsett hur du försöker vända och vrida på det.

Om man tittar specifikt på FMA fallet och matrismultiplikation så har Zen 5 dubbelt så hög kapacitet i flops med "bara" två FMA pipelines jämfört med M. Du skulle inte kunna använda fler FMA (slöseri med transistorer) i vilket fall som helst om du tittar på förhållandet mellan flops och load/store. Däremot kan du använda hela simd kapaciteten i Zen 5 till tex FFT där två ALUer kör FMA instruktioner och två FADD. Alla int/logik funktioner finns på alla simd ALUs.

SME är en "extern" accelerator som alla 4 P kärnorna i en M4 delar på. Den använder dessutom 512-bitars vektorlängd. Alltså raka motsatsen till ditt påstående. Därför är de siffrorna inte alls relevanta.

Det brukar ofta dyka upp diverse fantasifulla påståenden om arm/apple processorer här men att 4×128 bitars neon är lika bra eller bättre än 4×512 bitars AVX512 pga av hemliga ALUs trodde jag inte skulle dyka upp.

Jag tror knappast vi kommer längre.

Gå till inlägget

Oavsett hur många pipelines som finns är ett faktum: både M4 och Skymont/Darkmont kan med flera väldigt välanvända instruktioner (framförallt FMA som bokstavligen är hur GPU-tillverkarna räknar "GPU-kärnor") köra fler sådana instruktioner per cykel än vad Golden Cove (256-bit AVX) och Zen 5 (512-bit AVX-512) kan.

Fem myror är fortfarande fler än fyra elefanter, precis som 4 128-bit SIMD per cykel är fler än 2 256/512-bit SIMD per cykel. Det haltar lite då för enkla instruktioner blir det 4st 128/256/512-bit SIMD per cykel för alla.

Och för denna tråd: om det är någonstans detta syns riktigt bra är just Lion Cove vs Skymont. Gracemont hade bedrövlig SIMD-prestanda ställd mot P-cores, Skymont är fortfarande inte helt på samma nivå som Lion Cove men utanför specialfall som AVX-VNNI verkar skillnaden ligga i 10-30 % per cykel nivå.

Det när rätt symmetrisk 4st 128-bit AVX design ställs mot en 2/4st (beroende instruktion) 256-bit design.

Rimlig tes givet vad verkliga resultat visar i applikationer som använder SIMD: det är rätt mycket större utväxling på fler smalare SIMD-enheter än på färre väldigt breda. DET var den egentligen poängen, vad "teoretisk kapacitet" säger är rätt irrelevant om det inte realiseras i praktiken.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Oavsett hur många pipelines som finns är ett faktum: både M4 och Skymont/Darkmont kan med flera väldigt välanvända instruktioner (framförallt FMA som bokstavligen är hur GPU-tillverkarna räknar "GPU-kärnor") köra fler sådana instruktioner per cykel än vad Golden Cove (256-bit AVX) och Zen 5 (512-bit AVX-512) kan.

Fem myror är fortfarande fler än fyra elefanter, precis som 4 128-bit SIMD per cykel är fler än 2 256/512-bit SIMD per cykel. Det haltar lite då för enkla instruktioner blir det 4st 128/256/512-bit SIMD per cykel för alla.

Och för denna tråd: om det är någonstans detta syns riktigt bra är just Lion Cove vs Skymont. Gracemont hade bedrövlig SIMD-prestanda ställd mot P-cores, Skymont är fortfarande inte helt på samma nivå som Lion Cove men utanför specialfall som AVX-VNNI verkar skillnaden ligga i 10-30 % per cykel nivå.

Det när rätt symmetrisk 4st 128-bit AVX design ställs mot en 2/4st (beroende instruktion) 256-bit design.

Rimlig tes givet vad verkliga resultat visar i applikationer som använder SIMD: det är rätt mycket större utväxling på fler smalare SIMD-enheter än på färre väldigt breda. DET var den egentligen poängen, vad "teoretisk kapacitet" säger är rätt irrelevant om det inte realiseras i praktiken.

Gå till inlägget

Golden Cove har AVX512 även om det inte är aktivt på klientprocessorerna, precis som alla andra nya P cores. Om du ifrågasätter "men hur kan man veta det?" så är det bara att titta på hur stor register file du har för x87/xmm. De återanvänder avx512 maskregistren. Det är inte så att intel har slängt in en extra hög register för att optimera legacy kod utan det handlar om att det i grunden är avx512 enheter. På serverprocessorerna där man kan komma åt AVX512 så är FMA prestandan samma som Zen 5 med 2×FMA.

Poängen med simd är att utföra så mycket arbete som möjligt per cykel. Där vinner x86 lösningarna. Varje FMA enhet utför 16 single precision FMA operationer (32 flops) per cykel. Ta det gånger två så är du uppe i 32 FMA (64 flops). M4 kommer upp i 16 FMA (32 flops) operationer total per cykel. Det du argumenterar för är att det är bättre att det krävs fyra instruktioner för att göra mindre jobb än vad två instruktioner klarar av bara för att fyra är mer än två, vilket är ganska absurt. Starkt överdrivet är det som att säga att två glass vatten är mer än ett badkar vatten eftersom två är fler än ett. Det haltar inte bara lite, jag skulle nog säga att det påståendet saknar ben helt.

Med det sättet att tänka så ska man alltid undvika simd. Säg att du jobbar med bytes. 6 vanliga ALUs är fler myror än 4 simd elefanter som kan arbeta med 64 bytes åt gången.

Teamet bakom e-cores har gjort ett riktigt bra jobb och det är den arkitekturen som är framtiden när man går mot en mer enhetlig mikroarkitektur. Det är inte helt otroligt att det dyker upp bredare simd även där när man använder den arkitekturen för prestandakärnor. Även SMT kommer komma tillbaka i någon form, antagligen i mer traditionellt format än de mer spännande rentable units / super cores. Eftersom du verkar vara intresserad av riktigt breda arkitekturer och allt som inte är x86 kan det kanske vara intressant att titta på vad AheadComputing hittar på.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av jclr:

Golden Cove har AVX512 även om det inte är aktivt på klientprocessorerna, precis som alla andra nya P cores. Om du ifrågasätter "men hur kan man veta det?" så är det bara att titta på hur stor register file du har för x87/xmm. De återanvänder avx512 maskregistren. Det är inte så att intel har slängt in en extra hög register för att optimera legacy kod utan det handlar om att det i grunden är avx512 enheter. På serverprocessorerna där man kan komma åt AVX512 så är FMA prestandan samma som Zen 5 med 2×FMA.

Gå till inlägget

Vet redan ovan, men vet inte hur något av det är relevant.

För klientvarianten av Lion Cove har Intel nämnt att där ska det inte finnas något AVX-512 stöd alls. Har för mig det nämndes när de pratade om varför de ansåg borttagning av SMT var vettig.

Skrivet av jclr:

Poängen med simd är att utföra så mycket arbete som möjligt per cykel. Där vinner x86 lösningarna.

Gå till inlägget

Är 100 % med på första delen, hela poängen med SIMD just att data-parallella job kan få en rejäl ökning i perf/Hz perf/W, perf/transistor och absolut perf.

Vet inte hur man kan dra slutsatsen om att x86 lösningarna vinner när Apples ARM64 är generellt sett före i perf/Hz (och långt före i perf/W) trots att den på pappret har betydligt sämre teoretisk kapacitet.

Mer relevant för vad artikeln handlar om är hur nära Skymont (som lär vara väldigt nära Darkmont) presterar Lion Cove, trots att den senare har samma till dubbla (beroende på vad man tittar på) så hög teoretisk kapacitet på pappret. Är det inte ändå en vink om att Skymont:s rätt symmetriska 4x 128-bit SIMD kanske är en mer optimal lösning jämfört med Lion Coves betydligt mer asymmetriska 4x 256-bit SIMD, där flera vanliga instruktioner bara finns i 2 ALUs medan Skymont har dem i alla 4? Det är trots allt ~3:1 i kretsyta mellan Skymont och Lion Cove (dock oklart hur stor skillnaden är specifikt för SIMD).

Skrivet av jclr:

Varje FMA enhet utför 16 single precision FMA operationer (32 flops) per cykel. Ta det gånger två så är du uppe i 32 FMA (64 flops). M4 kommer upp i 16 FMA (32 flops) operationer total per cykel. Det du argumenterar för är att det är bättre att det krävs fyra instruktioner för att göra mindre jobb än vad två instruktioner klarar av bara för att fyra är mer än två, vilket är ganska absurt. Starkt överdrivet är det som att säga att två glass vatten är mer än ett badkar vatten eftersom två är fler än ett. Det haltar inte bara lite, jag skulle nog säga att det påståendet saknar ben helt.

Med det sättet att tänka så ska man alltid undvika simd. Säg att du jobbar med bytes. 6 vanliga ALUs är fler myror än 4 simd elefanter som kan arbeta med 64 bytes åt gången.

Gå till inlägget

Jag är helt med på vad som gäller i teorin.

Men vad spelar det för roll när det i praktiken är rätt liten skillnad mellan t.ex. Zen 4 och Zen 5, Lion Cove och Zen 5 samt Skymont och Lion Cove där det i alla fallen är upp till 2x högre kapacitet hos andra CPUn i varje par men det i praktiken ofta handlar om 0-30 % högre prestanda?

Idag bör också "vad som är optimalt" vägas mot alternativen. Det AVX-512 (och en eventuell SVE2 med stor databredd) i praktiken konkurrerar med är GPGPU. GPUer är normalt långt snabbare förutsatt att problemet är "tillräckligt stort". Nog precis samma sak för AVX-512 kontra "smalare" SIMD, fördelen lär öka på större problem.

Finns ändå många fall där SIMD är högst relevant för CPU. Det är ofta fall som inte är "tillräckligt stora" för att effektivt köras med GPGPU, då är det nog inte alls osannolikt att lite fler myror inte bra är fler utan även får mer gjort då flaskhalsen flyttas från råkapacitet till latens och möjlighet att göra så många mindre jobb så fort som möjligt (fördel då att har fler mindre work-shops än en stor när båda bara tar en kund per tidsenhet).

Skrivet av jclr:

Teamet bakom e-cores har gjort ett riktigt bra jobb och det är den arkitekturen som är framtiden när man går mot en mer enhetlig mikroarkitektur. Det är inte helt otroligt att det dyker upp bredare simd även där när man använder den arkitekturen för prestandakärnor. Även SMT kommer komma tillbaka i någon form, antagligen i mer traditionellt format än de mer spännande rentable units / super cores. Eftersom du verkar vara intresserad av riktigt breda arkitekturer och allt som inte är x86 kan det kanske vara intressant att titta på vad AheadComputing hittar på.

Gå till inlägget

Är egentligen inte specifikt intresserad av vare sig specifika ISA eller specifika mikroarkitekturer. Däremot vore det väldigt spännande att bättre förstå varför vi i nuläget ser att ARM64 tillverkarna är så väldigt långt före x86_64 i perf/Hz. Om man åter igen kikar på teoretisk kapacitet är ju både Intels och AMDs senaste mikroarkitekturer betydligt närmare än vad de visar i "verkligheten".

APX blir superkul att testa. Där kan man nog få lite känsla för vad vissa av idéerna som implementerats av ARM64 (och RISC-V, men vi har ju ingen high-end RISC-V mikroarkitektur ännu, finns teoretiska beräkningar gjorda som visar att RISC-V bör vara konkurrenskraftig med ARM64 sett till perf/Hz).

Vad de gäller breda mikroarkitekturer: med rätt ISA verkar det i nuläget vara den bästa vägen framåt. Så hoppas AheadComputing ger en vink om potentialen hos RISC-V!

Senast redigerat
Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Vet redan ovan, men vet inte hur något av det är relevant.

Gå till inlägget

Jag har inte heller en aning om hur "Golden Cove (256-bit AVX)" är relevant? Det är du som envisas med att räkna upp en massa olika CPU:er hela tiden som alls har något med ditt ursprungliga felaktiga påstående om att "Orsaken lär vara att M-serien har så pass många fler ALUs" jämfört med Zen 5, vilket var det påstående jag korrigerade. Problemet är att när du blandar in nya icke-relevanta saker det så dyker det upp nya tekniska knasigheter.

Nu rör du t.ex. ihop mikroarkitektur med processorer som använder den mikroarkitekturen. Golden Cove som mikroarkitektur har AVX512, det är bara avstängt på klientprocessorerna.

Skrivet av Yoshman:

För klientvarianten av Lion Cove har Intel nämnt att där ska det inte finnas något AVX-512 stöd alls. Har för mig det nämndes när de pratade om varför de ansåg borttagning av SMT var vettig.

Gå till inlägget

Jag som tyckte att jag var smart och svarade på det här redan i texten du citerar. Som sagt så kan man se avx512 mask-registren även på Lion Cove genom att titta på kapaciteten hos XMM/X87 eftersom de återanvänder samma register. De har ökat något sen tidigare generationer. Du kan även se de om du tittar på en bild av Lion Cove. Simd enheterna ligger uppe i hörnet på samma sida som L2 blocket som har ett L1 block ovanför sig.

Men allt det här vet du redan…

Skrivet av Yoshman:

Jag är helt med på vad som gäller i teorin.

Men vad spelar det för roll när det i praktiken är rätt liten skillnad mellan t.ex. Zen 4 och Zen 5

Gå till inlägget

När man skriver benchmarks för att jämföra prestanda så måste man veta vad exakt det är man mäter och varför man får det resultat man får.

Det som begränsar Zen 5 är minnesbandbredd (som kommer öka i kommande generationer). Hur stor vinst man får om man jämför Zen 5 och Zen 4 beror helt på hur minnesintensivt i förhållande till beräkningsintensivt problemet är. En snabb överslagsräkning gör att man hamnar på över 300 simd instruktioner per cacheline på 9950X om man vill utnyttja fulla simd kapaciteten. Det har alltså inget med själva simd implementationen att göra utan minnesbandbredd (där M serien också har ett stort övertag).

Problemet är att du kommer med gissningar helt tagna ur luften som tex "många fler ALUs", sen letar du upp en benchmark som du inte riktigt vet vad den mäter. Några inlägg senare är det fastslagna fakta att i praktiken är det si och så pga av blablabla.

Titta bara på geekbench resultaten som du använde och vad Geekbench 6 Internals dokumentet säger om de:

Object Detection:
"Object Detection uses instructions that accelerate quantized machine learning workloads (e.g.
AVX-VNNI, AVX512-VNNI, and AMX on x86 processors, DOTPROD, I8MM, and SME on ARM
processors)."

SME "extern" delad accelerator vs. AVX512

Background Blur:
"Background Blur uses SIMD and machine learning instruction sets (AVX, AVX2, and AVX-512
on x86 processors, NEON and SME on ARM processors)" och " Background Blur also uses generic SIMD instruction sets (AVX2 on x86 processors, NEON and
NEON FP16 on ARM processors) to accelerate image processing functions"

Återigen SME vs. AVX512. Dessutom är delar av testet AVX2 vs. NEON men där ARM använder FP16.

Photo Filter:
"Photo Filter uses generic SIMD instruction sets (AVX2 on x86 processors, NEON and NEON
FP16 on ARM processors) to image processing functions"

AVX2 vs. NEON där ARM dessutom använder FP16.

Ingen av de kan alltså användas för att visa det du tror de visar.

Skrivet av Yoshman:

Vad de gäller breda mikroarkitekturer: med rätt ISA verkar det i nuläget vara den bästa vägen framåt. Så hoppas AheadComputing ger en vink om potentialen hos RISC-V!

Gå till inlägget

Ja alla arkitekturer kommer bli bredare med större ROB, frågan är om det finns något att hämta i extremt breda arkitekturer. De fick det inte att fungerar när de jobbade på Intel men det kan ändå vara intressant om nåt liknande dyker upp från AheadComputing istället. Det finns fler high-end RISC-V på gång t.ex. från Tenstorrent och Ventana men de är ju mer traditionella. (op-cahce + upp till 16 wide decode).

Senast redigerat
Redigera
Citera flera Citera
1 2
Skriv svar