Skrivet av waverider:
Måste säga att jag inte förstår hur folk kan vara så imponerade av Ryzens prestanda? Själv är jag besviken på Ryzen, man har läst om all hype och förväntat sig likvärdig prestanda med Intels motsvarigheter. AMD hade ju t.ex. hävdat att 1800X skulle hålla jämna steg med 6900K, men enligt Sweclockers test så vinner 6900K i många fler benchmarks än vad 1800X gör, framförallt om man räknar in spel. Nu är visserligen en 6900K ung. dubbelt så dyr som en 1800X, men likvärdiga i prestanda är de ju inte.
Och även 7700K vinner fler tester än vad 1700 gör, till samma pris, och ändå så verkar det som om så många är så otroligt imponerade av 1700. Jag förstår inte varför? Givetvis är det bra med konkurrens, men som sagt, varför är så många imponerade av Ryzen?
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.
Skrivet av Yoshman:
Lätta först, Linux. Kolla i källkoden så ser du att det finns överhuvudtaget ingenting där som på något sätt tar hänsyn till att det finns två CCX i Ryzen. Finns inte heller någon kod i Linux som på något sätt bryr sig om cache-topologin när det kommer till hur trådar schemaläggs. Det man tar hänsyn till är NUMA-zoner, d.v.s. om vissa kärnor har olika kostnad att nå olika delar av RAM.
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.
Citat:
Vad Linux tar hänsyn till är SMT. Specifikt hanteras Ryzen som Intels Core, "gamla" Atom och i princip alla CPUer med SMT. Bulldozer-arkitekturen hanteras däremot separat, där väljer Linux att lasta båda trådarna i en modul innan nästa modul tas i anspråk, med SMT lastar man först en tråd per kärna så länge det finns kärnor som är "idle".
Win 8 patchen ändrade dock detta för att köra 2 trådar i en modul. Win10 gör samma sak.
Citat:
Att OS-trådar hoppar mellan CPU-trådar är dels inte vad som orsakar det du är ute efter, det är heller inte ett problem i praktiken då Windows skyfflar runt saker med en frekvens som inte alls är så hög att den har en relevant påverkan på prestanda.
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.
Citat:
Att OS-trådar hoppar runt på Windows och inte gör det på Linux beror på att de är optimerade för olika fall, båda designvalen har fördelar och nackdelar. Windows prioriterar svarstid över "throughput", framförallt för interaktiva applikationer (d.v.s. den applikation som har input-fokus). Linux specialbehandlar ingen process och där prioriteras "throughput" mer än svarstid.
Ett praktiskt exempel på ovan är: om tråd A postar en semaphore så tråd B nu bli körklar, ska tråd A eller tråd B fortsätta köra på aktuell CPU-tråd? Det är något som studerats väldigt ingående och finns inget svar som alltid är bäst, beror på en rad faktorer bl.a. om man vill optimera för CPU-throughput, I/O-throughput, svarstid etc.
En applikation som t.ex. jobbar mot en in-memory databas som är relativt stor lär köra snabbare om två samtida trådar ligger på separata CCX. Men det stora problemet är detta: anta att man håller saker inom CCX, hur ska man då schemalägga moderna spel som i princip alltid utnyttjar fler än fyra OS-trådar?
Så visst går det att vinna 20 % i ett leksaksexempel som ovan, men det skulle ändå inte lösa "riktiga" applikationer. Än mindre lösa fall när flera multitrådade applikationer kör samtidigt.
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.
Citat:
Och om det nu är ett problem, för AMDs del skulle det vara överlägset enklast att peka på att problemet ligger i Windows. Det skulle betyda att man kan fixa ett ställa och problemet är över. Nu erkänner man i stället att designen man valt är lurig att hantera generellt, lösningen blir att till viss del specialhantera designen i varje applikation. Det är ett budskap jag tvivlar någon vill ge innan det är absolut klarlagt att det är enda vägen framåt.
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.
Skrivet av Paddanx:
Det verkade inte vettig att göra så dock, men de måste ha satans med defekta chip då.
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