Skulle inte vara några som större problem från den aspekten, du har bara mindre strömbudget per kärna att röra dig med vid all core turbo. Förbrukningen skalar långt ifrån linjärt med frekvens och man hade bara behövt sänka all core turbo med några 100 MHz med 10st vs 8 aktiva kärnor, det hade definitivt varit en hyfsad vinst i typ CB och andra vältrådade laster. 1-8 core turbo hade sedan varit i princip oförändrat så man hade inte tappat prestanda i något sammanhang från den aspekten, MEN!
Det som däremot hade börjat bli problem är att med ytterligare kärnor så hade man försämrat "core to core" latenserna ännu mer (vilka redan inte står sig bra mot Comet Lake enligt tidig info). Med fler fysiska hopp men också avstånd mellan cores så betalar du också ett prestandapris i vissa sammanhang (spel t.ex).
Visst är skalningen med frekvens i praktiken icke-linjär.
(Sidnot: rent elektriskt är effektutvecklingen linjär m.a.p. frekvens, men i praktiken måste man också justera spänningen vid högre frekvens och där skalar effekt kvadratiskt).
Men som allt handlar det om avvägningar. I något läge måste man fråga sig om man designar en krets för batch-jobb eller om det fortfarande är en krets optimerad för interaktiv användning.
Ta 5950X, den har i praktiken maximal frekvens på ~5,0 GHz när en kärna jobbar. När alla kärnor jobbar trillar man ofta ned under 4,0 GHz. Om man primärt använder datorn interaktivt så går "batch-jobben" i bakgrunden snabbare med fler kärnor, fast det man jobbar med under tiden i förgrunden varierar upp mot 30 %. Eller egentligen är det ännu värre p.g.a. SMT, total prestanda per kärna ökar upp mot 25-30 % tack vare SMT men det betyder att prestanda per CPU-tråd (och interaktiva laster är väldigt ofta enkeltrådade och rejält beroende på prestanda per CPU-tråd) är ~50 % vid full last jämfört med ett icke-lastat system. 50 % ger prestanda per CPU-tråd motsvarande en 2 år gammal Android-telefon...
Det märks om man försöker jobba på datorn och regelmässigt har saker i bakgrunden som använder alla kärnor. Framförallt märks det om man växlar mellan Apple M1 och AMD/Intel i den här typen av laster. M1 har inte alls samma totala kapacitet p.g.a. endast 4+4 kärnor men det man gör i förgrunden är i stort sätt lika snabbt vare sig CPU är "idle" eller lastad till 100 % p.g.a avsaknad av både SMT och "turboboost".
Vidare bör rimligen Intel tänka på den större bilden. Om alla deras konsument CPUer har en GPU, en GPU som faktiskt är riktigt kompentent i GPGPU sett till sin effekt och kretsstorlek, blir incitamentet att utnyttja OneAPI betydligt större. Intel behöver all hjälp de kan få på GPGPU-scenen om de ska ha någon realistisk chans mot Nvidias CUDA.
Även med 32 CU och ~1,5 GHz har den GPUn en flyttalsprestanda som motsvara 5-6 moderna x86_64 kärnor som använder AVX (även heltalsprestanda ser riktigt bra ut i Xe, men behöver se fler tester). Prestanda/W är helt överlägsen i GPUn och OneAPI gör det riktigt enkelt att sprida jobb både över CPU och GPU. De rätt många saker där 8C/16T kan tänkas bli en flaskhals är saker som lämpar sig väl för GPGPU. För egen del suger det då just kompilering är något som skalar väldigt väl över CPU-kärnor, men är ett exempel på något som trots det inte alls lämpar sig för GPGPU. Så för mig passar det AMD gjort med 5950X perfekt, samtidigt finns väldigt många fall inom programutveckling där en iGPU är mer än nog.
Fler än man anar använder faktiskt iGPUn, med Xe och OneAPI kommer det vara fullt möjligt att använda det kislet på vettiga sätt även i system med dGPU!
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer