AMD kertoi lisää yksityiskohtia tulevista Ryzen-prosessoreista (Matisse)

[Marti77]

Kyllä se yhden ytimen suorituskyky nousee kun se olisi se alunperin oleva päivityksen syy mutta kuinka hyvin se jää nähtäväksi ja voi olla ettei tässä ensimmäisessä 3000 mallien julkaisussa nähdä enemmän ytimiä kun nuo 8kpl mutta voi tulla nopealla aikatalulla niitä lisää jos ne hyödylliseksi näkee ja että markkinatilanne sen vaatii kun 16 ytiminen puolittaa suoraan piirivalmistajan tuotantomääriä kyseiselle mallillle eli on melkein tuplasti kalliimpi valmistaa myöskin.
Kuitenkin se pistää intelin ahtaalle enemmän eli niiden on kohta pakko saada 10nm prosessi kuntoon elleivät halua katsoa vierestä kun AMD vie markkinoita heiltä.
Hyviä aikoja eletään kuluttajan kannalta prossupuolella tänä vuonna se on jo selvä.

 

[gouca]

Toivottavasti yhden ytimen suorituskyky olisi hyvä vihdoinkin.

Yhden ytimen suorituskyky on aika epärelevantti; olisipa muistiohjain vihdoin sitä tasoa, ettei viihdesuorituskyky kärsi 20% väärän luokan 3200 MHz -muistien takia.

 

[sra2010]

Yhden ytimen suorituskyky on aika epärelevantti; olisipa muistiohjain vihdoin sitä tasoa, ettei viihdesuorituskyky kärsi 20% väärän luokan 3200 MHz -muistien takia.

Kyllä ne Intelin prossulle kannattaa valita myös kunnon muistit eli Samsung B-die, maksavat kummallekin alustalle täsmälleen saman verran. Yhden ytimen suorituskyvyn toivoisi saavuttavan Intelin tai menevän hieman ohi.

 

[Weega666]

Enemmän kuin 8 ydintä voi toki tarkoittaa 10 ydintä tai 12 ydintä eikä suoraan 16, kuten monessa paikassa on veikattu.

Pointti tuossa monitulkintaisuudessa on se, että Su ei itseasiassa sanonut kertaakaan että siihen tulisi enemmän ytimiä, lähimmäs menee "I didn't say how many more". Edeltävä lause on kuitenkin muotoiltu niin, että Su sanoo uskovansa että toimittaja saattaisi odottaa että heillä olisi enemmän ytimiä, ei että voitte odottaa että meillä on enemmän ytimiä

Juu niinhän se sanoo mutta samassa myös vetäisee että AMD:lla on aina ollut etua lisäytimistä. Eli eiköhän siihen vapaaseen paikkaan laiteta lisää ytimiä, koska ei siihen huvikseen ole tilaa jätetty juurikin 8 coren verran. Mitä nyt näitä keskusteluja on seuraillut ymäri ATK maailman niin aika monei on tullut siihen jothtopäätökseen että 16/16 tai 12/12 core 3000 sarjalinen näkee päivänvalon jossain vaiheessa.

 

[BlackWolf]

Kyllä se yhden ytimen suorituskyky nousee kun se olisi se alunperin oleva päivityksen syy mutta kuinka hyvin se jää nähtäväksi ja voi olla ettei tässä ensimmäisessä 3000 mallien julkaisussa nähdä enemmän ytimiä kun nuo 8kpl mutta voi tulla nopealla aikatalulla niitä lisää jos ne hyödylliseksi näkee ja että markkinatilanne sen vaatii kun 16 ytiminen puolittaa suoraan piirivalmistajan tuotantomääriä kyseiselle mallillle eli on melkein tuplasti kalliimpi valmistaa myöskin.

Nyt joudun olemaan kanssasi hieman eriävää mieltä. Kun suurimmat kuluerät on kehitys ja tuotantolinjojen rakentaminen yms. niin yksittäisen chipletin (tai CPU moduulin miten vaan) teko ei ole kuin muutamia prosentteja kokonaisuuden (prosessorin) hinnasta. Juuri sen takiahan AMD on tuohon chiplet touhuun lähtenyt. Tällä tavalla ei tarvita monimutkaisia tuotantolinjoja eri tuotteille, vaan yhdeltä ja samalta linjalta voidaan puskea varsin kustannustehokkaasti ratkaisuja mistä voidaan sitten koostaa monia erilaisia prosessoreja.

Eli 16 core ei ole tuplasti kalliimpi valmistaa kuin 8 core, koska lopputuotteen hintaan vaikuttaa suoraan ne r&d, markkinointi, valmistus (tehtaan hinta) yms. kustannukset. Ja tämä siis per valmistettu prosessori, koska sieltä tulee myös se raha millä ne maksetaan. Oikeastaan voidaan arvioida että 16 core on jopa halvempi, koska sen kate lienee korkeampi. Jos niitä hintoja laskettaisiin per tehty chiplet, niin ehkä teoriassa tulisi tuplat kun laittaa kaksi chiplettiä yhteen, mutta kun AMD ei myy chiplettejä, vaan prosessoreja, mihin kuuluu myös se I/O piiri, siellä olevat muistit ja kotelointi. Tuohon kun laskee päälle sen että valmistusvikaiset saadaan lyötyä 12 core tms. paketteihin niin yhden chipletin hinta muodostuu vielä marginaalisemmaksi osaksi kokonaishintaa.

 

[Weega666]

Veikkaan, että yli 8 ytimen kuluttajamalleja ei tulla näkemään tänävuonna, van 2020 kun 7nm tuotanto on vakiintunut ja hyviä piirejä on saatu binnattua tarpeeksi kasaan.
Todenäköisenä pitäisin jopa sitä, että IO-piiri pitää ensin saada shrinkattua, ennen kuin on järkevää julkaista 105W lämpötehobudjetilla yli 8 ytimen mallia. Ja varmaan tulee vain 12 ytimen malli, jottei taistella threadripperin kanssa.

Jottei kilpailla liiaksi oman tuotannon kanssa, niin veikkaan AM4 saavan 16 ytimisen mallin sitten kun Threadripper 3000-sarja julkaistaan ja siihen tarjotaan minimissään 16 ytimistä mallia. Pienempiä ydinmääriä turha tarjota, kun TR4 kanta kuitenkin tukee vanhempia threadrippereitä ja rikkinäiset ytimet sisältävät piirit voidaan dumpata edullisempiin työpöytämalleihin, jos niitä edes hirveästi tulee (ei tule, kun 7nm tekniikalla 8 ryzen ydintä on kohtuu pieni piiri)

Tämä veikkaus että eivät tuo 16/16 corea koska Treadtrippereiden kannattavuus kärsisi on kyllä vähän nyt outo väite. TR:ssä on 4 kaistaa muisteille ja näille Rytsölöille olis edelleen vaan 2 kanavaa joten eivät kilpailisi suoraan TR:n kanssa tehoissa. Mutta oli miten oli niin mielenkiintoisia aikoja eletään nyt. On tämä ollutkin aika pitkään Intelin pillin mukaan tanssimista...Ja nyt AMD pistää ne polvilleen oikein kunnolla. Hienoa!

 

[Weega666]

Jos AMD julkaisee kesällä markkinoiden suorituskykyisimmän 8-ytimisen prosessorin (jota vieläpä on saatavilla ja vieläpä 9900K:ta halvemmalla), niin sen ei useaan kuukauteen kannata puhua mitään isommista ydinmääristä, koska se vain jarruttaisi oman markkinajohtajan myyntiä, sekä tietysti myös Threadripper voisi ottaa osumaa.

Loppuvuodesta kun iso läjä 8-ytimisiä malleja on myyty saadaankin sitten uusi hype päälle 12 tai jopa 16-ytimisten vekottimien ympärille ja saadaan parhaimillaan myytyä samalle porukalle kaksi saman sukupolven prossua!

"Samat tehot kuin intelillä ja 9kk myöhässä." Tuollaista kommenttia tulisi jos amd julkaisisi 9900K tasoisen "huippu"prossun kesällä. Kyllä amd on tuomassa vähintään sen 12 corea kesälle. Todennäköisesti myös 16 corea.

Se että porukka innostuisi päivittämään, ja nimenomaan amd:hen, olisi amd:n kannalta parasta. Ei se että junnataan ja tahallaan hidastellaan ja eletään Intelin tahtiin. Jos/kun mahdollisuus iskeä kilpailijaa oikein kunnolla yli 8v tauon jälkeen, se todellakin kannattaa. Ei silloin aleta himmailemaan ja "miettimään Threadripperin myyntejä". Ehkä paskin syy olla tuomatta 16 corea Ryzeniin.

Jep. Juurikin noin. AMD:lle TR:n on ihan marginaalituote, jolla ei ole mitään virkaa oikeasti ja voin ajatella niin että kun tuo 3000 sarja tulee niin TR:t voidaan suosiolla heittää mäkeen ja tehdä niistä ihan suosiolla EPYC:jä.

 

[Weega666]

Nykyisin jos yrittää tehdä edes nettisivujen selaamista core 2 duo e8400 prosessorilla on suurissa vaikeuksissa. Siinä on kuitenkin siis 2 ydintä jotka "toimivat nopeasti".

Ihan täysin en tätä allekirjoita, sillä ihan hyvin oma e8500 SER-kone pelasi perus nettiselauksessa. Samoin 2C/4T läppäritkin tuntuvat pelittävän ihan ok.

Ihan höpön löpöä tuo että nettiselaamiseen tarvitaan jotain multicore prossua. Täällä vedetään nettiä nytkin Semptronilla ja hyvin pyörii...Malli on HP vuodelta 2008 ja toimii kun junan vessa nettihommissa ja kevyessä tekstinkäsittelyssä. Pelikoneena on toki jotain järempää

 

[Weega666]

Ihan täysin en tätä allekirjoita, sillä ihan hyvin oma e8500 SER-kone pelasi perus nettiselauksessa. Samoin 2C/4T läppäritkin tuntuvat pelittävän ihan ok.

