AMD antoi CES 2019 -messuilla ensimaistiaiset tulevista 3. sukupolven Matisse-koodinimellisistä Ryzen-prosessoreista, jotka perustuvat Zen 2 -arkkitehtuuriin. Esittely jätti ilmoille kuitenkin monta kysymystä koskien mahdollisia tulevia prosessorimalleja.
Eniten kysymyksiä uusissa Ryzen-prosessoreissa on herättänyt sen alustalle jäänyt tyhjä tila, johon mahtuisi toinen Zen 2 -pikkupiiri täynnä prosessoriytimiä. Esillä oli kuitenkin vain yhdellä pikkupiirillä varustettu malli, eikä lavalla luvattu muuta.
Myöhemmissä haastatteluissa Lisa Su kuitenkin vihjasi, että lisää olisi tulossa. PCWorldin mukaan Su totesi yhtiöllä olleen aina ydinmäärässä etua, joten tällä kertaa valittiin tasaväkinen 8 ytimen ja 16 säikeen vertailu. Hän lisäsi vielä piirillä olevan tilaa enemmällekin ja että hän uskoo ihmisten odottavan että heillä olisi yli kahdeksan ydintä. Su kuitenkin muotoili sanansa siten, että ne voi tulkita moneen tapaan, joten voit lukea ne sanasta sanaan alla olevasta lainauksesta.
Reporter: So during the keynote, somebody messaged me about the core counts on Ryzen…
Su: So it only took like 30 minutes for somebody [to ask the question]!
Reporter: So can you give us any indication where Ryzen third-gen is going to be at?
Su: If you look at the evolution of Ryzen, we’ve always had an advantage in core count, and so in this particular case we wanted to show sort of a head-to-head comparison: eight cores, 16 threads. Some people may have noticed on the package that there’s some extra room.
Reporter: Yes, we’ve already done the math.
Su: So there is some extra room on that package. And I think you might expect that we will have more than eight cores. I didn’t say how many more.
Reporter: And two memory channels will be enough?
Su: As I said, more to come.
Tyhjä tila ja Sun kommentit nostivat jälleen esiin aiemmin netissä pyörineitä väitettyjä tietoja tulevista prosessoreista ja niiden eri mallien konfiguraatioista. Osa väitetyistä vuototiedoista osoittautui kuitenkin nopeasti vääriksi, koska luvatut esittelyajankohdat eivät pitäneet paikkaansa, ja nyt niille on antanut viimeisen niitin Anandtech, joka on saanut AMD:lta varmistuksen, ettei Matissesta tule versiota, jossa olisi kolmantena piirinä I/O- ja prosessoripiirien lisäksi grafiikkapiiri. Yhtiön mukaan Zen 2 -APU-piirejä on tulossa myöhemmin, mutta ne rakennetaan eri suunnittelua käyttäen.
Samassa yhteydessä AMD:n edustajat varmistivat, että 3. sukupolven Ryzen-prosessorien TDP-arvot tulevat vastaamaan toisen sukupolven prosessoreita. Käytännössä tämä mahdollistaa TDP-arvot 35 watista 105 wattiin.
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.
Nyt joudun olemaan kanssasi hieman eriävää mieltä. Kun suurimmat kuluerät on kehitys ja tuotantolinjojen rakentaminen yms. niin yksittäisen chipletin 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, 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.
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
Eikös tohom mahtuisi hbm2 muistia joku 16GB-32GB?.:kahvi:
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
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ä.
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.
![[IMG]](http://semimd.com/wp-content/uploads/2017/01/cost-projections.jpg)
Innovations at 7nm to Keep Moore’s Law Alive | Semiconductor Manufacturing & Design Community
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?
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. …
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ä.
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)
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.
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ä.
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.
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.
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.
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.
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.
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.
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.
:facepalm:
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.[/QUOTE]
höpöhöpö.
Zenin pelisuorituskykyä hidastaa mm. hidas L3-huti (mm. toisen CCXn tagien tarkastus, ja sen jälkeen lataus sieltä tai DRAMilta)
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 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.
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.
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.
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.
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.
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.
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ä?
Äskeisen Overclock3d linkin tuloksissa 720p high:lla 8c16t nopeampi kuin 6c12t. Ultralla oli sama vauhti molemmissa, mistä sitten johtuukaan.
Jos muisteista saisi 10% lisää niin olisko nuo pelit yhtään sen kummempia?
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.
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ä.
:facepalm:
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.
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.
:facepalm:
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.
Se tarkoittaa juuri sitä.
Muuten luetaan vanha versio siitä datasta, kun joku toisen CCXn ydin on kirjoittanut sen datan päälle
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
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
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ää.
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.
:facepalm:
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.
:kahvi:* Seuraa jutun eskaloitumista huvittuneena*
Mitenhän tämä taas lähti näin käsistä :rofl:
On ollu jo pitkään riittävä mihin vain… Paitsi pasianssissa 2000fps saamiseen. Saa vain 1999fps
"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ä.
Oma muistiavaruus. Kyllä vaan threadien paikalliset muuttujat on per thread.
Kuten sanoin aikaisemmin jos kooderi on idiootti niin kaikki data on jaettua. Muistihan on prosessorille privaattia jos sitä ei ole käytössä muualla.
Aivan, kooderinhan se on hoidettava threadien yhteisen datan jakaminen. Tässä ei mitään tarvetta snoopata toisen ytimen cacheja.
Tästä voitaneen olla ihan yhtä mieltä.
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.
Ja miksi pitäisi olla? Jos se muisti on threadissa varattua eikä sitä jaeta niin se pysyy privaattina kunnes threadi tapetaan.
Ja sinun ratkaisu olisi snoopata joka muistihaun yhteydessä kaikki cachet läpi? Et kovin nopeita prosessoreita saa aikaiseksi 😀
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 😀
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
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); }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.
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.
Entäs moderneilla ohjelmointikielillä?
Tälläinen ei kyllä kuulosta joltain, mitä kukaan tuottavaa ohjelmointityötä tekevä haluaisi tehdä. Itseasiassa C-koodin käyttäminen johonkin muuhun kuin sulautettuun järjestelmään ei kuulosta joltain, mitä kukaan haluaa tehdä työasema tai palvelinympäristössä 🙂
Ainakin minä tunnen sen, mutta minä tiedän myös että MESI on viime vuosituhatta, ja nykyisin on käytössä selvästi kehittyneempiä välimuistikoherenttiusprotokollia-
MESI ei mene minulta yhtään yli hilseen.
Käy vaan ärsyttämään kun tyyppi joka on aivan perusasioista aivan pihalla, mutta on opetellut muutaan kehittyneen nippelitiedon (muttei ymmärrä, mikä niiden merkitys on, koska ei ymmärrä perusasioita niden ympäriltä) tulee inttämään ihan typeriä.
Kaikkein normaalien käyttöjärjestelmien muistinsuojausmallit yms. perustuvat C-kieleen. Käyttikset eivät suojaa saman prosessin eri säikeiden pinoja toisiltaan, jotta rumasti kirjoitetut C-kieliset ohjelmat toimivat.
Toki monissa "kehittyneemmissä kielissä" ei edes ole normaalia monisäikeistystä ollenkaan. Suorituskyky kiittää.
MESIF, MOESI jne, sanoinhan tuolla aikaisemmin että välimuistikoherenttiusprotokollista voi turista vaikka mitä. Kaikki ne tekevät kuitenkin sen mitä MESI:kin, eli merkataan jaettu data ja pidetään privaatti nopeana jotta ei tarvii tehdä sitä kaikkien cachejen snooppausta jokaisen muistihaun yhteydessä, ainoastaan jaettujen.
Kuten että jokaisen muistihaun yhteydessä snoopataan kaikki cachet? Ymmärrätkö edelleenkään että jos käytetty data on privaattia, eli se on luettu vain yhden ytimen cacheen sitä luettaessa ja kirjoitettaessa ei tarvitse välittää yhtään mitä muut ytimet tekevät? Tämähän oli se pointti jota vastaan vänkäät henkeen ja vereen.
Mutta modernit pelimoottorit ja käytännön softa eivät perustu C-kieleen eivätkä sisällä suurella todennäköisyydellä rumasti kirjoitettua C-kieltä. C++:lla toki saa edelleen tehdä kaikki C-kielen idioottimaisuudet, mutta kaupallisessa ohjelmistotuotannossa nuo idiotismit (esim. muistin sörkkiminen pointtereilla) löytyvät erittäin suurella tödennäköisyydellä tyylioppaan ehdottomasti kielletyt osiosta.
Jopas sinulla on ruusuinen kuva maailmasta.
Melkein kaikki sisältää pellin alla paljon rumasti kirjoitettua C-kieltä. Niitä "uudempia kehittyneempiä kieliä" ajetaan virtuaalikoneissa tai tulkeissa, jotka on kirjoitetu (rumasti) Cllä/C++lla.
Ja ne uudet "kehittyneemmät kielet" kutsuvat monien suorituskykykriittisten rutiiniensa toteutuksessa (rumia) C/C++-kielellä koodattuja natiivirutiineita.
Ja ainakin niitä ajetaan käyttöjärjestelmällä, jonka muistimalli on tehty C/C++aa silmälläpitäen. Ja se käyttöjärjestelmän ydin on ainakin koodattu Cllä tai C++lla.
Mitä suorituskykykriittempää koodi on, sitä enememän siellä rikotaan tyylioppaita vastaan. Kernelit, virtuaalikoneet/tulkit, pelimoottoreiden graffanpiirtorutiinit.
Voi huoh.
Siinä MESIssä se kirjanpito jokaisella välimuistilla on vain niistä välimuistilohkoista, jotka sieltä omasta välimuistista löytyy. Kaiken prosessorin tukeman fyysisen muistin kirjanpito veisi zenillä sen 4 gigaa tilaa (jos vain yksi bitti, että muualla on/ei ole likaisena)
Jos se lohko löytyy sieltä välimuistista, ei sitä tarvi ladata yhtään mistään ulommasta muistista.
Jos taas se tarvii ladata ulommasta muistista, siitä ei (MESIssä) ole meillä kirjanpitotietoa.
MESIssä ei ole mitään sellaista tilannetta, että dataa ei ole omassa välimuistissa, ja se pitää ladata DRAMIlta, mutta tiedetään, että sitä ei ole muussa välimuistissa
Koko ajan olet höpissyt privaateista muisteista (ja selittänyt kuinka niiden takia ei tarvita mitään välimusitin koherenttiusprotokollaa) ja nyt sitte kerrot, että tarkoitat sillä MESI-protokollan E-tilaa.
Vaiktuttaa melko vahvalta maalitopllien siirtelyltä, tai joko hyvin huonolta selittämiseltä.
Jos välimuisti osuu, ei tietenkään tarvi tarkastaa mitään muista välimuisteista. Mutta jos välimusti osuu, ei olla lataamassa mitään DRAM-muistista.
Jos välimuisti ei osu, ei meillä ole myöskään mitään kirjanpitotietoa siitä, onko sitä kyseistä osoitetta muissa välimuisteissa, ja pitää tarkastaa, onko sitä muissa välimuisteissa.
Nykyään noissa tehdään just-in-time käännös ei tulkata. Javalla nyt tosin ei kukaan pelejä kirjoita. Unity on ainakin ulospäin C#, sisällä toki voi löytyä C++ rutiineja. Pointti nyt oli, että tuotantosofta ei aina ole optimoitu viimeisen päälle ja vähintäänkin kaikenlaista pointteriaritmetiikkaa vältelllään kuin ruttoa, koska se aiheuttaa kalliita bugeja (rauta on usein halvempaa kuin kalliit bugit).
Tai hotspot-käännös. Ja rutiineita, joita ajetaan enemmän, käännetään uudestaan järeämmät optimoinnit päällä. Ja se (C/C++lla koodattu) ajoympäristö joka sen kääntäjän sisältää, ehkä vielä profiloi sitä, mitkä on niitä kriittisiä rutiineita, jotka kannattaa kääntää uudestaan järeämmät optimoinnit päällä. Ja tämä profilointi voi olla melkoisen rumaa toisen säikeen pinon ronkkimista. Ja sen profiloinnin takia sinne generoituun koodiin saatetaan myös lisätä kaikkea "rumaa" joka tekee hassuja temppuja esim. juuri sillä pinolla.
Ja jos jit-käännöstä tehdään funktio kerrallaan, ja erityisesti vielä jos käytössä on dynaamista sitomista, funktiokutsuihin voi tulla hyvin jännää koodia.
Se jit- tai hotspot-käännetyn "kehittyneemmän kielen" natiivikoodi sisältä helposti paljon enemmän kaikkia "rumia temppuja" kuin mitä keskimääräinen C-ohjelma, koska se jit-/hotspot-kääntäjä on kikkaillut sinne vaikka mitä. C/C++-kieli taas määrittelee hyvin tarkkaan esimerkiksi suurimman osin muistiaccesseista ja niiden järjestyksen, eikä kääntäjä voi kikkailla kovin paljoa, vaikka siinä itse lähdekoodissa kikkailuita voikin olla enemmän.
Mutta sitä tuotantosoftaa ajetaan ympäristöissä, joissa alla on palasia, jotka sisältää sitä rumaa tappiin asti optimoitua koodia. Ja sitä ajetaan sen tuotantosoftan prosessissa.