AMD Ryzen 7 2700X och 5 2600X "Pinnacle Ridge" dyker upp i prestandatester

Dessa resultat kommer från Geekbench 4 databasen.

Ryzen 5 2600X : 4781 / 22235
Ryzen 7 2700X : 4736 / 25195

Jämför jag minnesresultaten med min Ryzen 5 1600 verkar 2600X köra med DDR4-2933 CL14 alt. CL16 medan 2700X verkar köra med DDR4-2666 CL14.

Mitt system med DDR4-2666 CL16: 4654 / 22236 (kör Linux vilket från 6 kärnor och uppåt ger synbart högre resultat jämfört med Windows, single-core är dock rätt jämförbart mellan OS)
Med DDR4-2933 CL16 : 4794 / 22600

Kör oklockat (då det är en server som kör 24/7).

Tycker personligen att Geekbench viktar effekten för RAM lite väl hårt, kan överhuvudtaget inte mäta någon skillnad mellan 2666 vs 2933 vs 3066 i saker som kompilering, shellscript som söker i stora datamängder, webserver etc.

I Geekbench ger framförallt bandbredd rätt stort utslag på resultatet, latens (som i praktiken är viktigare) ger ett tillskott men ett rätt litet sådant. Viktigt därför att man jämför system med ungefär samma RAM hastighet.

Här är ett ocklockat i7-8700K system med DDR4-2666 eller möjligen DDR4-2933 (inte helt lätt att säga, man får kika på "Memory Bandwidth" resultatet).
i7-8700K : 5535 / 24602

För alla som väljer 8C/16T eller mer, vare sig det handlar om AMD eller Intel: fundera på varför ni väljer en sådan CPU. Har ni verkligen nytta av den kanske Linux är ett bättre val.

Ocklockad Ryzen 7 1800X körande Linux får högre multicore resultat jämfört med Ryzen 7 2700X på Windows: 4796 / 30357

7,7 % stämmer kanske när GPUn är flaskhals. Både Ryzen och Coffee Lake testades primärt med GTX1080, där blir GPU en rätt rejäl flaskhals redan vid 1920x1080 "ultra".

ArsTechnica testade i7-8700K med GTX1080Ti, den är i genomsnitt >40% snabbare jämfört med Ryzen 1800X i spel där i upplösning 1920x1080 "ultra". I princip ingen skillnad mellan DX11 och DX12.

Skulle inte vara så säker. Fram till ~2010 var det ett väldigt fokus på att få in stöd för "multitrådning" i språk som C++, Java, C# etc. (Kuriosa: C och C++ hade faktiskt inget portabelt stöd för att köra mer än en tråd innan 2011...).

Trenden sedan dess och vad det ser ut som även i närtid väldigt mycket på "asynkron körning" och "co-rutiner". JavaScript är numera det vanligaste programspråket enligt många mätning. JavaScript har överhuvudtaget inget koncept av "multitrådade" applikationer. Ett exempel är NodeJS, ett väldigt populärt och ruggigt effektivt när det handlar om I/O.

Den senare är ett lysande exempel på att "concurrent programming" (som man nu främst jobbar med) inte alls är samma sak som "parallel programming" (som var vad man mycket jobbade innan 2010-2011).

Den förra är ofta toppvalet för applikationer som är begränsade av I/O. Slänga fler kärnor på problemet är sällan rätt lösning där, kan faktiskt sänka prestanda. Här vill man i stället fylla en kärna i taget med jobb, det ger bäst I/O-respons och därmed bäst total I/O-kapacitet.

Parallel programming är rätt i fall där flaskhalsen är rå beräkningskraft, typexemplen är HPC, rendering och liknande.

En trend som dök upp förra året och som accelererat i år är något som kallas "autovektorisering". Är själv helt övertygad att detta kommer vara viktigare för "vanliga" PC-program än vad massor med kärnor är då få "vanliga" program jobbar med problem som effektivt låter sig köras på många kärnor.

Autovektorisering är när man tar normal skalär och sekventiellt kod, d.v.s. standard C++, Java, C# kod, och hittar små delar som kan köras parallellt. Att lägga ut det på flera kärnor går inte, ljuset hastighet sätter käppar i hjulet så resultatet blir lägre prestanda. Men det man nu lyckas göra i allt fler lägen är använda SIMD (SSE/AVX på x86, NEON på ARM) för att få >100% boost i vissa tighta loopar.

Riktigt spännande teknik!

Tvåsiffrig procentuell prestandaökning jämfört med 1xxx-generationen.
Imponerande jämfört med Intel som brukar ligga runt 5%

Jag sitter på en 1600X som kostade mig runt 1900:-.
Det är den klart med prisvärda CPUn man kan få för pengar och den har mycket bra prestanda.
Den får hänga med ett tag till.

Det skall bli spännade att se vad för skillnader Ryzen 2 kommer att komma med.
Jag hoppas att prestandahoppet blir samma som för Intels Nehalem till Sandy Bridge blev, deras första iteration.

Du menar processorer som är klockade till nästan 1 GHz mer?

Skickades från m.sweclockers.com

AMD har själv varit klara med att det inte kommer att ske några mirakel med 2xxx serien. Så om du är besviken så är nog orsaken dina förväntningar.

Bättre än vad? Bättre än Intel? Bättre än Ryzen 1xxx? Bättre än Bulldozer? Bättre än det du ser i testet ovan?

Rätt lustigt att folk säger högre IPC på Intel när de jämför 1Ghz högre frekvens då... om nu inte frekvenser har något med det att göra. Men du kan räkna bort den om du vill. Vi kan klocka ner 8700k och 2700X och se vad den gör i samma frekvens som 1700X då.