Pelittäähän ne, kun Intelin takia kehitys on junnannut käytännössä paikoillaan. 12v vanha Q6600 on perus koneeseen tänäänkin ihan hyvä prosessori ja pieksee monia noita läppäreitä mennen tullen ja palatessa. Samalta piirisarjalta xeonit ja q9450 jne. pyörittää jopa pelejäkin.

Kiitos AMD:n, niin nyt kun alkaa piin rajat tulemaan vastaan ja enää ei oikein IPC laske, eikä kellotkaan tuosta 5 gigasta varmana enää hirveästi nouse, niin pakko siirtyä moniytimisiin. Aika samalla kaavallahan tämä touhu on mennyt viimeiset vuodet kuin meni ennen duoja, eli pikkuhiljaa kellot nousee ja viivanleveys laskee ja sieltä tulee se teho. Sitten alkoikin tulla katto vastaan ja piti keksiä muuta, niin laitettiin kaksi ydintä, sitten neljä jne. Kohta vain on tämäkin polku jo kuljettu. Intel olisi toki mielellään tehnyt 5% parannus prosessoreitaan vaikka seuraavat 20 vuotta jos se heistä olisi kiinni.

Olis Intel edes siihen 5% päässyt mutta aika monta kertaa jäätiin 3% ja jopa alle. On se jotenkin säälittävää että i7 4790K:lla vetää kaikkia nykypelejä mennen tullen ja palatessa kunhan näyttiksessä riittää potkua.

 

[Agent_007]

Kyllä ne Intelin prossulle kannattaa valita myös kunnon muistit eli Samsung B-die, maksavat kummallekin alustalle täsmälleen saman verran.

IMHO Intelillä ei noista kyllä kannata maksaa, ellei erikseen ole tarkoitus ylikellottaa joitakin muistibenchmarkkeja varten. Eli halvimmat 3000/3200 kammat ostoskoriin.
DDR4-muistinopeus & Coffee Laken suorituskyky - io-tech.fi
Intel i5-8400 CPU Review: 2666MHz & 3200MHz Gaming Benchmarks

 

[Melbac]

Eikös tohon mahtuisi hbm2 muistia joku 16GB-32GB?.Vähän outo kyllä toi piirien sijoittelu.Tosin tollekkin kai löytyy looginen selitys eli tarkoitettu käytettäväksi tulevaisuudessa kun io piiri vaihdetaan yms.

 

[sra2010]

IMHO Intelillä ei noista kyllä kannata maksaa, ellei erikseen ole tarkoitus ylikellottaa joitakin muistibenchmarkkeja varten. Eli halvimmat 3000/3200 kammat ostoskoriin.
DDR4-muistinopeus & Coffee Laken suorituskyky - io-tech.fi
Intel i5-8400 CPU Review: 2666MHz & 3200MHz Gaming Benchmarks

Luepa vielä tuo io-tech artikkeli ja erityisesti se peli osio, joka täällä yleensä kiinnostaa porukkaa, suhteellisen selkeä ero on, että ajetaanko prossua vakio muisteilla vai 3200Mhz
http://www.io-tech.fi/wp-content/uploads/2017/10/8700k-mem-bench-w3-3.png

 

[Agent_007]

Luepa vielä tuo io-tech artikkeli ja erityisesti se peli osio, joka täällä yleensä kiinnostaa porukkaa, suhteellisen selkeä ero on, että ajetaanko prossua vakio muisteilla vai 3200Mhz
http://www.io-tech.fi/wp-content/uploads/2017/10/8700k-mem-bench-w3-3.png

Taisit ymmärtää viestini väärin. Samsung B-diestä ei kannata Intelillä maksaa, kun noita muiden piirivalmistajien 3000 ja 3200 piirejä saa monta kymppiä halvemmalla, ja ero tiukkojen latenssien ja löysien kanssa on Intelin puolella olemattoman pieni.
Intel i7-8700K Coffee Lake Memory Benchmark Analysis

 

[Hannibal]

Toivottavasti yhden ytimen suorituskyky olisi hyvä vihdoinkin.

Yhden ytimen suorituskyky on aika epärelevantti; olisipa muistiohjain vihdoin sitä tasoa, ettei viihdesuorituskyky kärsi 20% väärän luokan 3200 MHz -muistien takia.

Perusarkkitehtuuri on edelleen sama, joten eiköhän 3000-sarjakin tykkää tiukoista latensseista.

 

[Lepakomäyrä]

Kyllä vaan tuntuu että intel tippuu kelkasta budjekti koneiden osalta ainakin, Ryzen tarjoaa erinomaista suorituskykyä ja riittävästi ytimiä pikku rahalla, Nyt jo huomaa miten Lan koneiden ytimien määrä i5 4/4 ei enään vaan piisaa.
Vaikea sitä on löytää järkevää budjekti ratkaisua intelin prossuista Lan huoneen koneisiin ja vielä kun uudet Ryzenit tulee niin taitaa hankinta päätös olla sitä myöden selvä.

 

[Threadripper]

Nyt joudun olemaan kanssasi hieman eriävää mieltä. Kun suurimmat kuluerät on kehitys ja tuotantolinjojen rakentaminen yms. niin yksittäisen chipletin (tai CPU moduulin miten vaan) teko ei ole kuin muutamia prosentteja kokonaisuuden (prosessorin) hinnasta. Juuri sen takiahan AMD on tuohon chiplet touhuun lähtenyt. Tällä tavalla ei tarvita monimutkaisia tuotantolinjoja eri tuotteille, vaan yhdeltä ja samalta linjalta voidaan puskea varsin kustannustehokkaasti ratkaisuja mistä voidaan sitten koostaa monia erilaisia prosessoreja.

Paljonko se toinen chiplet maksaisi? Pakkauskustannukset ovat max muutaman dollarin luokkaa lisää yhden chipletin prosessoriin verrattuna. Chipletin valmistushinta? Oletetaan: koko 80mm2, kiekon hinta 12 000$, hukkaan menee kokonaisuudesta 25%.

Tekee 662 toimivaa chiplettiä per kiekko ja yhden hinnaksi tulee 18 dollaria eli karkeasti valmistus + pakkaus olisi hintaan 20 dollaria lisää.

Eli todellakin mitätön summa.

 

[BlackWolf]

Paljonko se toinen chiplet maksaisi? Pakkauskustannukset ovat max muutaman dollarin luokkaa lisää yhden chipletin prosessoriin verrattuna. Chipletin valmistushinta? Oletetaan: koko 80mm2, kiekon hinta 12 000$, hukkaan menee kokonaisuudesta 25%.

Tekee 662 toimivaa chiplettiä per kiekko ja yhden hinnaksi tulee 18 dollaria eli karkeasti valmistus + pakkaus olisi hintaan 20 dollaria lisää.

Eli todellakin mitätön summa.

Itse kiekothan maksaa käsittääkseni jotain satasia. Sitten printattuna yms. ne maksaa kai jotain tuollaista 12 000 dollaria. Eli se valmistus maksaa, ei niinkään se itse silikooni ja siitä pitää sitten maksaa toimittajalle ja se taas siitä maksaa tehtaan kuluja ja kehitystä yms. Sen takiahan onkin juuri kannattavaa puskea yhtä laatua ulos ja ns. perhanasti, kun silloin noi valmistajan kulut pienenee ja hinta per yksikkö putoaa. Siksi on suorastaan naurettavan halpaa laittaa lisää noita chiplettejä per prossu, jos niistä saatava kate kuitenkin kasvaa satoja prosentteja. Se chipletin hinta on niin matala suhteessa kaikkiin muihin kuluihin ja taas siitä saatava tuotto nousee prosentuaalisesti moninkertaiseksi.

Innovations at 7nm to Keep Moore’s Law Alive | Semiconductor Manufacturing & Design Community

 

[ratkakapu]

Paljonko se toinen chiplet maksaisi? Pakkauskustannukset ovat max muutaman dollarin luokkaa lisää yhden chipletin prosessoriin verrattuna. Chipletin valmistushinta? Oletetaan: koko 80mm2, kiekon hinta 12 000$, hukkaan menee kokonaisuudesta 25%.

Tekee 662 toimivaa chiplettiä per kiekko ja yhden hinnaksi tulee 18 dollaria eli karkeasti valmistus + pakkaus olisi hintaan 20 dollaria lisää.

Eli todellakin mitätön summa.

Kysehän on siitä, kuinka paljon 7nm tuotantoa on ja kuinka paljon epyc myy. Jos epycillä on myyntiä enemmän mitä ehditään tuottamaan, niin järkevin hommahan olisi, että kuluttajamalleihin ei aleta toista sirua laittamaan ennen kuin tuotantokapasiteetti ottaa epycin myynnit kiinni, ellei Intel julkaise yli 8 ytimen mallia työpöydälle (ei julkaise)

 

[BlackWolf]

Kysehän on siitä, kuinka paljon 7nm tuotantoa on ja kuinka paljon epyc myy. Jos epycillä on myyntiä enemmän mitä ehditään tuottamaan, niin järkevin hommahan olisi, että kuluttajamalleihin ei aleta toista sirua laittamaan ennen kuin tuotantokapasiteetti ottaa epycin myynnit kiinni, ellei Intel julkaise yli 8 ytimen mallia työpöydälle (ei julkaise)

Jos sä saat tuotettua kahta prosessoria, toisen tuottaminen maksaa jotain 5-50% enemmän kuin toinen, mutta sen hinta on kaupassa 2.5x mitä se toinen, niin kumpikos on kannattavaa, myydä yhtä prosessoria vai kahta? Sitten jos sä saat vielä vähennettyä hävikkiä edes muutaman prosentin ottamalla rikkinäiset sirut ja tekemällä niistä muutaman välimallinversion, missä on vaikka 12 corea, sen sijaan että ne menisi roskiin, niin sähän teet roskasta timanttia. Hinta 0 dollaria ja kaupassa siitä maksetaan jotain ekan ja tokan prossun välistä.

 

[Sami Riitaoja]

Perusarkkitehtuuri on edelleen sama, joten eiköhän 3000-sarjakin tykkää tiukoista latensseista.

