SweClockers intervjuar Robert Hallock – AMD:s marknadschef för processorer

Permalänk
Cylon

SweClockers intervjuar Robert Hallock – AMD:s marknadschef för processorer

Inför SweClockers Live intervjuade vi högt uppsatta personer på Intel och AMD. Nu kan ni se AMD-intervjun i sin helhet.

Läs hela artikeln här

Permalänk
Medlem

Yes, fantastiskt! Sett fram emot att få se denna intervju! Tack

Permalänk
Medlem

Å där kom AMDs svar angående 300-serien

Permalänk
Medlem

Robert Hallock är en sån trevlig person som förklara tydligt i lagom takt.

Permalänk
Medlem

Denna ska ses igen! Snyggt skött av @UndaC

Permalänk
Medlem

Jag känner Robert privat (eller kände, rättare sagt). Otroligt trevlig snubbe som älskar spel och lan. För snart 17 år sedan arrangerade vi Lan tilsammans borta i Detroit där han bodde då. Då jobbade han på Geek Squad och var en Intel älskare av rang. Att ha AMD i hans pc fanns inte på kartan.

Permalänk
Medlem

Roligt content!

Permalänk
Medlem

Mycket bra intervju! Tack!

Permalänk
Medlem

Han fick allt in ett slag i magen mot Principled Technologies där utan att göra det på ett spydigt sätt. Snyggt skött. Bra frågor och bra svar

Permalänk
Datavetare

Även om dessa personer är rätt bakbundna i vad de kan säga är det ändå helt klart värt att göra den här typen av intervjuer. Bra jobbat SweC!

Reagerade ändå på några saker då en del av hans slutsatserna kring varför Zen3 presterar mycket bättre i spel än Zen2 går inte ihop med existerande data.

Om reduktionen av CCX och därmed reduktion av core-to-core latens skulle vara en av huvudförklaringarna till den bättre spelprestandan, varför ser då Linux ungefär samma prestandaboost där schemaläggaren explicit sprider lasten över alla tillgängliga CCX? Orsaken att Linux väljer denna strategi är att det maximerar utnyttjandet av tillgänglig cache och det ger högsta genomsnittlig mängd cache per CPU-tråd i lägen där inte alla CPU-trådar är aktiva.

På det stora hela har Zen-designen fungerat bättre under Linux än under Windows. Har jämfört ett par fall med totalt 6 trådar, dels med att lägga alla på en CCX (d.v.s. kör 3C/6T) och dels lägga det 1C/2T spridd över 3 CCX. Skillnaden är inte speciellt stor, men det senare fallet är i genomsnitt snabbare i alla fall jag testat (finns fall som föredrar 3C/6T på en CCX, men de är sällsynta). Rimligtvis då det första fallet har 16 MB L3$ för alla CPU-trådar och det senare har 16 MB för varje 1C/2T grupp (testat på en 3900X).

Vad jag kan se håller inte Windows lasten till specifika CCX, om den gör det är det i så fall inte alls lika tydligt som på Linux där man alltid kommer se att en applikation som använder exakt fyra trådar kommer alltid köra dessa fyra trådar på olika CCX om man har en 3900X/3950X.

Finns en vinst från färre CCX i spel, den nämner också Robert: mängden tillgänglig L3$ från en viss CPU dubblades från 16 MB till 32 MB tack vare CCX-förändringen. Självklart är latensen mellan CCX något som kan påverka prestanda negativt, men det verkar som i majoriteten av fallen (går absolut att konstruera fall som visar motsatsen) är den nackdelen mindre än vinsten i att i praktiken få tillgång till mer L3$ om man sprider lasten över tillgängliga CCX.

Sen, använder verkligen spel >6 kärnor ens idag i någon relevant utsträckning? Om så är fallet borde 1800X ha närmat sig 7700K i spel. Ställer man SweClockers första tester av 1800X och 7700K när dessa modeller vara nya mot hur det ser ut nu i Ryzen 5000 testerna är det i princip ingen relevant skillnad. Faktum är att 7700K har en lite större fördel i lägsta FPS över 1800X idag (men skillnad är liten nog för att kunna avfärdas som osäkerhet i testmetod). Spel använder absolut fler CPU-trådar än 4 st, men 6C/12T är fortfarande mer än nog.

