PCTuning fórum

HEAD píše:Nake nove info.Mimojine zen na 7nm bude porad 8c/ccx, ale bude mit dvojnasobek L3.
https://www.youtube.com/watch?v=K4xctJOa6bQ

já ti nevím, ale AdoredTV je pro mě stejně věrohodnej jako WCCFTECH.....

del42sa píše:já ti nevím, ale AdoredTV je pro mě stejně věrohodnej jako WCCFTECH.....

To je samozrejme pravda, ale vcera Charlie ze S|A napsal:

In our initial reveal we said there were 9 die or more specifically 8+1 dies with 8x 8-core CCXs and one IOX.

Takze to vyzniva, ze v jednom z jeho predchozich placenych clanku na tema Rome uz predstavil cihplety.

Byla by sranda, kdyby YT mel pristup za paywall k S|A clankum...

yuri.cs píše:Takze to vyzniva, ze v jednom z jeho predchozich placenych clanku na tema Rome uz predstavil cihplety.

Byla by sranda, kdyby YT mel pristup za paywall k S|A clankum...

tak to je klidně možné, to předplatné je sice dost drahé, ale pro nějakej magazín který se živí právě tímto způsobem neni problém těch 25tisíc ročně rozpustit v nákladech...

Do CESu ničemu nevěřím, ale 8C CCX se zdá být logický, pokud lowend plánujou pokrývat APU.

Am4 bude furt 8C/16t uveden. To je vše, co zatím vím.

Ano, to uz tak nejak bylo potvrzeno leakem cloveka z RTG.

AMD ma aktualne protichudne cile - kompatibilitou desek Zen1 az Zen2 (nebo i Zen3?) a naopak masivni navysovani jader.

AM4 se dvema kanaly uz moc dalsich jader "neuzivi". Mozna 10c, ale treba 16c bez omezeni? To zni i s velkou L3 a rychlymi pametmi mizerne. Navic desktop aktualne vic nez 8c urcite nepotrebuje.

Horsi to ma serverova platforma. Tam je tech uvadenych 64c zrejme tezko uzivitelnych pomoci stavajcich osmi kanalu s ~160GB/s. HPC Fujitsu pocita s ~1000GB/s pro svych 48c...

Ve svetle 48c rumours se nabizi varianta - 48c pro stavajici platformu a 64c monstrum pro nejakou novou.

Jseš si tim jistej? Já u 18 C jádrovýho Haswellu či 22 C Broadwellu můžu s klidem prohlásit že rozdíl mezi dual a quad channelem je v rámci chyby měření. Ba dokonce, 6 či 8 jádro ve stejnym socketu má mem bottleneck větší protože má mnohem menší L3. Asi jediná platforma kde je osazení všech kanálů kritické je... překvápko... AMD TR a EPYC, což je způsobené multidie + CCX zapojenim, kde každá die je vlastní CPU a navíc tam neni žádná cache přes kterou by jádra mohla komunikovat, vše musí přes RAM. Je to důsledek cheap návrhu AMD kterej bude, pokud se spekulace o centrálním čipu s NB a CPU čipech kolem potvrdí, odstraněn.

To s tým bottleneckom platí pre hry alebo HPC?

Pretože ak si prepočítate peak výkon a priepustnosť tak to je rádovo inde, najme s AVX (32/64 operácií za takt).

A mimochodom, ako sa odstráni ten bottleneck, keď v tom 8+1 návrhu nebude žiadna directly attached DIMM?

Snad všude krom syntentiky ala sanda či aida mem bandwith benchark je rozdíl minimální. Většina věcí co dobře threaduje má zároveň celkem nízké nároky na prostupnost. 32C TR padal i tam kde jsou tyto nízké nároky protože ihmo víme co se tam děje.

Pokud bude novej EPYC mít centrální 1 řadič paměti tak všechny jádra budou mít k dispozici stejnou RAM, tzn nebude zde hrozit kouklání do RAM jiného controlleru přes IF a možnost tvorby děsného bottlenecku právě tam.

Samo sebou toto neni nic obecného, pokud budeš mít fakt více apliakcí náročnejch na prostupnost tak ti dojde, ale to s čim si AMD honí každej večer, ala rendering, fakt prostupnost nepotřebuje.

DOC_ZENITH píše:Pokud bude novej EPYC mít centrální 1 řadič paměti tak všechny jádra budou mít k dispozici stejnou RAM, tzn nebude zde hrozit kouklání do RAM jiného controlleru přes IF a možnost tvorby děsného bottlenecku právě tam.