Tätähän ei vielä tiedetä. Ryzenin vaatimus tiukoille muistilatensseille johtuu L3-cachen toimimisesta L2:n victim-cachena vs Intelin L3 johon prefectherit pystyvät lataamaan seuraavaksi käytettyä dataa etukäteen AMD:n prossujen pystyessä lukemaan dataa vain suoraan L2-cacheen. Kerran muistiohjain on erillään muusta prosessoriytimestä pelisuorituskyvyn saamiseksi Intelin rinnalle ja ohikin vaatii L3-cachen toimintamallin muutosta. Pelisuorituskyky oli AMD:n listalla yksi asia johon Zen2:ssa keskitytään joten lienee hyvin mahdollista että L3 toimii erilailla, ja em. toimintamallin muutoksen jälkeen Ryzenin ei pitäisi antaa mitään tasoitetta Intelin prossuille eli mahdollisesti tulee jopa useamman kymmenen prosentin suorituskykylisä.

 

[L2K2]

Kysehän on siitä, kuinka paljon 7nm tuotantoa on ja kuinka paljon epyc myy. Jos epycillä on myyntiä enemmän mitä ehditään tuottamaan, niin järkevin hommahan olisi, että kuluttajamalleihin ei aleta toista sirua laittamaan ennen kuin tuotantokapasiteetti ottaa epycin myynnit kiinni, ellei Intel julkaise yli 8 ytimen mallia työpöydälle (ei julkaise)

Jos sä saat tuotettua kahta prosessoria, toisen tuottaminen maksaa jotain 5-50% enemmän kuin toinen, mutta sen hinta on kaupassa 2.5x mitä se toinen, niin kumpikos on kannattavaa, myydä yhtä prosessoria vai kahta? Sitten jos sä saat vielä vähennettyä hävikkiä edes muutaman prosentin ottamalla rikkinäiset sirut ja tekemällä niistä muutaman välimallinversion, missä on vaikka 12 corea, sen sijaan että ne menisi roskiin, niin sähän teet roskasta timanttia. Hinta 0 dollaria ja kaupassa siitä maksetaan jotain ekan ja tokan prossun välistä.

Jos se kalliimpi ei myy (riittävästi massoille), niin toki sitä halvempaa...

Samoin jos se kalliimpi leikkaa sen vielä kertoimella 10 kalliimman (todella hyvän katteen) EPYC-alustan tuotantokapasiteettia, niin sitten sitä halvempaa työpöydälle.

Tämä ei ole yksinkertainen optimointitehtävä. Et voi vaan sanoa, että koska tuoteesta X saa Y-kertaisen hinnan, niin se on parempi. Pitää huomioida myös paljonko sitä markkinaa on hinnalla Y, ja mikä on vaikutus muihin omiin tuotteisiin, jne. ...

 

[Mechanical Man]

Jos se kalliimpi ei myy (riittävästi massoille), niin toki sitä halvempaa...

Samoin jos se kalliimpi leikkaa sen vielä kertoimella 10 kalliimman (todella hyvän katteen) EPYC-alustan tuotantokapasiteettia, niin sitten sitä halvempaa työpöydälle.

Tämä ei ole yksinkertainen optimointitehtävä. Et voi vaan sanoa, että koska tuoteesta X saa Y-kertaisen hinnan, niin se on parempi. Pitää huomioida myös paljonko sitä markkinaa on hinnalla Y, ja mikä on vaikutus muihin omiin tuotteisiin, jne. ...

Ei vaan kysymys on katteesta ilman tai kanssa. Ei katteesta vs. 8 ydin koko myynti. 12/16 core mallit lisäävät markkinan kokoa ja ovat suurempi katteisia tuotteita.

 

[ratkakapu]

Ei vaan kysymys on katteesta ilman tai kanssa. Ei katteesta vs. 8 ydin koko myynti. 12/16 core mallit lisäävät markkinan kokoa ja ovat suurempi katteisia tuotteita.

Epyc on AMD:n tuotteista selkeästi parhaalla kattella. Näin ollen se on prioriteetti. Jos 7nm tuotantoa on tarpeeksi ja saannot ovat hyvät, niin 2 piirin työpöytäprosessori nähdään aikaisessa vaiheessa, jos se takkuaa, niin se nähdään myöhemmin, jos nähdään (melko varmasti nähdään joskus)

 

[hik]

Tätähän ei vielä tiedetä. Ryzenin vaatimus tiukoille muistilatensseille johtuu L3-cachen toimimisesta L2:n victim-cachena vs Intelin L3 johon prefectherit pystyvät lataamaan seuraavaksi käytettyä dataa etukäteen AMD:n prossujen pystyessä lukemaan dataa vain suoraan L2-cacheen. Kerran muistiohjain on erillään muusta prosessoriytimestä pelisuorituskyvyn saamiseksi Intelin rinnalle ja ohikin vaatii L3-cachen toimintamallin muutosta. Pelisuorituskyky oli AMD:n listalla yksi asia johon Zen2:ssa keskitytään joten lienee hyvin mahdollista että L3 toimii erilailla, ja em. toimintamallin muutoksen jälkeen Ryzenin ei pitäisi antaa mitään tasoitetta Intelin prossuille eli mahdollisesti tulee jopa useamman kymmenen prosentin suorituskykylisä.

Oliko muuten joissain aiemmissa AMD-prosuissa myös victim cache ja silti Zeniä pienempi latenssi?
Aiheesta en sinällään tiedä mitään ja siksi kiinnosti kysellä.
En tiedä oliko esim Phenomissa victim L3, löysin vaan että yleensä AMD:llä ollut semmoinen.

Spoileri: ramdom googlattu Aida latenssi Phenom II

 

[Sami Riitaoja]

Oliko muuten joissain aiemmissa AMD-prosuissa myös victim cache ja silti Zeniä pienempi latenssi?
Aiheesta en sinällään tiedä mitään ja siksi kiinnosti kysellä.
En tiedä oliko esim Phenomissa victim L3, löysin vaan että yleensä AMD:llä ollut semmoinen.

Spoileri: ramdom googlattu Aida latenssi Phenom II

Phenomin L3-latenssi on surkea, Zenin L3:n latenssi taitaa olla hyvin lähellä Phenomin L2:n latenssia. K10:ssä oli maksimoitu cachen mahdollinen datamäärä eksklusiivisuudella, sama data ei voinut olla useammassa cachessa yhtäaikaa joka hidasti toimintaa, Zenissä näin ei ole väkisin mutta tuo cachen toimiminen victim-cachena pitää sisällöt aika hyvin erillisinä.

Zenin L3:n nopeudessa ei siis ole mitään vikaa, se on nopeampi kuin Intelin prossuissa, ongelma on että peleissä tärkeä seuraavaksi haluttu data voidaan ladata Ringbus-Inteleissä etukäteen L3:een, Zenissä ainoastaan pienempään L2:een. Peliohjelmanopeuteen itse coren IPC:n nostaminen ei ole niin tarpeellista kuin saada L3-cache tehokkaampaan käyttöön.

Sinällänsä Zenissä on yksi välimuistitaso enemmän itse ytimissä kuin K10:ssä ja Bulldozerissa, Zenin L3 on osa ytimiä siinä missä L3 vanhemmissa AMD:n prossuissa ja Intelin tuotteissa on osa muistiohjainta/northbridgeä.

 

[hik]

Phenomin Aida RAM latenssi oli 50,6 ns.
Mahdollista on että luku on Ryzenin kanssa vertailukelpoinen. Ryzen pääsee B-die- muisteilla parhaimmillaan Aidassa kait jonnekin 62-65 ns heitteille - kun kellotettu ja tuunattu.

Tuntuu oudolta jos L3 prefetch näkyy Aidan latenssitestissä. Tosin olen pihalla aiheesta. Ja miksi vanhassa Phenomissa L3 prefetch ehkä olisi ja uudemmassa Ryzenissä ei.

Jotenkin hahmotan että CCX välinen säikeitten vuoropuhelu on Ryzenissä hidasta , mutta luulisi että sekään ei tulisi Aida-testissä näkyviin.

 

[hkultala]

Phenomin L3-latenssi on surkea, Zenin L3:n latenssi taitaa olla hyvin lähellä Phenomin L2:n latenssia.

Ei ole lähelläkään.

Zenin L3-viive (oman CCXn L3een) on jotain n. 37 kellojakson luokkaa, zen+lla jotain 32 kellojakson luokkaa

Phenomin L2-viive on n. 15 kellojakson luokkaa.

K10:ssä oli maksimoitu cachen mahdollinen datamäärä eksklusiivisuudella, sama data ei voinut olla useammassa cachessa yhtäaikaa joka hidasti toimintaa, Zenissä näin ei ole väkisin mutta tuo cachen toimiminen victim-cachena pitää sisällöt aika hyvin erillisinä.

Ihan samalla toimintaperiaatteella ne toimii molemmissa L2 - L3-välillä.

Zenissä vaan L1 ja L2 eivät ole keskenään poissulkevia, eli L2 ei victim cache L1llem, kun Phenomissa kaikki kolme tasoa olivat keskenään poissulkevia.

Zenin L3:n nopeudessa ei siis ole mitään vikaa, se on nopeampi kuin Intelin prossuissa,

Riippuu siitä, mistä L3sta puhutaan.

Zeppelin-piirillä on kaksi erillistä L3-kakkua. Sen ytimen Oman CCXn L3-kakun käyttäminen on nopeampaa kuin intelillä L3-kakun käyttäminen. Mutta sen toisen CCXn L3-kakusta minkään lataaminen on taas hidasta, selvästi hitaampaa kuin Intelillä.

 

[Sami Riitaoja]

Riippuu siitä, mistä L3sta puhutaan.

Zeppelin-piirillä on kaksi erillistä L3-kakkua. Sen ytimen Oman CCXn L3-kakun käyttäminen on nopeampaa kuin intelillä L3-kakun käyttäminen. Mutta sen toisen CCXn L3-kakusta minkään lataaminen on taas hidasta, selvästi hitaampaa kuin Intelillä.

