AMD paljasti ensimmäisiä tietoja Zen 3 -arkkitehtuurin muutoksista

[FireFly Renaissance]

Ei sitä ole väitettykään. Zen3:ssa saattaa olla CCX:ssa eri määrä ytimiä kuin 4, saattaa myös olla ettei siinä ole CCX:a ylipäätään ollenkaan.

Nämä ovat spekulaatiota. Tämän hetken faktalla on kuitenkin turha väittää siellä olevan 8 coren CCX koska AMD on linjannut maksimin olevan 4.

AMD:n sisäisissä arkkitehtuurikuvissa voi aivan hyvin olla ollut 8 ytimen CCX:iä jo vaikka kahden vuoden takaa, kun Zen 3:sta on alettu väkertämään. Emmekä me edes oikeasti tiedä, käyttääkö AMD:n insinöörit koko CCX termiä, vai onko se pelkkää markkinointiosaston keksimää viihteellistä brändäystä. Tämäkään ei yllättäisi.

Tässä ei ole kyseessä nyt edes mikään "industry standard" terminologia, vaan yhden yrityksen (markkinointi)nimi.

Ja se mikä on mielenkiintoista, on prosessorin rakenne, ei se, mitä hienoja termejä markkinointiosasto on sattunut keksimään

 

[Kaotik]

@Threadripper nyt loppuu tuo jatkuva vänkäys. Sinä olet väärässä, @hkultala ja muut jotka samaa asiaa sinulle täällä koittaneet tolkuttaa oikeassa. Asiassa ei ole mitään epäselvää tai keskusteltavaa tämän pidemmälle.

 

[pomk]

Kuulostaa mielenkiintoiselta ratkaisulta hakea tietoa cachesta jota ei ole jaettu.

Jos ohjelma käyttää useampaa säiettä käsittelemään samoja muuttujia, niin toisen CCX:n L3 cachessa voi muistikirjoitusten hitauden takia olla uudempi versio samasta muuttujasta kuin mitä CCX:n omassa L3 muistissa. Tästä syystä ne pitää aina kaikki koluta läpi säikeistetyissä softissa semmoisten muuttujien kohdalla jotka on merkattu jaetuiksi. toi CCX optimointisetti johon jatkuvasti viittaat perustuu juuri tähän, eli täytä ensin yksi CCX (zen2:ssa 2-4 ydintä, milanissa 100% varmuudella annettujen tietojen mukaan max 8 ydintä), jotta ei jouduttaisi tonkimaan muidenkin CCX:ien L3 cacheja läpi joka kerta kun luetaan jotain yhteistä muuttujaa.

Tossa aika hyvä luento jossa käydään asiaa läpi ilman että tarvii mitään esitietoja perus ohjelmointijargonin lisäksi:

Kiinnostaa siksikin ettei ainakaan Sandy Bridgessä L3 latenssi riippuu siitä mikä core hakee tietoa mistä cachesta, vaikuttaa myös nopeuteen: Intel's Sandy Bridge Architecture Exposed

Sandyssä ringbussin takia jotkut latenssit ei oo symmetrisiä. ´ytimien´välinen viive on siis pidempi jos ydin 1 kirjoittaa viestin ytimen 8 luettavaksi verrattuna siihen että ydin 8 kirjoittaisi viestin ytimen 1 luettavaksi, sillä fyysinen etäisyys näille matkoille ydin-L3-ydin on eri mittainen näissä. Zen arkkitehtuurissa crossbarin takia latenssit on aina identtiset CCX:n sisällä identtisten signaalivetojen pituuksien takia. Toi siivuhomma lienee joku erikoinen optimointi, pitäisi lukea jostain tarkemmin että tietäisi mistä on kyse.

 

[Muumi75]

Zen arkkitehtuurissa crossbarin takia latenssit on aina identtiset CCX:n sisällä identtisten signaalivetojen pituuksien takia.

Synkronisessa logiikassa, joita kuluttajakäytössä olevista prosessoreista on 100%, ei tarvi signaalivetojen olla "samanmittaisiaja ja identtisiä". Riittää kun saadaan kellonreunalla data talteen.
AMD:n tai Intelin CPU:issa väylät eivät ole asynkroonisia eli signaalijohtmen pituudella ei ole mitään tekemistä montako kellojaksoa kestää hakea data jostain tai kirjoittaa se jonnekin ASIC:n sisällä. Pitkät vedot vaikuttavat ainoastaan maksimitaajuuteen jolla saadaan data fliparilta fliparille kellojakson sisällä. Tämä on digitaalitekniikan peruskauraa.

 

[FireFly Renaissance]

Synkronisessa logiikassa, joita kuluttajakäytössä olevista prosessoreista on 100%, ei tarvi signaalivetojen olla "samanmittaisiaja ja identtisiä". Riittää kun saadaan kellonreunalla data talteen.
AMD:n tai Intelin CPU:issa väylät eivät ole asynkroonisia eli signaalijohtmen pituudella ei ole mitään tekemistä montako kellojaksoa kestää hakea data jostain tai kirjoittaa se jonnekin ASIC:n sisällä. Pitkät vedot vaikuttavat ainoastaan maksimitaajuuteen jolla saadaan data fliparilta fliparille kellojakson sisällä. Tämä on digitaalitekniikan peruskauraa.

Ei nyt ihan näinkään. Fliparien välillä signaali liikkuu gigahertsien kellotaajuuksilla erittäin lyhyen matkan. Kuvailemallasi tavalla kaikkien väylien latenssi olisi tasan yksi kellojakso. Jotta signaali saadaan riittävällä nopeudella jollekin L3 cachelle tarvitaan lukuisia rekisteriasteita (tai usean kellojakson yli kulkevia signaaleita) ennen kuin signaali pääsee määränpäähän asti.

 

