AMD Ryzen 7 1700

Men du, tiderna förändras, AMD is teh shit nu

Då är det fel på förväntningarna. Det fanns inte på kartan att AMD skulle kunna bräcka Intel över hela brädet. Att de ändå kom så nära som de gjorde är oerhört imponerande. De erbjuder ju faktiskt något som inte Intel gör.

Jag funderar i samma bana, fast i annat spår, nämligen att alla plötsligt blivit 1337 gamers på Sweclockers. Så minns jag inte att det varit förut, vill minnas det varit blandad kompott.

Bara för att ett test körs i 720p för att VISA SKILLNADEN mellan CPU:er betyder det inte att man själv behöver köra i den upplösningen. Lika lite som att man sitter och kör Blender eller lirar Cinebench hela dagarna. - Dock så flaskar Ryzen ur redan i 1080p som är en relevant upplösning. En upplösning som många 144Hz-skärmar har.. men det kanske inte spelar så stor roll? 60Hz är tillräckligt eller?

En relevant skillnad alltså, om man nu står i det valet och kvalet. Men vad är det då alla hemanvändare gör med sina kraftpaket, om det inte är att spela. Kan du inte ge exempel på vilket trade-off du gör. Vad dina multitrådade sysslor är som inte en i7 klarar av? Försök att inte ljuga ihop för mkt bara.

Hur kan man bli besviken när Ryzen överträffade förväntningarna? Det enda som är lite av en besvikelse är att dom inte klockar lite bättre även om det inte är så konstigt när det är en helt ny arkitektur på en ny tillverkningsprocess då det tar tid för den att mogna.

AMD har inte hävdat mer än dom prestandatester som uppvisades där den gör sig mycket bra mot 6900K. Det är en ny arkitektur som sagt, så många, läs MÅNGA program är inte optimerade ännu, alternativt identifierar Ryzen på ett felaktigt sätt som gör att den inte presterar så bra som den kan. Du kanske också borde läsa fler tester då en många recensenter använder några utav spelen som inte låter Ryzen använda sin kapacitet ännu. Visar exempel på det nedan.. Med det sagt, gör och se skillnad på hårdvaran och mjukvaran. Microsoft är på gång med mindre optimeringar och spelutvecklarna jobbar hårt med Ryzen nu.

Där ser du betydligt fler spel testade, och ändå är inte allt optimalt där. 7700K kapacitet används till fullo nu, medans Ryzen har en hel del kapacitet till framtida spel och samtidigt mosar sitt motstånd i multitasking och produktiva applikationer/rendering/encoding osv.

Samma plattform tillåter folk också att slippa byta moderkort när uppföljaren Ryzen 2 kommer.

Ibland hoppar du över saker som skrivs eller läser dom fel. Jag skrev att CPUID APIC flaggar om CCX strukturen. Det ser man i en patch här:
https://lkml.org/lkml/2015/11/3/634

+ core_complex_id = (apicid & ((1 << c->x86_coreid_bits) - 1)) >> 3;
+ per_cpu(cpu_llc_id, cpu) = (socket_id << 3) | core_complex_id;

Numera ser patchen ut såhär för att identifiera korrekt:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linu...

if (cpuid_edx(0x80000006)) {
            if (c->x86 == 0x17) {
                /*
                 * LLC is at the core complex level.
                 * Core complex id is ApicId[3].
                 */
                per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
            } else {
                /* LLC is at the node level. */
                per_cpu(cpu_llc_id, cpu) = node_id;
            }
        }

Oavsett vad så vet man att designen är den bästa kompromiss som AMD kunde gjort för att få arkitekturen att passa in i alla segment, men det ser jag inte som en svaghet. Jag skrev också ett inlägg i diskussionstråden för Ryzen att Sysinternals Coreinfo rapporterade felaktiga data. Det tillsammans med upptäckten att trådar som kastar runt på Zen fick mig inklusive många att tro att schemaläggaren i Windows var boven i dramat, speciellt när Win7 samtidigt visade betydligt högre draw calls och fps, en siffra som många gånger låg väldigt nära samma siffra som att kasta runt trådar mellan 2 CCX.