Zenin L3:t on osa ydinmoduulia, ei se toinen L3 ole L3-cache näille ytimille vaan toisen prosessorin cachea. Hidasta se on muillakin prosessoreilla jos joudutaan snooppaamaan toisen ytimen cacheihin vs oman L3:n käyttö. Prossut kuitenkin omaa koodiaan ajaessaan käyttävät vain omia cachejaan ja tässä Ryzenillä ei ole mitään nopeusongelmaa - ongelma on miten cachea käytetään, Ryzenillä on datan ennakkoluentaan käytössä vain 512KB tehollista cachea siinä missä Ringbus-Intelit voivat hyödyntää koko L3:n. Peleissä datasetti on yleensä suuri ja käydään läpi per frame jolloin L3 victim-cachena jää suurelta osalta turhaksi. Zeniin tulee todella suuri pelisuorituskyvyn parannus jos prefectherien annetaan ladata myös L3:een kuten Intelin desktop-prossuissa.

 

[hkultala]

Zenin L3:t on osa ydinmoduulia, ei se toinen L3 ole L3-cache näille ytimille vaan toisen prosessorin cachea.

Mutta jos haluttu data on likaisena toisen CCXn L3-välimuistissa, se on pakko ladata sieltä.

Ja tämän takia sen toisen CCXn TAGit pitänee tarkastaa ennen kuin päätetään, aletaanko hakea dataa DRAMilta. Tämä tehnee muistiviiveeseen saman viiveen lisää kuin ylimääräinen välissä oleva "oma" välimuistitaso tekisi.

Hidasta se on muillakin prosessoreilla jos joudutaan snooppaamaan toisen ytimen cacheihin vs oman L3:n käyttö.

Ensinnäkin, jos välimuistirakenne on tiukan inklusiivinen(kuten intelillä on Skylakeen asti, muttei Skylake-SPssä), ei jouduta snooppaamaan toisen ytimien välimuisteja, vaan jos dataa ei yhteisestä L3sta löydy, ei sitä voi olla myöskään minkään muun ytimen L2ssa tai L1ssä.

Ja vaikka rakenne ei olisi tiukan inklusiivinen, todennäköisyys sille, että data on likaisena jossain jonkun muun ytimen 256 kiB L2-kakussa on aika paljon pienempi, kuin että se on likaisena toisen CCXn 8 MiB L3-kakussa.

Prossut kuitenkin omaa koodiaan ajaessaan käyttävät vain omia cachejaan ja tässä Ryzenillä ei ole mitään nopeusongelmaa - ongelma on miten cachea käytetään, Ryzenillä on datan ennakkoluentaan käytössä vain 512KB tehollista cachea siinä missä Ringbus-Intelit voivat hyödyntää koko L3:n.

Jälleen hieno esimerkkki siitä, että olet jostain kaivanut yhden syvälle menevän tiedonjyväsen, mutta et ymmärrä mitä se käytännössä merkitsee.

Prefetchaus isoon kaukana olevaan välimuistiin ei ole mikään merkittävä tärkeä ominaisuus.

Prefetchaamisen idea on poistaa datan (ensimmäisestä lähiaikoina tapahtuvasta) käytöstä tulevan välimuistihutin viive.

Jos se prefetchaaminen tehdään kaukaiseen isoon välimuistiin, joudutaan edelleen kärsimään L1- ja L2-välimuistien hutiviiveet, eli L3n osumaviive Jos se prefetchaus tehdään L2-välimuistiin, joudutaan kärsimään vain L1-välimuistin hutiviive, eli L2n osumaviive.

Eli jos prefetch melko varmasti osuu, se halutaan ladata vähintään L2-välimuistiin.

Suoraan L3-välimuistiin halutaan tehdä vain hyvin epävarmoja prefetchejä, kun ei olla yhtään varmoja, että dataa oikeasti tarvitaan pian.


Eikä prefetchatulle datalle tarvita megatavuittain välimuistia. Jos prefetch toimii hyvin, se hakee datan juuri ennen kuin sitä tarvitaan. Jos prefetcher toimii yhtään järkevästi, siellä ei ole megatavuittain dataa odottamassa, että koska minua tarvittaisiin. Jos taas prefetcher latailee megatavuittain dataa liian aikaisin, se vaan lähinnä tuhlaa muistikaistaa, tukkien sitä ja aiheuttaen ylimääräistä kaistankulutusta.

Ja jos joku data prefetchataan, sen jälkeen käytetään, välissä käytetään pari megaa muuta dataa, ja sitten käyetään uudestaan, se menee ryzenissä välissä L2-kakusta L3-kakkuun ja ladataan sieltä. Aivan kuten intelilläkin, ainoa ero on se, että jos se alunperin prefetchattiin L2-kakkuun eikä L3-kakkuun, se ensimmäinen käyttö onkin ryzenillä nopeampi.

Tosin käytännössä se intelinkin prefetcher tyypillisesti lataa sen vähintään L2-kakkuun joten mitään eroa ei ole. Vain jos se on hyvin epävarma, että tarvitaanko dataa vain ei, se lataa sen L3-välimusitiin.

Peleissä datasetti on yleensä suuri ja käydään läpi per frame jolloin L3 victim-cachena jää suurelta osalta turhaksi.

Niinkuin oikeasti.

Sinulla ei ole hajuakaan, millaisissa patterneissa softat sitä muistia tyypillisesti käyttää, ja mitä se tarkoittaa käytännössä.

Tyypillisesti esimerkiksi saman tietorakenteen eri kenttiä käytetään monta kertaa peräkkäin. Tällöin ei ole mitään väliä, mikä on välimuistien inklusiivisuusperiaate, on väliä ainoastaan sillä, että välimuistissa on riittävä lohkokoko että sinne yhteen lohkoon mahtuu hyvä osa siitä tietorakenteesta.

Jos taas jotain dataa (tai välimuistilinjaa) käytetään vain kerran( tai monta kertaa siten, että L1n kapasiteetti sille riittää) , silloin se inklusiivisella välimuistilla päätyy heti kaikkiin välimuistitasoihin, kun taas poissulkevalla välimuistilla päätee ensin sisimpään tasoon ja valuu sieltä pikku hiljaa ulommille tasoille, poistuen samalla sisemmistä tasoista. Kumpi tahansa välimuistityyppi onkaan kyseessä, osumatarkkuus on tässä tilanteessa täysin sama, ja (vain luettu) data päädytään kirjoittamaan jokaiselle välimuistitasolle tasan yhtä kertaa.

(mutta, jos dataa käytetään sopivan ajan päästä uudestaan, voi se jossain tilanteessa poissulkevalla olla vielä tallessa uloimmassa välimusitissa siinä, missä inklusiivisella se on jouduttu heittämään sieltä, pois, kun jotain muuta on ladattu tilalle). Poissulkevuus vaan parantaa osumatarkkkuutta.

Ja, vaikka dataa käytettäisin vain kerran, jos sitä dataa myös kirjoitetaan, silloin poissulkeva on itse asiassa parempi, ja selvitään pienemmällä määrällä kirjoituksia; Inklusiivisella datan vanha versio päätyy ensin ulompiin väliomuisteihin, ja sitten sen päälle kirjoitetaan, pitää se data joko (invalidoida ulommasta ja kirjoittaa sinen kun se flushataan sisemmästä, write-back)) tai (kirjoittaa heti sinne ulompaan asti(write-through)). Molemmat tarkoittaa ylimääräistä kirjoitusta ulompaan välimuistiin.


Poissulkevan välimuistin huonot puolet on muualla; ne on siinä, että tulee lisää kommunikaatiota koherenssin takia(ja tämä voi aiheuttaa lisäviiveitä sitten muillekin välimuisteille), ja mahdollisuus sen ulomman tason välimuistin kirjoitusporttien saturaatioon kun sinne yritetään flushata kamaa liian nopeasti, mikä joskus johtaa pieneen lisäviiveeseen).

Zeniin tulee todella suuri pelisuorituskyvyn parannus jos prefectherien annetaan ladata myös L3:een kuten Intelin desktop-prossuissa.

höpöhöpö.

Zenin pelisuorituskykyä hidastaa se, että sen yhden säikeen suorituskyky on vaan intelin prosessoreita huonompi. Ja tähän syitä mm.

* matalampi turbokellotaajuus
* hidas L3-huti (mm. toisen CCXn tagien tarkastus, ja sen jälkeen lataus sieltä tai DRAMilta)
* muut mikroarkkitehtuuriliset syyt jotka myös johtavat matalampaan IPChen (L3-prefetchin puute ei ole näistä merkittävässä osassa, vaikka sillä joku hyvin pieni vaikutus voikin olla)

 

[Sami Riitaoja]

Mutta jos haluttu data on likaisena toisen CCXn L3-välimuistissa, se on pakko ladata sieltä.

Ja tämän takia sen toisen CCXn TAGit pitänee tarkastaa ennen kuin päätetään, aletaanko hakea dataa DRAMilta. Tämä tehnee muistiviiveeseen saman viiveen lisää kuin ylimääräinen välissä oleva "oma" välimuistitaso tekisi.

Jaetun muistin kanssa kyllä, mutta nopeuskriittinen muisti on prosessille privaattia tai kooderi on idiootti. Tai Windowsin scheluderi kuten on viimeaikoina käynyt ilmi. Jaetun muistin käyttö on toki hidasta mutta Ryzenin kanssakin jos scheluderi toimii fiksusti jaettua muistia käyttävät threadit on niputettu samaan CCX:ään jolloin toista CCX:ää ei tarvitse tarkistaa. Ja jaetun muistin kanssa lienee suhteellisen yleistä että sitä löytyy myös toisen ytimen sisemmistä cacheista.

Zenin pelisuorituskykyä hidastaa se, että sen yhden säikeen suorituskyky on vaan intelin prosessoreita huonompi. Ja tähän syitä mm.

* matalampi turbokellotaajuus
* hidas L3-huti (mm. toisen CCXn tagien tarkastus, ja sen jälkeen lataus sieltä tai DRAMilta)
* muut mikroarkkitehtuuriliset syyt jotka myös johtavat matalampaan IPChen (L3-prefetchin puute ei ole näistä merkittävässä osassa, vaikka sillä joku hyvin pieni vaikutus voikin olla)

