AMD CPU-spekulaatio (Zen6/Zen7 ...)

Pieni villi kortti tässä on kuitenkin toi uusien konsoleiden mukana tuleva uusi tapa SSD:n hyödyntämiseen peleissä, joka Windowsin puolella on tulossa Direct Storage nimellä: DirectStorage is coming to PC | DirectX Developer Blog
Nvidian puolella puhutaan RTX IO:sta: NVIDIA RTX IO: GPU Accelerated Storage Technology

Toki toinen asia on sitten kannattaako tuohon varautua vielä tässä kohtaa kun todellista nopeusvaikutusta ei vielä tiedetä ja toi todellisesti näkyy pc-peleissä varmaan yli vuoden päästä jolloin saa todennäköisesti taas nopeampaa ja isompaa ssd:tä halvemmalla. Ehkä harkittavissa kuitenkin jos on m2-paikat on muutenkin vähissä eikä aio pariin vuoteen uutta ssd:tä ostaa.
Totta sekin, tosin itse en tässä kohtaa ostaisi SSD-levyjä tai RAM-palikoita "varastoon". SSD-levyt halpenee vuosi vuodelta, ja DDR5 on jo horisontissa. Tuo tekniikka on vasta tulossa, ja kaiken lisäksi se tulee vaatimaan tuen myös pelin enginen osalta. Sen tukemiseen yleisesti voi siis mennä vielä vuosia aikaa.
 
Totta sekin, tosin itse en tässä kohtaa ostaisi SSD-levyjä tai RAM-palikoita "varastoon". SSD-levyt halpenee vuosi vuodelta, ja DDR5 on jo horisontissa. Tuo tekniikka on vasta tulossa, ja kaiken lisäksi se tulee vaatimaan tuen myös pelin enginen osalta. Sen tukemiseen yleisesti voi siis mennä vielä vuosia aikaa.
Sinänsä uskoisin että toi voi yleistyä aika nopeastikin tuon konsolitaustan seurauksena. Oletettavasti monet konsolipelit tota alkaa alkaa kuitenkin hyödyntämään kun se kummassakin konsolissa on ja tuntuu olevan "killer feature". Samankaltaisen raudan ja XBOX:n takia oletettavasti Windows -toteutus on aika samankaltainen tai identtinen konsolien kanssa ainakin XBOX:n osalta. Sen seurauksena olettaisi että monet cross-platform pelit tota tulevat pc-puolellakin aika nopeasti hyödyntämään ja sitä kautta voi yleistyä vauhdilla muutenkin. Mutta joo monta oletusta ja aika näyttää.
 
AMD julkassu päivitykset technical dokumentaatiohinsa. Application programmin dokkarissa mm seuraavaa
A shadow stack is a separate, protected stack that is conceptually parallel to the procedure stack and used only by the shadow stack feature. When enabled by system software, the shadow stack feature provides, in a manner that is transparent to application software, protection against a class of computer exploit known as 'return oriented programming'. System-programming details on the shadow stack feature are described in “Shadow Stacks” in Volume 2
Onkos tuo nyt sitten vasta Zen 3:ssa tullut juttu?
 
Taas vuosi lisää tuloksia. Tällä kertaa Geekbench:

Sinänsä vähän jännä että 5900x meni single coressa 5950x:n edelle vaikka 5950x:n kellot ovat kovemmat. Ilmeisesti 5950x ei saa niitä pidettyä single core ajossakaan kelloja yhtä hyvin täpissä kuin pikkuveljensä vai onko tolle muita selityksiä?
 
Taas vuosi lisää tuloksia. Tällä kertaa Geekbench:

Sinänsä vähän jännä että 5900x meni single coressa 5950x:n edelle vaikka 5950x:n kellot ovat kovemmat. Ilmeisesti 5950x ei saa niitä pidettyä single core ajossakaan kelloja yhtä hyvin täpissä kuin pikkuveljensä vai onko tolle muita selityksiä?
Eri kokoonpano. 5950X setti on surkeilla CL28 muistilatensseilla, .gb5 URLin perään niin näkyy tarkemmin ajon tiedot.

 
Tuon mukaan prossun boostikellot toimivat
lähempänä 5GHz kuin 4.9GHz
Renoir läppäreissäkin on menty helposti yli listatuista maksimikelloista vakiona ajellessa. Todennäköisesti AMD on ottanu opikseen vaan edellisestä kellontaajuussekoilusta ja että noi nyt ilmoitetut on paljon helpompi saavuttaa ja jopa ylittää.

edit: jopa MT testeissä kellontaajuus pysynyt yli 4,7 GHz, ST testeissä taas lähes kaikissa 4949-4985 MHz. Bclk:n jos nostaa 100 -> 100,4 niin päästään 5GHz haamurajan ohi. Ei taida olla mikään maailman vaativin testi, mutta kuitenkin antaa melko kovat odotukset tulevasta.
 
Viimeksi muokattu:
Jaahas, Passmarkista tullee lähiaikoina uusi versio tarjolle.
AMD Ryzen 5 5600X kun on päässyt yllättämään ja noussut Passmarkin single thread -testin kärkeen, aika reilustikin vielä...
1603440228909.png

 
Jaahas, Passmarkista tullee lähiaikoina uusi versio tarjolle.
AMD Ryzen 5 5600X kun on päässyt yllättämään ja noussut Passmarkin single thread -testin kärkeen, aika reilustikin vielä...
1603440228909.png

Täähän on jo wanha liikki, mutta kertokaapas onko tossa 10900K @ 3.7GHz nyt siis vain 3.7 taajuutena? Eikös se nyt buustaile sinne yli 5GHz kuitenkin?
 
Täähän on jo wanha liikki, mutta kertokaapas onko tossa 10900K @ 3.7GHz nyt siis vain 3.7 taajuutena? Eikös se nyt buustaile sinne yli 5GHz kuitenkin?
Passmark taitaa raportoida vain virallisen Base-kellon.
 
Jaahas, Passmarkista tullee lähiaikoina uusi versio tarjolle.
Jokohan userbenchmark kaverit on saaneet Inteliltä tiedot miten muuttaa pisteytystä, jotta näyttää taas paremmalta. :D

Täähän on jo wanha liikki, mutta kertokaapas onko tossa 10900K @ 3.7GHz nyt siis vain 3.7 taajuutena? Eikös se nyt buustaile sinne yli 5GHz kuitenkin?
Passmark taitaa raportoida vain virallisen Base-kellon.
Nuo passmark tulokset on monen ajon keskiarvo tjsp. Eli eiköhän se 10900K ole max boosteilla, varsinkin kun single core tulosta katsellaan.
 
Tässä joku sivusto väittää että 5900X:ssä olisi 8+4 ydintä eikä 6+6 ydintä. Onko kukaan nähnyt muualla vastaavaa väitettä?
Mun käsittääkseni 6+6 layouttia on pidetty itsestäänselvänä koska 3900X on myös samalla layoutilla. Mitään varmistusta suuntaan tai toiseen ei ole mielestäni julkaistu missään.
 
Ei tule olemaan 8+4, sillä se olisi aivan järjetön tilanne säikeiden hallinnan kannalta.

"Ei tule mitään chiplettejä koska se on aivan järjetön tilanne viiveiden kannalta"

-useampi käyttäjä tällä foorumilla 2018

Tuotantoteknisesti toi on aidosti järjetön ratkaisu, elleivät saannot ole hyvin lähellä 100%
 
Näitä asioitahan on laitettu kuntoon jo pitkin matkaa.

Prefered core listoilla voi kertoa mitä coreja käytetään ja hyppyjä yli ccx:n estetään jne.

