AMD Ryzen 3000 "Matisse" – samlingstråd

Hade varit ännu mer spännande att jämfört mot dagens modeller, d.v.s. 2700X och i9-9900K mot FX-8350 och i7-2600K. Men den data saknas här på SweClockers.

Både Asus och MSI har släppt nya BIOS idag som stödjer nya processorer, så vi kanske får leka snart.

Tyvärr testas inte de äldre modellerna i spel här. Var inget självändamål att det skulle vara samma frekvens, går ändå inte att göra någon vettig "IPC" uppskattning på något som spel då Zen och Bulldozer/Piledriver inte kan matchar till antalet kärnor/trådar på ett meningsfullt sätt. Gör man inte det blir det ingen "IPC" jämförelse, men kan ändå vara intressant att jämföra samma last med frekvensen låst på en känd nivå (relevant om målet i slutändan är att spekulera om eventuella förbättringar i Zen2).

CB i alla ära. Det är en bra benchmark i bemärkelsen: den producerar extremt reproducerbara resultat. Men det är allt mer ett rejält avvikande värde om målet är att få något form av mått på generell prestanda, det av flera orsaker

• nästan inget annat skalar så perfekt med kärnor/CPU-trådar, de saker som ändå gör detta (t.ex. rendering och machine-learning) är just de saker vi nu ser allt mer flyttals till GPUer

• flyttal är överhuvudtaget en nisch, i de fall man faktiskt kör mycket flyttal på CPU är det få moderna program som inte utnyttjar SIMD. T.ex Matlab, Matematica, statistikprogram/språk som t.ex R, många former av simulering (men har finns definitivt fall som inte passar SIMD, är nog också här där Epyc/TR haft fina framgångar)

Svar avklarat

Finns en del lite konstiga designbeslut i Zen. Eller den kan verka konstiga om man inte har hela bakgrundsbilden klar för sig. Jim Keller fick inte i uppdrag att leda ett team vars mål var att ta fram Zen. Som jag förstått det var det någon annan som ledde teamet som specifikt jobbade med Zen.

Kellers uppdrag låg en nivå högre: han skulle leda jobbet med att ta fram en mikroarkitektur som var tänkt att användas både för 64-bitars ARM (K12) och till Zen. När man kikar på detta får man rätt mycket känslan att K12 var mycket med Kellers "baby" än vad Zen var.
https://www.youtube.com/watch?v=SOTFE7sJY-Q

Rätt många gånger Keller nämner hur mycket bättre ISA är för 64-bitars ARM, spekulationen är att han slutade när de drog pluggen ur på K12, vilket man gjorde för Amazon var missnöjd med K12 och de var den primära kunden (Amazon designade en egen 64-bitars ARM, man har lanserat en tidig version men jobbet är långt ifrån klart)

Vad man gjorde helt rätt med Zen designen var att gå väldigt mycket "all-in". Zen har en brutal "bred" back-end, i praktiken bredare än vad man kan utnyttja effektivt om man kör x86-kod (K12 hade nog blivit mer lik Apples nuvarande CPUer, de har 40-50 % högre heltals IPC jämfört med Skylake!).

Sett till maxkapacitet matchar och i flera fall överträffar Zen Skylake, största övertaget är just vid skalära flyttal: så att den presterar bäst där är rätt väntat.

Realistisk IPC hos "riktiga" program som kör x86 kod på Zen är 1-2,5 x86 instruktioner per cykel. Man inser då rätt snabbt att vare sig front-end (kapabel till 4 st x86 instruktioner per cykel) eller back-end (upp till 8 st micro-ops per cykel) är någon relevant flaskhals. Det man måste jobba med framåt är att lura ut sätt att bättre mata de resurser man har, en tyvärr nästan omöjlig uppgift givet begränsningen att man måste köra x86 kod. Finns så många idiotiska designbeslut som orsakar beroende mellan instruktioner i samma ström, SMT ger sådan boost så man har helt oberoende instruktionsströmmar att jobba med (idiotiska beslut som även 32-bitars ARM har, men 64-bitars ARM inte har).

Så blir spännande att se vad AMD tar sig till i Zen2 och senare Zen3. Finns två grundläggande designbeslut som skiljer Zen radikalt från desktop-Core

• distribuerade schemaläggning av instruktioner, d.v.s. en instruktionskö per ALU. Så vitt jag vet kör alla dagens ARM-CPU med den designen, Intel använder det i Atom. Men för x86 finns fördelar med en central schemaläggare, d.v.s. en instruktionskö där man plockar upp till N instruktioner per cykel (där N är antalet ALUs). Core har en central schemaläggare, vilket är en stor förklaring till dess högre IPC i heltal trots satt både Skylake och Zen nära nog identisk ALU-bredd här (4 ALUs för heltal). Nackdelen med en central schemaläggare är att den tar mer transistorer och drar mer ström, det hade inte varit värt det på K12 då 64-bitars ARM inte har de svagheter som man till viss den kan hantera med att centralisera schemaläggning