Ökningen i spelprestanda är rätt identisk med ökningen i prestanda per kärna, så fort man kommer upp till 6C/12T är spelen än idag primärt begränsade av en mer eller mindre dominant tråd (eller, spelen är primärt begränsade av GPU, men om man explicit tar bort GPU ur ekvationen).

Vad både AMD och Intel tyvärr lärt sig är att se till att när man klättar i produktstegen så ökar inte bara antalet kärnor, man har också sett till att maxfrekvensen per kärna också ökar för om man inte gjorde det skulle modeller längre ned i praktiken få bättre resultat i t.ex. spel.

Permalänk
Medlem
Skrivet av Yoshman:

Vad både AMD och Intel tyvärr lärt sig är att se till att när man klättar i produktstegen så ökar inte bara antalet kärnor, man har också sett till att maxfrekvensen per kärna också ökar för om man inte gjorde det skulle modeller längre ned i praktiken få bättre resultat i t.ex. spel.

Jag tror det handlar om en medveten strategi från AMD att göra fler kärnor till norm, och Intel har snällt fått följa efter. Sannorlikt så skulle det vara lättare för AMD att binna processorerna så att man har en "guld-chiplet" som skulle kunna klockas högst och prestera bättre i spel än *950X, då dagens spel sällan eller aldrig utnyttjar mer än 8 kärnor, men om de gjorde så så skulle de tappa mycket av intäkterna de idag får in från *900X och *950X, då, som Robert själv konstaterar "de flesta spelar", och det skulle göra processorerna med fler kärnor onödiga för "den stora massan", men som det är nu så får man snällt finna sig i att köpa modellerna med högt pris och höga marginaler om man vill ha "det bästa" från både Intel och AMD, så det är väl logiskt.

Angående detta med att sorida lasten över flera CCX så är min erfarenhet att gör man så i Windows via process lasso eller att manuellt sätta affinity så får man lägre boost då det äter strömbudget och ökar värmepåslaget när man har kärnor och chiplets igång "i onödan". Men menar du då att tillgången på cache kompenserar för den lägre boosten, eller boostar inte Ryzen lägre i Linux med fler vakna chiplets?

Permalänk
Datavetare
Skrivet av Ozzed:

Jag tror det handlar om en medveten strategi från AMD att göra fler kärnor till norm, och Intel har snällt fått följa efter. Sannorlikt så skulle det vara lättare för AMD att binna processorerna så att man har en "guld-chiplet" som skulle kunna klockas högst och prestera bättre i spel än *950X, då dagens spel sällan eller aldrig utnyttjar mer än 8 kärnor, men om de gjorde så så skulle de tappa mycket av intäkterna de idag får in från *900X och *950X, då, som Robert själv konstaterar "de flesta spelar", och det skulle göra processorerna med fler kärnor onödiga för "den stora massan", men som det är nu så får man snällt finna sig i att köpa modellerna med högt pris och höga marginaler om man vill ha "det bästa" från både Intel och AMD, så det är väl logiskt.

Angående detta med att sorida lasten över flera CCX så är min erfarenhet att gör man så i Windows via process lasso eller att manuellt sätta affinity så får man lägre boost då det äter strömbudget och ökar värmepåslaget när man har kärnor och chiplets igång "i onödan". Men menar du då att tillgången på cache kompenserar för den lägre boosten, eller boostar inte Ryzen lägre i Linux med fler vakna chiplets?

Självklart handlar det om att de artificiellt begränsar maximal turbo på de lägre modellerna, de har båda lärt sig från HEDT att fler kärnor mer lägre boost leder till en extremt nischad produkt då färre men snabbare kärnor är bättre för en väldigt klar majoritet av användarna.

Boosten för allt över basfrekvens styrs i praktiken helt av CPU idag, så OS lär inte göra någon direkt skillnad. I Windows fall tenderar saker hoppa rätt friskt mellan kärnor, kan mycket väl vara så att om man begränsar program till specifika kärnor med processor lasso kan det ge lite lägre boost då de lastade kärnor rimligen kommer bli varmare.

Linux tenderar i det längsta undvika att flytta en viss OS-tråd från den CPU-tråd den kör på. Även om det kan ge lite högre boost att flytta den kostar det rätt mycket prestanda då L1$/L2$ är bundna till en specifik kärna och när en last flyttas måste data läsas om in i CPU-lokal cache.

