AMD Ryzen -prosessori (Summit Ridge)

Liittynyt
17.10.2016
Viestejä
256
Miksi tää 14nm prosessi vaatii näin kovia jänöjä suhteessa 32nm Bulldozeriin tai Sandy Bridgeen tai vaikkapa 22nm Haswelliin?
 
Liittynyt
16.10.2016
Viestejä
312
Miksi tää 14nm prosessi vaatii näin kovia jänöjä suhteessa 32nm Bulldozeriin tai Sandy Bridgeen tai vaikkapa 22nm Haswelliin?
Koska Ryzeneissa käytettävissä kellotaajuuksissa 14nm LPP toimii jo reilusti sen optimitaajuusalueen ulkopuolella (~2-3.1GHz), jolloin jännitettä tarvitaan enemmän vakaan kellotaajuuden saavuttamiseen. Bulldozerin 32nm SOI, ja Sandyssä ja Hasswellissa käytetyt prosessit olivat HP (High Performance) prosesseja, eli niiden optimitaajuusalue oli huomattavasti korkeampi. Tietysti sopassa on mukana vielä arkkitehtuuri, ja mutuna heittäisin, että osasyy Ryzenin huonohkoon ylikellottumiseen on L3 tason välimuistin ajaminen ytimen taajuudella kaikissa tilanteissa.
 
Liittynyt
22.10.2016
Viestejä
6 433
Koska Ryzeneissa käytettävissä kellotaajuuksissa 14nm LPP toimii jo reilusti sen optimitaajuusalueen ulkopuolella (~2-3.1GHz), jolloin jännitettä tarvitaan enemmän vakaan kellotaajuuden saavuttamiseen. Bulldozerin 32nm SOI, ja Sandyssä ja Hasswellissa käytetyt prosessit olivat HP (High Performance) prosesseja, eli niiden optimitaajuusalue oli huomattavasti korkeampi. Tietysti sopassa on mukana vielä arkkitehtuuri, ja mutuna heittäisin, että osasyy Ryzenin huonohkoon ylikellottumiseen on L3 tason välimuistin ajaminen ytimen taajuudella kaikissa tilanteissa.
Valmistusprosessilla ei ole mitään "optimitaajuusaluetta". Se on aina täysin arkkitehtuurikohtaista.


Saavutettu kellotaajuus on kolmen asian yhteisvaikutus(lähinnä kerto-/jakolasku)

1) Arkkitehtuuri, käytännössä liukuhinnan pituus, pitkä liukuhinna(lyhyemmät liukuhihnavaiheet) kellottuu paremmin (esim. P4). Tarkemmin ottaen pisimmän liukuhihnavaiheen pisimmän kriittisen polun pituus on se mikä kelloa rajoittaa.

2) Valmistusprosessi

3) Olosuhteet (lähinnä jännite, lämpötila)

Zen ja Polaris valmistetaan samalla valmistustekniikalla, mutta Zenin liukuhihnavaiheet ovat selvästi lyhyempiä kuin Polariksen liukuhihnavaiheet, ja tämä on ylivoimaisesti suurin syy miksi Zenissä puhutaan yli 3 GHz taajuuksista ja polariksessa n. 1.5 Ghz taajuuksista.


Jos vaikka jonkun K5:n valmistaisi tuolla samalla "14nm" prosssoilla, kellottuisi se hädin tuskin 1.2 GHz:aan, koska sen liukuhihnavaiheet ovat niin pitkiä.

Toisaalta, jos vaikka jonkun P4n valmistaisi tuolla samalla "14nm" prosessilla, kellottuisi se helpolla "normaaliolosuhteissa" jonnekin >5.5 GHz luokkaan, koska sen liukuhihnavaiheet ovat niin lyhyitä.
 

Dygaza

Platinum-jäsen
Liittynyt
28.10.2016
Viestejä
638
Onko jossain selitetty, mitä tuo downcore tarkoittaa? Kahden eri CCX:n ytimiä vai SMT:tä?