Zenin L3-huti on hidas privaatillekin muistille/yhden CCX:n prossuissakin. Voi se pääsyy olla hidas muistiohjainkin mutta Intelin prosessoreissa prefetch on niin aggressiivinen että muistien latenssi ei vaikuta juurikaan suorituskykyyn muuten kuin kokonaiskaistan muodossa, Ryzeneitten kanssa tilanne on toinen.

 

[Sami Riitaoja]

Phenomin Aida RAM latenssi oli 50,6 ns.
Mahdollista on että luku on Ryzenin kanssa vertailukelpoinen. Ryzen pääsee B-die- muisteilla parhaimmillaan Aidassa kait jonnekin 62-65 ns heitteille - kun kellotettu ja tuunattu.

Tuntuu oudolta jos L3 prefetch näkyy Aidan latenssitestissä. Tosin olen pihalla aiheesta. Ja miksi vanhassa Phenomissa L3 prefetch ehkä olisi ja uudemmassa Ryzenissä ei.

Jotenkin hahmotan että CCX välinen säikeitten vuoropuhelu on Ryzenissä hidasta , mutta luulisi että sekään ei tulisi Aida-testissä näkyviin.

Tarkoititkin muistilatenssia, itse puhuin cachen latensseista.

Muistilatenssi on lähinnä kiinni muistiohjaimesta, Phenomien muistiohjain tarjosi pienemmän latenssin mutta muistikaistan kustannuksella. Kaista on tärkeämpää, Zenin muistiohjain on monin verroin Phenomeita parempi - latenssit muistihausta lienee pääosin itse muistiohjaimen hitautta eli muistioperaatioiden järjestäminen maksimikaistan saavuttamiseksi hidastaa yksittäisen muistihaun latenssia mutta tätä voidaan kompensoida ajamalla muistiohjainta korkeammalla kellotaajuudella/optimoimalla muuten. Intelin muistiohjain on pirun hyvä, AMD:llä on varaa parantaa.

 

[hik]

Tarkoititkin muistilatenssia, itse puhuin cachen latensseista.

Juttu lähti liikkeelle DDR4 3200 muistilatensseista. Ostajan kannalta ristiriitaista, kun halpa Ryzen tarvii kallista muistia jostain syystä.

Syy kait johtuu jostain jutusta Ryzenin suunnittelussa, koska ainakin jonkun Phenomin ja FX:n muistiohjaimen latenssi oli pienempi. Jos seuraavan Zenin ohjain on nopeampi, ehkä silloin kerrotaan missä ongelmia oli, niin voidaan palata tähän.

En oikein hoksaa miksi muistiohjaimen maksimikaistaa ja muistin parasta latenssia ei saada samaan aikaan. Jos DDR4 latensseja laittaa biosista pienemmälle, muistiväylä samalla kasvaa. Mutta käyttäjän säädöt on tietysti eri juttu kuin muistiohjaimen suunnittelu.

 

[Sami Riitaoja]

Juttu lähti liikkeelle DDR4 3200 muistilatensseista. Ostajan kannalta ristiriitaista, kun halpa Ryzen tarvii kallista muistia jostain syystä.

Tästä höpöteltiin, muistilatenssi saadaan piilotettua täysin lataamalla tarvittava muisti riittävän paljon ennakkoon jotta data on prosessorilla valmiina kun se sitä tarvitsee. Tässä Intel toimii erilailla kuin AMD, data ennakkoluetaan sekä L2 että L3-cacheen eli ennakkoluenta voi olla paljon aggressiivisempaa.

Syy kait johtuu jostain jutusta Ryzenin suunnittelussa, koska ainakin jonkun Phenomin ja FX:n muistiohjaimen latenssi oli pienempi. Jos seuraavan Zenin ohjain on nopeampi, ehkä silloin kerrotaan missä ongelmia oli, niin voidaan palata tähän.

En oikein hoksaa miksi muistiohjaimen maksimikaistaa ja muistin parasta latenssia ei saada samaan aikaan. Jos DDR4 latensseja laittaa biosista pienemmälle, muistiväylä samalla kasvaa. Mutta käyttäjän säädöt on tietysti eri juttu kuin muistiohjaimen suunnittelu.

Toki voidaan, mutta jotta muistiohjain pystyisi saamaan maksimaalisen kaistan irti sen pitää uudelleenjärjestellä useita kymmeniä, jopa satoja muistihakuja parhaan mahdollisen käyttöasteen saavuttamiseksi. Zenin muistiohjain on aika pitkällä sen suhteen että tähdätään parhaaseen saavutettavaan kaistaan, vanhemmat AMD:n muistiohjaimet vaikka parempia latenssija saavuttikin jäi naurettavan huonoksi saavutetun maksimikaistan suhteen. Intelin muistiohjaimissa yhdistyy melkein Zenin tasoinen maksimikaista alhaisiin latensseihin - AMD:kin voi pistää nykyistä paremmaksi varsinkin jos dekstop-mallit saavat vartavasten työpöydälle optimoidun muistiohjaimen.

 

[KognaK]

Juttu lähti liikkeelle DDR4 3200 muistilatensseista. Ostajan kannalta ristiriitaista, kun halpa Ryzen tarvii kallista muistia jostain syystä.

Ei ryzen erityisesti tarvitse kallista muistia, täysin väärä käsitys. Kalliista muistista on toki paljon hyötyä peleissä kun prosessori on pullonkaulana. Mutta siihen pitää olla joko erittäin kallis näytönohjain tai grafiikat alennettuna tasolle peruna(tai ne on pelissä alunperinkin). Kun prosessori ei ole pullonkaulana, ei muisteista ole edes mitattavaa hyötyä. Sama koskee inteliäkin, tosin hyöty on jotain puolet mitä rusinalla. Edukkaan pelikoneen kasaajan ei kannata miettiä muistilatensseja ollenkaan, kunhan muistit ovat 3000-3200, se keskitason näytönohjain ei pysty niin korkeisiin fps-lukemiin että muistien erot tulisi esiin.

 

[hik]

Onhan näitä prosu pullonkaulana-pelejä. Ja ne on nyt jo kun prosut vasta kannetaan kaupasta ulos. Entä sitten 4 v päästä.
Kingdom come deliverancessa Ryzen 2600 ei itellä jaksa pitää 60 fps 1080p 1070ti. Testeissä AC Odyssey, 720p ultra 99% persentiili on joku 45 fps, gtx 1080.

 

[yberkurko]

Onhan näitä prosu pullonkaulana-pelejä. Ja ne on nyt jo kun prosut vasta kannetaan kaupasta ulos. Entä sitten 4 v päästä.
Kingdom come deliverancessa Ryzen 2600 ei itellä jaksa pitää 60 fps 1080p 1070ti. Testeissä AC Odyssey, 720p ultra 99% persentiili on joku 45 fps, gtx 1080.

Ainakin toi kingdom come on kai ihan perseelleen optimoitu. Käyttääköhän edes kaikkia säikeitä?

 

[hik]

Äskeisen Overclock3d linkin tuloksissa AC Odyssey 720p high:lla 8c16t nopeampi kuin 6c12t. Ultralla oli sama vauhti molemmissa, mistä sitten johtuukaan.

edit: sotkin nää 2 peliä keskenään. Kingdome come deliverance skaalautuu 8c 16t jos näyttis ei rajoita.

 

[KognaK]

Onhan näitä prosu pullonkaulana-pelejä. Ja ne on nyt jo kun prosut vasta kannetaan kaupasta ulos. Entä sitten 4 v päästä.
Kingdom come deliverancessa Ryzen 2600 ei itellä jaksa pitää 60 fps 1080p 1070ti. Testeissä AC Odyssey, 720p ultra 99% persentiili on joku 45 fps, gtx 1080.

Jos muisteista saisi 10% lisää niin olisko nuo pelit yhtään sen kummempia?

 

[Taneli-]

Edukkaan pelikoneen kasaajan ei kannata miettiä muistilatensseja ollenkaan, kunhan muistit ovat 3000-3200, se keskitason näytönohjain ei pysty niin korkeisiin fps-lukemiin että muistien erot tulisi esiin.

Uskoisin että ongelma on se että varsinkin ilmestymisen aikaan 2133 tai 2400 alkoivat olla lukuja mitä emolevyt ja prosessorit tukivat vaikka ostettuina olisikin 3200 muistit.
Esim. itselläni 32Gb (2x 16Gb 3200 kammat) ei alussa kovin kummoisesti kulkeneet 1700X prosessorilla. Olen saanut muistit toimimaan 2933 mutta en vielä kertaakaan 3200.

 

[hik]

No niin, mulla on Hynixit joten ei omaa kokemusta.
Mutta ajatus kulkee jotenkin niin, että mitä paremmin peli hyödyntää Ryzenin lisäytimiä, sen enemmän vuoropuhelua tarvitaan triidien kesken ja sen tärkeämpi olla b-die.
10 % IPC:ssä voi vastata 3 v tuotekehitystä.

 

[hkultala]

Jaetun muistin kanssa kyllä, mutta nopeuskriittinen muisti on prosessille privaattia tai kooderi on idiootti.

Koko peli pyörii tyypillisesti yhdessä prosessissa. Sen yhden prosessin eri säikeissä. Ei monessa eri prosessissa.

Niinkuin jälleen on aivan perusasiat hukassa.

Tai Windowsin scheluderi kuten on viimeaikoina käynyt ilmi. Jaetun muistin käyttö on toki hidasta mutta Ryzenin kanssakin jos scheluderi toimii fiksusti jaettua muistia käyttävät threadit on niputettu samaan CCX:ään jolloin toista CCX:ää ei tarvitse tarkistaa.

Ja jaetun muistin kanssa lienee suhteellisen yleistä että sitä löytyy myös toisen ytimen sisemmistä cacheista.

Sen toisen CCXn tagit pitää aina tarkastaa koska ei voida mitenkään tietää, mitä siellä toisella CCXllä on ajossa. Sillä on ihan täysi lupa säilöä saman fyysisen osoitteen sisältäviä välimusitilinjoja

