Skrivet av Ratatosk:
Nej det inlägg som du kritiserade var detta.
#16751890
Varför är det enbart 720p som är viktigt för dig, jag frågar igen, var det fel av Sweclockers att även testa 1080p?
Tycker för övrigt att du har ett väldigt aggresivt sätt att diskutera.
Hur allmängiltigt giltigt är egentligen 1920x1080 resultatet i ett CPU-test? Det är i många fall relativt GPU-bundet och därmed endast relevant för de som sitter med samma GPU som används i testet, i SweClockers fall ett GTX 1080.
Vidare så fick ju faktiskt hardware.fr samma relativa resultat mellan R7-1800X och i7-6900K, det i 1920x1080 fast där använde man Titan X Pascal.
För egen del skulle CPU-testerna faktiskt vara rätt värdelösa utan speltester där man tagit bort GPUn ur ekvationen. Inte för att jag spelar i 1280x720 eller kör i 200 FPS, är faktiskt rätt ointresserad av spelprestanda (har för närvarande ett GTX970 och kör i 1920x1080, skulle få samma FPS med i3-6100 som jag får med en tre gånger dyrare CPU).
Vad jag är ute efter är hur CPUn presterar i fall som främst beror av vanliga heltalsberäkningar, det då detta fall står för en förkrossande majoritet av vad som påverkar prestanda i "vanliga" program och prestanda hos OSet självt (som är kritiskt i bl.a. många I/O-intensiva laster). Tyvärr testar de flesta CPU-benchmarks saker som är helt irrelevant i praktiken utom för vissa väldigt smala nischer.
Allt fler verkar ta med kompilering-test. Det är jättebra för just kompilering har visat sig vara en väldigt bra indikation på generell heltalskapacitet i fall som skalar perfekt med CPU-kärnor.
Tester som Google octane och än mer webXPRT (som till skillnad från JS-benchmarks testar generell prestanda i webbläsaren) är lysande indikationer på heltalskapacitet i fall som är enkeltrådade.
Ett väldigt vanligt fall saknas nu, fallet som har viss skalning med CPU-kärnor men där underliggande problem inte är "embarrassing parallel". För mig och gissningsvis väldigt många andra som multitaskar, kör virtuella OS och liknande är detta den mest intressanta värdet. Av allt som brukas köras i CPU-tester är spel det enda som kan ge en siffra på detta, men det kräver att GPUn helt plockas bort ur ekvationen. Så för mig får de gärna köra spel i 320x200!
Just heltalsprestanda är tyvärr Ryzens svaga punkt. I kompilatorfallet (som alltså skalar perfekt med CPU-trådar) är R7-1700 och i7-7700K helt jämna. Är det jag menar visar: är teoretiskt omöjligt för R7-1700 att någonsin bli snabbare än i7-7700K i spel, best-case är att spel skalar helt perfekt med kärnor (något som är omöjligt i dagen spelmotorer, men är ju teoretiskt möjligt att de helt designas om i framtiden, realistiskt kommer det inte hända de närmsta 10-20 åren).
Än värre är det för enkeltrådfallet. Här presterar faktiskt Ryzen någon under Sandy Bridge vid samma frekvens, det positiva är ändå att Sandy Bridge står sig riktigt bra än idag och de högst klockade Ryzen-modellerna tar igen lite på att de är högre klockade än toppmodellerna av Sandy Bridge. Notera att detta gäller för heltal, tittar man på skalära flyttal (vilket väldigt många benchmark testar) presterar Ryzen i nivå med Broadwell vid samma frekvens (för mig är detta totalt irrelevant då jag inte använder något program där prestanda på något relevant sätt beror av prestanda vid beräkningar med skalära flyttal).
Angående just optimering av AoS. Verka just detta fall till viss del beror på något jag försökt pekat på ett par gånger: att "optimera" för hand är idag nästan dömt att misslyckas. Mer än nio av tio programmerare kommer göra ett sämre jobb än vad en kompilator plus en generellt bra design kommer nå.
Här verkar Oxide försökt "optimera" för bättre cache-utnyttjande genom att använda en instruktion, movntdq, som skriver data direkt till RAM utan att påverka CPU-cache. Detta verkar av någon anledning ha varit en extremt dåligt idé på Ryzen, gissar att man även tagit bort detta för Core. Skillnaden för Core är minimal, men alla som testat verkar i genomsnitt se en marginell förbättring även för Core.
movntdq kan ge en boost om den används rätt, men man måste förstå väldigt mycket om x86, dess minneskonsistensmodell och om cache-design i allmänhet för att få det rätt (i beyond3d tråden du länkade pratades det om att alla "nt" (non-temporal) instruktioner är "black magic"). I normalfallet: använd memcpy(), i alla fall på Linux använder den movntdq i vissa speciella lägen. Det är en användning som testats på massor med olika CPU-modeller och är som sagt rätt få fall man sett det vara en fördel.
Och detta visar en av de trevligaste egenskaperna med Core: det är en extremt förlåtande mikroarkitektur. Även "korkade" saker tenderar att prestera helt OK, men gör man sådant brukar det slå tillbaka rätt rejält om man måste köra på lite andra CPU-modeller.