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

Enligt den senaste uppdatering ska det tydligen räcka med att högerklicka och köra som administratör för att få samma effekt.

Den är ju faktiskt billigare än vad 7950X vid release, så dumt att säga att den är dyrare. Send prestera den mycket bättre under Linux än under windows. Så detta verkar vara ett Windows problem inte att AMD problem.

Det är olika schemaläggare på Windows och Linux.

Om felet är Windows eller amd får vi vänta och se.

För dyr, men är den verkligen 5% bättre i alla sammanhang har den sin plats. Till skillnad från säg 9900x, där man bara kan köpa 7950x istället vilket är snabbare.

En bugg i Windows som ger 9000 serien sämre prestanda.
Och felet kommer fixas i en kommande Windows update patch.

Länk? För det jag sett så påstår amd Windows bugg men kan lika gärna vara bristande driver support från deras håll....

Nu har iofs gapet mellan Windows och Linux blivit mindre från 20 - > 11% om man läser det Yoshman säger.
Men absolut att server marknaden är en större inkomst dock

Syftar du inte på grejerna från Hardware Unboxed (och övriga, som Calle) nu? Det påverkar även tidigare generationer Ryzen, och enligt kommentarer på deras videos även Intel.

Nä finns andra tech sidor som skriver att det är en bugg i just Windows som försämrar 9000 seriens performance men det kommer fixas senare i en Windows uppdate

Är nog både och men amd ska ha skickat ut drivers som ska ha fixat eller så kommer dom strax.
Meeen som ja sagt tidigare tar amd alla dagar i veckan före intel om ja inte vill värma upp huset o ha en egen kärnreaktor som skall leverera ström till club samt med alla krascher

Om du syftar på vad Hardware unboxed hittade på youtube så är det att de kör elevated admin konto och då tar bort mycket av säkerhets scanning som kan ge ökad Performance.
Denna ökning ges till alla cpuer verkar det som, inte bara 9000 serien. Sen är performance enbart 3%ish
Zen 4 fick 2.8%.ökad prestanda i deras tester.

De skyller på Windows bug, men en nyktrare bild är man får se vad som orsakar felet.
Givet amds historik så är mjukvaru fel inte otänkbart

Intel har inte fler crasher än amd?
Eller syftar du på degraderade cpuer så verkar de råda skilda meningar vem som har flest fallerande cpuer. Dock är Intels pga för hög ring volt medan amds bara verkar vara kassa (pugget system har amd mycket högre reklamationer)
Vi har enbart hört om pugget och server cpuer, så vad den riktiga siffran är får vi nog aldrig veta

Även om Intel drar mer så är det väldigt mycket lägre i gaming än vid multi core tasks

Edit
Om amd skall skicka ut drivers så är ju felet hos amd....

Har du verkligen belägg för vad du påstår här? I en senare artikel från Anandtech (dock fortfarande från hösten 2021) i vilken interaktionen mellan ITD och schemaläggaren i Win11 bekrivs lite utförligare så låter det annorlunda.

"The scheduler is Microsoft’s part of the arrangement, and as it lives in software, it’s the one that ultimately makes the decisions. The scheduler takes all of the information from Thread Director, constantly, as a guide."

"The scheduler can override the Thread Director, especially if the user has a specific request, such as making background tasks a higher priority."

"By defocusing the video export window, it now moves to the slower E-cores. If I want to keep it on the P-cores in this mode, I have to keep the window in focus and not do anything else. The way that this is described also means that if you use any software that’s fronted by a GUI, but spawns a background process to do the actual work, unless the background process gets focus (which it can never do in normal operation), then it will stay on the E-cores.

In my mind, this is a bad oversight. I was told that this is explicitly Microsoft’s choice on how to do things."

https://www.anandtech.com/show/16959/intel-innovation-alder-l...

Om man läser vad som står där så låter det som att det fortfarande är Windows och därmed Microsoft som har slutordet. Artikeln är ju dock drygt 2,5 år gammal så vissa saker kan ju ha ändrats. Jag har försökt hitta en nyare och lika ingående artikel i ämnet, dock tyvärr utan framgång. Har du några källor som visar på att det nu fungerar som du påstår?

Slutligen, för att svara på din fråga angående Linux. Nej, från de tester som publicerats hittills blir det svårt att säga något uteslutande om hur konsekvent just schemaläggaren i Linux jobbar med Zen5 utan det kan möjligtvis vara så att det är typen av laster som gör att den presterar så pass bra där. Kan väl bara konstatera att mig veterligen så har det än så länge iaf inte rapporterats några uppenbara problem som i fallet med Windows 11.

