AMD Ryzen 9 9950X – ett litet prestandalyft för mer pengar

Felet syns tydligt i vissa spel i låga upplösningar. Det betyder ju inte att det bara är där problemet kan uppstå.
Och CPU-kraven ökar över tid - kan bli relevant senare. (etc etc...)

Det är fortfarande ett mer eller mindre icke-problem nu vid lanseringen och CPU-kraven kommer inte öka nämnvärt i närtid. På längre sikt så lär väl problemen antagligen vara lösta så jag anser fortfarande att uppståndelsen kring detta är sjukt överdriven.

Särskilt med tanke på laptops där power management är väldigt, väldigt viktigt. Microsoft behöver trots allt till någon nivå konkurrera med Apple, och Linux gör defintivt någon slags framsteg med vad jag kan avgöra i laptops. Det går ju inte att komma undan att Windowslaptops generellt är sämre på allt som gäller prestanda/batteritid än macbooks, så var nog viktigt att se till att alder lake och efterföljare blev implementerade väl för laptops. Vilket de, längs vägen, blev.

Varför sitter du och försöker upplysa mig om fakta som jag skrev till dig redan i mitt andra svar??? Trollar du eller är du bara dålig på att argumentera?

"...de använde Windows för att åtgärda felet..." nä de "använde" Microsoft för att åtgärda Windows få att få strategin med P- och E-cores att fungera optimalt. Sluta tramsa och läs artikeln jag länkade istället.

Gulligt att du tror att det fungerar så men jag kan upplysa dig om att verkligheten inte ser ut så på riktigt stora företag.

"Jag vill att mitt team/min avdelning lägger sina resurser på de projekt vars externa partners är mest tillmötesgående och inte de projekt som ger mig mest cred/belöning internt." sa en projektledare/mellanchef aldrig...

Du har uppenbarligen fortfarande inte läst artikeln. Direkt saxat från den "Intel’s Thread Director controller puts an embedded microcontroller inside the processor such that it can monitor what each thread is doing and what it needs out of its performance metrics.". Ifall Intel löste sina problem genom patchning av den så betyder det att problemen du talar om inte var knutna till ett visst OS utan låg i mikrokoden direkt i hårdvaran. Hade AMD haft samma problem som Intel, hade de haft problem med Zen5s prestanda även i Linux vilket inte är fallet. Din teori att AMD skulle ha liknande problem som Intel hade med Alder Lake och att det är upp till dem att "använda Windows för att fixa det" håller inte. Punkt slut.

Microsoft ska inte lösa varken Intels eller AMDs interna kod, de ska bara se till att Windows interagerar korrekt med den efter givna förutsättningar. Varför skulle det överhuvudtaget krävas källkod som är open source menar du? Kravspecifikationer, teknisk dokumentation och testhårdvara skulle inte räcka för Microsoft att göra sin del menar du? Känns som att du griper efter halmstrån nu.

Hmm, visade sig att Zen 5 dual decoder inte används om bara en CPU-tråd är aktiv i en kärna. D.v.s. den fungerar inte som Crestmonts dual decoder (vilket de flesta utgick ifrån när AMD nämnde att Zen 5 har en 2x 4-wide decoder).

"Zen 5’s frontend has a 8-wide decoder, arranged in two 4-wide clusters. It’s AMD’s first clustered decode implementation, and differs from clustered decode in Intel’s E-Cores in that a single thread appears unable to use both decode clusters together."

Så intressant att AMD och Intel båda går till en dual-decoder av samma grundläggande orsak: är ett helvete att bygga en väldigt bred decoder för x86 (i.e. dyrt i effekt och transistorer), men de har rätt olika strategi för hur man bäst utnyttja en dual-decoder, Intel går efter högre single-thread medan AMD går efter högre dual-thread prestanda.

TL;DR är att Zen 5 är fortfarande 4-wide i enkeltrådade fall. Den är 8-wide när SMT används.

När halmstråna är slut så ger du upp, alltså?