Ale však každý prístup pôjde z kremíku s jadrami, cez IF, cez ďalší kremík do RAM.

Akurát rozdiel by bol v tom, že tentokrát tam nebudú ďalšie jadrá ale len pamäťový radič. Ale latencia bude worst-case súčasných EPYCov. Aj keď bude uniformná, prídu o tú rýchlu priamo pripojenú.

Zas tak jednoznačne by som to nevidel. Doteraz som mal za to, že aj u Zeppelinu je pamäťový radič (a iné I/O) pripojený cez Infinity Fabric. Takže je otázka, ako sa u Zeppelinu on-die_IF líši od off-die_IF a ktorej možnosti bude u hypotetického chiplet riešenia tá off-die_IF viac podobná.

off-die potrebuje oveľa viac energie na prenos bitu. To znamená výkonné io drivery (analógové).

To si myslím že si Adored vôbec neuvedomil. Tým deviatym kremíkom množstvo analógových častí vôbec neklesne, skôr naopak, každý prenos pôjde prakticky cez 3 serdes kým sa vôbec dostane k RAM/PCI.

Rozdíl bude naprosto zásadní, co u současného TR a EPYCu způsobuje ten problém jsou 2 faktory.

1. L3 je nejednotná a neni větší jak jedno CCX ala 4 jádra. Všechny data co teda proces v ní nenajde se musí řešit přes RAM. U jinejch architektur je L3 bránou do RAM a do oné L3 vidí všechny jádra a spousta operací co u Ryzuenu musí jít do RAM se vyřaší tam, to jednak zvedná výkon a druhak rapidně klesaj nároky na latence a prostupnost RAM.

2. U TR/epyc jedna DIE má 1 dual-channel řadič, a celkem jsou 4 DIE. Tzn pokud aplikace neni numa optimized (99% neni) tak neustále háže data do RAM random. Tzn neustále přistupuje do RAM přes infinite fabric. 75% prostupnosti jde přes IF z jinejch DIE a mezi die 1/3-2/4 je jen jedna IF linka . Toto je kombinováno s problémem 1, kdy data co se nenajdou v cache a proces je chce rovněž nenajde většinou ve své paměti, ale v paměti jiného CPU/DIE. IF se tedy jednoduše přetíží a stane se bottleneckem. Zde je největší problém pokud maš vyíženou tunu threadů a všechny chtěj solidní prostupnost RAM, to pak jde výkon do kopru.

Minimálně bod 2 nové schéma s centrálnim controller čipem vyřeší, protože všechny jádra budou mít stejnej RAM pool, nebude se muset sahat přes IF do jinejch CPU, vše bude na jednom místě. Tím opadne tuna zbytečného zahlcení interconnectu.

A jak se to jako může vylepšit, když bude úplně všechna RAM schovaná za jedním hopem mimo křemík fo uncore die? To přece něco stojí, přístup do RAM bude stejně drahej na latenci jako když se v TR šlo přes sousední křemík. A taky na spotřebu, externí rozhraní tohohle typu potřebuje dost energie a tady by jich bylo osm... přijde mi to úplně šílený.
Jako interposer to možná trošku zmírní, ale neodstraní.

Druhá věc - osmijádrovej CCX - to jako dají do APU taky 8 jader? (Poslední roadmapy z roku 2016 ještě říkaly že jenom 4)? A jak to bude propojený uvnitř? Dnešní 4core CCX maá spojení každý s každým, ale to u osmi jader moc nepůjde kvůli komplexnosti. Musel by tam být nějaký ringbus nebo tak něco. Nejspíš by se tedy s 8c CCX zpomalila i komunikace v rámci křemíku.

Takže já doufám, že jsou to kecy, protože tohle by mohlo dopadnout dost tragicky. Zvlášť pokud by se stejnej design dával do desktopu, jejda...

nejlepší bude nespekulovat a počkat na oficiální odhalení od AMD. Jakoukoliv změnu u Epyc2 udělali, měla by to být změnak lepšímu.

@Jan Olšan: Serverové řešení vůbec nemusí být identické jako desktopové čipy. Naopak rozdílů může být mnohem více než doteď a řešení odvážnější/radikálnější pokud to bude pro serverový workload přínosné.

To 8 jadrové CCX už niekto spomínal, je to o optimalizácii v stromových štruktúrach, počet vetiev vs hĺbka a podobne. Problém je v tom že pri arbitreroch a obvodoch na koherenciu s počtom vetiev z jedného uzlu rastie komplexnosť až exponenciálne (pokiaľ to nemá byť na úkor latiencie a priepustnosti).