edit:
ilmeisesti ytimiä, 1+1 tarkoittaa että molemmista CCX:stä yksi ydin?
ja 2+0 tarkoittaa että toinen CCX pois päältä ja toisesta 2 ydintä päällä?
Sitähän sillä haetaan, mutta noissa tuloksissa ei oo mitää järkeä. Miksi opengl:llä 2+2 /4/0 eroaa vulkanin vastaavista. Jos ongelmana pidetään että säikeet hyppivät CCX:ltä toiselle vaikka optimi olisi pitää ne yhdellä ccx:llä oman L2 ja L3 kakkunsa lämpimässä syleilyssä, niin mistä moiset erot johtuvat.

Jotenkin vaan tuntuu että olettamus että Affinityt 0-7 (CCX1) ja 8-15 (CCX2) ovat väärin. CCX 1 corethan voivat olla vaikka 0,1,6,7 ja CCX2 3,4,5,6. Tai vastaavasti vielä 0,1,4,5 ja 2,3,6,7.
 
Liittynyt
22.10.2016
Viestejä
6 056
Sitähän sillä haetaan, mutta noissa tuloksissa ei oo mitää järkeä. Miksi opengl:llä 2+2 /4/0 eroaa vulkanin vastaavista. Jos ongelmana pidetään että säikeet hyppivät CCX:ltä toiselle vaikka optimi olisi pitää ne yhdellä ccx:llä oman L2 ja L3 kakkunsa lämpimässä syleilyssä, niin mistä moiset erot johtuvat.

Jotenkin vaan tuntuu että olettamus että Affinityt 0-7 (CCX1) ja 8-15 (CCX2) ovat väärin. CCX 1 corethan voivat olla vaikka 0,1,6,7 ja CCX2 3,4,5,6. Tai vastaavasti vielä 0,1,4,5 ja 2,3,6,7.
tuossa on biosissa kytketty ytimiä päälle kummastakin ccx:stä. Eli eiköhän noi ole ihan oikein, tuskin se bios ihan mitä sattuu ytimiä disabloi.

Näissä tuloksissahan isoja ongelmia on selvästi vain tuossa vulcanissa. Harmi ettei ole laajempia tuloksia/testejä useilla peleillä.
 

Dygaza

Platinum-jäsen
Liittynyt
28.10.2016
Viestejä
638
tuossa on biosissa kytketty ytimiä päälle kummastakin ccx:stä. Eli eiköhän noi ole ihan oikein, tuskin se bios ihan mitä sattuu ytimiä disabloi.

Näissä tuloksissahan isoja ongelmia on selvästi vain tuossa vulcanissa. Harmi ettei ole laajempia tuloksia/testejä useilla peleillä.
Miten siinä biosissa disabloidaan ytimiä? Jos siinä on vaan että coret 1-8 erillisillä rivillä, niin ei se kerro vielä välttämättä niiden fyysistä sijaintia.
 
Liittynyt
22.10.2016
Viestejä
6 433
Sitähän sillä haetaan, mutta noissa tuloksissa ei oo mitää järkeä. Miksi opengl:llä 2+2 /4/0 eroaa vulkanin vastaavista. Jos ongelmana pidetään että säikeet hyppivät CCX:ltä toiselle vaikka optimi olisi pitää ne yhdellä ccx:llä oman L2 ja L3 kakkunsa lämpimässä syleilyssä, niin mistä moiset erot johtuvat.
Vaikuttaisi vähän siltä, että siellä on todella paljon jotain ylimääräistä synkronointia, tai cachen false sharingia, ja kaikki aika menee ping-pong-liikenteeseen kakkujen välillä, kun kunkin ytimen välimuisti yrittää aina ottaa kilpaa samaan osoitteeseen osoittavaa välimuistilinjaa omakseen kirjoittaakseen siihen.

Kun käytössä on vain yhden CCX:n ytimiä, tämä liikenne on saman CCX:n L2- ja L1-kakkujen välillä, ja tämä on nopeampaa, ja hidastaa vähemmän.

Kun käytössä on kahden CCX:n ytimiä, tulee tätä ping pong-liikennettä myös kahden eri CCX:n kakkujn välillä, ja tämä liikenne hitaampaa.

Perimmäinen syy: Dota2n vulkan-implementaation koodi Linuxilla siis vaikuttaisi sukkaavan pahasti.
 