Läs det du highlightade igen

"The scheduler can override the Thread Director, especially if the user has a specific request, such as making background tasks a higher priority."

Detta måste finnas i alla typer av styrsystem, för annars skulle användaren aldrig kunna forcera saker utan admin konto.
Om topologin var ITD överst så skulle användaren aldrig prioritera om vad Intels algorithm skulle säga.

ItD är enbart maskininlärnings algorithm och kan inte ta till sig requests utanför det.

OSet fungerar som en plc och tar till sig all data med topologin användare -> itd istället

Detta är enbart en gissning pga hur alla styrsystem är uppbyggda så borde detta vara likadant.

Självklart är det scheduler i OS som i slutändan är den som bestämmer var en viss OS-tråd kör. Det är liksom hela poängen med det subsystemet.

Men det utesluter inte att andra system i praktiken kan påverka tillräckligt mycket att de gör valen. Det är rätt mycket fallet i Linux (där vi har källkoden för att se exakt hur det görs) och det ser definitivt ut att vara så i Windows (men där får man titta på vad som verkar hända då vi inte har tillgång till källkod).

Att dessa "förslag" har rätt kraftig påverkan ser vi här

Inte exakt alla tänkbara permutationer, men flexibiliteten är uppenbarligen tillräckligt stor för att helt kasta om primärvalet som Windows kommer göra i form av att "i första hand E-cores" mot "i första hand P-cores".

Sen fallet du tog upp innan, läste på lite mer och det är ett fall av "det ska vara så!". En sak som Windows gör, och Linux inte gör, som på ytan verkar helt rimlig är nog roten till mycket av det som upplevs som "udda beteende" i Windows. Windows gör så att den process med input-fokus har rätt mycket högre prioritet än andra (i fallet P/E-cores betyder det normalt att den processen får första tjing på P-cores).

Men det problemet är inget problem givet att det faktiskt går att sätta konfigurationen så att P-kärnor fortsätta användas även när processen befinner sig i bakgrunden. Det är i de flesta fall ett icke-optimal val och därför inte default, men går att ändra.

I fallet dual CCD CPUer är ju skillnaden mellan CPU-trådarna mindre, men ändå fyra klasser att hålla reda på

2 klasser kommer av: CPU-kärnor som delar CCD och där "andra" CPU-tråden är "idle", det finns 2 CCD
2 klasser kommer sedan av SMT på respektive CCD

Vad Microsoft verkar val här är att säga "detta är ett tillräckligt litet problem utanför spel att vi löser detta specifikt för spel via game-bar". Vad en drivers, den AMD initialt gjorde 7900X3D/7950X3D och som nu tydligen också ska användas för 9900X/9950X, kan göra här beskrivs i den information jag hittat som "soft core-affinity".

Det program som processor-lasso och liknande gör är att sätta hårda begränsningar på var en viss process kan köras. Detta är en typ av tillåten explicit styrning som både Windows och Linux har (men MacOS saknar) som går ovanför vad OS-scheduler kan göra. Så den vägen kan ju användas att begränsa t.ex. ett spel till en specifik CCD, game-bar funktionen gör i praktiken detta men där finns tydligen fortfarande möjligheten för OS-scheduler att göra avsteg (t.ex. om två applikationer har samma policy, i det läget är det i praktiken bättre att köra ena programmet på ena CCD och andra på andra CCD även om båda föredrar t.ex. första CCD).

För att göra detta ännu mer komplicerat finns numera även säkerhetsaspekten med vid användning av SMT (SMT har visat sig vara osäkert "by design", det är en side-channel inom en CPU). Vet inte om Windows implementerat detta ännu, men Linux undviker numera att köra två OS-trådar som inte explicit litar på varandra (typ de tillhör samma program) på olika CPU-trådar hos samma CPU-kärna. Skulle potentiellt kunna påverka spel då spel mår bäst av att bara en CPU-tråd per kärna används för de trådar som inår i spelet. Denna policy minskar antalet tillgängliga CPU-trådar som kan användas för andra saker som körs i bakgrunden.

TL;DR det är absolut så att OS-scheduler har sista ordet, men i praktiken lyssnar den så mycket på de "förslag" som ges från t.ex. Thread Director att dessa "förslag" i praktiken kan styra som de vill. OS-scheduler väljer dock alltid en specifik CPU-tråd, hjälpsystemet föreslår bara i praktiken en "klass" av CPU-trådar.

