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

[pomk]

Eli kommunikaatio vasemman puolen ytimen ja oikean puolen ytimen välillä vaatii koko L3 cachen läpäisyä.

Mitään suoraa kommunikaatiota ytimien välillä ei ole! Ytimissä ajettavat koodinpätkät kommunikoivat keskenään käyttäen muistiosotteita, joka käytännössä tapahtuu L3 cachen ohjaimen läpi.

 

[Kaotik]

Miksi tehdä asiasta liian vaikeaa? AMD on sanonut tuota "täytä CCX ennen toisen käyttöä" aika monta vuotta. Mikäli CCX määritellään 8-ytimiseksi, ohje pitäisi muuttaa seuraavasti: Täytä CCX ennen toisen käyttöä, mikäli CCX:a on vain yksi, täytä (tähän joku uusi termi ytimien ryhmälle) ensin ja sitten täytä (se toisen ryhmän termi) sitten.

Tai sitten ei keksitä uutta termiä vaan todetaan sen neljän ytimen ryhmän olevan CCX ja mitään muutosta ei tarvita. Edelleen täytetään toinen CCX ensin.

Katsotaan miten käy.

Eikä pitäisi. CCX on tällä hetkellä yhden L3:n yhdistämät prosessoriytimet, niitä sattuu olemaan neljä. Niitä voisi olla ihan yhtä hyvin kaksi, kahdeksan tai vaikka 666 ydintä, eikä se muuttaisi sitä. Sama sääntö pätisi aina, "täytä CCX ennen toisen käyttöä".

Sillä aivan käsittämättömällä logiikalla millä sinä näet tuossa Zen3:ssa nyt "kaksi ryhmää", olisi myös nykyisessä neljän ytimen CCX:ssä "kaksi ryhmää".

 

[hkultala]

Miksi tehdä asiasta liian vaikeaa?

Jospa kysyisit tätä ihan itseltäsi.

Kaikille muille tämä asia on ihan päivänselvä.

AMD on sanonut tuota "täytä CCX ennen toisen käyttöä" aika monta vuotta. Mikäli CCX määritellään 8-ytimiseksi, ohje pitäisi muuttaa seuraavasti: Täytä CCX ennen toisen käyttöä, mikäli CCX:a on vain yksi, täytä (tähän joku uusi termi ytimien ryhmälle) ensin ja sitten täytä (se toisen ryhmän termi) sitten.

Ei ole mitään "toista ryhmää". L3-välimuisti on aina ollut sen CCXn keskellä, eli puolet CCXn ytimistä on (ja on aina ollut) sen L3-välimuistin toisella puolella, puolet toisella puolella, mutta kaikki ovat loogisesti ja kytkennöiltään ihan samaa ryhmää.

Tai sitten ei keksitä uutta termiä vaan todetaan sen neljän ytimen ryhmän olevan CCX ja mitään muutosta ei tarvita. Edelleen täytetään toinen CCX ensin.

Katsotaan miten käy.

Ei ole mitään toista neljän ytimen ryhmää.

Zen3ssa on vain kahdeksan aivan samalla tasolla olevaa, aivan samalla tavalla kytkettyä ydintä isommassa CCXssä. Toiset sattuvat sijaitsemaan piirillä fyysisesti hiukan eri paikassa, (aivan samalla tavalla kuin puolet ytimistä nykyisen zenin CCXssä sijaitsee piirillä fyysisesti hiukan eri paikassa) ihan vaan sen takia, että on fyysisesti mahdotonta sijoittaa ne samaan paikkaan, ja tuollaisella rakenteella minimoidaan kaikkien oleellisten väylien pituudet.

Luepa keskustelua taaksepäin. Tässä on kyse juurikin siitä miten ne on piirretty. Eli kommunikaatio vasemman puolen ytimen ja oikean puolen ytimen välillä vaatii koko L3 cachen läpäisyä. Siinä ei ole järisyttävää eroa nykyiseen ratkaisuun.

Siellä on crossbar johon on aivan samalle tasolle kytketty kaikki ytimet sekä L3-välimuisti. "vasen ja oikea puoli" eivät eroa toisistaan mitenkään muuten kuin fyysisen paikan suhteen. Siellä niiden välimuistilohkojen välissä sijaitsee sen kaiken toisiinsa kytkevän crossbarin logiikkaa. Lisäksi crossbarin johtoja saattaa ehkä kulkea myös ylemmissä johtokerroksissa niiden välimuistilohkojen yläpuolella (tästä en ole varma).



Ja kiinnostaisi myös tietää, että mitähän kommunikaatiota sinä kuvittelet niiden ydinten kommunikoivan keskenään? Olen aika varma, että et osaa nimetä mitään. Prosessorin käskykannasta ei nimittäin löydy mitään sellaisia käskyjä kuin "lähetä tämä data ytimelle X".

(tähän kysymykseen saa sitten vastata vain threadripper, älkää muut spoilatko )

 

[pomk]

Ja kiinnostaisi myös tietää, että mitähän kommunikaatiota sinä kuvittelet niiden ydinten kommunukoivan keskenään. Olen aika varma, että et osaa nimetä mitään. Prosessorin käskykannasta ei nimittäin löydy mitään sellaisia käskyjä kuin "lähetä tämä data ytimelle X".