Liittynyt
22.10.2016
Viestejä
6 433
Miten siinä biosissa disabloidaan ytimiä? Jos siinä on vaan että coret 1-8 erillisillä rivillä, niin ei se kerro vielä välttämättä niiden fyysistä sijaintia.
Tuon artikkelin edellisellä sivulla näytetään miltä se BIOSin valintaoptio ytimien disabloinniksi näyttää.
 
Liittynyt
07.03.2017
Viestejä
1 185
Vaikuttaisi vähän siltä, että siellä on todella paljon jotain ylimääräistä synkronointia, tai cachen false sharingia, ja kaikki aika menee ping-pong-liikenteeseen kakkujen välillä, kun kunkin ytimen välimuisti yrittää aina ottaa kilpaa samaan osoitteeseen osoittavaa välimuistilinjaa omakseen kirjoittaakseen siihen.

Kun käytössä on vain yhden CCX:n ytimiä, tämä liikenne on saman CCX:n L2- ja L1-kakkujen välillä, ja tämä on nopeampaa, ja hidastaa vähemmän.

Kun käytössä on kahden CCX:n ytimiä, tulee tätä ping pong-liikennettä myös kahden eri CCX:n kakkujn välillä, ja tämä liikenne hitaampaa.

Perimmäinen syy: Dota2n vulkan-implementaation koodi Linuxilla siis vaikuttaisi sukkaavan pahasti.
Vaikka coreja ja CCX:iä onkin disabloitu, niin SMT on vielä päällä. Osaako toi Dota2 erottaa nopeat ytimet noista virtuaaliytimistä oikein? Ja voiko pelin koodi valita missä ytimessä sitä ajetaan vai määrääkö käyttis sen? Tuossa olisi tarvinnut olla jokin ydinkohtainen kuormitus lisäksi näytettävänä.
 

Dygaza

Platinum-jäsen
Liittynyt
28.10.2016
Viestejä
638
Vaikka coreja ja CCX:iä onkin disabloitu, niin SMT on vielä päällä. Osaako toi Dota2 erottaa nopeat ytimet noista virtuaaliytimistä oikein? Ja voiko pelin koodi valita missä ytimessä sitä ajetaan vai määrääkö käyttis sen? Tuossa olisi tarvinnut olla jokin ydinkohtainen kuormitus lisäksi näytettävänä.
Jotenkin nää tulokset on niin randomia kun on keskisuurimäärä säikeitä käytössä että ei oikeasti tiedä mitä tapahtuu. Loadit jossa oikeasti 16 säiettä käytössä että säikeet eivät pompi toimivat hyvin. Muut eivät. Harmittaa kun ei löydy mitään custom affinity testejä jossa eri threadeja pakotetaan eri ytimille. Tekisi mieli hakea kaupasta lankku ja prossu ja testata.
 
Liittynyt
22.10.2016
Viestejä
6 433
Vaikka coreja ja CCX:iä onkin disabloitu, niin SMT on vielä päällä. Osaako toi Dota2 erottaa nopeat ytimet noista virtuaaliytimistä oikein? Ja voiko pelin koodi valita missä ytimessä sitä ajetaan vai määrääkö käyttis sen? Tuossa olisi tarvinnut olla jokin ydinkohtainen kuormitus lisäksi näytettävänä.
Saman ytimen kahden virtuaaliytimen välillä false sharing ei ole ongelma, koska niille kaikki välimuistit on yhteisiä.

Käyttis määrää missä säikeitä ajetaan.

Tosin useimmilla käyttiksillä säie voi myös yrittää esittää toivomuksen siitä, millä ytimellä sitä ajetaan. Tämä on kuitenkin vain toivomus, ja luulisin, että pelit eivät näitä toivomuksia esitä, koska sen laskeminen, mikä "toivomus" on se oikea ja hyödyllinen on hyvin vaikeaa ja riippuu hyvin paljon siitä millä raudalla softaa ajetaan, ja mitä muuta koneella on samaan aikaan pyörimässä, ja näiden laskeminen siten että siitä olisi useammin hyötyä kuin haittaa olisi ihan hirveää nysväämistä ja silti osutaan liian helpolla pahasti pieleen.
 

Dygaza

Platinum-jäsen
Liittynyt
28.10.2016
Viestejä
638
Saman ytimen kahden virtuaaliytimen välillä false sharing ei ole ongelma, koska niille kaikki välimuistit on yhteisiä.