Podobne ten deviaty kremík. Aby zvládol spracovanie z 8 vetiev pri rozumnej priepustnosti a latencii, tak jeho komplexnosť bude musieť byť extrémna. To je ďalšia otázka v tých špekuláciách: 7nm CPU kremíky a 14nm IO s 512MB L4 bude asi ťažko realizovateľné (mimochodom, 200MB SRAM na úrovni L3 mala vyše 500 mm2 na 14nm).

Pre porovnanie SPARC má L3 s 8 vetvami a tá konštrukcia je masívna. Zaberá väčšinu čipu. A to tam je len polovica jadier a nieje to orientované na najvyššiu priepustnosť (AVX vektory).

To že tam je viac rozdielov, zmeny v APU... také veci zvyšujú cenu čo bol hlavný argument pre tieto extrémne MCM teórie. V takom prípade by urobili lepšie ak by rovno navrhli separátne desktop a serverové verzie (čo sa tu už tiež objavilo).

@DOC: L3 v CCX jsou spojene IF. To, ze to dle testu vypada, jako by to slo do RAM, je dilem sdielni frekvencni domeny IF a MEM radice.

@APU: Ono vlastne bude jeste dlouho trvat, nez se dostavi Zen2 7nm APU. Nekdy v 2019 vyde Picasso, ktere je porad Zen(+) a 12nm. Takze treba Zen2 APU lowend preskoci... treba primo k 8c ve 2021.

@xbar pro 4+ jadra: Nemuzu si z hlavy vzpomenout, ale urcite jsem nekde (server ARM nebo Oracle?) videl xbar pro 8 jader. Takze to technicky jde.

@pocty kanalu vs vykon: Kydyby vsechny chipy od 4 po 64c si vystacili se 2 kanaly, tak proc by Intel, AMD, IBM, Fujitsu, atd. navysovali jejich pocet, kdyz to tedy prinasi jen starosti?

Počet kanálů se navyšoval hlavně kvůli kapacitě a dalším funkcím jako třeba spolehlivosti (možnost kopie kanálů od LGA2011 a pod), protože řešení co byly předtim kde byl řadič v chipsetu a na desce musely bejt spešl buffery aby to tolik paměti vůbec pobralo a celkově to bylo katastrofální. Já jsem nikde neřekl že 2 kanály stačí forever, ale více než 2 mělo vždy disktutabilní benefit a maj příjnos jen ve specifickejch situacích. A to že EPYC má problémy i s 8 kanály neznamená že je to problém nedostatku kanálů či prostupnosti RAM, problém je design EPYCu.

Co se CCX týče tak ano IF škáluje s taktem RAM, ale CCX má dva bloky 8MB L3 cache bloky a ta cache nezvládne pobrat více jak 8MB dataset, nesčítá se to a kdo ví jestli se vůbec přes IF dívá do té druhé nebo jde pro data rovnou do RAM. Já bych tipoval spíš že rovnou do RAM protože dívat se a nenajít by stálo další latenci. Je to komplet jiná situace jako třeba na Intelu kde se do L3 vždy podíváš protože přes ní stejně jdeš do RAM a data v ní jsou ze všech jader, spoustakrát se tam teda najdou a do RAM se nemusí chodit. Toto chování tak trochu potvrzuje i to že Ryzen benefituje mnohem víc z menších latencí RAM než z frekvence RAM a když frekvence RAM zlepšuje bandwitch mezi L3 bloky tak touhle logikou by měla pomáhat mnohem více, ale ono to rádo spíš latence, tzn latence do RAM a tam se to kouká primírně a tam je bottleneck.

Ja bych se drzel pri zemi. AMD podle me pujde i v Ryzenu - Ryzen 2 stejnou cestou jako Phenom - Phenom 2. Jader je dost. I pristi rok bude 8 jader pro desktop az az.

Typuju stejny pocet jader v CCX jako dnes, s lepsim vyrobnim procesem bude vyssi frekvence a vetsi L3.

Nemuzou si veskerou munici vystrilet hned, co by pak vylepsovali s Ryzen 3? To bude ta spravna doba na zvysovani poctu jader.

Podľa patchu je prítomné len AVX2. Šírka jadra vyzerá byť nezmenená. Vylepšenia by mali byť v latenciách, najmä load/store ale sám som to neporovnával.

https://gcc.gnu.org/ml/gcc-patches/2018 ... ftO1_w.txt

https://www.phoronix.com/scan.php?page= ... -GCC-Patch