Problemen visade sig vara fler, alltifrån power plans, till HPET, bios, recensenter som körde för lågt klockade minnen och spel som inte identifierar Ryzen korrekt. PC-per snackade om att utöka funktionaliteten hos schemaläggaren i sin del.2, och jag är inte den enda som tänker i dom banorna även om den i sig inte gör något fel idag. Det är fullt möjligt, men bäst hade vart om applikationen styr assignationen.

Win 8 patchen ändrade dock detta för att köra 2 trådar i en modul. Win10 gör samma sak.

Nej, återigen är det inget problem så länge dom gör det inom samma CCX vilket var hela poängen, och leksaksexperimentet fungerar bevisligen.

Visst beror det på tillämpning/segment, och det är därför jag tror att förbättringar finns för respektive sådant. Vi snackar om 1 CPU för desktop/WS bruk och inte HPC kluster.

Det är ju ett problem när 20% prestanda går väck och man vet hur man kan lösa det. Ny arkitektur=optimeringar kommer till mjukvaran. Det blir intressant att se kommande tid.

Ryzen är liten och därmed billig att tillverka för AMD. Det hade blivit betydligt dyrare att göra tape-out på 2 olika designer av samma arkitektur och kasta alla defekta die's istället för att göra som nu, där man tar vara på dom som inte klarar binningen för octa cores och inaktiverar kärnor och säljer dom som fullt fungerande hex och quadcores

+ core_complex_id = (apicid & ((1 << c->x86_coreid_bits) - 1)) >> 3;
+ per_cpu(cpu_llc_id, cpu) = (socket_id << 3) | core_complex_id;

if (cpuid_edx(0x80000006)) {
            if (c->x86 == 0x17) {
                /*
                 * LLC is at the core complex level.
                 * Core complex id is ApicId[3].
                 */
                per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
            } else {
                /* LLC is at the node level. */
                per_cpu(cpu_llc_id, cpu) = node_id;
            }
        }

Förstår du vad syftet koden ovan har?

Den kommer inte på något sätt att påverka hur schemaläggaren fungerar, vad den används till är information till applikationer kring topologin för cache. Motsvarande vad Windows ger via GetLogicalProcessorInformation.

I Linux fall hittar man detta under /sys/devices/system/cpu/cpuN/ specifikt cache information ligger sedan i underkatalogen cache/indexL där det finns ett "indexL" för varje cache nivå L. Patchen ovan ser till att noden cache/index3/shared_cpu_map visar korrekt information på Zen, d.v.s. att L3 delas av fyra kärnor i ett CCX.

Enda kodförändring som är Zen-specifikt och påverkar hur schemaläggaren fungerar är detta

               if (c->x86 >= 0x17) {
                        c->cpu_core_id = ebx & 0xff;

                        if (smp_num_siblings > 1)
                                c->x86_max_cores /= smp_num_siblings;
                }

och kikar man i kiden för Intel HyperThreading ser man att raden där c->x86_max_cores delas med antal "siblings" finns även där. D.v.s. ACPI rapporterar i båda fallen alla CPU-trådar som "riktiga" kärnor, om SMT/HT är påslaget måste man alltså kompensera för det.

"Spel som inte identifierar Ryzen korrekt", vad betyder ens det? Spel bryr sig i >99,99 % i fallen inte om vilken CPU-modell man använder, den stora fördelen med moderna x86 CPUer är att de är väldigt okänsliga för lågnivå optimeringar då det handlar om out-of-order designer med väldigt stort djup.

Hur ska man hålla t.ex. ett spel inom en CCX, spel använder fler än fyra trådar? Vidare så schemalägger både Windows och Linux OS-trådar helt utan att ta hänsyn till vilken process de tillhör, så är omöjligt (idag) att ha en policy som håller en applikation inom en CCX och om totala antalet aktiva OS-trådar går över fyra är det kört.

D.v.s. det är inte praktiskt vettigt att försöka väga in det faktum att varje CCX har separat L3$ i schemaläggningsbeslut som tas av OSet. Applikationer har däremot möjlighet att utnyttja detta, blir dock mäkta förvånad om någon kommer lägga de resurser som behövs för att göra en sådan optimering.

Huvudanledningen att Ryzen hamnar efter i spel är ändå inte CCX, det är att Zen är väsentligt svagare än Intels aktuella modeller när det kommer till hantering av skalära heltal. Det är något som ingen optimering i världen kommer kunna fixa.