Det är inte Intel Thread Director som bestämmer vad OSet ska göra. Den informerar operativsystemet i realtid om vilka fysiska processtrådar som i varje ögonblick är mest lämpliga för olika typer av laster, lägst latens, mest beräkningskraft, mest energieffektivitet etc. Hur den här informationen sen används är upp till operativssystemets schemaläggare att avgöra. Återigen läs artikeln, allt står där, så slipper du gissa. Det är också anledning till att man fortfarande ser skillnad mellan hur Windows och Linux presterar trots att de utsätts för liknande laster vilket Yoshman är inne på här ovanför.

Du svarade aldrig på hur open source kom in i bilden förresten...

Jag tror att även om du har skrivit ett långt och insiktsfullt inlägg så har du överkomplicerat frågeställningen som debatterades en hel del.

Intel själva säger att Thread Director gör nytta på Windows 10 men kräver Windows 11 för att nå optimal prestanda.

"Thread director also works with Windows 10 Scheduler, but it is not optimized for it. In summary, for optimal performance for 12th Gen processors, you should go with Windows 11."
https://www.intel.com/content/www/us/en/support/articles/0000...

Det betyder alltså att även om Intel Thread Director är Intels teknologi och det sitter i deras produkter så är det inte bara upp till dem att "fixa det" (som vissa hävdat, inte du dock) utan det kräver även insats från tredje part som Intel bara indirekt kunnat påverka.

Jag har från början hävdat att så även kan vara fallet när AMD har SIN lansering av SINA produkter. De finns faktorer kring hur konsekvent de presterar som ligger utanför AMDs kontroll trots det.

Det är inte heller så att allt var frid och fröjd med interaktionen mellan Windows och Intel Thread Director bara för att Windows 11 lanserades. Det fanns fortfarande problem i vissa scenarion för enskilda användare vilket följande är ett exempel på.
"This issue only pertains to hybrid architecture CPUS like Intel 12th gen on Windows 11. I believe this has to do with the thread director that was introduced for Windows 11. This has been an issue before the 22H2 update - when a program is minimized or clicked off of, it would only run on the efficiency cores of my CPU. I could deal with that, although it was a downgrade from Windows 10 where I was able to do something else on that PC without losing performance. However, with this update, the program (HandBrake) now also runs only on E-Cores when the screen is turned off. The CPU affinity is set to all 20 of the threads in my i7-12700H, so this is not an issue. I either have to sacrifice my screen to burn-in or double my video encoding time."
https://learn.microsoft.com/en-us/answers/questions/1027852/w...

Intressant nog så verkar administratörsrättigheter ha avhjälpt problemet:
"I did some more research and found that running the program as administrator actually prevents this behavior. I have no idea why this would fix it, but Handbrake now runs on all 20 threads both when minimized and when the screen is off."

Det låter väldigt bekant...

Problemet du beskriver ovan lär ju vara 100 % upp till Intel att fixa i Windows 11.

Stora skillnaden mellan Windows 10 och Windows 11 för detta är: Windows 11 ger i stort sätt full kontroll för en driver att bestämma var en viss OS-tråd ska köra, Windows 10 ger begränsad sådan möjlighet.

HW-delen av Thread Director ger "bara" väldigt detaljerad information. Den ger samma information oavsett om man kör Windows 10, 11 eller Linux. Vad en driver sedan kan göra med informationen varierar mellan Win10, 11 och Linux.

I Windows 11 och Linux är det i praktiken upp till HW-tillverkaren att endera vara OK med default-policy alt. göra en driver som ändrar detta beteende på "optimalt sätt". Huvudproblemet här är att "optimalt sätt" är långt ifrån entydigt, om Thread Director gör något vettig är det lite enklare att göra detta p.g.a. mer relevant information.

För multi-CCD CPUer är det upp till AMD att ha en driver som gör "rätt sak", det oavsett om det är Windows 11 eller Linux. Och som jag skrev ovan: var finns indikationer på att det i nuläget fungerar bättre under Linux?

Att Phoronix visar större fördel för Zen 5 beror primärt på att de har en långt större andel tester som drar nytta av AVX512, vilket inte visar att schemaläggning fungerar bättre. Ovanpå det vet vi att Linux generellt sett är bättre på att schemalägga på CPUer med många kärnor, det är dock inte Zen 5 specifikt på något sätt.