• Cache-design. Designar man primärt för servers är den design som Zen och Skylake SP använder, exklusiv LLC (last-level cache), den mer effektiva designen då det gör det effektiva storleken på cache större. Hos servers har man typiskt många enkeltrådade laster som sinsemellan är oberoende.
  För desktop är normalfallet att flera trådar samarbetar för att lösa samma problem, i detta fallet är det optimalt att LLC dels delas av alla CPU-kärnor samt att den är inkluderande av alla data i kärnlokal cache. Detta då en sådan design gör synkronisering mellan kärnor billigare/effektivare

Zen2 känns mer än Zen/Zen+ som "server first" från AMDs del. Gissningsvis rätt strategi sett till ekonomin, men man kan ju hoppas att även AMD gör den splitt Intel gjorde med Skylake framöver: en design för desktop och en för servers. Dessa två segment optimeras bäst på olika sätt, sätt som allt mer divergerar ju fler kärnor man stoppar in i servers.

Mycket intressant. Att navi inte klockar högt enligt vissa källor kan ha att göra med att det är en ny arkitektur kanske rentav dålig sådan.
Som han sa i slutet, om vega som typ bara är en krympning fick rejält högre klockgastigheter så varför skulle inte en polerad + krympt med hpp nod ryzen få stora gains i frekvens.
Han var även väldigt tydlig att detta är rykten och gissningar. Det är det absolut då ingen annan om ens amd har slutgiltig information än!

Skickades från m.sweclockers.com

Aktien faller nog närmaste dagarna pga denna film.

Såg du filmen? Det var ju fakta han använde i denna film och inte rykten.
Ingenjörs ex, visades vilka alltid är lägre klockade än slutprodukten.

Zen 2 kommer knappast att suga, men den kanske inte blir speciellt mycket bättre än Zen+, men bättre kommer den att vara annars kan dom lägga ner. Iofs var Bulldozer i flera fall sämre än sin föregångare, men då var det en helt ny arkitektur.

Det alla undrar är om den slår Intel, som sagt väldigt osäkert eftersom vi vet så lite. Inte ens Intel slår Intel, därför 10nm dröjer så länge - det typ suger för tillfället. Det säljs redan Intel 10nm processorer i kinesiska skol laptops, dom klockar sämre än 14nm OCH har sämre energieffektivitet.

Nej... Så länge slutsatsen baseras på rykten och inte direkt från AMD så är det spekulationer. Fakta är något man kan bygga upp med belägg och vilka belägg finns det att Zen 2 kommer att prestera X? Noll. Alltså är det spekulationer. Sedan kan ju självfallet spekulationer vara mer eller mindre troliga.

AMD är ju som bekant redan före intel idag i tillverkningsprocessen med sina 12nm på Zen+ jämfört med Intels 14nm.

Vi vet tyvärr inte så mycket om Epyc Rome heller

Hade vi vetat det hade man kunna säga rätt mycket om IPC då det är samma CPU-chiplett i båda fallen. För Epyc finns som sagt AMDs C-Ray test (som AdoredTV videon nämner) samt SiSoft. SiSoft kör tyvärr Dhrystone(heltal)/Whetstone(flyttal) som inte är jätterelevanta för att avgöra prestanda + de körs ur L1$ och skalar därför helt perfekt med CPU-kärnor samt visar noll om effekter från LLC och minneskontroller.

Vad SiSoft Sandra säger är: om man sätter kvoten av flyttalsprestanda mellan Epyc Rome mot Skylake SP till X så visar det testet på att kvoten för heltalsprestanda blir ~0,7X. Eller om man tycker det känns mer "positivt", om heltalskvoten Epyc Rome / Skylake SP sätts till Y är flyttalsprestandakvoten ~1,4Y.

Skulle inte dra någon större slutsats av detta, möjligen att även detta ger en vink om att inte jättemycket har hänt kring heltals-IPC (för det lär ju knappast ha minskat) medan flyttalsprestanda ökat (detta enbart för icke-SIMD laster då Dhrystone/Whetstone inte alls använder SIMD).

Jag har flera gånger läst vad du nämner här, men aldrig sett det komma från AMD.

Vad jag tror är att folk tolkade detta
https://qph.fs.quoracdn.net/main-qimg-62d45f086eaf17308f715cb2b5edccaf
specifikt "increased dispatch/retire bandwidth" som att kretsen kan hantera fler instruktioner per cykel.