Välimuistikoherenttius onraudan ominaisuus. Raudan pitääaina näyttää (toimivuuden kannalta) softalle siltä, kuin koko välimuistia ei olisi olemassakaan.

Zenin L3-huti on hidas privaatillekin muistille/yhden CCX:n prossuissakin.

Rauta ei erottele "privaattia ja jaettua" muistia toisistaan. Se toteuttaa aivan saman välimuistikoherenttiusprotokollan kaikelle muistille.

mutta Intelin prosessoreissa prefetch on niin aggressiivinen että muistien latenssi ei vaikuta juurikaan suorituskykyyn muuten kuin kokonaiskaistan muodossa, Ryzeneitten kanssa tilanne on toinen.

Höpöhöpö.

Prefetcher ei voi olla koskaan lähellekään täydellinen, koska jos tehdään jotain monimutkaisempaa(kuten pelit tekevät), tulee niitä välillä hakuja hyvin satunnaisiin osoitteisiin, ja prefetcher ei auta näissä yhtään. Prefetcher voi olla "täydellinen" jos tehdään jotain yksinkertaisia matriisioperatioita isoilla matriiseilla.

Toisekseen, olet käsittänyt kaistan ja viiveen suhteen aivan väärin. Siihen, kuinka kauan jonkun latauskäskyn suorittamiseen menee aikaa vaikuttaa suoraan nimenomaan viive, ei kaista. Kaistan vaikutus suorituskykyyn tulee nimenomaan sitä kautta. että jos kaista saturoituu, viive alkaa kasvamaan.

 

[Sami Riitaoja]

Koko peli pyörii tyypillisesti yhdessä prosessissa. Sen yhden prosessin eri säikeissä. Ei monessa eri prosessissa.

Niinkuin jälleen on aivan perusasiat hukassa.

Nyt täytyy sanoa että sulla on perusasiat hukassa. Ryzenissä on vain yksi L3-cache per 4 ydintä, 8:lle ytimelle ei ole yhteistä cachea. Mutta ei se herranjestas sitä tarkoita että joka muistihaun yhteydessä pitäisi snoopata muidenkin CCX:ien cachet. Joka threadi omaa privaatin muistin jota ei todellakaan ole käytössä muissa threadeissa. Sen lisäksi on jaettua muistia jolla threadit/prosessit synkronoidaan, mutta siinäkään kaksi eri threadia ei voi kirjoittaa samaa muistia yhtäaikaa tai kaikki hajoaa käsiin. Jaettu muisti lukitaan threadille joka sitä kirjoittaa ja synkronoidaan muiden threadien kanssa kun em. threadi on omassa privaatissa muistissaan tehnyt mitä nyt tekeekään.

Cache-coherency protokollista ja niiden optimoinneista voi kyllä jänkättää vaikka mitä mutta ne ei todellakaan liity muistilatensseihin.

Mutta eräshän tietty tarttui vain siihen että tuossa mun kirjoituksessa oli prosessi tuossa yhteydessä threadin sijaan, valtava virhe tuon ylläolevan perusasian rinnallla.

 

[Sami Riitaoja]

Ja jaetun muistin kanssa lienee suhteellisen yleistä että sitä löytyy myös toisen ytimen sisemmistä cacheista.

Jos meillä on multithreadattu koodinpätkä jossa yhtäaikaa ratkaistaan ongelmaa ja threadit synkronoidaan data jakamiseksi kumpikaan threadi ei todennäköisesti poistu ajovuorosta synkronointien ajaksi moniprosessorisysteemissä, cacheja ei flushata muistiin vaan threadit synkronoidaan suoraan cachesta cacheen. Intelin inklusiiivisissa L3-cacheissakin on tagit myös sisemmistä cacheista jotta data voidaan kysyä suoraan siltä ytimeltä jolla sen tiedetään olevan, ei se tarvittu data yleensä L3:ssa ole valmiina.

 

[hkultala]

Nyt täytyy sanoa että sulla on perusasiat hukassa.
Ryzenissä on vain yksi L3-cache per 4 ydintä, 8:lle ytimelle ei ole yhteistä cachea.

MISSÄÄN EN OLE VÄITTÄNYT ETTÄ KOKO VÄLIMUISTI OLISI KAIKILLE YTIMILLE YHTEINEN.

Että voisitko olla väittämättä että olisi sanonut jotain, mitä en ole sanonut. Mutta olkiukkoja on kiva piestä, kun on pihalla kuin lumiukko eikä ymmärrä niitä oikeita teknisiä yksityiskohtia.

Mutta ei se herranjestas sitä tarkoita että joka muistihaun yhteydessä pitäisi snoopata muidenkin CCX:ien cachet.

Se tarkoittaa juuri sitä.
Muuten luetaan vanha versio siitä datasta, kun joku toisen CCXn ydin on kirjoittanut sen datan päälle

Joka threadi omaa privaatin muistin jota ei todellakaan ole käytössä muissa threadeissa.

Niinkuin oikeasti, EI

Säikeen kaikki muisti on täysin muiden saman prosessin muiden säikeiden nähtävissä ja käytettävissä.

Siellä prosessin sisällä ei ole mitään erillisiä "privaatteja" ja "jaettuja" muisteja.

Se on juuri ero säikeen ja prosessin välillä. Prosesseilla on oma muistinsa, saman prosessin säikeillä yhteinen

Sen lisäksi on jaettua muistia jolla threadit/prosessit synkronoidaan, mutta siinäkään kaksi eri threadia ei voi kirjoittaa samaa muistia yhtäaikaa tai kaikki hajoaa käsiin.

Tässäkään et nyt ymmärrä eroa softassa olevien lukkojen ja raudalla olevan välimusitikoherenssiusmekanismin välillä. Sitä raudalla olevaa välimuistikoherenssiusmekanismia tarvittan että ne lukot toimii

Jaettu muisti lukitaan threadille joka sitä kirjoittaa ja synkronoidaan muiden threadien kanssa kun em. threadi on omassa privaatissa muistissaan tehnyt mitä nyt tekeekään.

Ei.

Molemmilla säikeillä on "privaattia" muistia ainoastaan oma pinonsa, mutta pino on hyvin pieni, ja se pinokaan ei oel sille oikeasti privaattia, se toinen säie pystyisi sitä toisenkin säikeen pinoa aivan hyvin accessoimaan. Esim. C-kielessä ottamalla &-operaattorilla osoitteen pinossa olevasta muuttujasta saa siihen pointterin.

Sitä dataa ei tarvi kopioida mihinkään kuvitteellsieen "privaattiin muistiin" että sitä voi käsitellä.

Jos vaikka monisäkeistetään numeronmurskaus, jossa käydään joku iso taulukko läpi ja muutetaan sen jokaista arvoa, voi kaksi säiettä aivan hyvin käpistellä tätä taulukkoa turvallisesti, eikä itse laskennan aika tarvita mitään synkronointia, kun toinen käsittelee vain parillisia rivejä, ja toinen vain parittomia rivejä.

Sitten siihen välimuistikoherenttiuden tarpeeseen: (tapaus false sharing)

Jos tilanne olisikin niin, että välimuistilinjan pituus olisi suurempi kuin rivin pituus. silloin molemmat lataisivat saman välimuistilinjan välimuisteihinsa yhtä aikaa, kirjoittaisivat sinne yhtä aikaa , merkkaisivat sen likaiseksi, ja molemmat haluaisivat kirjoittaa oman versionsa muistiin. Tällöin se viimeinen kirjoitus ylikirjoittaisi sen ensimmäisen tekevän kirjoituksen. (jos ei olisi välimuistikoherenttiutta)

CPUt ovat välimusitikoherentteja, ja ongelma ratkaistaan raudalla: SIinä vaiheessa kun yksi ydin kirjoittaa välimuistilinjaan, se invalidoidaan kaikilta muilta ytimiltä, ja kun toinen ydin haluaa käyttää saman välimuistilinjan dataa, se siirretään välimusitien välillä, toinen ydin saa päivitetyn version välimuistilinjasta ensimmäiseltä, ja kuntämä lopulta kirjoittaa sen muistiin, muistiin päätyy oikea data.

(toki tästä false sharingin kanssa tulee hirveä hidastuminen, hitaampi kuin yksiäikeinen versio, mutta tämä oli vain esimerkki yhdestä tilanteessa jossa välimusitikoherenttiutta tarvii, normaalisti data pyritään sijoittelemaan muistissa/työ jakamaan säikeiden välillä siten että false sharingisa ei esiinny)

Ja tosiaan, rauta ei tiedä mitään siitä, onko joku musiti softalle privaattia tai jaettua muistia. Välimuisti käsittelee vain fyysisiä muistiosoitteita, eikä piitta yhtään siitä, kenelle ne kuuluu tms. Sen pitää aina varautua siihen, että joku muu haluta käyttää samaa osoitetta. Rauta ei voi opitmoida sellaisten asioiden perusteella, mitä se ei voi tietää 100% varmuudella.

(Nykyisin markkinoilla olevilen prosesorien käskykannoissa) ei ole mitään sellaista rajapintaa, minkä kautta prosessin välimuistikoherenttiuslogiikalle voisi kertoa että "tämä data on privaattia tälle säikeelle.

(tosin itse olen miettinyt omaa käskykantaa, jossa tällainen tieto itse asiassa tietyssä rajoitetussa tilantessa olisi)


Tässä on nyt taas vahvana tämä:

Dunning–Kruger effect - Wikipedia

Toinen meistä on koodannut korkeintaan hello worldin verran, toinen luennoi yliopistossa rinnakkaisohjelmointia ja koodaa prosessorinsuunnittelutyökalun kääntäjää.

Cache-coherency protokollista ja niiden optimoinneista voi kyllä jänkättää vaikka mitä mutta ne ei todellakaan liity muistilatensseihin.

Kyllä ne liittyy, ei saada ladata dataa väärästä paikasta, jos jossain muualla on siitä samasta datasta uudempi, päivitetty versio. Ja ainoa keino, millä rauta voi tietää, että muualla ei ole samasta datasta uudempaa versiota on se välimusitikoherenttiusprotokolla.