Dom har hittat en bugg i Windows som skadeskjuter amd 9000 serien och ger den sämre performance i spel.

Men ja väljer Amd alla dagar i veckan före intel

"Det?"

Samma Phoronix-test som diskuterats hittills?

Så: Linux är bättre i absoluta tal och Linux hanterar de nya processorerna bättre än Windows 11. På just de tester Phoronix körde förstås. Marginalen tycks... marginell.

Geometriskt medelvärde 73 tester.

Phoronix motivering till urvalet av tester:

Men urvalet är ju som påpekat av Yoshman väldigt skevt med över 60% av benchmarks som tjänar på AVX-512. Hade de kört samma tester i Windows hade den vinsten också varit mycket större än vad de flesta recensionerna fann; skillnaden är inte främst Linux vs Windows utan AVX-512 vs utan.

Det har en extrem övervikt program som har någon form av nytta av AVX512. Bara en handfull av programmen som testas saknar AVX2 och/eller AVX512 optimeringar. Inte precis ett representativt genomsnitt av "typiska program" som primärt beror av skalära heltal (medan det som testas här är primärt vektoriserade flyttal).

Det vi främst ser från de testerna är att 7950X och 9950X får båda i genomsnitt bättre resultat om man använder Linux. Det är ingen nyhet, man får samma resultat med Intels CPUer med många kärnor.

"relying mostly on tests that offer official binaries for both Windows and Linux systems to rule out compiler differences."

Det där är verkligen en WTF! Kör man med officiella binärer kan man direkt utgå från att det i 9 fall av 10 kommer vara skillnader i kompilatorer.

• Default-kompilator för Windows är MSVC++, även om Clang/LLVM börjar bli lite vanligare. GCC har inte direkt Windows-stöd även om det finns sätt att använda den kompilatorn (fast sällan optimalt för Windows).

• Default-kompilator för Linux är GCC, även om Clang/LLVM används i bland.

• Default-kompilator för MacOS är Clang/LLVM, även om GCC används ibland.

Ett typexempel på vad man kan förvänta sig av ovan har vi sett med Geekbench innan version 6. En viktig nyhet i GB6 är att man specifikt undviker ovan genom att köra Clang/LLVM på alla OS då det är enda kompilatorn med officiellt stöd för Windows, Linux och MacOS.

I GB6 presterar Windows, Linux och MacOS väldigt snarlikt på samma system. I tidigare versioner var det inte fallet, både Clang/LLVM och GCC är idag en bättre kompilator jämfört med MSVC++ om man med "bättre" menar "producerar snabbaste binärerna" (finns poänger med MSVC++, bl.a. är de idag ofta snabbast att implementera nya delar av C++ standarden).

Det finns saker som ändå kan skilja mellan Linux och Windows, typiskt till Linux fördel sett till prestanda, även om man använder samma kompilator. Detta då de har olika ABI! T.ex.

Register Usage

Windows (Microsoft x64 Calling Convention)

	•	General Purpose Registers Used for Parameters:
	•	The first four integer or pointer arguments are passed in the following registers (in order):
	•	RCX, RDX, R8, R9
	•	Additional arguments are passed on the stack.
	•	Floating Point Arguments:
	•	The first four floating-point arguments are passed in the following registers (in order):
	•	XMM0, XMM1, XMM2, XMM3
	•	Additional floating-point arguments are passed on the stack.
	•	Return Values:
	•	Integer and pointer return values are returned in RAX.
	•	Floating-point return values are returned in XMM0.
	•	Caller-Saved (Volatile) Registers:
	•	RAX, RCX, RDX, R8, R9, R10, R11, XMM0-XMM5
	•	Callee-Saved (Non-Volatile) Registers:
	•	RBX, RBP, RDI, RSI, R12-R15, XMM6-XMM15