Käyttis määrää missä säikeitä ajetaan.
No eikös tämä juuri ole se ongelma jos käyttis ei erota virtuaaliytimiä oikeista. Esim pelissä vaikka pelin maithread ja näyttiksen ajurithreadi samalle ytimelle, vaikka molemmat käytännössä vaativat oman dedikoidun ytimen.
 

jsa

Liittynyt
20.10.2016
Viestejä
330
Ihan nyt vois tietty testata Windowsillakin samat testit niin jäisi pois tuo "pieni" olettamus että noi AMD:n Linux driverit on Vulkan(inkin) osalta vaiheessa.
 
Liittynyt
22.10.2016
Viestejä
6 433
No eikös tämä juuri ole se ongelma jos käyttis ei erota virtuaaliytimiä oikeista. Esim pelissä vaikka pelin maithread ja näyttiksen ajurithreadi samalle ytimelle, vaikka molemmat käytännössä vaativat oman dedikoidun ytimen.
Yleensä käyttis erottaa, lähinnä bulldozerin tapauksessa heti julkaisun jälkeen käyttikset eivät erottaneet.

Ja ainakin käyttis tietää sen paljon paremmin kuin peli itse, minkä takia peli helposti antaisi käyttikselle vääränlaisia vihjeitä, jos se yrittäisi alkaa samomaan millä ytimellä se haluaa pyöriä.

Zenin kanssa ongelma on se, että käyttikset eivät osaa mallintaa/laskea tuota hitaampaa/kalliimpaa kommunikaatiohintaa kahden eri CCXn ydinten välillä. Mutta tämähän on oikeastaan päinvastainen ongelma, Zenillä haluttaisin sijoitella (keskenään kommunikoivat) säikeet samalle CCX:lle eikä hajauttaa niitä useammalle, kun taas SMT-ongelmissa on kyse siitä että haluttaisiin hajauttaa useammalle fyysiselle ytimelle eikä ajaa saman fyysisen ytimen virutaaliytimissä

Käytännössä järkevä skeduli Zenille 4-säikeiselle pelille olisi yleensä sijoittaa pelin 4 säiettä yhden CCX:n kaikille ytimille, ja lukita ne sinne, eikä sallia mitään muuta ajoon niillä, vaikka pelin säikeet nukkuisivat(jottei välimuisteista heitetä pois mitään pelin dataa), ja jättää toinen CCX kaikille taustaprosesseille. Mutta sitten kuin pelillä on enemmän kuin 4 säiettä, tämä ratkaisu ei enää toimi.
 
Viimeksi muokattu:
Liittynyt
07.03.2017
Viestejä
1 185
Ihan nyt vois tietty testata Windowsillakin samat testit niin jäisi pois tuo "pieni" olettamus että noi AMD:n Linux driverit on Vulkan(inkin) osalta vaiheessa.
Avoimen lähdekoodin ajuri AMD grafiikka kortilla. Samalla ajurilla myös i7-7700K:n framerate putoaa kun siirrytään vulkan rajapintaan. Pudotus on vain paljon pienempi.
 

copter

Last Man Standing
Liittynyt
05.12.2016
Viestejä
3 198
Voisi kuvitella että jos ongelma olisi Windows drivereissä niin vastaava ongelma esiintyisi myös hyötyohjelmissa ja CPU benchmarkeissa?

Varmasti niissä on parannettavaa sitä en sano, mutta näin mutuna näkisin että ongelma on enemmän pelien tavassa käyttää ytimiä. Kuten aiemmin sanoin, niin ongelma ei pelien suhteen välttämättä ole se että niitä pitäisi optimoida tajuttomasti, mutta ennemminkin se että ne käyttää Ryzeniä samalla tapaa kuin Inteliä ja niille tehdyillä optimoinneilla.
 
Liittynyt
22.10.2016
Viestejä
6 056
Yleensä käyttis erottaa, lähinnä bulldozerin tapauksessa heti julkaisun jälkeen käyttikset eivät erottaneet.

Ja ainakin käyttis tietää sen paljon paremmin kuin peli itse, minkä takia peli helposti antaisi käyttikselle vääränlaisia vihjeitä, jos se yrittäisi alkaa samomaan millä ytimellä se haluaa pyöriä.

