AMD Zen 5 kan ge 40-procentig prestandaökning

Så 12 kärnor per CCD bekräftat då.

Tror att den största ökningen ligger i "AI-prestanda" och inte "gaming-prestanda".

Inte vid samma klockfrekvems. Men du har rätt, jag borde specifierat det.

Klockfrekvensen tycker inte jag är så intressant att jämföra mellan de olika plattformarna. Jag tror inte det bara är att skruva upp klockfrekvensen på ARM för att få fri prestandaökning, utan det är bättre titta på prestanda och effektåtgång. Men samtidigt har Intel skruvat på alla kranar för att kräma allt ur de senaste x86 desktopmodellerna. Finns artiklar med tips på att ställa ner en hel del och ändå bibehålla väldigt bra prestanda.

Angående ARM på Windows såg jag precis denna nyhet precis om en Lenovo med Qualcomms ARM. Får hoppas det blir lite mer konkurrens på Windows-marknaden mellan plattformarna.
https://videocardz.com/newz/lenovo-laptop-spotted-with-snapdr...

Äntligen något som kanske orkar driva runt Tarkovs knackiga kod...😂
Låter överdrivet alt. i ett väldigt specifikt scenario. Men man kan hoppas, allt över ~25% bättre spel prestanda är imponerande, och det kanske inte är omöjligt med tanke på vilka framsteg och satsningar AMD har gjort dom senaste åren.

Det är två månader kvar till Computex 2024, där AMD förväntas presentera Zen 5. Då får vi väl se AMD info om potentiell CPU prestanda. Eller så blir det bara AI istället.

Jämförelsen vid samma klockfrekvens är väldigt intressant av två orsaker.

För det första så är klockfrekvensen till väldigt stor del det som driver upp strömförbrukningen. Med ett givet chip så skalar typiskt effektförbrukningen kvadratiskt mot frekvensen. Utöver detta så måste ett chip designas för att klara hög klockfrekvens. Detta innebär att hur stora så kallade "kombinatoriska träd" kan vara begränsas. För att minska dessa träd för samma funktion så delas de upp i flera steg med flipfloppar emellan. Detta skapar ett större pipeline djup, vilket kan göra andra delar av kretsen mer komplex för att klara av att hantera det. Detta leder till att kretsen blir större (och drar ännu mer ström) bara för att klara högre frekvens.

Den andra anledningen till att det är intressant att jämföra vid samma frekvens är att det finns fysikaliska begränsningar för hur snabbt en grind kan ändra värde i en kiselkrets. Det beror en del på tillverkningsteknik, men det finns en övre gräns där det inte går att öka frekvensen längre. Dessutom finns, vad jag vet, inga hinder för att skala upp frekvensen för vilket chip som helst till de nivåerna intels kör på. Det behöver designas om i viss mån enligt min grova beskrivning ovan. Min poäng är att det är en tillgänglig väg för att öka prestandan utan att utveckla smartare metoder för att öka IPCn, och det övre taket bör ligga vid ungefär samma frekvens oavsett instruktions-arkitektur.

8800X3D kanske det blir fart i? Min nästa cpu kommer nog vara en variant med mer cache.
Kanske prestandan kommer av att cache mängden ökat på även vanliga modeller?
Men rykten är just det. Vi får se vid lansering.

Om det blir ett sånt hopp mellan 7800X3D och 8800X3D kan det bli en uppgradering faktiskt.

Nöjd nog med nuvarande CPU men man vill ju altid ha något snabbare. Och är mitt B650E-F kompatibelt så varför inte.

Rykten för nya GPU och CPU säger väl alltid "40%"? Sen brukar det bli de vanliga 15-25%.

Rykte i kvadrat

√1,4≈1,15<1,25

En 8c 16t laptop CPU med 3d cache i nivå med 7800x3d hade varit magiskt.
Kombinerat med ett laptop RTX 5600 120w och 32GB DDR5 ram.

2560x1400 240HZ OLED 17"

Sign me up!

Vågar man hoppas på 12 kärnor för 9800X3D?

Får dom plats med 12 kärnor på en CCD?

Parallellisering är inte samma som out of order på en ensam tråd