Gjorde ett snabbskott, variansen på genomsnittlig frekvens över de 3 kärnor / 6 trådar som lastas är typ <100 MHz. Högsta frekvens får jag genom att lägga allt på CCX#0 som i mitt fall har CPU #1, #3 och #4 sett till maximal boost. Kör jag i ställt på CCX#2 eller CCX#3 blir genomsnittlig frekvens lägre om alla trådar går i ett CCX jämfört med att köra 1/2T över CCX#0-2.

D.v.s. skillnaden i frekvens är så liten samtidigt som man totalt sett får 3x så mycket L3$ genom att sprida över CCX.

Sen ska man inte överdriva effekten av mer cache. Miss-rate minskar ungefär som roten ur storleken på cachen. Redan vid de L3$ storlekar vi hade för ett par år sedan ligger miss-rate ofta ~10 % eller lägre. Hit-rate går då ~90 % till 93 % om man dubblar storlek på cache, det är en minimal ökning. Just spel tenderar se högre vinst av mer L3$ medan övriga program ofta redan har väldigt hög hit-rate oavsett. Det indikerar också att det är mer att effektiv L3$ per kärna ökade än minskad latens mellan CPU-kärnor som ger en boost för Zen3, prestandaökningen är klart större i spel jämfört med de flesta andra applikationer.

Permalänk
Medlem
Skrivet av Yoshman:

Självklart handlar det om att de artificiellt begränsar maximal turbo på de lägre modellerna, de har båda lärt sig från HEDT att fler kärnor mer lägre boost leder till en extremt nischad produkt då färre men snabbare kärnor är bättre för en väldigt klar majoritet av användarna.

Boosten för allt över basfrekvens styrs i praktiken helt av CPU idag, så OS lär inte göra någon direkt skillnad. I Windows fall tenderar saker hoppa rätt friskt mellan kärnor, kan mycket väl vara så att om man begränsar program till specifika kärnor med processor lasso kan det ge lite lägre boost då de lastade kärnor rimligen kommer bli varmare.

Linux tenderar i det längsta undvika att flytta en viss OS-tråd från den CPU-tråd den kör på. Även om det kan ge lite högre boost att flytta den kostar det rätt mycket prestanda då L1$/L2$ är bundna till en specifik kärna och när en last flyttas måste data läsas om in i CPU-lokal cache.

Gjorde ett snabbskott, variansen på genomsnittlig frekvens över de 3 kärnor / 6 trådar som lastas är typ <100 MHz. Högsta frekvens får jag genom att lägga allt på CCX#0 som i mitt fall har CPU #1, #3 och #4 sett till maximal boost. Kör jag i ställt på CCX#2 eller CCX#3 blir genomsnittlig frekvens lägre om alla trådar går i ett CCX jämfört med att köra 1/2T över CCX#0-2.

D.v.s. skillnaden i frekvens är så liten samtidigt som man totalt sett får 3x så mycket L3$ genom att sprida över CCX.

Sen ska man inte överdriva effekten av mer cache. Miss-rate minskar ungefär som roten ur storleken på cachen. Redan vid de L3$ storlekar vi hade för ett par år sedan ligger miss-rate ofta ~10 % eller lägre. Hit-rate går då ~90 % till 93 % om man dubblar storlek på cache, det är en minimal ökning. Just spel tenderar se högre vinst av mer L3$ medan övriga program ofta redan har väldigt hög hit-rate oavsett. Det indikerar också att det är mer att effektiv L3$ per kärna ökade än minskad latens mellan CPU-kärnor som ger en boost för Zen3, prestandaökningen är klart större i spel jämfört med de flesta andra applikationer.

Intressant. Jag får köra lite egna tester sedan och jämföra. Men då Ryzen per default verkar hoppa mellan kärnor även vid typ CB-single core tester så vet jag inte om man kan vara säker på att även om man genom affinity begränsar lasten till vissa kärnor så håller de sig fysiskt till de kärnorna. DVS är de kärnor man ser i task manager eller HWINFO fysiska eller är det en logisk representation?