En näe minkäänlaiseksi ongelmaksi uusimmilla windowsseilla.
Tuossa systeemissä ne paremmat ytimet olisi sillä neljän ytimen CCX:llä kaksinkertaisen cachen takia, mutta peleissä säikeet menee nykyään helposti yli neljän ja ongelmia tulee siksi varhaisemmassa vaiheessa kuin 6+6 konfiguraatiossa. Suorituskyky olisi korkeampi 6+6 sen lisäksi että se on edullisempi valmistaa sillä ei tarvitse käyttää ehjiä siruja.
 
Tuossa systeemissä ne paremmat ytimet olisi sillä neljän ytimen CCX:llä kaksinkertaisen cachen takia, mutta peleissä säikeet menee nykyään helposti yli neljän ja ongelmia tulee siksi varhaisemmassa vaiheessa kuin 6+6 konfiguraatiossa. Suorituskyky olisi korkeampi 6+6 sen lisäksi että se on edullisempi valmistaa sillä ei tarvitse käyttää ehjiä siruja.
Et edes lukenut artikkelia. Amd ei merkkaa fyysesti parhaita ytimiä muutenkaan parhaaksi. Se on irrelevanttia. AMD merkkaa parhaaksi ne joita sen mielestä on järkevintä käyttää ja täyttää ensin. Eli AMD voisi aivan hyvin merkata sen 8 setin parhaaksi jos he ovat sitä mieltä.
 
Et edes lukenut artikkelia. Amd ei merkkaa fyysesti parhaita ytimiä muutenkaan parhaaksi. Se on irrelevanttia. AMD merkkaa parhaaksi ne joita sen mielestä on järkevintä käyttää ja täyttää ensin. Eli AMD voisi aivan hyvin merkata sen 8 setin parhaaksi jos he ovat sitä mieltä.
Ja mikäs järki siinä sit olisi? Käyttää parhaita mahdollisia 8 ytimisiä chiplettejä johonkin keskikastin tuotteeseen?
 
Ja mikäs järki siinä sit olisi? Käyttää parhaita mahdollisia 8 ytimisiä chiplettejä johonkin keskikastin tuotteeseen?
Nyt ei keskusteltu siitä vaan väitteestäsi säikeiden hallinnasta. Koita pysyä asiassa.
 
No johan tuohon 5800X:n on pakko käyttää sellaisia?
Eikä ole, siinä on huonomman V/f käppyrän piiri. Lisäksi hinta per ydin on 5800x:llä korkeampi nimenomaan siitä syystä että siinä käytetään AMD:n näkökulmasta arvokkaampia piirejä.


Nyt ei keskusteltu siitä vaan väitteestäsi säikeiden hallinnasta. Koita pysyä asiassa.
Säikeiden asettaminen voidaan kyllä schedulerin toimesta tehdä kuten mainitsit, mutta mitenkään optimaalista se ei tule olemaan tuollaisessa 8+4 konfiguraatiossa suorituskyvyn suhteen. Ts. säikeiden hallinta on ongelmallista suorituskykynäkökulmasta.
 
Eikä ole, siinä on huonomman V/f käppyrän piiri. Lisäksi hinta per ydin on 5800x:llä korkeampi nimenomaan siitä syystä että siinä käytetään AMD:n näkökulmasta arvokkaampia piirejä.



Säikeiden asettaminen voidaan kyllä schedulerin toimesta tehdä kuten mainitsit, mutta mitenkään optimaalista se ei tule olemaan tuollaisessa 8+4 konfiguraatiossa suorituskyvyn suhteen. Ts. säikeiden hallinta on ongelmallista suorituskykynäkökulmasta.
Ja se peruste on mikä suhteessa windowssin scheduleriin? Koska sinä sanot?
 
Ja se peruste on mikä suhteessa windowssin scheduleriin? Koska sinä sanot?
Koska eri ohjelmat suosii eri tavalla suurta cachea ja nopeita ytimiä. Scheduleri ei osaa ohjelmakohtaisesti tehdä päätöstä siitä että minne ne säikeet tulisi heittää. 6+6 konfiguraatiossa scheduleri toimii nykysäädöillään lähellä optimia, sillä ytimet käyttäytyvät identtisesti ja CCX:t eriävät vain kellontaajuuden osalta.