Vilken kod du än kör kommer ha högre prestanda per cykel på apple än x86 som det ser ut nu. Apples gör ju nära dubbelt så mycket arbete per klockcykel

Du har lite fel. Han avser inte hur många trådar, och därmed kärnor, du kan dela upp det i, utan hur mycket man kan mata beräkningsenheterna inne i varje kärna. En processorkärna har ett flertal olika exekveringsenheter internt. Jag kan inte det hela särskillt väl. Men enkelt (och med förbehåll för missförstånd) kan jag säga att man använder en prefetch för att försöka ha så mycket uppgifter redo som möjligt och en schemaläggare som sedan försöker hålla alla beräkningenheter fyllda. Detta gäller även vid en tråd. Även om flertrådsteknik är ett sätt att utnyttja de resurser som inte utnyttjas av en ensam tråd.
Du kan lägga till fler beräkningsenheter i en kärna och öka kapaciteten, men du måste se till att kunna schemalägga tillräckligt för att dra nytta av dem. I mycket kod så kan du inte påbörja en beräkning innan du har svaret från beräkningen innan och enheterna kan då gå på tomgång. Det man kan göra är att göra exekveringen spekulativ och chansa på vilken data som ska beräknas hur i förväg och tjuvstarta.
Äldre processorer hade inte nytta av mer än några enstaka beräkningsenheter, men framsteg med prefetch, schemaläggning, cache och flerttrådsteknik har ökat processorns förmåga att utnyttja fler enheter. Men det blir svårare och svårare.

Det man kan göra är att korta ner pipelinen, så att antalet cykler det tar att få en output minskar, det hjälper när du behöver ett resultat från tidigare beräkning för att kunna mata beräkningsenheterna. Total throughput ökar dock inte. Efter att man ökat på längden på pipeline för att öka frekvenser med gamla P4 till priset av IPC, och misslyckats, så är jag rätt säker på att varje pipelinesteg är väldigt befogat idag. Och att de allt längre pipelines vi ser snarast ökar IPC med de steg som lagts in. Något man kanske kan göra är väl dock att öka bredd samtidigt som man kortar ner antalet steg. Men Zen 4 är redan idag uppe på en issue width på 10, mot 7 i Zen 3. Som kontrast så låg ursprungliga Zen på 4 om jag inte minns fel, Bulldozer på 2, men gamla hederliga Athlon/Athlon64 låg på 3.

Med tanke på vad jag hört om IPC innan så är jag ganska förvånad att vi sett de framsteg på IPC som vi sett över Haswell. Någon på forumet oändligt mycket kunnigare än jag i frågan förklarade svårigheterna på den tiden.

IPC är inte inklusive frekvenshöjningar.

Ja och de senare ryktena som kommit efter säger 20-25%.

nja @aleshi har rätt här. IPC på en modern x86 arkitektur innebär att du måste kunna mata alla ALU:s i en kärna med jobb den cyceln för att du ska komma upp i de siffror som presenteras. På simplare CPU:er som 6502 som har en enda ALU så är högre IPC alltid bättre för singeltrådade laster men på moderna arkitekturer är det inte så enkelt längre eftersom en kärna numera innehåller flera exekveringsenheter (ALU:er för heltal).

Zen5 t.ex har 6 ALU:er per kärna mot 4 på Zen4 så om schedulern kan fylla alla 6 med jobb i en cykel så kommer du upp i den IPC som AMD specar, men som någon i tråden redan anmärkte på så finns det gott om laster där man inte ens kan fylla alla 4 i Zen4 (och att så är fallet är ju det som hela biten med HT handlar om eftersom man då kan köra andra trådar i de ALU:s som blir över).

Det du skriver motsäger inte vad jag skrev, att högre IPC inte alltid kan utnyttjas fullt ut innebär inte att den inte är högre, som många redan har påpekat så kommer resultaten att variera vilt beroende på last men det kommer med all sannolikhet aldrig att gå långsammare ....

Vilka rykten? Menar du tweeten på Hindi? Den sa ett antal benchtests och slutade med "Avg 3x%?". Den indikerade ett snitt på över 30% i alla fall.