[pomk]

Synkronisessa logiikassa, joita kuluttajakäytössä olevista prosessoreista on 100%, ei tarvi signaalivetojen olla "samanmittaisiaja ja identtisiä". Riittää kun saadaan kellonreunalla data talteen.
AMD:n tai Intelin CPU:issa väylät eivät ole asynkroonisia eli signaalijohtmen pituudella ei ole mitään tekemistä montako kellojaksoa kestää hakea data jostain tai kirjoittaa se jonnekin ASIC:n sisällä. Pitkät vedot vaikuttavat ainoastaan maksimitaajuuteen jolla saadaan data fliparilta fliparille kellojakson sisällä. Tämä on digitaalitekniikan peruskauraa.

Juu oikeassa olet, kunhan yritin esittää asian siten että Threadripper varmasti pysyy kärryillä.

 

[Muumi75]

uvailemallasi tavalla kaikkien väylien latenssi olisi tasan yksi kellojakso.

Selitin aika epäselvästi. Minulle "kaikki väylät" eivät ole viiva markkinointipowerpointissa kahden laatikon välillä.
Väylä kahden rekisteriasteen välissä on yleensä se kellojakso (toki multicycle on mahdollista, miten haluaa suunnitella). Rekisteriasteen lisääminen tuo kellojakson viiveen, multicycle puolittaa kaistan.

20 vuotta ASIC suunnittelua taustalla, joten jokin käsitys minulla on miten digitaalinen mikropiiri toimii.

 

[Sami Riitaoja]

Jos ohjelma käyttää useampaa säiettä käsittelemään samoja muuttujia, niin toisen CCX:n L3 cachessa voi muistikirjoitusten hitauden takia olla uudempi versio samasta muuttujasta kuin mitä CCX:n omassa L3 muistissa. Tästä syystä ne pitää aina kaikki koluta läpi säikeistetyissä softissa semmoisten muuttujien kohdalla jotka on merkattu jaetuiksi. toi CCX optimointisetti johon jatkuvasti viittaat perustuu juuri tähän, eli täytä ensin yksi CCX (zen2:ssa 2-4 ydintä, milanissa 100% varmuudella annettujen tietojen mukaan max 8 ydintä), jotta ei jouduttaisi tonkimaan muidenkin CCX:ien L3 cacheja läpi joka kerta kun luetaan jotain yhteistä muuttujaa.

Ei se nyt ihan noin surkeasti mene, Mesi-protokollassa invalidoidaan ei-nykyiset datat muista L3-cacheista ennen kirjoitusta, yhteisen datan lukemisessa cachesta ei hidastuksia ole. Ja jos kirjoitetaan jaettuun dataan paljon ihan sama mikä cache-järjestelmä systeemissä on, suorituskyky sakkaa. Nykyohjemillä CCX-penalti on aika mitätön Zeneissä, suuremman CCX:n etu tulisi pääosin siitä yhden ytimen käytettävissä olevan cachen suurenemisesta.

Threadripperi on vähän ulalla monestakin asiasta mutta L3 Ryzenissä on ydinkohtaista ja jaettu suorilla väylillä neljän ytimen kesken. Muistiosoitteet on multipleksattu eri ytimien L3:n kesken joten keskimääräinen latenssi on sama, AMD itseasissa taitaa sanoa että jokainen ydin saa datan jokaisesta L3:n palasesta samalla viiveellä. Mutta L3 siis on ydinkohtaista, jokaisen ytimen kirjoitukset menevät omaan L3:een ja siitä eteenpäin, tarvitaan vain 6 väylää L3:n palasten välille täydelliseen kytkentään. Mistä päästään siihen miten Zen3:n L3 on toteutettu? Suorat väylät kasvaa eksponentiaalisesti ydinmäärän mukana samoinkuin L3:ssa tarvittavien IO:n määrä joten sama suora kytkentä ydinkohtaisilla L3:lla lienee epätodennäköinen, itse veikkaan ratkaisuksi että kaksi ydintä jakaa L3:n palasen jolloin sama suora kytkentä onnistuu helposti edelleenkin, mutta toki muitakin vaihtoehtoja on.

 

[Stephen Elop]

Ei se 12-ytiminen zen3-sarjan piirikään tule olemaan mikään "8+4". Vaan sekin tulee olemaan "6+6".

No enhän minä niin väittänytkään.

 

[jive]

Oho, tämä ketju lähti äkkiä kierroksille...

 

[IcePen]

Ei minimi vaan maksimi, ihan samalla tapaa myös uudella rakenteella voidaan poistaa ytimiä käytöstä kuin ennenkin.
edit:
Tarkennus: Yhdessä chipletissä tulee edelleen olemaan 8 ydintä, ne vain näyttäisivät olevan jatkossa kahden sijasta yksi CCX. Ytimiä voidaan kuitenkin poistaa ihan yksi kerrallaan käytöstä, se ei siitä muutu.

Tai saattaa muutua kun ei tarvi tasapainottaa kahta CCX:ää kun on vain yksi 8 ydin CCX niin voisi tulla prosessoreja myös parittomilla ydinmäärillä eli 7, 5 ja/tai 3 ytimisiä kuluttaja prosessoreja.

Ja kahta chiplettiä käyttäen voisi tulla 14, 10 ja/tai 6 ytimiset prosessorit.