Min poäng kvarstår att IPCn ska enligt AMD ha bättrats, du kan göra väldigt mycket med så färsk arkitektur som Ryzen är. (Finns en hel del ställen att läsa på, om du inte hängt med)

Ett annat ex på detta har du mellan Nehalem och Sandy Bridge och Ivy Bridge. Nehalem och Sandy är både 32nm, och där gjordes mycket framsteg. Men även mellan Sandy och Ivy, som var helt ny nod, gjordes också framsteg i IPCn.
https://us.hardware.info/reviews/6215/2/intel-five-generation...

Faktum är att Intel lyckats öka detta nästan varje släpp, lite för lite. Och nu sitter du och säger att AMD inte kan göra samma sak? Mot AMDs egna ord?

Jag önskar jag kunde ge dig fakta, men det finns inget som är bevisat än, då för lite data om Ryzen+ finns ute. Men det som finns visar att även om du tar med frekvensen, går matten inte alltid ihop. Problemet är just... vi vet inte hur den boostar heller. Enda vi har är några siffror hit och dit som är väldigt svåra att jämföra. Men de få man ser, man kan spekulera till att se en IPC bättring. Bara att titta på förra artikeln om detta i Sweclockers och räkna på den + den som är länkad i forum tråden där.

Så jag kommer ta AMDs egna ord, och Intels bevis på att det går att göra, framför dina, tills jag fått vettiga benchmarks på att "det inte går".

AMD har trots allt gjort både Nod, generation och arkitektur byte, i ett svep och lyckats rätt bra med det. Tror ärligt de borde kunna göra 2 av 3 igen då...

Men du får tro vad du vill.

Det spelar ingen roll för slutanvändaren om prestandan kommer ur hög ipc eller hög frekvens, i slutänden är det kombinationen av de två som räknas. Att AMD inte kan få upp sin klockfrekvens mer, är något som håller tillbaka singeltrådprestandan.

https://www.sweclockers.com/test/23426-amd-ryzen-7-1800x-och-...

Skillnaden är inte direkt stor i samma klockfrekvens mellan 1700X och 7700K som i sin tur presterar ungefär samma som 8700K i single men betydligt sämre i multitrådat.

Oberoende så verkar 2700X prestera bättre än 1700X vid samma klockfrekvens. En stor orsak till 8700Ks prestanda är dess höga klockfrekvens.. kommer AMD närmare denna så krymper skillnaden snabbt. 400 MHz i är ändå ganska mycket.

Läsförståelse? Var har jag påstått något annat?

Gå inte omkring besviken, livet är kort...

Du får helt enkelt handla från någon annan tillverkare som inte gör dig besviken!

Ojdå , det där vågar man ju inte köpa, Dom där AMD bugg snubbarna sa ju att AMD kommer att konka!!!

[/satir]

Grejen med Zen vs Coffee Lake och IPC är att man får väldigt olika svar beroende på vad som är primär flaskhals i programmet.

På det stora hela finns tre huvudklasser där IPC skiljer sig markant

1. heltalsberäkningar

2. traditionell (d.v.s. pre-2000-style) flyttalsberäkningar, det man får från standard C math.h

3. vektoriserade flyttal, det ser i program program som använder de-facto standarden BLAS

Väldigt många verka kika på Cinebench (vilket man kan förstå då i princip ALLA teknikwebbplatser använder denna benchmark och många läckor brukar vara just detta). Cinebench tillhör 2. och Zen är väldigt stark på denna punkt, helt i nivå med Coffee Lake när det kommer till IPC.

Fast någon får gärna upplysa mig om program som är aktuella 2018 där x87 style flyttalskapacitet är primär flaskhals, utöver Cinebench och kanske någon annan benchmark som gör samma sak.

För punkt 3. är det rejäl fördelen för Coffee Lake, >100% högre IPC i fall som drar nytta av AVX. Syns t.ex. i Matlab. Samma sak syns i t.ex. Octave, programspråket R och många andra moderna program för vetenskapliga beräkningar (då alla dessa använder t.ex. MKL eller något annat som implementerar BLAS)

Visa innehåll

i7-855U totalt demolerar R5-2500U i Matlab, båda är 4C/8T modeller

Visa innehåll

'The Stilt' såg samma sak i t.ex. Linpack med 4C/8T, alla modeller kör 3,5 GHz här

För de flesta PC-användare är både 2. och 3. irrelevanta, 1. är den primära flaskhalsen för de flesta PC-program som spel, webbläsaren, MS Office, kompilering, etc.

Här finns viss spridning mellan program, många program är ju egentligen mer I/O-bundna än beräknings-bundna. För de som är beräkningsbundna, t.ex. spel och kompilering (och webbläsaren då allt fler applikationer är baserade på renderingsmotorn i Chromium via Electron, ett exempel är Visual Studio Code), brukar det handla om 20-30 % fördel i IPC för Coffee Lake.

Vi kan ju ta SweClockers "test vid samma frekvens" som referens, då specifikt speltesterna i 1280x720 (ja det är CPUer vi vill jämföra, inte GPU) och ställa i7-8700K mot R6-1600 (båda 6C/12T, blir samma i princip resultat med i7-7700K vs R5-1500X).

Här är det ~25 % fördel för Coffee Lake / Kaby Lake över Zen vid 2,8 GHz.

TL;DR skulle säga att det är helt korrekt att hävda att Intel har klart högre IPC.

Om du är besviken över minimum 10% ökning av IPC gällande en refresh, så skulle jag vilja veta hur du känner när Intel släpper helt nya generationer som knappt mäktar med 5% i ökning.