Riippuen siitä että miten päin toi 8+4 on konffattu, eli siis että kummat ytimet esitetään parempina schedulerille, osa ohjelmista voi olla nopeampia kuin mitä toi tuleva 6+6 prossu, mutta keskimäärin parempaan tulokseen päästäneen 6+6 konfiguraatiolla, etenkin monisäikeisillä kuormilla. Lisäksi etuna on hyvä ennustettavuus eri kuormien suorituskyvyn suhteen ja mitään outolintutuloksia ei tarvitse alkaa selittelemään missä 5900x olisi yllättäen hitaampi kuin 5600x. Bonuksena se on edullisempi valmistaa AMD:n näkökulmasta.
 
Koska eri ohjelmat suosii eri tavalla suurta cachea ja nopeita ytimiä. Scheduleri ei osaa ohjelmakohtaisesti tehdä päätöstä siitä että minne ne säikeet tulisi heittää. 6+6 konfiguraatiossa scheduleri toimii nykysäädöillään lähellä optimia, sillä ytimet käyttäytyvät identtisesti ja CCX:t eriävät vain kellontaajuuden osalta.

Riippuen siitä että miten päin toi 8+4 on konffattu, eli siis että kummat ytimet esitetään parempina schedulerille, osa ohjelmista voi olla nopeampia kuin mitä toi tuleva 6+6 prossu, mutta keskimäärin parempaan tulokseen päästäneen 6+6 konfiguraatiolla, etenkin monisäikeisillä kuormilla. Lisäksi etuna on hyvä ennustettavuus eri kuormien suorituskyvyn suhteen ja mitään outolintutuloksia ei tarvitse alkaa selittelemään missä 5900x olisi yllättäen hitaampi kuin 5600x. Bonuksena se on edullisempi valmistaa AMD:n näkökulmasta.
Luodessa säikeitä 8+8 tai 8+4:lle ei tule mitään eroa aluksi. Kenenkään ei tarvi olla missään määrin kiinnostunut lopun neljän isommasta cachesta. Sillä isommalla loppucachella voi olla vain positiivisia vaikutuksia, mutta ei negatiivisia. Windowssin (tyhmähkön) scheduloinnin näkökulmasta 8+8 tai 8+4 on yhtä ongelmallisia tai ongelmattomia 12 säikeeseen asti.

Edelleenkään et saanut kaivettua tasan mitään schedulointiongelmaa esille. Eli tarinoit vain omiasi taas. Mutta sait sentään mielipiteenä kerrottua että 6+6 voisi olla keskimäärin nopeampi. Minä vastaan siihen omalla mielipiteellä että uskon 8+4 olevan minua kiinnostavissa kuormissa nopeampi.
 
Minä vastaan siihen omalla mielipiteellä että uskon 8+4 olevan minua kiinnostavissa kuormissa nopeampi.
Millaisissa kuormissa? Ehkä jos ohjelma käyttää vähintään seitsemää, mutta korkeintaan kahdeksaa säiettä, mutta silloin 5800x on muutenkin kustannustehokkaampi valinta. Tuon yli jos mennään niin 6+6 konffissa on enemmän kakkua per säie ja siten suorituskyky on parempi. Tuon alle jos mennään niin taas on kakkua sama määrä 6+6:ssa. Aika kapea kuormakategoria tuo vain 7-8 säikeen softat, jossa tosta 8+4:stä voisi jotain hyötyä.
 
Millaisissa kuormissa? Ehkä jos ohjelma käyttää vähintään seitsemää, mutta korkeintaan kahdeksaa säiettä, mutta silloin 5800x on muutenkin kustannustehokkaampi valinta. Tuon yli jos mennään niin 6+6 konffissa on enemmän kakkua per säie ja siten suorituskyky on parempi. Tuon alle jos mennään niin taas on kakkua sama määrä 6+6:ssa. Aika kapea kuormakategoria tuo vain 7-8 säikeen softat, jossa tosta 8+4:stä voisi jotain hyötyä.
Kuormissa jossa on toisistaan riippuvia threadeja.