En väldigt bra genomgång av AVX512 i Zen 5 hittar ni här: http://www.numberworld.org/blogs/2024_8_7_zen5_avx512_teardow...

Två saker som kanske flera funderar kring.

Hur påverkar användning av AVX512 CPU-frekvensen. Det var/är ett problem på Intels konsumentmodeller att frekvensen minskar rejält när AVX512 används. Visar sig att Zen 5 påverkas mindre och framförallt mer gradvis, men är rätt stor påverkan

Den andra, som författaren kände han explicit behövde nämna, är att PS3 emulatorer och liknande kommer inte se någon nytta av att AVX512 nu är 512-bit i Zen 5. Dessa emulatorer använder AVX512 (vilket gav Zen 4 en boost), men de använder bara 128-bit AVX512 (finns 128, 256 och 512-bit varianter av i stort sätt alla AVX-512 instruktioner, Intels kommande AVX10 är AVX-512 med 128 och 256-bit stöd). Så Zen 5 är inte snabbare än Zen 4 på detta.

Någon som hört ngt mer om windows updatering/Bios etc och/eller stabilare resultat? Är det på gång?

Om det kan ses som en självklarhet att Windows schemaläggare alltid har sista ordet, så blir det även indirekt en självklarhet att när kombinationen "CPU-driver" och schemaläggare inte beter sig som förväntat och/eller optimalt så går det inte automatiskt att direkt peka ut den ena som "boven i dramat", oavsett om vi pratar om AMD eller Intel. Det är precis vad jag har argumenterat för från första början i tråden.

Även om schemaläggaren är relativt "slapphänt" och låter "CPU-drivern"/trådregissören göra som den vill i 99 fall av 100, så kan man ändå inte utgå från att den inte har varit inne och ställt till med något den gången det väl dyker upp problem just eftersom den alltid har sista ordet.

Det spelar ju heller ingen roll hus pass komplicerade algoritmer som trådregissören använder sig av, i det här hänseendet, då mer precisa rekommendationer hur hårdvaran ska användas i slutändan inte ändrar "maktbalansen" mellan trådregissör och schemaläggare.

Sen får man heller inte glömma bort att hur pass optimalt hårdvaran utnyttjas är en objektiv frågeställning, om än en oändligt komplicerad sådan. Den andra sidan av myntet, som schemaläggaren och därmed även Microsoft måste ta ställningen till, är vad systemet och/eller användaren upplever som viktigast, vilket är subjektivt. Om fler processer än tillgängliga trådar vill ha högsta prioritet och de enligt trådregissören kommer föreläggas likadant i hårdvaran, vilka får gå före? Är systemprocesser viktigare än användarprocesser? Vilka processer anses vara viktiga nog att köra energiineffektivt etc? Svaret på sådana frågor är subjektiva och inget som trådregissören (oavsett komplexitetsgrad) kan svara på utan det måste schemaläggaren avgöra själv. Man inser ganska snabbt att det kommer skilja från fall till fall och att Microsoft här måste bygga in subjektiva prioriteringar i schemaläggaren som de tror att de flesta användarna kommer vara nöjda med. Givetvis kan saker och ting gå snett här, både vad gäller vilka val man som gör samt hur de implementeras.

Slutligen vill jag bara flika in att naturligtvis kan det i fallet Zen5 vara så att det är AMDs form av trådregissör som inte ger tillräckligt klara direktiv till Windows schemaläggare och att det därmed är AMD själva som är ansvariga för att fixa problemet. Stör mig dock på när folk uttalar sig tvärsäkert om att det skulle vara just så fast att de omöjligen kan veta det.

Nu verkar det som att dessa kanske inte går att fixa alls, AMD verkar ha misslyckats totalt med inter-CCD kommunikationen. Latencyn mellan CCD är mer än fördubblad vs Zen 4 ja tom vs Zen 2 och 3. Påverkar saker som spel mycket negativt, inte så mycket serverlaster.

Förklarar varför man måste ha core parking igång till varje pris vid gaming, prestanda kraschar om den andra CCD:n vaknar. Dessutom ohyggligt krångligt att få att fungera korrekt, samt att det är oerhört ineffektivt att ha en 16-kärnig processor där man bara kan använda 8 kärnor. Med Intel är i alla fall E-cores igång för bakgrundstjänster.