Går ju annars göra ett rätt enkelt test genom att köra ett spel och kolla villka kärnor som belastas, är det då t. ex 4st kan man i första testet lägga dem på en chiplet, för att i nästa test köra 2 kärnor per chiplet, och då med inställningar som gör att GPU inte flaskar. Är det så att det är en signifikant skillnad som ligger utanför felmarginalen så har AMD skjutit sig i foten med raketkulspruta då de fram tills nyligen legat efter Intel i spel, och därigenom dragit på sig ett mindset från konsumenter att "Intel är bättre i spel, oavsett produkt."

Permalänk
Datavetare
Skrivet av Ozzed:

Intressant. Jag får köra lite egna tester sedan och jämföra. Men då Ryzen per default verkar hoppa mellan kärnor även vid typ CB-single core tester så vet jag inte om man kan vara säker på att även om man genom affinity begränsar lasten till vissa kärnor så håller de sig fysiskt till de kärnorna. DVS är de kärnor man ser i task manager eller HWINFO fysiska eller är det en logisk representation?

Besudlade datorn med CB20 (CB23 verkar inte fungera under Wine), det markerade har inget med Ryzen att göra utan är 100 % en effekt av hur Windows fungerar. Kör jag CB20 ST på Ubuntu server 20.04 ligger lasten helt fast på en en enda kärna, man kan få den att byta genom att dra igång något specifikt på den kärna CB20 valt annars ligger den fast- Det beteendet ger möjligen lite lägre boostfrekvens p.g.a. värme, men det är optimalt ur prestandahänseende då man håller L1$/L2$ "varma".

Skrivet av Ozzed:

Går ju annars göra ett rätt enkelt test genom att köra ett spel och kolla villka kärnor som belastas, är det då t. ex 4st kan man i första testet lägga dem på en chiplet, för att i nästa test köra 2 kärnor per chiplet, och då med inställningar som gör att GPU inte flaskar. Är det så att det är en signifikant skillnad som ligger utanför felmarginalen så har AMD skjutit sig i foten med raketkulspruta då de fram tills nyligen legat efter Intel i spel, och därigenom dragit på sig ett mindset från konsumenter att "Intel är bättre i spel, oavsett produkt."

Ser inte vad AMD gjort fel innan. De var sämre i spel primärt då deras CPUer var svagare per kärna än Intels, fanns inget AMD kunde göra i programvara för att ändra på det ("optimera för Ryzen" har aldrig varit realistiskt utanför några enstaka procent).

Nu när de har en CPU som är snabbare än Intel per kärna samt "tillräckligt med kärnor" (6C/12T är mer än nog) så kliver man förbi. Det var inte svårare än så.

Permalänk
Medlem
Skrivet av Yoshman:

Ser inte vad AMD gjort fel innan. De var sämre i spel primärt då deras CPUer var svagare per kärna än Intels, fanns inget AMD kunde göra i programvara för att ändra på det ("optimera för Ryzen" har aldrig varit realistiskt utanför några enstaka procent).

Nu när de har en CPU som är snabbare än Intel per kärna samt "tillräckligt med kärnor" (6C/12T är mer än nog) så kliver man förbi. Det var inte svårare än så.

Då folk verkar bry sig om 2-3 procent skillnad så tycker jag nog att de kunde ha jobbat lite mer med mjukvara eftersom det tydligen var svårt att fixa i hårdvara, det var mest så jag menade

Jag gjorde lite snabba tester med GTA V nu. Jag får bäst resultat genom att sätta affinity till kärna 0, 2, 4, 6, 8 och så vidare med chiplet 2 helt avstängt, vilket borde vara samma sak som att slå av SMT på en 3800X. Har inte riktigt verktyg för att få fram vettiga jämförelser men upplevde högre FPS och lite bättre flyt. Kanske 4-5FPS mer i snitt. Anekdotiska bevis och isolerat till ett enda spel, men ändå intressant. Kan ju ha att göra med att om en tråd får all L1-cache för sig själv så hjälper det något. Sämst resultat fick jag genom att köra samma sak fast på chiplet 2, vilket är logiskt då det är lökigare bin på den chipleten. Spred jag up det så att varje chiplet fick hälften av trådarna så hamnade jag ungefär i mitten, men fortfarande sämre än att inte sätta affinity alls.

Permalänk
Datavetare
Skrivet av Ozzed:

Då folk verkar bry sig om 2-3 procent skillnad så tycker jag nog att de kunde ha jobbat lite mer med mjukvara eftersom det tydligen var svårt att fixa i hårdvara, det var mest så jag menade

Jag gjorde lite snabba tester med GTA V nu. Jag får bäst resultat genom att sätta affinity till kärna 0, 2, 4, 6, 8 och så vidare med chiplet 2 helt avstängt, vilket borde vara samma sak som att slå av SMT på en 3800X. Har inte riktigt verktyg för att få fram vettiga jämförelser men upplevde högre FPS och lite bättre flyt. Kanske 4-5FPS mer i snitt. Anekdotiska bevis och isolerat till ett enda spel, men ändå intressant. Kan ju ha att göra med att om en tråd får all L1-cache för sig själv så hjälper det något. Sämst resultat fick jag genom att köra samma sak fast på chiplet 2, vilket är logiskt då det är lökigare bin på den chipleten. Spred jag up det så att varje chiplet fick hälften av trådarna så hamnade jag ungefär i mitten, men fortfarande sämre än att inte sätta affinity alls.

Fast det handlar aldrig om några 2-3 procent, kikar vi i Ryzen 5000 resultaten ligger 10900K 31 % högre (720p) och 25 % högre (1080p) än 3900X i lägsta FPS över de titlar som SweC testar.

Idag handlar det om enstaka procent, Ryzen 5000 är snabbare än Comet Lake men sett över lite fler titlar är fördelen just några enstaka procent. Enligt SweClockers mätningar har Intel av någon märklig orsak något bättre lägsta FPS i 1080p och uppåt, märkligt då man ligger någon enstaka procent under i 720p och det borde konvergera mot noll.

Hade krävs magi för att göra något relevant innan Ryzen 5000 och AMD ska vara väldigt glad att de han ut med den serien i samma veva GPU-prestanda ökade så pass mycket att även relativt nya CPU-modeller börjar bli flaskhals (i lägsta FPS i alla fall, finns lite mer svängrum i genomsnittlig FPS).

De som rekommenderade Ryzen innan 5000 för spel med motiveringen "mer framtidssäker" känner sig förhoppningsvis inte helt nöjd med sina insatser i att vägleda andras köp just nu...

Permalänk
Medlem
Skrivet av Yoshman:

Fast det handlar aldrig om några 2-3 procent, kikar vi i Ryzen 5000 resultaten ligger 10900K 31 % högre (720p) och 25 % högre (1080p) än 3900X i lägsta FPS över de titlar som SweC testar.

Idag handlar det om enstaka procent, Ryzen 5000 är snabbare än Comet Lake men sett över lite fler titlar är fördelen just några enstaka procent. Enligt SweClockers mätningar har Intel av någon märklig orsak något bättre lägsta FPS i 1080p och uppåt, märkligt då man ligger någon enstaka procent under i 720p och det borde konvergera mot noll.

Hade krävs magi för att göra något relevant innan Ryzen 5000 och AMD ska vara väldigt glad att de han ut med den serien i samma veva GPU-prestanda ökade så pass mycket att även relativt nya CPU-modeller börjar bli flaskhals (i lägsta FPS i alla fall, finns lite mer svängrum i genomsnittlig FPS).

De som rekommenderade Ryzen innan 5000 för spel med motiveringen "mer framtidssäker" känner sig förhoppningsvis inte helt nöjd med sina insatser i att vägleda andras köp just nu...

Det är väl bättre att "bara" ligga 27% efter än att ligga 30% efter? Nåja. Det är i alla fall intressant att det går krama ur lite prestanda till om man nu skulle råka sitta på en Ryzen 3000, och det borde ju ligga i AMD's intresse att vara "så bra som möjligt" om de inte kan vara "bäst".

Angående 720P vs 1080P så undrar jag om inte det kan ha med cache-strukturen att göra? Intel kör väl inte victim cache på desktop om jag minns rätt, så det kan ju vara det.

"framtidssäkra" processorer är bara marknadsföring, vilket väl tydligast illustrerades med Bulldozer. Man får helt enkelt köpa det som är bäst idag om man ska köpa nytt, eller göra som de flesta och "låta sin 2600K hänga med några år till"