Vaikka nyt ei tulisi 8+4 cputa (en edes usko itsekään joillakin perusteilla joota sinäkin sivusit) niin 8+8 cpun pitäisi antaa käsitystä miten mikäkin toimisi. Kellotaajuuserot toki sotkee, mutta sinun logiikan mukaan tietyt windows kuormat olisivat sitten 6+6:lla 8+8 nopeampia.
 
Antaahan tuo 8+4 konfiguraatio mahdollisuuden erilaisten piirien kehittelyyn, eli erittäin korkealle kellottuvan 4c chipletin yhdistäminen paskaan 8c chiplettiin. Kaikille säikeille em. prosessorissa näkyy 32-megainen L3 slice eli scheludointiongelmaa ei ole, säikeiden välinen komminikointi eri chiplettien välillä on ihan riittävän nopeaa datan vaihdossa ytimien välillä eli sen suhteen on ihan sama miten ytimet jakautuu chiplettien välillä.

Tosin epäilen että ihan 6+6 konfiguraatiota tulevat käyttämään yksinkertaisuuden vuoksi, mutta en näe myöskään mitään estettä asymmetriselle versiollekaan.
 
sinun logiikan mukaan tietyt windows kuormat olisivat sitten 6+6:lla 8+8 nopeampia.
Pitää paikkansa. Se kuinka monet sellaisia on onkin sit eri asia. 12 suuresta cachesta hyötyvää paljon toistensa kanssa keskustelevaa säiettä voisi olla moinen kuorma.

Kuormissa jossa on toisistaan riippuvia threadeja.
Jeps, ja juuri kuten viestissäni kirjoitin niin se säiemääräikkuna jossa 8+4 voisi olla nopeampi on hyvin kapea.
 
Jeps, ja juuri kuten viestissäni kirjoitin niin se säiemääräikkuna jossa 8+4 voisi olla nopeampi on hyvin kapea.
Tai sitten ei. Se että näille cpuille tulee cachen koko eroja per ydin ei välttämättä myöskään näy mitenkään. Vastauksessasi oletit että se on se ratkaiseva. Se voi olla vielä ”kapeampi” osio kun tuo toinen. Jolloin taas päästään siihen että 8+4 olisi silti yleisesti parempi.
 
Tai sitten ei. Se että näille cpuille tulee cachen koko eroja per ydin ei välttämättä myöskään näy mitenkään. Vastauksessasi oletit että se on se ratkaiseva. Se voi olla vielä ”kapeampi” osio kun tuo toinen. Jolloin taas päästään siihen että 8+4 olisi silti yleisesti parempi.
Kaikki on mahdollista. Eikun 5950x kaupasta ja process lasson kanssa testailemaan.
 
Pitää paikkansa. Se kuinka monet sellaisia on onkin sit eri asia. 12 suuresta cachesta hyötyvää paljon toistensa kanssa keskustelevaa säiettä voisi olla moinen kuorma.

Moinen kuorma jakautuisi säie per ydin ihan riippumatta siitä mikä on chiplettien konfiguraatio. Ytimien olo eri chipleteissä ei juuri vaikuta nopeuteen ytimien välisen kommunikaation kautta, se on jokatapauksessa hidasta ja tappaa suorituskyvyn jos sitä on liikaa, kirjoitus jaettuun dataan invalidoi datan toiselta ytimeltä riippumatta missä CCX:ssä se sijaitsee - nopeusero CCX:n kasvattamisesta tulee melkein sataprosenttisesti siitä että ytimelle näkyvä maksimi cachen määrä tuplaantuu. Sama L3:n määrä näkyy ytimelle oli se Zen3:ssa sitten 4:n tai 8:n ytimen chipletissä joten suurta epätasa-arvoa ei ytimien välille muodostu.
 