Mutta eräshän tietty tarttui vain siihen että tuossa mun kirjoituksessa oli prosessi tuossa yhteydessä threadin sijaan, valtava virhe tuon ylläolevan perusasian rinnallla.

Jos prosessorin toimisivat, kuten kuvittelet niiden toimivan, mitä ne eivät tee, säikeen ja prosessin välillä olisi tuon kannalta hyvin oleellinen ero.

Mutta koska prosessorit eivät toimi, kuten kuvittelet, ei tällä ole väliä, koska ehdottamasi systeemi ei toimi kummankaan kanssa.

Ja sinulla on Juuri tuo mainitsemasi perusasia väärin.

 

[yberkurko]

* Seuraa jutun eskaloitumista huvittuneena*

Mitenhän tämä taas lähti näin käsistä

 

[Hellsinki]

Toivottavasti yhden ytimen suorituskyky olisi hyvä vihdoinkin.

On ollu jo pitkään riittävä mihin vain... Paitsi pasianssissa 2000fps saamiseen. Saa vain 1999fps

 

[Sami Riitaoja]

MISSÄÄN EN OLE VÄITTÄNYT ETTÄ KOKO VÄLIMUISTI OLISI KAIKILLE YTIMILLE YHTEINEN.

Että voisitko olla väittämättä että olisi sanonut jotain, mitä en ole sanonut. Mutta olkiukkoja on kiva piestä, kun on pihalla kuin lumiukko eikä ymmärrä niitä oikeita teknisiä yksityiskohtia.

"Ryzenissä on kaksi L3:a joista toinen nopea, toinen hidas" Ei ole vaan kahdella neljän ytimen ryppäällä on kummallakin oma L3, toisen ytimen data ei mene toisen L3:een ellei se ole jaettua dataa.

Se tarkoittaa juuri sitä.
Muuten luetaan vanha versio siitä datasta, kun joku toisen CCXn ydin on kirjoittanut sen datan päälle

Mieti nyt vähän vaikka moniprosessorivehkeitä. Olisivat todella nopeita jos kaikki cachet snoopattaisiin jokaisen muistihaun yhtedessä.

Niinkuin oikeasti, EI

Säikeen kaikki muisti on täysin muiden saman prosessin muiden säikeiden nähtävissä ja käytettävissä.

Siellä prosessin sisällä ei ole mitään erillisiä "privaatteja" ja "jaettuja" muisteja.

Se on juuri ero säikeen ja prosessin välillä. Prosesseilla on oma muistinsa, saman prosessin säikeillä yhteinen

Oma muistiavaruus. Kyllä vaan threadien paikalliset muuttujat on per thread.

Sitä dataa ei tarvi kopioida mihinkään kuvitteellsieen "privaattiin muistiin" että sitä voi käsitellä.

Kuten sanoin aikaisemmin jos kooderi on idiootti niin kaikki data on jaettua. Muistihan on prosessorille privaattia jos sitä ei ole käytössä muualla.

Jos vaikka monisäkeistetään numeronmurskaus, jossa käydään joku iso taulukko läpi ja muutetaan sen jokaista arvoa, voi kaksi säiettä aivan hyvin käpistellä tätä taulukkoa turvallisesti, eikä itse laskennan aika tarvita mitään synkronointia, kun toinen käsittelee vain parillisia rivejä, ja toinen vain parittomia rivejä.

Aivan, kooderinhan se on hoidettava threadien yhteisen datan jakaminen. Tässä ei mitään tarvetta snoopata toisen ytimen cacheja.

Sitten siihen välimuistikoherenttiuden tarpeeseen: (tapaus false sharing)

Jos tilanne olisikin niin, että välimuistilinjan pituus olisi suurempi kuin rivin pituus. silloin molemmat lataisivat saman välimuistilinjan välimuisteihinsa yhtä aikaa, kirjoittaisivat sinne yhtä aikaa , merkkaisivat sen likaiseksi, ja molemmat haluaisivat kirjoittaa oman versionsa muistiin. Tällöin se viimeinen kirjoitus ylikirjoittaisi sen ensimmäisen tekevän kirjoituksen. (jos ei olisi välimuistikoherenttiutta)

Tästä voitaneen olla ihan yhtä mieltä.

Ja tosiaan, rauta ei tiedä mitään siitä, onko joku musiti softalle privaattia tai jaettua muistia. Välimuisti käsittelee vain fyysisiä muistiosoitteita, eikä piitta yhtään siitä, kenelle ne kuuluu tms. Sen pitää aina varautua siihen, että joku muu haluta käyttää samaa osoitetta. Rauta ei voi opitmoida sellaisten asioiden perusteella, mitä se ei voi tietää 100% varmuudella.

Ja miksi se ei tietäisi? Mitä jos pistetään jokaiseen välimuistilinjaan tieto siitä onko cachelinja käytössä vai ei. Privaatin tapauksen kanssa kirjoitus cacheen ei tarvii mitään toimenpidettä minnekään muualle kun tiedetään että muisti ei ole missään muualla käytössä. Jos nyt toinen threadi/prosessi haluaa käyttää samaa välimuistilinjaa broadcastataan tieto muillekin em. linjaa käyttäville jotta kirjoitukset aiheuttavat linjan päivityksen kaikkiin käyttöpaikkoihin. Jos moniprosessorikoodista aiotaan jotain nopeusetuakin saada on käytetty muutettava muisti syytä olla pääosin privaattia.

(Nykyisin markkinoilla olevilen prosesorien käskykannoissa) ei ole mitään sellaista rajapintaa, minkä kautta prosessin välimuistikoherenttiuslogiikalle voisi kertoa että "tämä data on privaattia tälle säikeelle.

Ja miksi pitäisi olla? Jos se muisti on threadissa varattua eikä sitä jaeta niin se pysyy privaattina kunnes threadi tapetaan.

Kyllä ne liittyy, ei saada ladata dataa väärästä paikasta, jos jossain muualla on siitä samasta datasta uudempi, päivitetty versio. Ja ainoa keino, millä rauta voi tietää, että muualla ei ole samasta datasta uudempaa versiota on se välimusitikoherenttiusprotokolla.

Ja sinun ratkaisu olisi snoopata joka muistihaun yhteydessä kaikki cachet läpi? Et kovin nopeita prosessoreita saa aikaiseksi

 

[Sami Riitaoja]

Tässä on nyt taas vahvana tämä:

Dunning–Kruger effect - Wikipedia

Toinen meistä on koodannut korkeintaan hello worldin verran, toinen luennoi yliopistossa rinnakkaisohjelmointia ja koodaa prosessorinsuunnittelutyökalun kääntäjää.

Toinen meistä kuitenkin tuntee MESI-protokollan

Kuinkahan hyvin tuo sun efekti kuvaa prosessorisuunnittelijaa jolta moinen menee yli hilseen ja jaksaa selittää selvästä aiheesta vaikka ja mitä samalla muita solvaten

 

[hkultala]

edit: nyt alkaa olla editoitu kasaan.

"Ryzenissä on kaksi L3:a joista toinen nopea, toinen hidas" Ei ole vaan kahdella neljän ytimen ryppäällä on kummallakin oma L3, toisen ytimen data ei mene toisen L3:een ellei se ole jaettua dataa.




Mieti nyt vähän vaikka moniprosessorivehkeitä. Olisivat todella nopeita jos kaikki cachet snoopattaisiin jokaisen muistihaun yhtedessä.

Voi huoh.

Perinteinen snooppaus ei edes sellaisenaan toimi nykyaikaisilla väylärakenteilla, koska jonkun core2n jälkeen ei ollut mitään yhtä väylää, jota voisi snoopata.

Minä en ole sanallakaan mielestäni puhunut mitään mistään snooppaamisesta.

Vaan se välimusitikoherenttiusprotokolla on nykyään aika paljon monimutkaisempi ja fiksumpi, ja toteutusyksityiskohdat vaihtelee selvästi eri prossujen välillä.

Aina kun jonkun muistiosoitteen sisältämää dataa halutaan muistista, tarvii tietää, onko se jo likaisena josain välimuistissa, mutta sitä tietoa ei tarvi hakea sieltä toiselta välimuistilta asti, koska tästä niiden muiden välimuistien likaisisten lohkojen krijanpidosta voidaan pitää lähempänä olevia kopioita.
Mutta sitten tämän kirjanpidon ylläpitämisestä tulee kuitenkin paljon liikennettä, ja ne kirjanpidon ylimääräiset kopiot vie paljon tilaa.

Tyypillinen kehittyneempi ratkaisu on hakemistopohjainen välimuistikoherenssi. Huonona puolena on se, että tuon kirjaston tietorakenteet on isoja, se vaatii pajon (S)RAMia.
Todennäköisesti huomattava osa Romen IO-piirin pintaa-alasta menee juuri tähän.

Directory-based coherence - Wikipedia

Oma muistiavaruus. Kyllä vaan threadien paikalliset muuttujat on per thread.

Mikään ei estä toisia säikeitä ronkkimasta niitä toisen säikeen paikallisia muuttujia, ja se on aivan sallittua koodia C-kielellä, niin kauan kun sen paikallisen muuttujan sisältävästä funktiosta ei ole poistuttu.


Esimerkkikoodi, ei ole käännetty eikä testattu ja sisältää todennäköisesti muutaman pikkuvirheen.

Tässä tuo luotu säie jää looppaamaan, kunnes sen paikallisen muuttujan arvo muuttuu. Ja sitä muutetaan ulkopuolelta, pääsäikeestä.

void myFunc0(int** ptr) {
int myLocalVar = 0;
*ptr = &myLocalVar; // store pointer to my local variable to the external pointer
 while (ptr == 0) {
    /* still looping */
}

}

void anotherFunc(int* ptr) {
    *ptr = 1; // write one to the pointer.
}

void main() {

pthread_t myThread;
int* ptr;
pthread_create( myThread,  NULL, &myFunc, &ptr),

anotherFunc(ptr);

pthread_join(myThread, NULL);

}

Kuten sanoin aikaisemmin jos kooderi on idiootti niin kaikki data on jaettua.