Linux (System V AMD64 ABI)

	•	General Purpose Registers Used for Parameters:
	•	The first six integer or pointer arguments are passed in the following registers (in order):
	•	RDI, RSI, RDX, RCX, R8, R9
	•	Additional arguments are passed on the stack.
	•	Floating Point Arguments:
	•	Floating-point arguments are passed in the following registers (in order):
	•	XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7
	•	Additional floating-point arguments are passed on the stack.
	•	Return Values:
	•	Integer and pointer return values are returned in RAX.
	•	Floating-point return values are returned in XMM0.
	•	For complex data structures, additional values may be returned in RDX or XMM1.
	•	Caller-Saved (Volatile) Registers:
	•	RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, XMM0-XMM7
	•	Callee-Saved (Non-Volatile) Registers:
	•	RBX, RBP, R12-R15, RSP (stack pointer), XMM8-XMM15

Verkar också preliminärt som att det även påverkar Intel, så det verkar vara en allmän prestandapåverkan snarare än något AMD-relaterat.

Det enda som betyder nåt är priset nu, inte vad det kostade vid släpp. 7000 serien är mkt billigare än nya 9000 serien till i princip samma prestanda. Så att betala mkt mer är bara dumt.
Än värre att AMD i princip ljög om prestandan tidigare under presentationen.

Okej om det ända som betyder något är priset just nu, så betyder det att allt som har med pris att göra är totalt orelevent i alla recensioner och långsiktigt så är det bara dumt att ha med pris i testet..

Samt ljög? Alla vet att ALLA drar till lite när dom presenterar sina resultat, sen har det juuh visat sig att det delvis är Windows och inte AMD som är problemet då man får i vissa scenarion över 10% ökning bara att att sitta på admin kontot (inte ett konto med admin rättigheter utan det "gömda" riktiga admin kontot.

Samt om nu priset just nu spelar roll så är sweclockers recensioner lite underliga då denna fick högt pris medans 7950x vid lansering va dyrare och inte fick det.

Fast då fanns inte "7950X som är nästan lika bra" utan "5950X som är en hel del långsammare", därav skillnaden i värdering.

Tycker detta är jättetråkigt eftersom jag har 7950X LoL betalar inte 9000Kr för 5% bättre prestanda som ibland är sämre ...

Med det sagt, jag hoppas fortfarande på 9800X3D/9950X3D och att de skall bli en hit samt att jag fortfarande är nyfiken på X870E moderkorten. Vi får se.

Att priset kommer upp nu beror nog väldigt mycket på att 7950X var en så stor uppgradering över 5950X, i TechPowerUps test av applikationer (som är den klart mest omfattande för Windows) var ökningen där över 33 %. Klart att man kan ta med betalt för 7950X då.

Det stämde rätt OK med de jämförelser AMD själva skickat ut innan, där pratade man om ökningar från 30 % till upp mot 50 % i specifika program. Sure, i överkant men de 33 % som TPU fick i genomsnitt är i alla fall inom intervallet.

AMD hävdade över 50 % bättre prestanda för 9950X mot 14900K i Handbrake, SweClocker uppmätte en skillnad på 1,5 %.

AMD hävdade 16 % IPC-ökning i genomsnitt, vilket då det är samma frekvens är samma som förväntad prestandaökning. Det blev, lite beroende på modell, från 5-8 % i TPU applikationsmätning. Både TPU och HUB (som är de som testar flest spel) fick 2 % ökning i spel, vilket AMD nu säger "det låter rimligt, vi får 5 %".

Så visst cherry-pickar tillverkarna, men det är på en helt verklighetsfrånvänd nivå för Zen 5 och en nivå vi aldrig tidigare sett.

Vilket i grunden känns rätt onödigt: trots den relativt modesta ökningen är ändå Zen 5 i ledningen för om man håller sig till x86!

Även om Lion Cove verkar ha lite högre IPC-ökning har ju Intel problemet (fast det är knappast ett problem om det samtidigt sänker peak-effekt med <=100 W) att peak-frekvensen verkar gå från dagens 6,0-6,2 GHz till 5,7 i Lion Cove -> kan mycket väl bli samma 5-10 % faktiskt ökning där som för Zen 5! Så full möjligt att AMD behåller ledningen även efter oktober.