Zenin kanssa ongelma on se, että käyttikset eivät osaa mallintaa/laskea tuota hitaampaa/kalliimpaa kommunikaatiohintaa kahden eri CCXn ydinten välillä. Mutta tämähän on oikeastaan päinvastainen ongelma, Zenillä haluttaiisin sijoitella (keskenään kommunikoivat) säikeet samalle CCX:lle eikä hajauttaa niitä useammalle.

Käytännössä järkevä skeduli Zenille 4-säikeiselle pelille olisi sijoittaa pelin 4 säiettä yhden säikeen kaikille ytimille, ja lukita ne sinne, ja jättää toinen CCX kaikille taustaprosesseille. Mutta sitten kuin pelillä on enemmän kuin 4 säiettä, tämä ratkaisu ei enää toimi.
Niin toisaalta, jos taas sitä kommunikaatiota ei ole paljoa on parempi kun ne säikeet on eri CCX:llä ja kaikilla on nopea oma cache. Eli jotenkin se pitäisi sitten saada tuohon skedulointiin mukaan, jos halutaan että se toimii aina optimaalisesti.
 
Liittynyt
22.10.2016
Viestejä
6 433
Avoimen lähdekoodin ajuri AMD grafiikka kortilla. Samalla ajurilla myös i7-7700K:n framerate putoaa kun siirrytään vulkan rajapintaan. Pudotus on vain paljon pienempi.
Vulkan on hyvin matalan tason rajapinta joten veikkaisin, että tuo ongelma on ihan pelin koodin eikä ajurin koodin puolella; Vulkanilla pelin koodi joutuu tekemään asioita jotka aiemmilla rajapinnoilla oli ajurin vastuulla.
 
Liittynyt
17.10.2016
Viestejä
1 468
Tuostahan ei tosiaan voi tietää yhtään kuinka iso vaikutus sillä on. Saattaa olla suurikin tai sitten täysin olematon. Vaihtelu eri ohjelmien ja pelien välilläkin todennäköisesti suurta.
 

Taneli-

☤ Virallinen ⚔ testaaja ☣
Liittynyt
17.10.2016
Viestejä
3 321
Tuostahan ei tosiaan voi tietää yhtään kuinka iso vaikutus sillä on. Saattaa olla suurikin tai sitten täysin olematon. Vaihtelu eri ohjelmien ja pelien välilläkin todennäköisesti suurta.
Testaamalla sen näkee, käytännössähän säikeistys antaa hieman bonusta peleihin (huomaa esim. kun testaa i7 ilman säikeistystä = i5) joten JOS pelissä Ryzenillä saat paremman pelikokemuksen ilman säikeitä kuin säikeiden kanssa => tulet saamaan vielä enempi bonusta kun tuo saadaan korjattua. Tosin osassa peleistä ei tullut mitään eroa joten pelikohtaista (mitä arvosteluista katsellut).
 

Dygaza

Platinum-jäsen
Liittynyt
28.10.2016
Viestejä
638
Säikeistyksenhän voi windowsissa itsekin korjata kun vaa määrittää theadien affinityn itse. Se on vaan vähä turhan vaivalloista.
 

Dygaza

Platinum-jäsen
Liittynyt
28.10.2016
Viestejä
638
Process hackerin nightly versiossa voi tallentaa affinityn ohjelmakohtaisesti.

Nightly Builds - Process Hacker
(windowsin tehtävienhallinnan kaltainen ohjelma)
Samaa ohjelmaa olen käyttänyt, mutta uudessa versiossa ilmeisesti lisää ominaisuuksia. Tästä varmaan olisi Ryzenin omistajille apua kunnes ongelma korjataan oikeasti. Mitenhän tuo tallentaa kun thread id:t on aina eri jokaisella käynnistyskerralla.
 

Ryydike

BANNATTU
BANNED
Liittynyt
04.11.2016
Viestejä
974
Hieman offtopiccia : Kuinka monta Ryzen prosessoria AMD on tähän päivään mennessä myynyt?
 
Toggle Sidebar

Uusimmat viestit

Statistiikka

Viestiketjut
94 923
Viestejä
1 909 784
Jäsenet
40 316
Uusin jäsen
PoXx

Hinta.fi

Ylös Bottom