Ei, vaan jos koodari on idiootti niin koodari kopioi aivan turhaan dataa edestakaisin.

Sinulla ei ole mitään pätevyyttä arvioida koodarien idioottiutta kun tiedät koodaamisesta paljon vähemmän kuin edes idioottikoodarit.

Muistihan on prosessorille privaattia jos sitä ei ole käytössä muualla.

VOi huoh. Voisitko nyt ottaa yhtään selvää, mistä höpiset?

Kaikki normaalit pienehköt, yhteen laatikkoon mahtuvat , moniprosessorijkärjestelmät toimivat ohjelmointimallin kannalta SMP-periaatteella. jaetulla muistimallilla. Kaikki muisti on nimenomaan oletuksena jaettua systeemin sisällä.

Tälle kilpaileva moniprosesorointimalli on sitten viestinvälitys, jossa kaikilla on oma muistinsa ja sitten erikseen viesteillä lähetellään dataa muille. Sitä käytetään vain hyvin järeissä, tuhansien ytimien supertietokoneissa, ja niissäkin muutama ydin on yleensä tyypillisesti keskenään SMP.

OpenCL sitten määrittelee myös muistimallin, jossa on myös sekä work-itemille omaa muistia(private) että work-gropille omaa muistia (local), mutta tämä on irrelevanttia sen kannalta, miten C-kielisiä ohjelmia ajamaan kykenevä käyttöjärjestelmä ja prosessori ajavat normaaleita ohjelmia.

Aivan, kooderinhan se on hoidettava threadien yhteisen datan jakaminen. Tässä ei mitään tarvetta snoopata toisen ytimen cacheja.

Paitsi että se rauta ei mistään voi ennakolta tietää, aikovatko ne kaksi eri säiettä käyttää samassa välimuistilonjassa olevaa dataa, tai onko siellä vielä jollain kolmannella ytimellä joku säie, joka käyttää samassa välimusitiliinjassa olevaa dataa.

Sen raudan täytyy toteuttaa joku välimuistikoherenttiusprotokolla, joka huolehtii, että samaa välmuistilinjaa ei ole likaisena monessa eri välimusitilinjassa, jatoteuttaa lisäksi käskykantaspeksin mukaiset konsistenttiussäännöt.

Ja miksi se ei tietäisi? Mitä jos pistetään jokaiseen välimuistilinjaan tieto siitä onko cachelinja käytössä vai ei.

Mitähän nyt tarkoitat "jokaisella välimuistilinjalla" ?

Tietysti siellä välimuistissa on täytyy olla kirjanpito siitä, mitä se sisältää. (kutsutaan yleensä nimellä tag)

Mutta jos haluat alkaa jäljittämään koko systeemin osoitteista, että onko ne jossain jonkun muun välimuistissa, niin:

Zen taitaa tukea ainakin 2 teratavua fyysistä muistia.
välimuistilinja on 64 tavua. Eli koko fyysinen muistiavaruus jakautuu 32 miljardiin välimuistilinjaan.

Että jos ehdotat noin suoraviivaista ratkaisua, niin saat lisätä sinne prosessorille 4 gigatavun verran sitä kirjanpitoa.

Tähän on hiukan fiksumpia ratkaisuita, joissa sen kirjanpidon määrä pysyy inhimillisenä. Mainitsin tuossa ylempänä jo tuon hakemistopohjaisen koherenttiusprotokollan periaatteen.

Privaatin tapauksen kanssa kirjoitus cacheen ei tarvii mitään toimenpidettä minnekään muualle kun tiedetään että muisti ei ole missään muualla käytössä.

Ei tiedetä, missään x86-järjestelmässä ei oel mitään privaattia musitia. Kaikki muisti on jaettua koko systeemin kesken. X86 on SMP. ARM on SMP. Kaikki normaalit CPU-arkkitehtuurit on SMP.

Ainoa, missä se tiedetään on se välimusitikoherenttiusprotokolla. Sen välimuistikoherenttiusjärjestelmän kirjanpito merkitsee sen lohkon privaatiksi, jos sitä ei sillä hetkellä ole muussa välimuistissa. Ja sitten kun siihen kirjoitetaan, se merkitään myös likaiseksi.

Jos nyt toinen threadi/prosessi haluaa käyttää samaa välimuistilinjaa

Ei , vaan joku toinen VÄLIMUISTI haluaa osoittaa samaan osoitteeseen.

ja välimuistin koherenssiprotokolla huomaa tämän.

broadcastataan tieto muillekin em. linjaa käyttäville jotta kirjoitukset aiheuttavat linjan päivityksen kaikkiin käyttöpaikkoihin.

Ne "muut" tiedetään tasan tarkkaan vain sen välimuistin koherenssiusprotokollan kautta. Ja ne muut on muita välimuisteja.

Ei prosesseja eikä säikeitä.


Ja käyttöjärjestelmä voi myös koska tahansa siirtää sen säikeen ajautumaan toiselle ytimelle.

Jos moniprosessorikoodista aiotaan jotain nopeusetuakin saada on käytetty muutettava muisti syytä olla pääosin privaattia.

... että voidaan aivan turhaan tuhlata aikaa ja kaistaa turhaan muistin kopiointiin edestakaisin. Niillä ytimillä on välimuistit sitä varten, että liikenne siihen dataan, mitä sillä hetkellä käsitelläöän on nopeaa.

Ja mikään normaali SMP-periaatteella tarjoava yleiskäyttöinen moniprosessorijärjestelmä ei tarjoa mitään "privaattia " muistia joka olisi mitenkään raudalla eroteltu "jaetusta" muistista. Prosessorin näkökulmasta se kaikki on aivan samanlaista muistia.

Ja miksi pitäisi olla? Jos se muisti on threadissa varattua eikä sitä jaeta niin se pysyy privaattina kunnes threadi tapetaan.

Rauta ei tiedä, mikä muisti on "privaattia" ja mikä ei ole "privaattia".

Tai ainoa keino miten se tietää sen, on välmuistikoherenttiusprotokollan kautta.

Ja sinun ratkaisu olisi snoopata joka muistihaun yhteydessä kaikki cachet läpi? Et kovin nopeita prosessoreita saa aikaiseksi

Minä en ole sanallakaan puhunut mitään mistään snooppaamisesta. Sinä sen sijaan höpiset siitä jatkuvasti ja tunget sitä sanaa minulle suuhun.

Vaan että vaaditaan jonkinlainen välimuistin koherenttiusprotokolla jolla varmistutaan, ettei data ole muissa välimuisteissa.

Minä ymmärrän, mitä raudalta vaaditaan, että ohjelmat toimivat.
Minä olen oikeasti koodannut monisäikeisiä ohjelmia.

Minä olen myös ollut pääsuunnittelijana pienen 4-ydin-signaaliprosessorin arkkitehtuurissa (työkaverit sitten suunnittelivat RTL-toteutuksen). Siinä tosin ei ollut välimuistikoherenttiutta, koska siinä OLI sinun kaipaamasi privaattimuistit, eikä ollenkaan välimuistia yhteiselle isolle muistille. ja juuri niiden privaattimuistien takia sillä ei voinut ollenkaan ajaa C-kielisiä normaaleilla säikeistysrajapinnoilla(pthread ja muut vastaavat) tehtyjä monisäikeistettyä ohjelmia vaan sitä ohjelmoitiin OpenCL:llä.

http://www.almarvi.eu/assets/almarvi_d3.5_final_v10.pdf

 

[Sami Riitaoja]

edit: oikeasti tämä viesti on kesken, lähti vahingossa.



Voi huoh.

Perinteinen snooppaus ei edes sellaisenaan toimi nykyaikaisilla väylärakenteilla, koska jonkun core2n jälkeen ei ollut mitään yhtä väylää, jota voisi snoopata.

Vaan se välimusitikoherenttiusprotokolla on nykyään aika paljon monimutkaisempi ja fiksumpi, ja toteutusyksityiskohdat vaihtelee selvästi eri prossujen välillä.

Aina kun jonkun muistiosoitteen sisältämää dataa halutaan muistista, tarvii tietää, onko se jo likaisena josain välimuistissa, mutta sitä tietoa ei tarvi hakea sieltä toiselta välimuistilta asti, koska tästä niiden muiden välimuistien likaisisten lohkojen krijanpidosta voidaan pitää lähempänä olevia kopioita.
Mutta sitten tämän kirjanpidon ylläpitämisestä tulee kuitenkin paljon liikennettä, ja ne kirjanpidon ylimääräiset kopiot vie paljon tilaa.

Tyypillinen kehittyneempi ratkaisu on hakemistopohjainen välimuistikoherenssi. Huonona puolena on se, että tuon kirjaston tietorakenteet on isoja, se vaatii pajon (S)RAMia.
Todennäköisesti huomattava osa Romen IO-piirin pintaa-alasta menee juuri tähän.

Directory-based coherence - Wikipedia

Jänkääminen vain jatkuu. Välimuisticoherenttiuden eri viritelmiä tarvitaan sen jaetun(S) muistin tilanteen kirjoilla pitämiseen ja käyttämisen nopeuttamiseen. Jos ja kun data pääosin on privaattia(E) mitään tarkistuksia mihinkään suuntaan ei tarvii tehdä dataa käsiteltäessä. Jaettu muisti hidasta, privaatti nopeaa. Jos halutaan monisäikeistyvän softan nopeuttavan eikä hidastavan niin käytämme mahdollisimman paljon privaattia muistia ja jaettua vain pakollisen. Jaetussa muistissa on aina muutakin ongelmaa kuin välimuistikoherenttius, deadlockit, race condition yms.

Mikään ei estä toisia säikeitä ronkkimasta niitä toisen säikeen paikallisia muuttujia, ja se on aivan sallittua koodia C-kielellä, niin kauan kun sen paikallisen muuttujan sisältävästä funktiosta ei ole poistuttu.

No ei olekaan. Heti kun toinen ydin varaa muistilohkon sen tila muuttuu jaetuksi. Aivan sallittua mutta pitää tasan tarkkaan tietää mitä tekee tai mikään ei kohta toimi.