Moinen kuorma jakautuisi säie per ydin ihan riippumatta siitä mikä on chiplettien konfiguraatio. Ytimien olo eri chipleteissä ei juuri vaikuta nopeuteen ytimien välisen kommunikaation kautta, se on jokatapauksessa hidasta ja tappaa suorituskyvyn jos sitä on liikaa, kirjoitus jaettuun dataan invalidoi datan toiselta ytimeltä riippumatta missä CCX:ssä se sijaitsee - nopeusero CCX:n kasvattamisesta tulee melkein sataprosenttisesti siitä että ytimelle näkyvä maksimi cachen määrä tuplaantuu. Sama L3:n määrä näkyy ytimelle oli se Zen3:ssa sitten 4:n tai 8:n ytimen chipletissä joten suurta epätasa-arvoa ei ytimien välille muodostu.
Kyllä se vaikuttaa. Clock for clock mätsätty 3100 vs 3300x ja eron voi mitata täysin selvästi.
 
Kyllä se vaikuttaa. Clock for clock mätsätty 3100 vs 3300x ja eron voi mitata täysin selvästi.

No siinä on nimenomaan cache-ero, 2 kertaa 8mb vs 16mb. Jos otetaan vertailuksi pari jossa kahden CCX:n konfiguraatiossa on 2*16mb L3:a tilanne on aivan eri - kahden CCX:n versio on pääsääntöisesti nopeampi kiitos suuremman efektiivisen cachensa. Tilanteeet joissa yhden CCX:n versio on nopeampi ovat harvinaisia. Zen3:ssa aivan sama tilanne, kahden chipletin 5900x on keskimääärin nopeampi peleissä kuin 5800x vaikka threadeja olisi vähän - suurempi efektiivinen cache - kummassakin L3:ssa ei tarvitse olla kaikki data samaa.
 
No siinä on nimenomaan cache-ero, 2 kertaa 8mb vs 16mb. Jos otetaan vertailuksi pari jossa kahden CCX:n konfiguraatiossa on 2*16mb L3:a tilanne on aivan eri - kahden CCX:n versio on tilanteesta riippuen nopeampikin kiitos suuremman efektiivisen cachensa.
Onko sinulla tästä jotain testidataa vai mutuiletko? Intercore latency erotkin on kuitenkin selvästi mitattavia. Väitit tuossa äsken että ei juuri eroa ole. Noissa yllämainituissa se tuplaantuu.

edit. En tiedä pysyinkö edes kärryillä nyt. 3100 vs 3300x cache määrä corelle näkyvissä on sama mutta latenssi siinäkin.

Ja aiemmassa skenaariossa ccd eron takia toista cachea ei edes näy.
 
Viimeksi muokattu:
Onko sinulla tästä jotain testidataa vai mutuiletko? Intercore latency erotkin on kuitenkin selvästi mitattavia.

No onhan noita testannut AMD itsekin, ja kertoo hyvin suoraan mistä CCX:n kasvattamisen vaikutus suorituskykyyn tulee, efektiivinen cache priority threadille kasvaa kaksinkertaiseksi. Intercore latency on ihan riittävän hyvä chiplettien välilläkin jotta threadien synkkaus ei suorituskykyyn vaikuta - saman datan roplaaminen kahdella ytimellä on kuitenkin mahdotonta oli ytimet samassa CCX:ssä tai ei - nykyprossuilla datan pitää olla per thread jotta kuorma kannattaa jakaa eri threadeille - ja jos koodari kopioi suuria määriä dataa ytimien välillä threadien synkassa niin lopputulos on jo alkuunsa tuhoon tuomittu, se on jo lähtökohtaisesti nopeampaa käsitellä silloin yhdellä ytimellä.
 

Statistiikka

Viestiketjuista
258 136
Viestejä
4 484 800
Jäsenet
74 173
Uusin jäsen
kaljakonna

Hinta.fi

Back
Ylös Bottom