Så, ser ut som att dubbel CCD chippen kan vara obsoleta för desktop. DOA. Återstår då enkel CCD chippen, 9600X och 9700X, men som båda får rejält med stryk av 7800X3D. Man får ju hoppas att 9800X3D verkligen är snabbare och att AMD inte har sabbat även kommunikationen med 3D vcache ....

Nu förstår i alla fall jag varför AMD fortfarande lanserar nya AM4-chip, man är rädd att försäljningen skall krascha för självklart känner AMD till att Zen 5 är en tågurspårning. Liksom board partners som har varit försiktiga med nya moderkort med X870(E).

Inte blev det bättre för att man överdrev prestandasiffror i förväg. Nu har man gett setboll till Arrow Lake, kanske blir ett Z890-system för att stilla byggklådan

Verkar ju som att APU-versionen av Zen 5 är en hel del mer lyckad än den rena CPU:n, monolitisk och inga skumma latenser, synd bara att den är kastrerad för gaming med för liten mängd cache för topp prestanda.

Man blir ju irriterad när min egen 7950X presterar bättre i tex Cinebench 2024 multi än vad 9950X gör.

Den videon var ju inte mycket att "hänga i granen" ifall man inte hade noll koll på dramat kring Zen5-lanseringen sen innan. Det enda riktigt intressanta de tog upp var latency-matrisen från Anandtechs artikel men är man intresserad av den är det bättre att gå direkt till källan. Speciellt med tanke på att det lyckades med konststycket att misstolka vad den representerar och drog felaktiga slutsatser. Anandtech skriver följande själva i sin artikel:

"Our current working theory is that this is a side-effect of AMD's core parking changes for Ryzen 9000. That cores are being aggressively put to sleep, and that as a result, it's taking an extra 100ns to wake them up. If that is correct, then our core-to-core latency test is just about the worst case scenario for that strategy, as it's sending data between cores in short bursts, rather than running a sustained workload that keeps the cores alive over the long-haul."
https://www.anandtech.com/show/21524/the-amd-ryzen-9-9950x-an...

Anandtechs test som ligger till grunden för siffrorna motsvarar inte en kontinuerligt aktiv last som hoppar eller kommunicerar mellan de olika CCD:erna och motsvarar därför bara ett specialfall som antagligen inte är speciellt relevant för de benchmark-resultat som alla pratar om.

Sen visar varken Sweclockers tester, eller andra som jag har läst, att 7950X skulle vara snabbare 9950X i Cinebench 2024 flertrådat vid jämförbara tester. Så jag ser inte relevansen i vad du får för värde med din 7950X med överklockade minnen samt eventuellt optimerade processorparametrar...

AMD rekommenderar "överklockade" minnen i sin review guide så alla har nog kört med det, för övrigt verkar inte Zen 5 klocka minnen ett dugg bättre än Zen 4 vilket är en viktig parameter när man köper en plattform gjord för just överklockning.

Men visst, det ser ut som att minnes subsystemet är en stor flaskhals men det hjälper inte vid CCD-hoppande.

Det är nog mer än att "väcka kärnor" som bråkar med tanke på att 7800X3D faktiskt är en hel del bättre i spel än alla nu släppta Zen 5. Reviews visar att 9700X oftast är snabbast i spel av dom nya Zen 5, den har en CCD, 9600X vinner faktiskt ibland men det är inte så konstigt eftersom den har mer cache/kärna.

Bagatellisera inte den dåliga prestandan, ja i statiska laster är Zen 5 5-15% snabbare men så fort det börjar hända saker kroknar den. Det är ett problem eftersom vi inte sitter och kör 7-zip hela dagarna.

Men självklart skulle jag bli glad om du kan visa på hur bra Zen 5 är vs det som redan finns, jag har dock litet hopp.

9950X är fortfarande väldigt bra i Linux:

https://www.phoronix.com/review/linux-os-amd-ryzen9-9950x/7

Att använda Clear Linux ger ytterligare 16% bättre prestanda mot att använda Ubuntu 24.04

Zen 5 är riktigt bra för den som vill ha en Linux-rigg, Windows och spel är tyvärr än så länge ospännande

Vågar man ens chansa på att köpa Zen 5 och hoppas på nya drivrutiner? Skall köpa ny i helgen men vet fortfarande inte vad jag skall välja..

Skall du köpa precis nu är det Ryzen 7000-serien du ska gå på, då den i nuläget är betydligt mer prisvärd. Båda serierna körs ju på samma platform (AM5) så du gör heller inget dåligt val i uppgraderingssyfte genom att välja Ryzen 7000 istället.

Så Intels OS gjorde amds cpu bättre? 👌