(tähän kysymykseen saa sitten vastata vain threadripper, älkää muut spoilatko

[/QUOTE]
Bootin yhteydessä ne voi hei ehkä teoriassa kirjoitella toistensa konfigurointirekistereihin!!!

 

[Threadripper]

Mitään suoraa kommunikaatiota ytimien välillä ei ole! Ytimissä ajettavat koodinpätkät kommunikoivat keskenään käyttäen muistiosotteita, joka käytännössä tapahtuu L3 cachen ohjaimen läpi.

Mistä tiedät miten asia tulee olemaan Milanissa? Varsinkin että latenssi on sama riippumatta siitä kummalla puolella L3 cachea ollaan.

Eikä pitäisi. CCX on tällä hetkellä yhden L3:n yhdistämät prosessoriytimet, niitä sattuu olemaan neljä. Niitä voisi olla ihan yhtä hyvin kaksi, kahdeksan tai vaikka 666 ydintä, eikä se muuttaisi sitä. Sama sääntö pätisi aina, "täytä CCX ennen toisen käyttöä".

Sillä aivan käsittämättömällä logiikalla millä sinä näet tuossa Zen3:ssa nyt "kaksi ryhmää", olisi myös nykyisessä neljän ytimen CCX:ssä "kaksi ryhmää".

Jos on vain yksi CCX, silloin ei voida täyttää ensin "toista CCX:a", koska sitä ei ole. Tarvitaan toinen sääntö täyttämiseen.

Kun katsoo Milanin kuvaa, siinä esitetään selkeästi kaksi ydinryhmää. Täysin mahdoton ymmärtää miten siitä voi olla näkemättä kahta ydinryhmää: toinen L3 cachen vasemmalla puolella, toinen oikealla puolella.

Voi olla ettei lopullinen toteutus ole se mitä kuva esittää. Valitettavasti mitään parempaa ei juuri nyt ole tarjolla. Vai onko?

Jospa kysyisit tätä ihan itseltäsi.

Kaikille muille tämä asia on ihan päivänselvä.

Pari muuta = kaikki, OK.

Ei ole mitään "toista ryhmää". L3-välimuisti on aina ollut sen CCXn keskellä, eli puolet CCXn ytimistä on (ja on aina ollut) sen L3-välimuistin toisella puolella, puolet toisella puolella, mutta kaikki ovat loogisesti ja kytkennöiltään ihan samaa ryhmää.

Ei ole mitään toista neljän ytimen ryhmää.

Zen3ssa on vain kahdeksan aivan samalla tasolla olevaa, aivan samalla tavalla kytkettyä ydintä isommassa CCXssä. Toiset sattuvat sijaitsemaan piirillä fyysisesti hiukan eri paikassa, (aivan samalla tavalla kuin puolet ytimistä nykyisen zenin CCXssä sijaitsee piirillä fyysisesti hiukan eri paikassa) ihan vaan sen takia, että on fyysisesti mahdotonta sijoittaa ne samaan paikkaan, ja tuollaisella rakenteella minimoidaan kaikkien oleellisten väylien pituudet.

Ne jotka sijaitsevat samalla puolella L3 cachea ovat samalla puolella L3 cachea (mikäli L3 cache on keskellä). Niiden ytimien keskinäinen kommunikaatio voidaan saada(!) nopeammaksi kuin kommunikaatio L3 cachen toisella puolella olevien ytimien kanssa.

Siellä on crossbar johon on aivan samalle tasolle kytketty kaikki ytimet sekä L3-välimuisti. "vasen ja oikea puoli" eivät eroa toisistaan mitenkään muuten kuin fyysisen paikan suhteen. Siellä niiden välimuistilohkojen välissä sijaitsee sen kaiken toisiinsa kytkevän crossbarin logiikkaa. Lisäksi crossbarin johtoja saattaa ehkä kulkea myös ylemmissä johtokerroksissa niiden välimuistilohkojen yläpuolella (tästä en ole varma).

Ja kiinnostaisi myös tietää, että mitähän kommunikaatiota sinä kuvittelet niiden ydinten kommunikoivan keskenään? Olen aika varma, että et osaa nimetä mitään. Prosessorin käskykannasta ei nimittäin löydy mitään sellaisia käskyjä kuin "lähetä tämä data ytimelle X".

(tähän kysymykseen saa sitten vastata vain threadripper, älkää muut spoilatko )

Eroavat fyysisen paikan eli etäisyys ytimestä toiseen on erilainen. Toteutuksesta riippuen sillä voi olla merkitystä. Uutisen mukaan Milanissa on tehty merkittäviä muutoksia välimuistikäytäntöihin, joten se mikä pätee Zeniin, ei välttämättä päde Milaniin.

Haetaan vaikkapa toisen ytimen L3 cachesta tietoa, koska L3 cache on ydinkohtainen mutta silti jaettu kaikkien kesken.

 

[hkultala]

Haetaan vaikkapa toisen ytimen L3 cachesta tietoa, koska L3 cache on ydinkohtainen mutta silti jaettu kaikkien kesken.

Ei ole ydinkohtainen vaan kaikille CCXn ytimille yhteinen.

Että väärä vastaus.

Ja dataa haettaessa ei muutenkaan voida heti aluksi tietää, mistä se tulee löytymään. Pitää tarkastaa jokaisen wayn TAGit että tiedetään, mistä se löytyy.

 

[pomk]

Mistä tiedät miten asia tulee olemaan Milanissa? Varsinkin että latenssi on sama riippumatta siitä kummalla puolella L3 cachea ollaan.

AMD ei ole antanut mitään viitteitä siitä, että se olisi tekemässä jotain uutta x86 käskykantalaajennusta. Voihan sieltä sellainen toki tulla, joka sitten mahdollistaisi näiden ytimien välisen suoran kommunikaation.

 

[hkultala]

AMD ei ole antanut mitään viitteitä siitä, että se olisi tekemässä jotain uutta x86 käskykantalaajennusta. Voihan sieltä sellainen toki tulla, joka sitten mahdollistaisi näiden ytimien välisen suoran kommunikaation.

Niinpä, yleensä uusista käskykantalaajennoksista kuitenkin julkaistaan tietoja pari vuotta etukäteen, jotta kääntäjien kehittäjät saavat niille väsättyä tukea ja softakehittäjät osaavat varautua niiden tulemiseen.

Ja millaisiakohan ne uudet käskykantalaajennokset oikein olisivat, millaisen järkevän semantiikan niille voisi oikein keksiä? Kun ei kuitenkaan tiedetä, kuka siellä toisella ytimellä on ajossa...

 

[hkultala]

Mistä tiedät miten asia tulee olemaan Milanissa? Varsinkin että latenssi on sama riippumatta siitä kummalla puolella L3 cachea ollaan.

Jos on vain yksi CCX, silloin ei voida täyttää ensin "toista CCX:a", koska sitä ei ole. Tarvitaan toinen sääntö täyttämiseen.

Koko milan-paketissa on kahdeksan kappaletta niitä CCXiä. Kalliimmissa kuluttajakantaan tulevissa kuluttajamalleissakin tulee olemaan kaksi.

Ja muutenkin, luet nyt vanhaa optimointiopasta ja sen perusteella päättelet jotain tulevien prossujen rakenteesta?

un katsoo Milanin kuvaa, siinä esitetään selkeästi kaksi ydinryhmää. Täysin mahdoton ymmärtää miten siitä voi olla näkemättä kahta ydinryhmää: toinen L3 cachen vasemmalla puolella, toinen oikealla puolella.

Kuten on sanottu jo hyvin selvästi, loogisesti siellä ei ole mitään kahta eri ryhmää sen enempää kuin nykyisten CCXien sisällä on kahta eir ryhmää. Se on vain fyysistä ytumien sijoittelua.

Ne jotka sijaitsevat samalla puolella L3 cachea ovat samalla puolella L3 cachea (mikäli L3 cache on keskellä). Niiden ytimien keskinäinen kommunikaatio voidaan saada(!) nopeammaksi kuin kommunikaatio L3 cachen toisella puolella olevien ytimien kanssa.

Edelleenkään et ole kertonut (paikkaansapitävää vastausta) siitä, mitä se kommunikaatio voisi olla.

Se, minkä kommunikaation nopeudella on väliä on sillä, kuinka nopeasti ydin saa luettua dataa sieltä L3-välimusitilta. Ja kun välimuisti (jonne kaikki tekee hakuja) on keskellä, viiveet ytimiltä sinne on kaikkein pienimmät. Tällöin puolet ytimistä on luonnollisesti sen toisella puolella, puolet toisella puolella.

Eroavat fyysisen paikan eli etäisyys ytimestä toiseen on erilainen. Toteutuksesta riippuen sillä voi olla merkitystä.

Toteutus on yksi crossbar, jonka kautta kaikki on kytketty toisiinsa. Tällöin sillä ei ole merkitystä.

Uutisen mukaan Milanissa on tehty merkittäviä muutoksia välimuistikäytäntöihin, joten se mikä pätee Zeniin, ei välttämättä päde Milaniin.

Se merkittävä muutos on juuri se CCXn koon tuplaaminen.

 

[mRkukov]

Ja millaisiakohan ne uudet käskykantalaajennokset oikein olisivat, millaisen järkevän semantiikan niille voisi oikein keksiä? Kun ei kuitenkaan tiedetä, kuka siellä toisella ytimellä on ajossa...

Yksi laajennos voisi olla "tee threadripper tyytyväiseksi".

 

[Threadripper]

Ei ole ydinkohtainen vaan kaikille CCXn ytimille yhteinen.

Että väärä vastaus.

Ja dataa haettaessa ei muutenkaan voida heti aluksi tietää, mistä se tulee löytymään. Pitää tarkastaa jokaisen wayn TAGit että tiedetään, mistä se löytyy.

Ei vaan ydinkohtainen JA jaettu. Yhdellä ytimellä CCX:ssa on tietty määrä L3 cachea kaikesta mutta kaikkien ytimien L3 cache on kaikkien ytimien kesken jaettu. Yhteinen välimuisti löytyy vaikka Core 2 Duosta, siinä ei ole mitään ydinkohtaista jakoa. Se on yhteinen.

AMD ei ole antanut mitään viitteitä siitä, että se olisi tekemässä jotain uutta x86 käskykantalaajennusta. Voihan sieltä sellainen toki tulla, joka sitten mahdollistaisi näiden ytimien välisen suoran kommunikaation.

En tiedä mitä taas yrität selittää mutta yleisesti ottaen mitä pidemmän matkan signaali joutuu kulkemaan, sitä kauemmin signaali kulkee. Kuten vaikka Intelin ring busista voi havaita.

 

[Kizmo]

Ei vaan ydinkohtainen JA jaettu. Yhdellä ytimellä CCX:ssa on tietty määrä L3 cachea kaikesta mutta kaikkien ytimien L3 cache on kaikkien ytimien kesken jaettu. Yhteinen välimuisti löytyy vaikka Core 2 Duosta, siinä ei ole mitään ydinkohtaista jakoa. Se on yhteinen.

Miten ajattelit tämmöisen toteuttaa käytännössä?

Ja miksi AMD tekisi jotain tämmöistä kun ZEN2 heikkous on juuri tuo CCX ryppäiden kesken jaettu L3? Näkyy aika makeasti latensseissa. Se, että joka ydin on samanarvoinen L3 koko kapasiteetin suhteen on pelkästään etu.

 

[hkultala]

Ei vaan ydinkohtainen JA jaettu. Yhdellä ytimellä CCX:ssa on tietty määrä L3 cachea kaikesta mutta kaikkien ytimien L3 cache on kaikkien ytimien kesken jaettu.

Höpöhöpö.

Se koko L3-välimuisti on ihan kaikkien ytimien yhteistä. Ja se sijaitsee juuri siinä ytimien välissä, jotta sinne on mahdollisimman lyhyt matka kaikilta ytimiltä.

Jos sinulla olisi yhtään hajua siitä, miten välimuistit toimivat, tajuaisit tämän, mutta kun on pihalla kuin lumiukko on helppo heitellä absurdeja väitteitä.

Ps. Suosittelen myös tutustumaan esim malleihin ryzen 5 1600, ryzen 5 1600X, ryzen 5 1500X. Niiden ydin- ja välimuistimääriin.

Yhteinen välimuisti löytyy vaikka Core 2 Duosta, siinä ei ole mitään ydinkohtaista jakoa. Se on yhteinen.

Se on ihan yhtä yhteinen kuin ryzeninkin L3-välimuisti. Väylärakenne miten se on kytketty on vaan hiukan erilainen.




Ja meni muutenkin nyt melkoiseksi maalitolppien siirtelyksi tämä. Kun et keksinyt, mitä liikennettä niiden ytimien välillä oikeasti voi olla, rupesit sotkemaan L3-välimuistia tähän mukaan, ja uudelleenmäärittelemään sitä, mitä ydin tarkoittaa.

L3-välimuisti ei ole osa ydintä. Ja matka kaikilta ytimiltä koko L3-välimuistille minimoidaan nimenomaan nykyisellä rakenteella.

 

[Threadripper]

Koko milan-paketissa on kahdeksan kappaletta niitä CCXiä. Kalliimmissa kuluttajakantaan tulevissa kuluttajamalleissakin tulee olemaan kaksi.

Ja muutenkin, luet nyt vanhaa optimointiopasta ja sen perusteella päättelet jotain tulevien prossujen rakenteesta?

Aika hyvin tiedät asiat yhden dian perusteella. Jossa ei edes sanota sanaakaan kuluttajamalleista

AMD on tehnyt ison työn saadakseen optimointeja prosessoreilleen. Miten sitä edistäisivät jatkuvat muutokset? Huonosti.

Kuten on sanottu jo hyvin selvästi, loogisesti siellä ei ole mitään kahta eri ryhmää sen enempää kuin nykyisten CCXien sisällä on kahta eir ryhmää. Se on vain fyysistä ytumien sijoittelua.

Ainoa mitä on tiedossa on yksi kuva. Ja sen perusteella luulet tietäväsi mitä tulee olemaan

Toteutus on yksi crossbar, jonka kautta kaikki on kytketty toisiinsa. Tällöin sillä ei ole merkitystä.

Entä jos on eri toteutus? Ring bus vaikka? Silloin sillä on merkitystä.

Miten ajattelit tämmöisen toteuttaa käytännössä?

Ja miksi AMD tekisi jotain tämmöistä kun ZEN2 heikkous on juuri tuo CCX ryppäiden kesken jaettu L3? Näkyy aika makeasti latensseissa. Se, että joka ydin on samanarvoinen L3 koko kapasiteetin suhteen on pelkästään etu.

Miksi pitäisi toteuttaa?

Höpöhöpö.

Se koko L3-välimuisti on ihan kaikkien ytimien yhteistä, eikä mitenkään "ydinkohtaista".

Jos sinulla olisi yhtään hajua siitä, miten välimuistit toimivat, tajuaisit tämän, mutta kun on pihalla kuin lumiukko on helppo heitellä absurdeja väitteitä.

Ps. Suosittelen myös tutustumaan esim malleihin ryzen 5 1600, ryzen 5 1600X, ryzen 5 1500X. Niiden ydin- ja välimuistimääriin.

Se L3 välimuisti on ytimessä kiinni, joten se on ydinkohtaista mutta jaettu kaikkien ytimien kesken.

Spekuloitu Zen2 IO die:n L4 cache (jota ei tullut) olisi yhteistä. Koska 1. ydinkohtaista välimuistia käyttää nopemmin (ainakin on mahdollista saada käyttämään) se ydin jonka yhteydessä se on 2. kaikki ytimet saavat käytettyä sitä yhtä nopeasti jos homma toteutetaan optimaalisesti.

 

[IcePen]

On siinä se järki ...

Ei ole, CCX ei ole jokin satunnainen maantieteellien alue jolla on satunaisesti mudostuneet rajat sen sijaan CCX on looginen toimintojen kokonaisuus ja yksi osa tuota kokonaisuutta on L3 muisti.

Jep, tässä nähdään kuinka jotkut saatuaan päähänsä jotain eivät millään voi myöntää olevansa väärässä.
...

 

[hkultala]

Aika hyvin tiedät asiat yhden dian perusteella.

Niitä slidejä oli kaksi kappaletta, ja tuo Milan-CCXien määrä paketissa kyllä kävi hyvin selväksi niistä.

Milanin ytimien määrä itseasiassa mainittiin molemmissa slideissä.

 

[Kizmo]

Ja kehityksen suunta on looginen, AMD:lle jaetusta L3:sta on vain haittaa. Varmasti jos pystyisivät niin CCX olisi 64 corea ja 256M L3 kaikille ytimille yhteinen.

 

[Threadripper]

Niitä slidejä oli kaksi kappaletta, ja tuo Milan-CCXien määrä paketissa kyllä kävi hyvin selväksi niistä.

Milanin ytimien määrä itseasiassa mainittiin molemmissa slideissä.

Koko milan-paketissa on kahdeksan kappaletta niitä CCXiä. Kalliimmissa kuluttajakantaan tulevissa kuluttajamalleissakin tulee olemaan kaksi.

Näen slideissä pelkkää Epycia.

 

[Kizmo]

Näen slideissä pelkkää Epycia.

Epyc Naples
Epyc Rome
Epyc Milan

 

[pomk]

Se L3 välimuisti on ytimessä kiinni, joten se on ydinkohtaista mutta jaettu kaikkien ytimien kesken.

Mistä olet lukenut että osa L3 välimuistista olisi ytimessä ’kiinni’ tai että se ei olisi kaikki saman CCX:n yhteisessä käytössä? Jos näin olisi (ei ole), niin esim. 6 ytimisissä zen prossuissa olisi vähemmän L3 cachea kuin 8 ytimisissä.

kirjoittelit myös, että missään ei lue etteikö milanissa olisi ringbus arkkitehtuuria.. nämä on just sellasia juttuja joista kerrottaisiin erittäin aikaisessa vaiheessa, sillä ne vaikuttavat voimakkaasti optimointistrategioihin, samoin kuin että CCX:n alle speksattaisiin joku uusi matalempi visuaaliseen layouttiin perustuva rakenne.

 

[Stephen Elop]

Jos nyt vaikka lähtis lukemaan tosta kappaleesta 4 eiäppäin http://ac.aua.am/arm/public/2017-Sp...mputerOrganizationAndDesign5thEdition2014.pdf.

Kyllå siellä ne kakutkin tulevat sitten vastaan ennen pitkää, niin asia selkenee. Olen tässä asian joukon/joukkion kannalla. Tarjoo tääkin keskustelu näinkin silti omat huvinsa

 

[Threadripper]

Epyc Naples
Epyc Rome
Epyc Milan

Kuluttajaprosessoreita?

Mistä olet lukenut että osa L3 välimuistista olisi ytimessä ’kiinni’ tai että se ei olisi kaikki saman CCX:n yhteisessä käytössä? Jos näin olisi (ei ole), niin esim. 6 ytimisissä zen prossuissa olisi vähemmän L3 cachea kuin 8 ytimisissä.

Se L3 on jaettu osiin, 1, 2 tai 4 megaa. Osat ovat ytimien vieressä eli käytännössä fyysisesti ytimessä kiinni. Ne cachethan ovat saman CCX:n käytössä ja vieläpä samalla latenssilla, sanoinko jossakin muuta? Mutta niinhän sen ei tarvitsisi olla, voitaisiin tarjota nopein pääsy siihen osaan joka on ydintä lähinnä.

Ekirjoittelit myös, että missään ei lue etteikö milanissa olisi ringbus arkkitehtuuria.. nämä on just sellasia juttuja joista kerrottaisiin erittäin aikaisessa vaiheessa, sillä ne vaikuttavat voimakkaasti optimointistrategioihin, samoin kuin että CCX:n alle speksattaisiin joku uusi matalempi visuaaliseen layouttiin perustuva rakenne.

Ring bus oli vain yksi esimerkki mahdollisesta muutoksesta, tässä vaiheessahan ei tiedetä edes sitä missä L3 välimuisti sijaitsee. Eikä se ole yksinkertaista. "32+" eli 64 MB cachea ytimiin jolla kisaisi Inteliä vastaan? Chiplet on noin 74 mm2. 16MB cache vie tilaa karkeasti 16mm2, ihanaa, 1mm2 per mega. 64 megaa veisi 64 mm2 tilaa ja chiplet olisi 122mm2. Se ei ole enää "pieni". Koska tuo slide koski vain ja ainoastaan Milania, olisiko mitään 58mm2 chiplet ja L3 cache I/O piiriin ja 64-ytimen CCX.

Juuri siihen optimointiin liittyen, AMD on toitottanut vuosia CCX:n olevan 4 ydintä ja CCX:a olevan 2. Mitä tapahtuu jos CCX:n koon edes kerrotaan olevan jotain muuta kuin 4? Siitä seuraa paljon negatiivisia asioita kehittäjiltä.

 

[vemkki]

Juuri siihen optimointiin liittyen, AMD on toitottanut vuosia CCX:n olevan 4 ydintä ja CCX:a olevan 2. Mitä tapahtuu jos CCX:n koon edes kerrotaan olevan jotain muuta kuin 4? Siitä seuraa paljon negatiivisia asioita kehittäjiltä.

Voisitko täsmentää, miksi CCX:n koon kasvaminen 8 ytimeen olisi ohjelmistokehittäjien kannalta huono juttu?

 

[pomk]

Se L3 on jaettu osiin, 1, 2 tai 4 megaa. Osat ovat ytimien vieressä eli käytännössä fyysisesti ytimessä kiinni. Ne cachethan ovat saman CCX:n käytössä ja vieläpä samalla latenssilla, sanoinko jossakin muuta? Mutta niinhän sen ei tarvitsisi olla, voitaisiin tarjota nopein pääsy siihen osaan joka on ydintä lähinnä.

Juuh, kantsii vähän lukea siitä miten eri cache-tasot toimivat. Vinkkinä, että saman tason cachea voi käyttää vain jos sen koko sisällön tarkistaa aina kun sieltä lukee jotakin. Cacheen kirjoitettaessa ei sen nopeudella ole mitään merkitystä.

CCX:ien koko on aivan alusta asti vaihdellut ainakin välillä 3-4. Mikä käytännön ongelma on laajentaa tätä skaalaa esim. kahdeksaan asti?

 

[Muumi75]

En tiedä mitä taas yrität selittää mutta yleisesti ottaen mitä pidemmän matkan signaali joutuu kulkemaan, sitä kauemmin signaali kulkee. Kuten vaikka Intelin ring busista voi havaita

Ring Bus ja Crossbar ovat kaksi eri asiaa. AMD:n käyttämästä Crossbarista emme saa todennäköisesti tietää koskaan kaikkia yksityiskohtia. Yhdysvalloissa kun voi patentoida aivan triviaaleja asioita.

Matkalla lohkojen välillä layoutissa ei ole juurikaan merkitystä tässä casessa vs Ringbus. Oletus on että hitaampi lenkki on L3 kontrollilogiikka kuin dataväylä "kauimmaiselle corelle". Ei tässä kuuhun asti olla menossa. Sillä on synkronisessa logiikassa merkitystä on ehtiikö data seuraavaan nousevaan/laskevaan kellonreunaan. Jätetääs tästä kuitenkin kellopuun balansointi, hajakapasitanssit ja parasiittiset ilmiöt pois yksinkertaisuuden vuoksi, ne ovat enemmän backend kaverien ongelmia.

tässä vaiheessahan ei tiedetä edes sitä missä L3 välimuisti sijaitsee

Arvaus: Eivät ole siirtämässä sitä IO-dielle.

 

[Apukuski]

Ihan välihuomautuksena, kun luen tätä vaikka moni asia menee yli oman osaamisen enkä siksi voi itse osallistua:

Threadripper vastaa asiallisesti argumentoi perustelee näkemyksen ja pohdinnan tulevasta ilman ylimääräistä ja henkilökohtaista huttua.

Hänen kanssaan/vastaan keskustelevat, joko alussa, keskellä tai lopussa, viljelee näitä lapsellisia emoji naamoja tai "höpöhöpö" "lopeta jo" "mene lukemaan/opettelemaan" ym turhaa huttua, joka tekee ikävää luottevaa keskustelusta joka voisi muuten olla asiallinen ja opettava.

Esim. hkultala ei ole yhtä ainoaa viestiä pystynyt kirjoittamaan ilman jotain edellä mainituista, yleensä ei ilman useampaa

 

[Threadripper]

Juuh, kantsii vähän lukea siitä miten eri cache-tasot toimivat. Vinkkinä, että saman tason cachea voi käyttää vain jos sen koko sisällön tarkistaa aina kun sieltä lukee jotakin. Cacheen kirjoitettaessa ei sen nopeudella ole mitään merkitystä.

Miten tämä liittyy siihen ettei cachen nopeus voi riippua siitä mistä luetaan? Cachen latenssi voi olla erilainen riippuen siitä mikä ydin lukee mistä vaikka cache olisi jaettu kaikkien ytimien kesken.

CCX:ien koko on aivan alusta asti vaihdellut ainakin välillä 3-4. Mikä käytännön ongelma on laajentaa tätä skaalaa esim. kahdeksaan asti?

Se edellyttäisi ainakin jonkinlaisia muutoksia: Papermaster: AMD's 3rd-Gen Ryzen Core Complex Design Won’t Require New Optimizations

"The optimization that we worked with the industry as we first rolled out Ryzen was our core complex," Papermaster said, "We very successfully worked across the OS, with Windows and Linux, so there is a recognition of AMD’s core complex, and so you can really have your workloads leverage that organization. As we go forward into this next-generation with Zen 2-based products, we actually just make it easier because as you have cores going into a common I/O die, it is the same core complex approach that we had before, and you actually just have a very centralized path. In our server implementation all the way through the Ryzen implementation we showed today, it adds no complication whatsoever for the software providers. All the work we did with first-gen Ryzen will carry right over. All those optimizations carry right over."

Tuosta paistaa läpi se ettei AMD halunnut tehdä Zen2:n mitään sellaisia muutoksia Zen:n nähden joka edes vähäisessä määrin tekisi Zenille tehdyistä optimoinneista toimimattomia. AMD haluaa olla hyvissä väleissä ohjelmistopuolen kanssa, joten ymmärrettävää.

Ring Bus ja Crossbar ovat kaksi eri asiaa. AMD:n käyttämästä Crossbarista emme saa todennäköisesti tietää koskaan kaikkia yksityiskohtia. Yhdysvalloissa kun voi patentoida aivan triviaaleja asioita.

Matkalla lohkojen välillä layoutissa ei ole juurikaan merkitystä tässä casessa vs Ringbus. Oletus on että hitaampi lenkki on L3 kontrollilogiikka kuin dataväylä "kauimmaiselle corelle". Ei tässä kuuhun asti olla menossa. Sillä on synkronisessa logiikassa merkitystä on ehtiikö data seuraavaan nousevaan/laskevaan kellonreunaan. Jätetääs tästä kuitenkin kellopuun balansointi, hajakapasitanssit ja parasiittiset ilmiöt pois yksinkertaisuuden vuoksi, ne ovat enemmän backend kaverien ongelmia.


Arvaus: Eivät ole siirtämässä sitä IO-dielle.

Ring busin otin esiin koska se on loistava esimerkki matkan vaikutuksesta nopeuteen. Kaikissa tilanteissahan nopeus ei ole kaikki kaikessa eikä aina edes haeta nopeinta ratkaisua koska usein on pakko valita paras kompromissi. USA:n patenteista joku muu tietää paremmin. Sen perusteella mitä olen lukenut, ei harmita.

Ring bus tarjoaisi vaihtoehdon L3:n kautta kiertämiselle, ja lyhyenä (vähän ytimiä) se todennäköisesti olisi nopeampikin. Miten se kannattaisi transistorikulutuksen ja muiden kannalta on toinen juttu. Todennäköisesti kokonaisuutena ei.

Se missä AMD ei tällä hetkellä pärjää on kuormat jotka haluavat paljon välimuistia. Chipletteihin L3:n lisääminen se nostaa valmistuskustannuksia radikaalisti. Erillinen suuri L3 cache (ja ehkä jopa L3 cache pois chipleteistä jotta säästöä) voisi antaa tietyissä kuormissa Intelille kunnolla kyytiä. Kotikäytössä joku 32+ MB L3 olisi mukava, hieman vaikea uskoa sellaista tuotavan ainakaan massamalleihin. Vaikuttaisi oudolta ratkaisulta valmistaa vain yhtä chiplettiä. Sellaista jossa jättimäinen L3 cache

 

[Muumi75]

Ring busin otin esiin koska se on loistava esimerkki matkan vaikutuksesta nopeuteen. Kaikissa tilanteissahan nopeus ei ole kaikki kaikessa eikä aina edes haeta nopeinta ratkaisua koska usein on pakko valita paras kompromissi. USA:n patenteista joku muu tietää paremmin. Sen perusteella mitä olen lukenut, ei harmita.

Mitä tarkoitat matkalla? Fyysistä etäisyyttä? Vai sitä että jokaisessa ringin nodessa on logiikkaa jonka kautta väylä kulkee? Logiikka: lisää kellojaksoja ja latenssia.

 

[hkultala]

Ihan välihuomautuksena, kun luen tätä vaikka moni asia menee yli oman osaamisen enkä siksi voi itse osallistua:

Threadripper vastaa asiallisesti argumentoi perustelee näkemyksen ja pohdinnan tulevasta ilman ylimääräistä ja henkilökohtaista huttua

Niissä argumenteissa ei vaan ole päätä eikä häntää, ja sen tajuaa jos tietää yhtään mitään tietokonetekniikasta.

Ja maalitolppien siirtely ei muutenkaan ole asiallista argumentointia.

Hänen kanssaan/vastaan keskustelevat, joko alussa, keskellä tai lopussa, viljelee näitä lapsellisia emoji naamoja tai "höpöhöpö" "lopeta jo" "mene lukemaan/opettelemaan" ym turhaa huttua, joka tekee ikävää luottevaa keskustelusta joka voisi muuten olla asiallinen ja opettavava

Kun toisen ymmärrys asioista on kolmivuotiaan tasolla ja kyky myöntää sitä puhtaat nolla, siinä missä toiset ovat oikeasti suunnitelleet prosessoreita niin kyllä siinä alkaa hermo mennä tuohon inttämiseen.

dunning-krueger on hyvin vahvoilla tässä.

Esim. hkultala ei ole yhtä ainoaa viestiä pystynyt kirjoittamaan ilman jotain edellä mainituista, yleensä ei ilman useampaa

Olenpas, esim eilen klo 00.01 kirjoittamani viesti.
Jolloin sinä syyllistyt valehteluun tuossa väitteessäsi.

 

[pomk]

Miten tämä liittyy siihen ettei cachen nopeus voi riippua siitä mistä luetaan? Cachen latenssi voi olla erilainen riippuen siitä mikä ydin lukee mistä vaikka cache olisi jaettu kaikkien ytimien kesken.

Ainakaan tuossa kuvatussa symmetrisessä rakenteessa on vaikea kuvitella merkittäviä eroja ytimien L3 latenssien välille, vai pystytkö piirtämään yhdeltä ytimeltä L3 muistin siitä kauimpaan kulmaan kuin joltain toiselta ytimeltä? Et, sillä rakenne on symmetrinen näiden etäisyyksien ja siten L3 latenssin suhteen. Edelleenkin, jotta L3 välimuistista voi lukea jotakin, pitää kaikkien CCX:ien L3 välimuistit koluta läpi jopa toisia chiplettejä myöten. Jos tässä on jotakin epäselvää, niin kannattaa ihan oikeasti hieman tutustua cache-hierarkiaan ja miten se toimii. Youtubesta löytyy pari hyvää n. tunnin luentoa jotka voin linkata jos kiinnostaa.

Etenkin serveriprossuissa, joissa ytimet jatkossakin sijaitsevat eri chipleteillä, yhden CCX:n L3 latenssien eroilla ei olisi mitään vaikutusta, sillä pisin etäisyys ja latenssi on kuitenkin jonkun toisen chipletin kauimmaiseen L3 välimuistin nurkkaan.

Tuosta paistaa läpi se ettei AMD halunnut tehdä Zen2:n mitään sellaisia muutoksia Zen:n nähden joka edes vähäisessä määrin tekisi Zenille tehdyistä optimoinneista toimimattomia. AMD haluaa olla hyvissä väleissä ohjelmistopuolen kanssa, joten ymmärrettävää.

Alleviivaisitko vielä sen kohdan joka vaikuttaa optimointeihin CCX:n (maksimi)kokoa muutettaessa. Jo nyt ne on erikokoisia riippuen prosessorimallista. Onhan se mahdollista että jotain optimointeja on kovakoodattu toimimaan vain kun n{3,4}, mutta se on nopeasti korjattu.

Kotikäytössä joku 32+ MB L3 olisi mukava, hieman vaikea uskoa sellaista tuotavan ainakaan massamalleihin. Vaikuttaisi oudolta ratkaisulta valmistaa vain yhtä chiplettiä. Sellaista jossa jättimäinen L3 cache

Nykyiset Zen2 chipletit sisältävät jo 32MB L3 cachea. Piirin koon ei tarvitse muuttua L3 cachejen yhdistyessä, vaan se saattaa jopa kutistua milanissa, kun siirrytään samalla uudempaan valmistustekniikkaan.

 

[hkultala]

Hieno esimerkki virkkeestä, johon saatu kaksi perustavanlaatuista virhettä/väärinkäsitystä tietokonetekniikan asioista.

Ring bus tarjoaisi vaihtoehdon L3:n kautta kiertämiselle

mitä sieltä kiertäisi? Mitä se liikenne olisi? Minkä seurauksena se liikenne tapahtuisi?

Prosessori tekee sen mitä suorittamat käskyt sen käskee tekemään.

Kuten tässä ollaan pomkin kanssa jo monta kertaa sanottu, x86-käskykannassa ei ole mitään sellaisia käskyjä jotka toimisivat tyyliin "siirrä tämä data tuolle toiselle ytimelle".

Edelleenkään et ole tarjonnut mitään (toimivaa) vastausta tähän kysymykseen vaikka sitä kysyin jo kauan sitten.

Höpiset vaan jostain ydinten välisestä kommuunikaatiosta tajuamatta yhtään, mitä se on. Tajuamatta yhtään, miten ne oikeasti kommunikoivat keskenään.

, ja lyhyenä (vähän ytimiä) se todennäköisesti olisi nopeampikin.

Crossbar on nimenomaan se nopein tapa kytkeä pienehkö määrä asioita yhteen. Kaikkialta pääsee kaikkialle ilman mitään välihyppyjä, ja eri asioiden välillä voidaan tehdä yhtäaikaisia siirtoja.


Sitten kun kytkettävien asioiden määrä kasvaa liian suureksi, crossbarista tulisi liian iso(pinta-alaltaan, virrankulutukseltaan) ja myös data rate alkaisi hidastua jossain vaiheessa. Crossbarista joudutaan käytännössä pakon edessä siirtymään pois kun kytkentämäärä kasvaa liian suureksi.

 

[Teuras]

Onpas taas tuottavaa, eikä siinä popparit kourassa ja lueskellaan, miten vaikeaksi noinkin simppeli muutos paperilla saadaan tehtyä. #hyvääviidettä

Terkuin se kaveri mikä ei vieläkään ymmärrä mistään, mistä täällä puhutaan.

 

[hkultala]

Se edellyttäisi ainakin jonkinlaisia muutoksia: Papermaster: AMD's 3rd-Gen Ryzen Core Complex Design Won’t Require New Optimizations

Eikä edellytä.

Meillä on jo nyt myös kahden ja kolmen ytimen CCXiä eikä pelkästään neljän ytimen CCXiä, ja se, että ydinten määrä CCXssä kasvaa vain helpottaa asioita; Kaikki se koodi, joka on optimoitu neljän ytimen CCXlle toimii vähintään yhtä hyvin kahdeksan ytimen CCXllä.

Hidastumista tulee siitä, että joku säie haluaa lukea dataa, josta on likainen kopio eri CCXn välimuistissa, tai haluaa ylikirjoittaa dataa, josta on likainen kopioi eri CCXn välimuistissa (kuin sen CCXn, missä se itse on ajossa).

Se, että yhdessä CCXssä on enemmän ytimiä ei aiheuta tätä ongelmaa; Päin vastoin, se vaan harventaa sitä.

Tuosta paistaa läpi se ettei AMD halunnut tehdä Zen2:n mitään sellaisia muutoksia Zen:n nähden joka edes vähäisessä määrin tekisi Zenille tehdyistä optimoinneista toimimattomia. AMD haluaa olla hyvissä väleissä ohjelmistopuolen kanssa, joten ymmärrettävää.

.. Ja siirtyminen kahdeksan ytimen CCXään ei riko yhtään mitään zen-optimointeja. Tämäkin on triviaali asia, kun ymmärtää niistä optimoinneista yhtään mitään.

Se missä AMD ei tällä hetkellä pärjää on kuormat jotka haluavat paljon välimuistia.

Ei, vaan ne on ne kuormat joilla zen2 nimenomaan pärjää HYVIN.

Chipletteihin L3:n lisääminen se nostaa valmistuskustannuksia radikaalisti.

Jälleen kerran väärin.
Välimuistit tehdään SRAMista, ja SRAM skaalautuu erinomaisesti valmistusprosessin pienentyessä.

TSMCn "7nm" tekniikalla tehty HD-SRAM-solu on pinta-alaltaan 0.027 um^2.
Globalfoundriesin "14nm" tekniikalla tehty HD-SRAM-solu on pinta-alaltaan 0.064 yum^2.

Eli välimuisti "7nm" tekniikalla tehtynä vie mukavasti n. 42% siitä pinta-alasta mitä se veisi GFn "14nm" prosessilla. "7nm" valmistusprosessin hinta pinta-alaa kohden on käsittääkseni alle 2.37-kertainen "14nm" prosessin hinnasta, eli välimuisti tulee halvemmaksi ydin-chipletillä kuin IO-chipletillä.

Erillinen suuri L3 cache (ja ehkä jopa L3 cache pois chipleteistä jotta säästöä) voisi antaa tietyissä kuormissa Intelille kunnolla kyytiä. Kotikäytössä joku 32+ MB L3 olisi mukava, hieman vaikea uskoa sellaista tuotavan ainakaan massamalleihin. Vaikuttaisi oudolta ratkaisulta valmistaa vain yhtä chiplettiä. Sellaista jossa jättimäinen L3 cache

Hieno heitellä hatusta tällaisia ymmärtämättä kokonaiskuvaa.

Jos siellä olisi joku "erillinen suuri L3 cache" ei se olisi L3-cache vaan L4-cache, mikäli niillä chipleteillä olisi edelleen L3-cache.

Ja sen olemassaolo myös hiukan hidastaisi muistiaccesseja DRAMiin, koska tieto siitä, tarviiko muistiaccess tehdä selviää vasta kun ollaan tarkastettu, löytyykö dataa ulomman tason välimuistista (joka tarkastetaan vasta sen jälkeen kun on ensin tarkastettu toiseksi ulomman tason välimuisti, joka tarkastetaan vasta sen jälkeen, kun on ensin tarkastettu kolmanneksi ulomman tason välimuisti jne)


ja mikäli niillä chipleteillä taas ei olisi edelleen L3-välimuistia, sitten L2-huti olisi hyvin hidas koska sen "erillisen suuren cachen" viive on todella paljon hitaampi kun sen lähellä CCXssä olevn L3-kakun, ja lisäksi kaistaa chiplettien välillä tarvittaisiin paljon enemmän.

Intelin prossujen (joilla on kaikille ytimille yhteinen L3) L3-viive on selvästi suurempi kuin zenin L3-viive, vaikka intelin prossuissa se L3 on edelleen samalla piilastulla.

 

[Mechanical Man]

Kaikki pääsisi helpommalla kun laittaisitte threadripperin ignoreen mihin kuuluu

 

[demu]

Niissä argumenteissa ei vaan ole päätä eikä häntää, ja sen tajuaa jos tietää yhtään mitään tietokonetekniikasta.

Ja maalitolppien siirtely ei muutenkaan ole asiallista argumentointia.



Kun toisen ymmärrys asioista on kolmivuotiaan tasolla ja kyky myöntää sitä puhtaat nolla, siinä missä toiset ovat oikeasti suunnitelleet prosessoreita niin kyllä siinä alkaa hermo mennä tuohon inttämiseen.

dunning-krueger on hyvin vahvoilla tässä.



Olenpas, esim eilen klo 00.01 kirjoittamani viesti.
Jolloin sinä syyllistyt valehteluun tuossa väitteessäsi.

En väitä olevani mikroprosessoreiden asiantuntija, vaikka aikanaan olenkin elektroniikan harjoitustyönä suunnitellut binääritason tilakoneesta alkaen, ohjelmoinut, simuloinut ja toteuttanut FBGA-toteutuksena yhden pienen (ei ohjelmoitavan) mikropiirin (tai oikeastaan selaisen osasen).
Yhdellä aika pitkällä kurssilla suunnittelimme myös mikroprosessorin arkkitehtuurin jokseenkin yleisellä tasolla. Sen verran muutakin koulutusta digitaalisten mikropiirien suunittelusta kuitenkin hankin, että diplomityöni rahoituksen viivästyminen Suomen Akatemialta vaikutti kauan kauan sitten uravalintaani niin suuntaavasti, että ajauduin mikropiirisuunnittelun sijaan teletoimialalle erilaisiin ohjemisto- ja asiantuntijatehtäviin.

Vaikka tästä koulun penkillä istumisesta on kulunut jo liki 30 vuotta, olen kohtuullisen yleisella harrastustasolla pyrkinyt seuraamaan erityisesti CPUiden arkkitehtuurin kehittymistä.

Niin etevä en kylläkään ole, että osaisin vahvasti argumentoida kaikkia tämän foorumin väittelyissä käytyjä mielipiteitä, mutta sen verran ymmärrän, että osaan perustellusti todeta hkultalan osaamisen näissä keskusteluissa olevan merkittävästi useimpia foorumilaisia edistyneemmällä tasolla.

Sitten on näitä muita keskustelijoita - kuten tämän keskustelun haaran kohteena oleva henkilö - joiden osaaminen - kaikella kunnioituksella - tuntuu olevan eri web-sivustojen uutispalstojen kommenttikenttien perusteella johdettua 'omaa asiantuntemusta'.
Jos osaamisen taso on sitä, että arvioidaan jonkin komponentin (esim. ccx-blokin) toimintaa ja arkkitehtuuria powerpoint -kalvosta kaapatun merkittävästi yksinkertaistetun graafisen kuvan perusteella, lisätään siihen omia ja sekalaisten nettipalstojen / foorumeiden 'asiantuntijoiden mielipiteitä/spekulointeja/toiveita', ei lopputuloksen voikkaan olettaa olevan muuta kuin tässä edellä esitetyt - sanotaan suoraan haihattelut.

Väkisin vänkäämisen ja väärin perustein tapahtuvan argumentoinnin sijaan kannattaisi vaikka kysellä tyyliin 'voisiko tämän xxx-ratkaisun suunnitella tai toteuttaa vaikka tällä tavalla', tai 'toimiiko tuo niin, että...'.
Näihin osaavat ihmiset varmaan vastaavat mielellään.

Kaikkea AMD/Intel/nVidia/jne. eivät toki kerro yksityiskohtaisesti noissa julkistetuissa tai vuotaneissakaan kalvoissa edes kumppaneilleen tai tutkijapiireille, joten aina sinne jää epäselviä asioita pohdittavaksi foorumeillekin.

 

[hsalonen]

Näyttää kovasti siltä, että kun joskus tulevaisuudessa @hkultala on väärässä, niin puoli foorumia ei uskalla hänelle siitä sanoa yhtään mitään ja yhtyy väärään olettamukseen.

Tässä kuitenkin @Threadripper on väärässä ja @hkultala yrittää selittää asioiden oikeaa kantaa, mutta se ei mene perille. Sivustakatsojana tästä tulee vähän tylsää ekan sivun jälkeen.

Keskustelu ja väittely tietotekniikkafoorumilla on kivaa, mutta tässä on taas vähän liikaa "painavaa tekstiä" ja osa siitä on spekuloitu puuttellisesta datasta. @demu sanoi, että voisi kysyä kohteliaasti mielipidettä, mutta paljon helpommin saa asioita hkultalasta irti, kun on vaan suoraan väärässä ja esittää asian faktana.

--

Itse artikkelista bongasin vain CCX:n kaksinkertaistumisen, muut tiedot ei itselle riitä tarkempaan spekulaatioon. Ehkä tulevaisuudessa 8-ydin CCX on uusi minimi. Vaikea kuvitella, että siitä sitten disabloidaan coreja hirveästi, että saadaan niitä halpisprosessoreita. Ehkä uusi standardi on 6 ydintä minimi ja vähemmällä ei uudet AAA-julkaisut pyöri?

 

[zepi]

AMD:ltä on tulossa 7nm APU, joka on joka tapauksessa aivan eri layouttiin perustuva tuote ja joka täyttää desktopilla nimenomaan noita hintaluokkia missä nyt on noita leikatumpia piirejä.

 

[Kaotik]

Itse artikkelista bongasin vain CCX:n kaksinkertaistumisen, muut tiedot ei itselle riitä tarkempaan spekulaatioon. Ehkä tulevaisuudessa 8-ydin CCX on uusi minimi. Vaikea kuvitella, että siitä sitten disabloidaan coreja hirveästi, että saadaan niitä halpisprosessoreita. Ehkä uusi standardi on 6 ydintä minimi ja vähemmällä ei uudet AAA-julkaisut pyöri?

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.

 

[L2K2]

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.

Itse asiassa ytimiä voinee poistaa (mahdollisesti) jopa nykyistä monipuolisemmin, kun noissa nykyisissä näyttäisi olevan sama määrä ytimiä kussakin CCX. Toki esimerkiksi jotain 7-ydinprosessoreita epäilen suuresti koskaan markkinoille tuotavan.

Toki vaikea sanoa miten ne yli 8 ytimen olevat (mutta silti vajaat) prosessorit kannattaa tehdä. Yksi hyvä täysi siru ja sen kaveriksi ja yksi huono siru tuottaisi sellaisia nVidian näyttömuistikikkailufiiliksiä, kun se skaalautuminen tietyn ydinmäärän jälkeen olisikin selvästi huonompaa.

Näyttää kovasti siltä, että kun joskus tulevaisuudessa @hkultala on väärässä, niin puoli foorumia ei uskalla hänelle siitä sanoa yhtään mitään ja yhtyy väärään olettamukseen.

Millä perusteella? Kyllä tässäkin ketjussa näyttäisi olevan usempi kirjoittelija, joka olisi sanonut vastaan sille väärässä olevalle osapuolelle, riippumatta kumpi se tässä oli.

 

[vemkki]

Toki vaikea sanoa miten ne yli 8 ytimen olevat (mutta silti vajaat) prosessorit kannattaa tehdä. Yksi hyvä täysi siru ja sen kaveriksi ja yksi huono siru tuottaisi sellaisia nVidian näyttömuistikikkailufiiliksiä, kun se skaalautuminen tietyn ydinmäärän jälkeen olisikin selvästi huonompaa.

Miten tilanne eroaisi nykyisestä? 3900X:ssä on kaksi chiplettiä, joissa on 6+6 ydintä, 3950X:ssä 8+8 ydintä. Neljän toimivan ytimen chipletit menevät halpisprosuihin. Jos toimivia ytimiä on vähemmän, menee siru roskiin.

 

[Stephen Elop]

Miten tilanne eroaisi nykyisestä? 3900X:ssä on kaksi chiplettiä, joissa on 6+6 ydintä, 3950X:ssä 8+8 ydintä. Neljän toimivan ytimen chipletit menevät halpisprosuihin. Jos toimivia ytimiä on vähemmän, menee siru roskiin.

Tuossa nyt ajettiin takaa sitä että 3900 on 6+6 eikä esimerkiksi 8+4, jolloin toisen chipletin 4 ydintä saisi enemmän L3 cachea verrattuna 8 ytimen chiplettiin.

 

[hkultala]

Tuossa nyt ajettiin takaa sitä että 3900 on 6+6 eikä esimerkiksi 8+4, jolloin toisen chipletin 4 ydintä saisi enemmän L3 cachea verrattuna 8 ytimen chiplettiin.

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

 

[Threadripper]

Mitä tarkoitat matkalla? Fyysistä etäisyyttä? Vai sitä että jokaisessa ringin nodessa on logiikkaa jonka kautta väylä kulkee? Logiikka: lisää kellojaksoja ja latenssia.

Fyysistä etäisyyttä. Esim. Bulldozerin L2 cachea on haukuttu (aiheesta) hitaaksi. Syynä lienee fyysinen etäisyys.

Ainakaan tuossa kuvatussa symmetrisessä rakenteessa on vaikea kuvitella merkittäviä eroja ytimien L3 latenssien välille, vai pystytkö piirtämään yhdeltä ytimeltä L3 muistin siitä kauimpaan kulmaan kuin joltain toiselta ytimeltä? Et, sillä rakenne on symmetrinen näiden etäisyyksien ja siten L3 latenssin suhteen. Edelleenkin, jotta L3 välimuistista voi lukea jotakin, pitää kaikkien CCX:ien L3 välimuistit koluta läpi jopa toisia chiplettejä myöten. Jos tässä on jotakin epäselvää, niin kannattaa ihan oikeasti hieman tutustua cache-hierarkiaan ja miten se toimii. Youtubesta löytyy pari hyvää n. tunnin luentoa jotka voin linkata jos kiinnostaa.

Ei suurta eroa, mutta eroa kuitenkin. Aika pienestä pitää nykyisin puristaa suorituskyvyn rippeitä.

Anna ihmeessä lisätietoa tuosta lihavoidusta. Alkoi kiinnostamaan. Esim. linkki johonkin artikkeliin.

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

L3 latency is significantly reduced from around 36 cycles in Westmere to 26 - 31 cycles in Sandy Bridge. We saw this in our Sandy Bridge preview and now have absolute numbers in hand. The variable cache latency has to do with what core is accessing what slice of cache.

Etenkin serveriprossuissa, joissa ytimet jatkossakin sijaitsevat eri chipleteillä, yhden CCX:n L3 latenssien eroilla ei olisi mitään vaikutusta, sillä pisin etäisyys ja latenssi on kuitenkin jonkun toisen chipletin kauimmaiseen L3 välimuistin nurkkaan.

Samat sanat tähän kuin edelliseen. Kuulostaa mielenkiintoiselta ratkaisulta hakea tietoa cachesta jota ei ole jaettu.

Alleviivaisitko vielä sen kohdan joka vaikuttaa optimointeihin CCX:n (maksimi)kokoa muutettaessa. Jo nyt ne on erikokoisia riippuen prosessorimallista. Onhan se mahdollista että jotain optimointeja on kovakoodattu toimimaan vain kun n{3,4}, mutta se on nopeasti korjattu.

Perussääntö muuttuu. Nyt ei voi mennä pahasti pieleen jos kuorma jaetaan CCX:n sisällä. Tuon muutoksen jälkeen saattaa voida (ei tiedetä tarkasti tässä vaiheessa). Eli nyt riittää yksi perussääntö, muutoksen jälkeen ei välttämättä. Lisäksi Papermaster korosti ettei mitään muutoksia tehty CCX rakenteeseen jotta mitään muutoksia ohjelmissakaan ei tarvittaisi. Eli AMD:n mielestä CCX:n muutos olisi aiheuttanut muutostarpeen ohjelmistoihin.

Maailmassa on hirveä kasa kovokoodattuja asioita jotka OLISI nopeasti korjattu. Kuka ne korjaa ja milloin on täysin toinen juttu.

Nykyiset Zen2 chipletit sisältävät jo 32MB L3 cachea. Piirin koon ei tarvitse muuttua L3 cachejen yhdistyessä, vaan se saattaa jopa kutistua milanissa, kun siirrytään samalla uudempaan valmistustekniikkaan.

Niin, 32+ MB joka tietenkin voi olla lähes mitä tahansa. TSMC lupaa 15% säästöä pinta-alassa. 64MB cachella tuskin pienenee.

Hieno esimerkki virkkeestä, johon saatu kaksi perustavanlaatuista virhettä/väärinkäsitystä tietokonetekniikan asioista.

mitä sieltä kiertäisi? Mitä se liikenne olisi? Minkä seurauksena se liikenne tapahtuisi?

Prosessori tekee sen mitä suorittamat käskyt sen käskee tekemään.

Kuten tässä ollaan pomkin kanssa jo monta kertaa sanottu, x86-käskykannassa ei ole mitään sellaisia käskyjä jotka toimisivat tyyliin "siirrä tämä data tuolle toiselle ytimelle".

Edelleenkään et ole tarjonnut mitään (toimivaa) vastausta tähän kysymykseen vaikka sitä kysyin jo kauan sitten.

Höpiset vaan jostain ydinten välisestä kommuunikaatiosta tajuamatta yhtään, mitä se on. Tajuamatta yhtään, miten ne oikeasti kommunikoivat keskenään.

x86 prosessorissa ei tietääkseni ole käskyjä monelle asialle, kuten lataa Windows ja käynnistä pasianssi. En sitten tiedä hoidetaanko se jollakin dokumentoimattomalla erikoiskäskyllä, kun en itsekään löytänyt sellaista käskyä. Jossain täytyisi olla kattavampi lista prosessorin tukemistä käskyistä, niin tietäisi mitä kaikkia ohjelmia nykyprosessorit pystyvät käynnistämään.

Vitsit vitsinä, jatketaan vihdoin sillä alkuperäisellä aiheella, eli 8-core CCX: http://developer.amd.com/wp-content/resources/56420.pdf

Within each Zeppelin there are 2 Compute Complexes (CCX). Each CCX has•its own L3 cache. Each core has its own L2 and L1i and L1d caches•up to 4 cores per CCX, i.e. 32 cores per socket. Other EPYCcore counts follow

Tuossa annetaan linjaus jonka mukaan CCX:ssa on maksimissaan 4 corea. Siten CCX:ssa ei voi olla yli 4 corea. Lähteenä on AMD:n virallinen dokumentti 12/2018.

Mikä taho päättää CCX:n määritelmän? CCX ei ole käytössä muissa kuin AMD:n prosessoreissa eivätkä muut tahot kuin AMD sitä tuotteissaan käytä. Siten se taho joka määrittelee miten CCX määritellään on AMD.

Koska CCX:ssa ei voi olla yli 4 ydintä, CCX:ssa ei voi olla 8 ydintä. Se on tilanne tällä hetkellä.

Voit täysin vapaasti spekuloida tilanteen olevan erilainen Milanin julkaisun hetkellä tai ennen sitä. Mutta juuri nyt tilanne on se ettei CCX:ssa voi olla yli 4 ydintä. Tietysti voit esittää vastaavan dokumentin, AMD:n työntekijän lausunnon tai AMD:n julkaiseman kuvan jossa kerrotaan jotain muuta. Sitä odotellessa.

Eikä edellytä.

Edellyttää mikäli on aiemmin mainittua termiä käyttäen kovokoodattu 4-core CCX:n mukaan.

Meillä on jo nyt myös kahden ja kolmen ytimen CCXiä eikä pelkästään neljän ytimen CCXiä, ja se, että ydinten määrä CCXssä kasvaa vain helpottaa asioita; Kaikki se koodi, joka on optimoitu neljän ytimen CCXlle toimii vähintään yhtä hyvin kahdeksan ytimen CCXllä.

Hidastumista tulee siitä, että joku säie haluaa lukea dataa, josta on likainen kopio eri CCXn välimuistissa, tai haluaa ylikirjoittaa dataa, josta on likainen kopioi eri CCXn välimuistissa (kuin sen CCXn, missä se itse on ajossa).

Se, että yhdessä CCXssä on enemmän ytimiä ei aiheuta tätä ongelmaa; Päin vastoin, se vaan harventaa sitä.

Toimii jos ne 8 ydintä ovat keskenään suunnilleen "samanarvoiset", ts. on lähes se ja sama miten kuorma niiden kesken jaetaan. Jos niin ei ole, ongelmat ovat taattuja koska kaikki eivät kuitenkaan heti ymmärrä vaihtaa toimintatapojaan vaan muistavan sen slogania jota AMD on vuosia toitottanut: täytä yksi CCX ensin.

.. Ja siirtyminen kahdeksan ytimen CCXään ei riko yhtään mitään zen-optimointeja. Tämäkin on triviaali asia, kun ymmärtää niistä optimoinneista yhtään mitään.

Jos kuormanjaolla ytimien kesken ei ole merkitystä, sitten ei. Jos on, sitten tulee ongelmia. Vielä kerran se yleissääntö: täytä yksi CCX ensin. Jos CCX:a on yksi ja CCX on 4-ytiminen, ei voi mennä pahasti pieleen tällä säännöllä. Jos CCX:a on yksi ja CCX on 8-ytiminen JA kuormanjaolla on merkitystä, joku mokaa satavarmasti jossakin vaiheessa.

Kun et kerran minua usko, otetaan AMD:n edustajan mielipide asiaan:

The optimization that we worked with the industry as we first rolled out Ryzen was our core complex," Papermaster said, "We very successfully worked across the OS, with Windows and Linux, so there is a recognition of AMD’s core complex, and so you can really have your workloads leverage that organization. As we go forward into this next-generation with Zen 2-based products, we actually just make it easier because as you have cores going into a common I/O die, it is the same core complex approach that we had before, and you actually just have a very centralized path. In our server implementation all the way through the Ryzen implementation we showed today, it adds no complication whatsoever for the software providers. All the work we did with first-gen Ryzen will carry right over. All those optimizations carry right over.

Eli ratkaiseva asia on CCX ja kun se on SAMA CCX kuin aiemmin, ei tarvita optimointeja.

Ei, vaan ne on ne kuormat joilla zen2 nimenomaan pärjää HYVIN.

Eikä pärjää. Kun sanoin paljon cachea tarkoitin paljon, eli 50+ MB jaettua kaikkien ytimien kesken.

Jälleen kerran väärin.
Välimuistit tehdään SRAMista, ja SRAM skaalautuu erinomaisesti valmistusprosessin pienentyessä.

TSMCn "7nm" tekniikalla tehty HD-SRAM-solu on pinta-alaltaan 0.027 um^2.
Globalfoundriesin "14nm" tekniikalla tehty HD-SRAM-solu on pinta-alaltaan 0.064 yum^2.

Eli välimuisti "7nm" tekniikalla tehtynä vie mukavasti n. 42% siitä pinta-alasta mitä se veisi GFn "14nm" prosessilla. "7nm" valmistusprosessin hinta pinta-alaa kohden on käsittääkseni alle 2.37-kertainen "14nm" prosessin hinnasta, eli välimuisti tulee halvemmaksi ydin-chipletillä kuin IO-chipletillä.

Tuohon vaikuttavat myös saannot (joista ei tarkkaa tietoa) ja kun vielä huomioidaan ettei AMD tälläkään hetkellä tee kuin yhtä ainoaa chiplettiä mutta tekee kahta eri I/O piiriä kahdella eri prosessilla, niin en olisi ihan varma.

Tarkistaisin nuo välimuistien todelliset koot prosessoreissa mutta en löytänyt kunnollista Zen2 die shottia.

Hieno heitellä hatusta tällaisia ymmärtämättä kokonaiskuvaa.

Jos siellä olisi joku "erillinen suuri L3 cache" ei se olisi L3-cache vaan L4-cache, mikäli niillä chipleteillä olisi edelleen L3-cache.

Sanoinkin "ehkä jopa L3 cache pois chipleteistä jotta säästöä". Silloin se olisi L3 cache.

Ja sen olemassaolo myös hiukan hidastaisi muistiaccesseja DRAMiin, koska tieto siitä, tarviiko muistiaccess tehdä selviää vasta kun ollaan tarkastettu, löytyykö dataa ulomman tason välimuistista (joka tarkastetaan vasta sen jälkeen kun on ensin tarkastettu toiseksi ulomman tason välimuisti, joka tarkastetaan vasta sen jälkeen, kun on ensin tarkastettu kolmanneksi ulomman tason välimuisti jne)

ja mikäli niillä chipleteillä taas ei olisi edelleen L3-välimuistia, sitten L2-huti olisi hyvin hidas koska sen "erillisen suuren cachen" viive on todella paljon hitaampi kun sen lähellä CCXssä olevn L3-kakun, ja lisäksi kaistaa chiplettien välillä tarvittaisiin paljon enemmän.

Kokonaiskuvaa katsoen, miksi AMD on julkaissut pelkästään Zen2-prosessoreita joissa on täysi L3 cache. Vai onko tullut muita? Kai niitä cachevikaisiakin tulee, sopisivat tuohon hyvin. En todellakaan usko kaikkien pikkuvikaisten prosessorien olevan sellaisia joissa nimenomaan cache toimii täysin.

Nämä prosessorit olisi tarkoitettu niitä prosessoreita vastaan joille AMD:lla ei ole vastinetta. Niitä joissa on paljon cachea, 60 megatavua ja yli.

Intel pyytää quad coresta suunnilleen saman kuin AMD 64-coresta: Intel® Xeon® Processor E7-8893 v4 (60M Cache, 3.20 GHz) Product Specifications

Intelin prossujen (joilla on kaikille ytimille yhteinen L3) L3-viive on selvästi suurempi kuin zenin L3-viive, vaikka intelin prossuissa se L3 on edelleen samalla piilastulla.

Sanoin jo tuossa aiemmin siitä cachen määrästä. Joissakin Intelin prosessoreissa kaikkien ytimien kesken jaettua cachea on paljon enemmän. AMD:lle ei vieläkään ole prosessoria jossa kaikille ytimille yhteistä L3/L4 cachea olisi Paljon. AMD hakee Zen2:lla muita kuin niche markkinoita enkä tiedä paljonko noita 50+ megan cache -prosessoreita ostetaan. Silti, yksi chiplet ja karsittu I/O piiri jätticachella ja hintalapuksi 9K$ ei kuulosta kovin pahalta.

Sitten on näitä muita keskustelijoita - kuten tämän keskustelun haaran kohteena oleva henkilö - joiden osaaminen - kaikella kunnioituksella - tuntuu olevan eri web-sivustojen uutispalstojen kommenttikenttien perusteella johdettua 'omaa asiantuntemusta'.
Jos osaamisen taso on sitä, että arvioidaan jonkin komponentin (esim. ccx-blokin) toimintaa ja arkkitehtuuria powerpoint -kalvosta kaapatun merkittävästi yksinkertaistetun graafisen kuvan perusteella, lisätään siihen omia ja sekalaisten nettipalstojen / foorumeiden 'asiantuntijoiden mielipiteitä/spekulointeja/toiveita', ei lopputuloksen voikkaan olettaa olevan muuta kuin tässä edellä esitetyt - sanotaan suoraan haihattelut.

Tässä on edelleen ollut kyse siitä voiko CCX olla 8-core. AMD sanoo ettei voi. Oliko muuta asiaan liittyvää?

Se powerpoint -kalvosta kaapatun merkittävästi yksinkertaistettu graafinen kuva on valitettavasti parasta mitä on saatavilla. Sitäpaitsi siitä kyllä näkee asioita kun osaa katsoa, esimerkiksi siitä nähdään kuinka ytimiä voidaan poistaa käytöstä. Enkä väitä että minä näen. Joku muu näkee.

Tässä kuitenkin @Threadripper on väärässä ja @hkultala yrittää selittää asioiden oikeaa kantaa, mutta se ei mene perille. Sivustakatsojana tästä tulee vähän tylsää ekan sivun jälkeen.
--

Itse artikkelista bongasin vain CCX:n kaksinkertaistumisen, muut tiedot ei itselle riitä tarkempaan spekulaatioon. Ehkä tulevaisuudessa 8-ydin CCX on uusi minimi. Vaikea kuvitella, että siitä sitten disabloidaan coreja hirveästi, että saadaan niitä halpisprosessoreita. Ehkä uusi standardi on 6 ydintä minimi ja vähemmällä ei uudet AAA-julkaisut pyöri?

Fakta on edelleen: AMD:n virallisessa dokumentissa viime vuoden joulukuulta linjataan ettei CCX:ssa voi olla yli 4 ydintä. Tuolla perusteella: miten CCX:ssa voi olla 8 ydintä? Vastaisitko tuohon kysymykseen kun kerran minun esitit olevan väärässä, kiitos.

 

[vemkki]

Fakta on edelleen: AMD:n virallisessa dokumentissa viime vuoden joulukuulta linjataan ettei CCX:ssa voi olla yli 4 ydintä. Tuolla perusteella: miten CCX:ssa voi olla 8 ydintä?

Siinä käsiteltiin tietysti viime vuonna markkinoilla olevia prosessoreita. Yleensä parin vuoden päästä markkinoille tulevien prosessorien speksejä ei ole tapana kertoa kovin tarkalla tasolla. Nyt ilmeisesti alkoi olla jo aika valottaa salaisuuden verhoa.

 

[Threadripper]

Siinä käsiteltiin tietysti viime vuonna markkinoilla olevia prosessoreita. Yleensä parin vuoden päästä markkinoille tulevien prosessorien speksejä ei ole tapana kertoa kovin tarkalla tasolla. Nyt ilmeisesti alkoi olla jo aika valottaa salaisuuden verhoa.

Niinhän siinä käsiteltiin. Se on kuitenkin AMD:n virallinen kanta, parempaa saa esittää. Kalvoissahan ei sanota CCX:sta tai sen koosta sanaakaan. Siksi niillä kalvoilla voi spekuloida, muttei väittää faktana olevansa oikeassa.

 

[Kizmo]

Vitsit vitsinä, jatketaan vihdoin sillä alkuperäisellä aiheella, eli 8-core CCX: http://developer.amd.com/wp-content/resources/56420.pdf

Within each Zeppelin there are 2 Compute Complexes (CCX). Each CCX has•its own L3 cache. Each core has its own L2 and L1i and L1d caches•up to 4 cores per CCX, i.e. 32 cores per socket. Other EPYCcore counts follow

Tuossa annetaan linjaus jonka mukaan CCX:ssa on maksimissaan 4 corea. Siten CCX:ssa ei voi olla yli 4 corea. Lähteenä on AMD:n virallinen dokumentti 12/2018.

Mutta tuossahan puhutaan vain Zeppelin ytimestä. Jeesuksen vanhaa rautaa näin ZEN 2 aikana.

Samaten sulta unohtui sandyn L3 viipale-viive spekuloinnissa suuruusluokka. Muutama kellojakso sinne tänne ei juuri venettä keikuta.

AMD:n tapauksessa kokonaisviive kasvaa todella rumasti

 

[FireFly Renaissance]

Ei se mitään perustuslakia ole. Se, että CCX:ssä oli tuolloin neljä corea ei millään tavalla estä, ettei CCX:ssä tulevassa Zen 3:ssa ole neljää corea.

Se on ainakin jo nyt selvää, että nykyisenkaltaista CCX:ää siellä ei julkistettujen tietojen mukaan ole. Millä termillä sitä sitten jatkossa kutsutaan, on ihan täysin yhdentekevää.

 

[Kizmo]

Niin ja kun ajattelee sen L3 muistiratkaisun päivittämisen teknisiä perusteita niin siihen kyllä kannattanee uhrata aikaa ettei välimuistissa olisi NUMA tilannetta ollenkaan. Siitä ei suorituskyvyllisesti ole mitään haittaa ja vanhatkin per 4-core ccx optimoidut ohjelmat toimii aivan kuten ennenkin.

 

[Threadripper]

Mutta tuossahan puhutaan vain Zeppelin ytimestä. Jeesuksen vanhaa rautaa näin ZEN 2 aikana.

AMD:n Papermaster sanoo Zen2:sta seuraavaa:

"The optimization that we worked with the industry as we first rolled out Ryzen was our core complex," Papermaster said, "We very successfully worked across the OS, with Windows and Linux, so there is a recognition of AMD’s core complex, and so you can really have your workloads leverage that organization. As we go forward into this next-generation with Zen 2-based products, we actually just make it easier because as you have cores going into a common I/O die, it is the same core complex approach that we had before, and you actually just have a very centralized path."[/quote]

Zen2:sta löytyy sama vanha rakenne, joten olennainen pätee tänäänkin ihan täysin. CCX on sama kuin aiemmin ja myös välimuistirakenne on sama siltä osin kuin sanotaan.

Samaten sulta unohtui sandyn L3 viipale-viive spekuloinnissa suuruusluokka. Muutama kellojakso sinne tänne ei juuri venettä keikuta.

AMD:n tapauksessa kokonaisviive kasvaa todella rumasti

Sandy esimerkki oli vain osoittamaan ettei koko cachea ole pakko lukea, kuten väitettiin.

AMD:n tapauksessa kokonaisviive kasvaa tietyissä tilanteissa ja juuri optimoinneilla on paljon merkitystä.

Ei se mitään perustuslakia ole. Se, että CCX:ssä oli tuolloin neljä corea ei millään tavalla estä, ettei CCX:ssä tulevassa Zen 3:ssa ole neljää corea.

Se on ainakin jo nyt selvää, että nykyisenkaltaista CCX:ää siellä ei julkistettujen tietojen mukaan ole. Millä termillä sitä sitten jatkossa kutsutaan, on ihan täysin yhdentekevää.

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.

 

[Kizmo]

AMD:n Papermaster sanoo Zen2:sta seuraavaa:

"The optimization that we worked with the industry as we first rolled out Ryzen was our core complex," Papermaster said, "We very successfully worked across the OS, with Windows and Linux, so there is a recognition of AMD’s core complex, and so you can really have your workloads leverage that organization. As we go forward into this next-generation with Zen 2-based products, we actually just make it easier because as you have cores going into a common I/O die, it is the same core complex approach that we had before, and you actually just have a very centralized path."

Zen2:sta löytyy sama vanha rakenne, joten olennainen pätee tänäänkin ihan täysin. CCX on sama kuin aiemmin ja myös välimuistirakenne on sama siltä osin kuin sanotaan.

Nyt et kyllä ole ymmärtänyt ollenkaan mitä tuolla on jälkimmäisellä boldauksella on haettu takaa.

Zen/Zen+ threadripperit ja epycit oli tosi pahasti NUMA "vammaisia".

ZEN2 toi suuren parannuksen siinä että jokainen ydin on samanarvoinen dramiin päin huudellessa joten softien ja käyttisten ei tarvi välittää siitä että millainen kaista milläkin fyysisellä suoritinytimellä on käytettävissään.