Kan självklart vara så, men vore väldigt underlig nomenklatur från AMDs sida.

Är i princip säker att "bandbredd" här refererar till att man ökat data-bandbredden för att kunna mata AVX instruktioner som nu är 256-bitars även i kislet.

Skulle kretsen hanterar fler instruktioner per klockcykel borde man sagt att dess "bredd" (dispatch/retire width) ökade.

Både ja och nej

Ökar snabbare IF IPC? Absolut, snabbare IF har en positiv effekt på alla operationer som missar CPU-cache!

Men relativt säker på att x2,3 siffran här refererar till inter-krets kommunikation. Här måste man komma ihåg att alla minnesoperationer och all inter-chiplett kommunikation går via IF som är extern till kretsen. Lokala minnesoperationer gick tidigare aldrig via IF då det var en on-die minneskontroller.

Gula fält är här "on-die" IF medan de gröna är "on-package inter-die IF" (gråa/blåa fält är "inter-socket IF", inte relevant för vare sig Ryzen eller TR). Data från ServeTheHome
https://www.servethehome.com/wp-content/uploads/2017/07/AMD-EPYC-Infinity-Fabric-DDR4-2666-Bandwidth-in-MBps-package-mapping.jpg
Behöver nästan x2,0 gånger boost i inter-krets kommunikation för att matcha vad man tidigare hade mellan CCX på samma krets. Nog ett bra riktmärke att sikta på nu när IF måste hantera alla minnesoperationer.

Totalt sett vet vi egentligen noll om saker som latens mot RAM för Zen2. Rimligen blir det högre jämfört med Zen/Zen+ då dessa har integrerad minneskontroller. Större L3$ hjälper en del, men mindre än många kanske tror då Zen har en victim-cache som L3$ och inte en inkluderande cache. Victim-cache ser snabbare "dimishing returns" av storlek.

"The returns although seem to level off beyond victim cache size of 50 blocks, thus proving Joupii's[1] observation that victim cache benefits reach a plateau after the first few victim blocks."

Zen har ju faktiskt en relativt stor L2$ (512 kB) men hög set-associvitet (båda egenskaperna minskar risken för "conflict-misses").

Personligen tror jag den större micro-op cachen kommer ge större effekt än dubblad L3$. Ju närmare en cache ligger CPU-kärnorna, ju större effekt ger en förbättring i den cachen. Man kan se micro-op cache som en form av L0I$ (den håller bara instruktioner och ligger "före" L1I$).

Både SiSoft Sandra och Userbenchmark (som båda är rätt usla benchmarks) pekar ändå på 10-15 % högre IPC i flyttalsdelen och relativt nära noll i heltalsdelen, det när L2$ och högre delar av minneshierarkin är helt ute ur ekvationen. Så vi vet väldigt lite

Lite märkligt att AMD inte visat någon AVX tung benchmark. Här borde man ju se upp mot en fördubbling jämfört med Zen/Zen+. Fast man kan undviker detta då jämförelsen med Intel inte har något PR-värde?

Lite märkligt att AMD inte visat någon AVX tung benchmark. Här borde man ju se upp mot en fördubbling jämfört med Zen/Zen+. Fast man kan undviker detta då jämförelsen med Intel inte har något PR-värde?

Valhalla Common Options:
* Performance
* Core Watchdog:
1) Core Watchdog Timer Enable
2) Core Watchdog Timer Interval
3) Core Watchdog Timer Severity

Soc Miscellaneous Control:
* ABL Console Out Control

BIXBY Common Options

Local APIC Mode:
1) xAPIC
2) x2APIC
3) Auto

MCA error thresh enable
1) False
2) True

MCA error thresh count

SMU and PSP Debug Mode
1) Disabled
2) Enabled
3) Auto

Xtrig7 Workaround
1) Auto
2) No Workaround
3) Bronze Workaround
4) Silver Workaround

PPIN Opt-in
1) Disabled
2) Enabled
3)Auto

CCD/Core/Thread Enablement
* CCD Control:
1) Auto
2) 2 CCDs
3) 3 CCDs
4) 4 CCDs
5) 6 CCDs

or

* CCD Control:
1) Auto
2) 2 CCDs
3) 3 CCDs
4) 4 CCDs

or

* CCD Control:
1) Auto
2) 1 CCDs

Core control:
1) Auto
2) TWO (1 + 1)
3) FOUR (2 + 2)
4) SIX (3 + 3)

Link:
CAKE CRC perf bounds Control
CAKE CRC perf bounds
4-link xGMI max speed
3-link xGMI max speed

System probe filter

PSP error injection support

NUMA nodes per socket:
1) NPS0
2) NPS1
3) NPS2
4) NPS4
5) Auto

1TB remap:
1) Do not remap
2) Attempt
3) Auto

DRAM map inversion:
1) Disabled
2) Enabled
3) Auto

ACPI
*ACPI SRAT L3 Cache As NUMA Domain
* ACPI SLIT Distance Control
* ACPI SLIT remote relative distance
* ACPI SLIT virtual distance
* ACPI SLIT same socket distance
* ACPI SLIT remote socket distance
* ACPI SLIT local SLink distance
* ACPI SLIT remote SLink distance
* ACPI SLIT local inter-SLink distance
* ACPI SLIT remote inter-SLink distance

Common RAS
* DRAM Post Package Repair
* RCD Parity
* DRAM Address Command Parity Retry
* Max Parity Error Replay
* Write CRC Enable
* DRAM Write CRC Enable and Retry Limit
* Max Write CRC Error Replay
* Disable Memory Error Injection

ECC Configuration
* DRAM UECC Retry

Security
* Chipselect Interleaving:
1) Disabled
2) Auto
Address Hash CS
Address Hash Rm

Memory MBIST
* MBIST Test Mode:
1) Interface Mode
2) Data Eye Mode
3) Both
4) Auto
* MBIST Per Bit Slave Die Reporting
1) Disabled
2) Enabled
3) Auto
* Pattern Select
1) PRBS
2) SSO
3) Both
* Pattern Length
* Aggressor Channel
* Aggressor Static Lane Control
* Aggressor Static Lane Select Upper 32 bits
* Aggressor Static Lane Select Lower 32 Bits
* Aggressor Static Lane Select ECC
* Aggressor Static Lane Value
* Target Static Lane Control
* Target Static Lane Select Upper 32 bit
* Target Static Lane Select Lower 32 Bits
* Static Lane Select ECC
* Target Static Lane Value
* Data Eye Type:
1) 1D Voltage Sweep
2) 1D Timing Sweep
3) 2D Full Data Eye
4) Worst Case Margin Only
* Worst Case Margin Granularity
* Read Voltage Sweep Step Size
* Read Timing Sweep Step Size
* Write Voltage Sweep Step Size
* Write Timing Sweep Step Size

XFR Enhancement:
1) FCLK Frequency
2) MEMCLK Frequency
3) UCLK DIV1 MODE:
a) Auto
b) UCLK==MEMCLK
c) UCLK==MEMCLK/2
+ precision boost override

SMU Common Options
* CLDO_VDDP Control
* EfficiencyModeEn
* Package Power Limit Control
* DF Cstates
* Fixed SOC Pstate
* CPPC

NTB Common Options
* Link Speed : Gen 4

Translation into simple language. We have:

1) New memory controller with partial error correction for nonECC memory
2) Desktop processor with two (2 CCD) chiplets on board, 32 threads maximum
3) New MBIST (Memory built-in self-test)
4) Core watchdog - is a fail/safe function used to reset a system in case the microprocessor gets lost due to address or data errors
5) XFR - at the moment I do not see anything special about it, the algorithm and limits have been updated. Scalar Controll come back with new processors.
6) Updated core control has a symmetric configuration of the active cores . In 2CCD configurations, each chiplet has its own RAM channel in order to minimize latency to memory access. 1 channel on 8 cores will be a bottleneck if you use the system in the default state.

UPD: point number 6 is questionable, perhaps there will be a special long-range interface for connecting a chiplet with IO

This is not all information which I will gladden you in the near future

Ny läcka:

https://www.overclock.net/forum/13-amd-general/1640919-new-dr...

Stämmer ryktet så kommer vardera chipmet få en minnes kanal om 8 kärnor vilket kommer flaska som även står, verkar vara lite oigenomtänkt om det stämmer? Hur snabbt minne behövs för att undvika flaskning. Räcker ens dual channel för 8 kärnor? Känns som prestanda förbättringarna idag börjar avta efter 3000mhz?

Skickades från m.sweclockers.com

Ja, osäkert hur dom tänkt sig, men kan vara att en kanal har direkt access medans den andra kanalen måste gå över I/O-die om det bara är en chiplet. Eller också kommer dom alltid att köra med dubbla chiplets med varierande antal kärnor.

Till det positiva hör att IF verkar få DDR, så dubbla hastigheten mot idag, lär ju hjälpa en del med latenserna, kan ju vara så att man flyttat upp marginalerna i och med det så att det inte kommer att börja flaska förrän med DDR5. Och då kanske man höjer IF ytterligare en multipel.

Samtidigt måste man ju begränsa minneskanalerna, eftersom AM4 inte har tillräckligt många pins.

Intels spoiler finns inte på AMD`s processor dom är immuna för detta säkerhetshål https://www.overclock3d.net/news/cpu_mainboard/amd_confirms_t...