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

[hkultala]

Kyse oli synkronoiduista säikeistä, jotka siis synkronoituvat pääsäikeen kanssa.

Mitähän nyt tarkkanottaen tarkoitat näillä "synkronoiduilla säikeillä"?

Säikeet välillä tekevät synkronointia toistensa kanssa. Ei ole erikseen "ei-synkronoituja" ja "synkronoituja" säikeitä.

Pelit voivat luoda toki paljon enemmän aktiivisia säikeitä, kuin mitä CPU:ssa on. Context switchingistä tulee kuitenkin ennen pitkää haittaa, jos aktiivisia säikeitä on liikaa. Tämä ei ole omaa kuvitelmaa, vaan luin tästä Unreal Enginen dokumentaatiosta.

SMTn hyöty (moderneilla prosessoreilla, ignorataan P4 jossa oli aivan liian pieni L1D-kakku) on tyypillisesti monenkertainen context switcheistä tulevaan haittaan verrattuna, mikäli kuorma on jakautunut tasaisesti.

Ja pelille on aivan triviaalia kysyä käyttikseltä, montako säiettä rauta pystyy ajamaan yhtä aikaa, ja käynnistämään (maksimissaan) sama määrä säikeitä.

Toki optimaalisen säikemäärän luomista haittaa se, että käyttiksessä voi olla ajossa muuta softaa yhtä aikaa, mutta tyypillisesti joidenkin taustaprosessien CPU-kuorma on aika olematon.

 

[GreenT]

Melkoista pulushakkia kun joka toisessa viestissä vaihtuu se, mitä olet tarkoittavinaan ja olet aivan totaalisen sekaisin siitä, mitä on ytimet, mitä säikeet, ja mitä virtaaliytimet("rautasäikeet").

Typoja tulee. Turha niitä jäädä vatvomaan ja lainailemaan. Olen kyllä kirjoittanut aivan riittävästi monisäikeistä koodia, jotta voin näitä asioita kommentoida. Maailmankatsomuksesi tuntuu olevan vahvasti raudan läheinen, omani enemmän devaajan näkökulma.

Se, että kovin mobessa nykypelissä ei ole niitä >6 säiettä johtuu vaan siitä, että niitä ei ole optimoitu 6-ytimisille SMT-prosessoreille.

No tämä jo selvisi aiemmin. Seuraava kehityssteppi on luultavasti 8C/16T.

SMTn hyöty on todella monenkertainen conrtext swticheistä tulevaan haittan verrattuna.

Nämä ovat kaksi täysin eri asiaa. Context switchingiä tapahtuu oli SMT päällä tai ei. Pointti tuossa oli se, että liian säikeistetty koodi johtaa liialliseen context switchingiin. Tuo on korjattavissa vähentämällä koodin säikeistystä.

 

[pomk]

Pointti tuossa oli se, että liian säikeistetty koodi johtaa liialliseen context switchingiin.

Toi on melkoinen puolitotuus. Säikeitä kannattaa aina luoda lisää niin kauan kunnes kaikki virtuaaliytimet on täytetty, kunhan säikeiden luontiin ja kokoamiseen ei kulu suhteettoman paljon aikaa verrattuna itse ohjelmakoodiin mitä säikeistettynä ajetaan.

Context switchejä ei kyseisessä tapauksessa tapahdu missään kohtaa tarpeettomasti ja ne context switchit itsessään eivät ole käytännössä koskaan se ongelma.

Jotta context switchit loisivat mitään pullonkauloja pitäisi säikeitä luoda paljon enemmän kuin on virtuaaliytimiä mitä niillä täyttää - joka on vaan täyttä idiotismia.

 

[GreenT]

Toi on melkoinen puolitotuus. Säikeitä kannattaa aina luoda lisää niin kauan kunnes kaikki virtuaaliytimet on täytetty, kunhan säikeiden luontiin ja kokoamiseen ei kulu suhteettoman paljon aikaa verrattuna itse ohjelmakoodiin mitä säikeistettynä ajetaan.

Context switchejä ei kyseisessä tapauksessa tapahdu missään kohtaa tarpeettomasti ja ne context switchit itsessään eivät ole käytännössä koskaan se ongelma.

Jotta context switchit loisivat mitään pullonkauloja pitäisi säikeitä luoda paljon enemmän kuin on virtuaaliytimiä mitä niillä täyttää - joka on vaan täyttä idiotismia.

Ei niitä koodisäikeitä kannata luoda vain sen takia, että järjestelmässä on resursseja vapaana vaan silloin kun niitä tarvitaan. "Liiallinen" tässä tarkoitti tilannetta, jossa context switchingillä on merkittävä vaikutus suorituskykyyn.

Kyse ei ole idiotismista, vaan monisäikeisen koodin tuottaminen on yleisesti vaikeaa. Ja sen optimointi vielä vaikeampaa. On helppoa luoda vahingossa turhia säikeeltä toiselle vaihtoja ja niitä ei pelkkää koodia lukemalla välttämättä huomaa.

 

[GreenT]

Jotta palataan aiheeseen, niin tietääkö joku onko säikeiden context switch Zen3-arkkitehtuurissa tehokkaampi vs. Zen2? Siellähän on nyt tuplasti isompi jaettu L3 cache. Mutta osaako CPU siirtää kontekstin ilman ylimääräistä kirjoitus+lukuoperaatiota?

 

[hkultala]

Jotta palataan aiheeseen, niin tietääkö joku onko säikeiden context switch Zen3-arkkitehtuurissa tehokkaampi vs. Zen2? Siellähän on nyt tuplasti isompi jaettu L3 cache. Mutta osaako CPU siirtää kontekstin ilman ylimääräistä kirjoitus+lukuoperaatiota?

Prossu ei osaa (juuri) yhtään mitään, context switch tehdään softalla käyttiksen toimesta.

 

[pomk]

"Liiallinen" tässä tarkoitti tilannetta, jossa context switchingillä on merkittävä vaikutus suorituskykyyn.

Tälläistä ei tapahdu kuin tilanteissa joissa luodaan useampia säikeitä kuin mitä on virtuaaliytimiä. Kukaan ei toivottavasti ole niin tyhmä että loisi niitä enemmän, virtuaaliytimien määrän kun voi pyytää käyttöjärjestelmältä.

On helppoa luoda vahingossa turhia säikeeltä toiselle vaihtoja ja niitä ei pelkkää koodia lukemalla välttämättä huomaa.

Säikeeltä toiselle vaihdot on erittäin nopeita. Liiallisen säikeistämisen pullonkaulat on lähes poikkeuksetta säikeiden synkronoinnista johtuvia.

 

[GreenT]

Prossu ei osaa (juuri) yhtään mitään, context switch tehdään softalla käyttiksen toimesta.

Juu, mutta jos se johtaa lopulta suorituksen siirtoon toiselle ytimelle, niin eikös jaetun isomman L3 cachen pitäisi auttaa tuossa (vrt. tilanne, jossa joudutaan kopiomaan tieto toiseen L3:een)?

 

[hkultala]

Juu, mutta jos se johtaa lopulta suorituksen siirtoon toiselle ytimelle, niin eikös jaetun isomman L3 cachen pitäisi auttaa tuossa (vrt. tilanne, jossa joudutaan kopiomaan tieto toiseen L3:een)?

Varsinaista "context"ia eli rekistereiden sisältöä on X86-64ssa AVXn kanssa alle 700 tavua, AVX-512n kanssa vajaat 2.2 kiB.

Siihen, paljonko varsinaiseen context swithiin menee aikaa ei sillä L3-kakulla ole käytännössä merkitystä.

Se, paljonko softa hidastuu siirryttyään eri ytimelle on sitten eri asia, ja riippuu täysin tilanteesta. Zen3lla on toki suurempi todennäköisyys sille, että kun säie on ensin siirtynyt pois suorituksesta ja joskus myöhemmin siirtyy takaisin suoritukseen, se on ytimellä jolla on sama L3-kakku ja sieltä löytyy vielä jotain dataa sen jäljiltä.

 

[GreenT]

Tälläistä ei tapahdu kuin tilanteissa joissa luodaan useampia säikeitä kuin mitä on virtuaaliytimiä. Kukaan ei toivottavasti ole niin tyhmä että loisi niitä enemmän, virtuaaliytimien määrän kun voi pyytää käyttöjärjestelmältä.

Tämä pätee softissa, joissa kaikki säikeet hallinnoidaan itse. Perinteinen malli peleissä on esim oma säie logiikalle, renderöinnille, audiolle ja tietoliikenteelle. Tuo malli ei skaalaudu isommalle CPUn säiemäärälle, mutta toisaalta context switchingiä ei juuri tapahdu.

Parempi malli on käyttää ns. thread poolia, joka hoitaa säikeiden varaamisen, vaihtamisen ja ajon. En tiedä kuinka tämä on peleissä käytössä, mutta hyötysoftissa laajemmin. Eri osajärjestelmät voivat rinnakkaistaa omaa laskentaansa ja lopulta kaikki ajetaan samoilla CPU-säikeillä. Tässä tapahtuu luonnostaan paljon context switchiä. Kun koodi rinnakkaistaa itse itseään, voi aktiivisia säikeitä olla ajossa iso määrä. Tämä voi johtaa tilanteeseen, jossa context switching syö tehot (thread pool starvation).

 

[hkultala]

Tämä pätee softissa, joissa kaikki säikeet hallinnoidaan itse. Perinteinen malli peleissä on esim oma säie logiikalle, renderöinnille, audiolle ja tietoliikenteelle. Tuo malli ei skaalaudu isommalle CPUn säiemäärälle, mutta toisaalta context switchingiä ei juuri tapahdu.

Parempi malli on käyttää ns. thread poolia, joka hoitaa säikeiden varaamisen, vaihtamisen ja ajon. En tiedä kuinka tämä on peleissä käytössä, mutta hyötysoftissa laajemmin. Eri osajärjestelmät voivat rinnakkaistaa omaa laskentaansa ja lopulta kaikki ajetaan samoilla CPU-säikeillä. Tässä tapahtuu luonnostaan paljon context switchiä. Kun koodi rinnakkaistaa itse itseään, voi aktiivisia säikeitä olla ajossa iso määrä. Tämä voi johtaa tilanteeseen, jossa context switching syö tehot (thread pool starvation).

Oikein tehdyssä thread poolingissa sinne pooliin luodaan säikeitä nimenomaan juuri se määrä, mikä prossussa on rautasäikeitä, jolloin siellä nimenomaan EI KOSKAAN OLE siitä softasta enempää säikeitä ajossa kuin mitä prossulla on rautasäikeitä.

Koska nimenomaan thread poolingissa niitä säikeitä ei luoda koska sattuu, vaan vain softan käynnistyessä luodaan sinne juuri oikea määrä säikeitä.

Toki tätä kuviota sotkee, jos koneella ajetaan jotain muutakin kuormittavaa yhtä aikaa.

 

[hsalonen]

Cinebench R20. PBO pois päältä ja muistit 3200CL16.

16 threadia (default):

8 threadia (@GreenT "optimi"):

32 threadia ("APUA! Context Switchit paukkuu koko ajan!"):

Tämä testi on vielä kaikkien toistettavissa ja raskasta laskentaa, jossa säikeitä rasitetaan koko ajan.

Voisitteko nyt vaikka itse testata tai ottaa sen pään pois sieltä hiekasta?

 

[pomk]

Parempi malli on käyttää ns. thread poolia, joka hoitaa säikeiden varaamisen, vaihtamisen ja ajon. En tiedä kuinka tämä on peleissä käytössä, mutta hyötysoftissa laajemmin. Eri osajärjestelmät voivat rinnakkaistaa omaa laskentaansa ja lopulta kaikki ajetaan samoilla CPU-säikeillä. Tässä tapahtuu luonnostaan paljon context switchiä. Kun koodi rinnakkaistaa itse itseään, voi aktiivisia säikeitä olla ajossa iso määrä. Tämä voi johtaa tilanteeseen, jossa context switching syö tehot (thread pool starvation).

Jos thread poolin perustaa järkevästi siten että sinne luodaan virtuaalisten ytimien määrää vastaava määrä säikeitä, niin context switchejähän ei teknisesti tapahdu ollenkaan.

Mitä hyötyä on siitä että sinne pooliin luodaan säikeitä joita ei voida ajaa samanaikaisesti? (Spesifisti puhuttaessa pelimoottoreista siis. jossain enterprise softassa voin kuvitella moiselle jotain käyttöä, sillä vaikka jokaiselle käyttäjälle voidaan webbipalvelussa varata oma säie ja siten välttyä turhilta tietokantahauilta tai muuta vastaavaa.)

 

[GreenT]

Tämä testi on vielä kaikkien toistettavissa ja raskasta laskentaa, jossa säikeitä rasitetaan koko ajan.

Voisitteko nyt vaikka itse testata tai ottaa sen pään pois sieltä hiekasta?

Peleistähän tässä on ollut koko ajan kyse. Cinebench ei ole edes reaaliaikasovellus ja se osaa varsin varmasti hyödyntää kaikki CPU-resurssit. Kokeile sama testi SMT off ja on jonkun pelin kanssa ja katso paljonko FPS paranee (spoiler: ei vaikutusta).

Moni tuntuu käsittävän context switchingin rampauttavan CPU:n heti, kun "rautasäikeet" on varattu. Yritin selittää, että tuo tapahtuu vasta erittäin suurella määrällä softasäikeitä ja on käytännössä ohjelmointivirhe. Ilmeisesti epäonnistuin tuossa selityksessä. Voitte tarkistaa vaikka task managerista, montako threadia koneella on ajossa ja vaikuttaako se tahmealta (itsellä nyt n. 4000 idlessä, 1-3% kuormitus). Tässä menee nyt monella sekaisin CPU:n säikeet, käyttöjärjestelmän säikeet ja softan säikeet.

Jos thread poolin perustaa järkevästi siten että sinne luodaan virtuaalisten ytimien määrää vastaava määrä säikeitä, niin context switchejähän ei teknisesti tapahdu ollenkaan.

Mitä hyötyä on siitä että sinne pooliin luodaan säikeitä joita ei voida ajaa samanaikaisesti? (Spesifisti puhuttaessa pelimoottoreista siis. jossain enterprise softassa voin kuvitella moiselle jotain käyttöä, sillä vaikka jokaiselle käyttäjälle voidaan webbipalvelussa varata oma säie ja siten välttyä turhilta tietokantahauilta tai muuta vastaavaa.)

Thread pool on yleensä frameworkin/enginen hallitsema ja sinne ei käsin luoda säikeitä. Tuon voi ajatella työjonona, johon pusketaan töitä useasta lähteestä. Thread pool jakaa työt vapaille säikeille, vuorottelee niitä, havaitsee nälkiintymisen, deadlockit jne. Säikeitä ajetaan luonnollisesti rinnakkain niin montaa kuin mahdollista. Tässä ratkaisussa etuna on mm. se, että kaikki CPU-säikeet käytetään optimaalisesti hyödyksi kuorman perusteella ja softa skaalautuu ylöspäin rajatta. Koodaajan täytyy vain huolehtia, ettei ns. blokkaa säiettä (se ei vapaudu silloin muille, laskee suorituskykyä ja voi aiheuttaa thread poolin nälkiintymisen).

Softassa voi siten olla vaikka tuhat koodisäiettä ajossa yhtäaikaa, jotka hoidetaan thread poolin kautta CPU:n säikeille, kuinka paljon niitä ikinä onkaan. Nämä koodisäikeet ajetaan thread poolin säikeillä, jotka saadaan käyttikseltä, joka saa ne CPU:lta.

Webbipalvelussa ei kannata varata säikeitä käyttäjille, vaan edelleen käyttää poolia ja luoda sinne tehtäviä jonoon. Jos varaat säikeen käyttäjälle, niin mitäs jos se vaan avaa etusivun ja lähtee kahville? Ja seuraavat sata tekee samoin?

 

[pomk]

Peleistähän tässä on ollut koko ajan kyse. Cinebench ei ole edes reaaliaikasovellus ja se osaa varsin varmasti hyödyntää kaikki CPU-resurssit. Kokeile sama testi SMT off ja on jonkun pelin kanssa ja katso paljonko FPS paranee (spoiler: ei vaikutusta).

Moni tuntuu käsittävän context switchingin rampauttavan CPU:n heti, kun "rautasäikeet" on varattu. Yritin selittää, että tuo tapahtuu vasta erittäin suurella määrällä softasäikeitä ja on käytännössä ohjelmointivirhe. Ilmeisesti epäonnistuin tuossa selityksessä. Voitte tarkistaa vaikka task managerista, montako threadia koneella on ajossa ja vaikuttaako se tahmealta (itsellä nyt n. 4000 idlessä, 1-3% kuormitus). Tässä menee nyt monella sekaisin CPU:n säikeet, käyttöjärjestelmän säikeet ja softan säikeet.


Thread pool on yleensä frameworkin/enginen hallitsema ja sinne ei käsin luoda säikeitä. Tuon voi ajatella työjonona, johon pusketaan töitä useasta lähteestä. Thread pool jakaa työt vapaille säikeille, vuorottelee niitä, havaitsee nälkiintymisen, deadlockit jne. Säikeitä ajetaan luonnollisesti rinnakkain niin montaa kuin mahdollista. Tässä ratkaisussa etuna on mm. se, että kaikki CPU-säikeet käytetään optimaalisesti hyödyksi kuorman perusteella ja softa skaalautuu ylöspäin rajatta. Koodaajan täytyy vain huolehtia, ettei ns. blokkaa säiettä (se ei vapaudu silloin muille, laskee suorituskykyä ja voi aiheuttaa thread poolin nälkiintymisen).

Softassa voi siten olla vaikka tuhat koodisäiettä ajossa yhtäaikaa, jotka hoidetaan thread poolin kautta CPU:n säikeille, kuinka paljon niitä ikinä onkaan. Nämä koodisäikeet ajetaan thread poolin säikeillä, jotka saadaan käyttikseltä, joka saa ne CPU:lta.

Webbipalvelussa ei kannata varata säikeitä käyttäjille, vaan edelleen käyttää poolia ja luoda sinne tehtäviä jonoon. Jos varaat säikeen käyttäjälle, niin mitäs jos se vaan avaa etusivun ja lähtee kahville? Ja seuraavat sata tekee samoin?

Mutta miksi se (pelimoottorin) framework tekisi pooliin säikeitä enemmän kuin on virtuaaliytimiä? Mikä on se etu tästä? Pelimoottoreissa on erilaisia taskeja jotka pitää aina saattaa valmiiksi ennen kuin aletaan seuraavaa framea laskemaan, joten millään vuorottelulla ei saada aikaiseksi kuin context switchailusta johtuvaa hidastumista.

Nämä koodisäikeet ajetaan thread poolin säikeillä, jotka saadaan käyttikseltä, joka saa ne CPU:lta.

No ei tasan saa niitä CPU:lta. Säikeiden luominen on ihan softatason hommia.

Webbipalvelussa ei kannata varata säikeitä käyttäjille, vaan edelleen käyttää poolia ja luoda sinne tehtäviä jonoon. Jos varaat säikeen käyttäjälle, niin mitäs jos se vaan avaa etusivun ja lähtee kahville? Ja seuraavat sata tekee samoin?

Siellä voi olla poolissa vaikka miljoona säiettä. Vanhin tai vähiten käytetty voidaan tuhota siinä vaiheessa kun ne loppuvat kesken. Jos laitetaan vain tehtäviä jonoon, niin asiakaskohtainen data pitää joka kerta hakea tietokannasta kun uutta tehtävää suoritetaan. En oikeasti tiedä mitä hyötyä näistä isoista threadpooleista on, tämä oli vain joku heitto.
Kerro sinä?

Peleistähän tässä on ollut koko ajan kyse. Cinebench ei ole edes reaaliaikasovellus ja se osaa varsin varmasti hyödyntää kaikki CPU-resurssit.

Pelitkään ei ole reaaliaikasovelluksia, windows ole reaaliaikakäyttöjärjestelmä ja ryzen ei sovellu reaaliaikaisiin toteutuksiin ylipäänsä vaikka käyttis vaihdettaisiin. Tämä johtuu siitä että ryzen prossussa on paljon epädeterministisiltä vaikuttavia mekanismeja ja AMD:lla ei ole halua antaa niin tarkkoja dokumentaatiota että nämä asiat voitaisiin huomioida oikean reaaliaikajärjestelmän vaatimalla tarkkuudella.

Thread pool jakaa työt vapaille säikeille, vuorottelee niitä, havaitsee nälkiintymisen, deadlockit jne.

On aika älytön idea että threadpoolia käytettäisiin mitigoimaan paskasta säikeistämisestä johtuvia ongelmia, kuten nälkiintyminen ja deadlockit. Hyvä homma jos se noista ilmoittaa ja auttaa näyttämään että missä on implementaatiovirheet, mutta että ihan oikeasti tuotannossa tuohon luotettaisiin... toisaalta on sitä hullumpiakin juttuja kuultu. Noiden tunnistamiseenhan menee ihan typerän kauan aikaa kaiken lisäksi, eikö?

 

[GreenT]

Mutta miksi se (pelimoottorin) framework tekisi pooliin säikeitä enemmän kuin on virtuaaliytimiä? Mikä on se etu tästä? Pelimoottoreissa on erilaisia taskeja jotka pitää aina saattaa valmiiksi ennen kuin aletaan seuraavaa framea laskemaan, joten millään vuorottelulla ei saada aikaiseksi kuin context switchailusta johtuvaa hidastumista.

Poolissa ei toki ole säikeitä - tai oikeammin workereita - enempää kuin virtuaaliytimiä (ainakaan en tunne tällaista tilannetta). Workereita voi olla myös vähemmän kuin virtuaaliytimiä käyttötarkoituksesta riippuen. Peli voi esim. luoda pääsäikeen ja käyttää muita alijärjestelmiä yhteisen rajatun thread poolin kautta. Tämä vastannee aika moneen kysymykseesi.

Vuorottelulla saadaan nimenomaan aikaiseksi se, että virtuaaliytimiä hyödynnetään optimaalisesti.

Ajatellaan esimerkki, jossa pelissä on 4 alijärjestelmää ja ne kukin luovat taskeja pooliin: A=100, B=50, C=25 ja D 25 taskia. CPU:na esimerkiksi joku 4C/4T. Yksinkertaisuuden vuoksi oletetaan, että yksittäisten taskien ajoajat ovat samoja. Otetaan käyttöön thread pool, jossa on 4 workeria. Koska taskeja on yhteensä 200, yhden framen laskenta kestää 50 taskin verran. Jos jokaiselle alijärjestelmälle taas varattaisiin oma dedikoitu säie (kuten pelit yleensä toimivat), niin yhden framen laskentaan kuluisi 100 taskin verran (koska silloin mennään hitaimman alijärjestelmän mukaan). Näin ollen ajoaika puolittuu thread poolilla. Isommalla määrällä virtuaaliytimiä poolia käytettäessä frame time parantuisi edelleen.

Jos laitetaan vain tehtäviä jonoon, niin asiakaskohtainen data pitää joka kerta hakea tietokannasta kun uutta tehtävää suoritetaan.

Ei tarvitse. Yhden alijärjestelmän taskit voivat prosessoida samaa dataa. Haet datan kannasta ja prosessoit sen rinnakkain erillisillä taskeilla (esim. vuosiraportissa kuukausien mukaan tms).

Pelitkään ei ole reaaliaikasovelluksia, ...

Tarkoitin reaaliaikasovelluksella softaa, jossa dataa ei voi puskuroida kuin millisekunneiksi kuten esim. pelit ja audiosoftat.

On aika älytön idea että threadpoolia käytettäisiin mitigoimaan paskasta säikeistämisestä johtuvia ongelmia, kuten nälkiintyminen ja deadlockit. Hyvä homma jos se noista ilmoittaa ja auttaa näyttämään että missä on implementaatiovirheet, mutta että ihan oikeasti tuotannossa tuohon luotettaisiin... toisaalta on sitä hullumpiakin juttuja kuultu. Noiden tunnistamiseenhan menee ihan typerän kauan aikaa kaiken lisäksi, eikö?

NIin, onneksi tuotannossa ei ikinä ole paskaa koodia Battle-testatun thread poolin käyttö on huomattavasti järkevämpää kuin yrittää tehdä parempaa itse. Niissä omissa virityksissä ongelmien metsästys ei ole kovin mukavaa, jos softa jumiutuu satunnaisesti kerran päivässä tai viikossa (nimim. kokemus on ). Thread poolilla säikeiden väärinkäyttö on edelliseen verrattuna huomattavasti pienempi ongelma, koska vain suorituskyky kärsii.

 

[pomk]

Poolissa ei toki ole säikeitä - tai oikeammin workereita - enempää kuin virtuaaliytimiä (ainakaan en tunne tällaista tilannetta). Workereita voi olla myös vähemmän kuin virtuaaliytimiä käyttötarkoituksesta riippuen. Peli voi esim. luoda pääsäikeen ja käyttää muita alijärjestelmiä yhteisen rajatun thread poolin kautta. Tämä vastannee aika moneen kysymykseesi.

Vuorottelulla saadaan nimenomaan aikaiseksi se, että virtuaaliytimiä hyödynnetään optimaalisesti.

Ajatellaan esimerkki, jossa pelissä on 4 alijärjestelmää ja ne kukin luovat taskeja pooliin: A=100, B=50, C=25 ja D 25 taskia. CPU:na esimerkiksi joku 4C/4T. Yksinkertaisuuden vuoksi oletetaan, että yksittäisten taskien ajoajat ovat samoja. Otetaan käyttöön thread pool, jossa on 4 workeria. Koska taskeja on yhteensä 200, yhden framen laskenta kestää 50 taskin verran. Jos jokaiselle alijärjestelmälle taas varattaisiin oma dedikoitu säie (kuten pelit yleensä toimivat), niin yhden framen laskentaan kuluisi 100 taskin verran (koska silloin mennään hitaimman alijärjestelmän mukaan). Näin ollen ajoaika puolittuu thread poolilla. Isommalla määrällä virtuaaliytimiä poolia käytettäessä frame time parantuisi edelleen.

Noniin, eli miten context switchit on ongelma jos säikeitä ei ole kuin sama määrä mitä virtuaaliytimiä on järjestelemässä? Context switch on spesifisti tilanne jossa ajossa oleva säie vaihdetaan toiseen, jos säikeitä ei ole enempää kuin virtuaaliytimiä niin tälläisiä tilanteita ei tule koskaan! (käyttis voi välillä rikkoa tilannetta, mutta käsittääkseni olemme puhuneet tilanteesta jossa context switchit ovat (sinusta) ongelma softan optimoimisessa moniydinjärjestelmille)

Olen ihan tarpeaksi paininut elämässäni säikeistettyjen enterprise softien, reaaliaikajärjestelmien ja säikeistetyn reaaliaikasoftan kanssa ja tunnen kyllä termit, älä turhaan yritä alkaa opettamaan.

Vuorottelulla saadaan nimenomaan aikaiseksi se, että virtuaaliytimiä hyödynnetään optimaalisesti.

Voisitko tarkentaa mitä tällä tarkoitat. Säikeiden ja taskien vuorottelu ytimillä hukkaa aina aikaa tilanteessa jossa pooliin annetut taskit pitää laskea auki jossain tavoiteajassa. Em. lainauksen alla olevassa kuvauksessa yhtäkään säiettä tai taskia ei vuorotella. Vuorottelulla tarkoitetaan spesifisti sitä että jokin kesken olevaa taskia suorittava säie otettaisiin pois suorituksesta ja toinen laitettaisiin tilalle, tälläistä tapahtuu esimerkiksi tilanteissa joissa säikeitä on ajossa enemmän kuin järjestelmässä on virtuaaliytimiä.

Tarkoitin reaaliaikasovelluksella softaa, jossa dataa ei voi puskuroida kuin millisekunneiksi kuten esim. pelit ja audiosoftat.

Jaa, käytä mielellään sitten oikeita termejä. Jonkun tietokone tai konsolipelin n. 17ms syöte-vaste "aikakriittisyys" on aika kaukana mistään reaaliaikasovelluksesta. Esimerkiksi G-syncin koko idea on että mitään tiukkoja aikakriittisyyksiä ei enää ole. Englanniksi puhutaan near real time sovelluksista, ja toi 17ms on siinäkin kontekstissa jo aika villi aikaikkuna, ottaen huomioon että mitään tiukkaa takarajaa ei ole. Audiosoftissa on tiukat takarajat joiden jälkeen tulee erilaisia artefakteja, ja siten niiden kohdalla on asiallista puhua NRT softasta. Audiopuolellakin varsinaiset RT toteutukset tehdään siihen kykenevällä raudalla, joku ryzen PC ei tälläinen ole.

edit: ja vielä korostan: lähes poikkeuksetta liiasta säikeistämisestä johtuvat ongelmat syntyvät säikeiden synkronoimisen overheadista, joka on helppo välttää olemalla säikeistämättä liian pieniä yksiköitä koodista. Joku cinebench ei esimerkiksi tarvitse juuri mitään synkronointia säikeiden välille, sillä tulosten keräilyllä ei ole mikään kiire, ja ei luultavasti hidastu merkittävästi vaikka sitä ajaisi tuhansilla säikeillä ja siten järjettömällä määrällä context switchejä. Pelimoottoreissa taas tyypillisesti tarvitaan edellisen vaiheen tulokset jotta seuraava voidaan aloittaa. Tällöin säikeet pitää saada synkattua välissä ja siihen menevä aika valitettavasti usein skaalautuu isommaksi isommilla säiemäärillä. Tämän takia säikeitä/taskeja ei kannata luoda kaikissa tilanteissa jokaiselle virtuaaliytimelle laskettavaksi, sillä liian pienten taskien tapauksessa synkronointiin alkaa menemään enemmän aikaa kuin mitä laskenta nopeutuu säikeistämisestä. Etenkin varhaisilla säikeistämistä helpottavilla kirjastoilla oli usein liian helppoa vahingossa säikeistää softaa liian pitkälle.

 

[Stephen Elop]

Onpa täällä nyt hirvee pohdinta miten säikeistys on tehty peleissä. Jos kiinnostaa niin pari ihan kovaa pelimoottoria on lähdekoodeineen ilmaiseksi saatavilla (unreal ja se amazonin hankkima vanhempi cryo -engine). Uniginestä en ole varma tuleeko siinä lähdekoodi näkyviin.

Mainitsen vain ettei tartte tyytyä olettamuksiin ja nettimutuiluihin.

Ja omasta mielestäni 5900 toisella chipletillä oleva cache on sen verran pieni oletettava haitta ettei ole mitään väliä. Mutuilen haitaksi peleissä maksimissaan 5%. Vertailkaa vaikka 3800x ja 3900x prossuja samoilla kelloilla ja asetuksilla. Antaa ihan riittävän hyvin suuntaa tuohon säie -jaaritteluun.

 

[pomk]

Onpa täällä nyt hirvee pohdinta miten säikeistys on tehty peleissä. Jos kiinnostaa niin pari ihan kovaa pelimoottoria on lähdekoodeineen ilmaiseksi saatavilla (unreal ja se amazonin hankkima vanhempi cryo -engine). Uniginestä en ole varma tuleeko siinä lähdekoodi näkyviin.

Ei ole valitettavasti kyse edes mistään noin mielenkiintoisesta, vaan siitä että tää yks sankari väittää että context switchit olis joku oleellinen ongelma pelien yhteydessä ja että moista tapahtuisi tyypillisissä thread poolia käyttävissä softissa. Kumpikaan väite ei erityisesti pidä paikkaansa missään järkevässä mittakaavassa, mutta kaveri ei ymmärrä lopettaa.

Ja omasta mielestäni 5900 toisella chipletillä oleva cache on sen verran pieni oletettava haitta ettei ole mitään väliä. Mutuilen haitaksi peleissä maksimissaan 5%. Vertailkaa vaikka 3800x ja 3900x prossuja samoilla kelloilla ja asetuksilla. Antaa ihan riittävän hyvin suuntaa tuohon säie -jaaritteluun.

Siis sehän tulee vain nopeuttamaan kyseistä prossua verrattuna yhden chipletin prossuihin samalla ydinmäärällä per chiplet niin kauan kuin peli rullaa lähinnä toisen chipletin sisällä. Vain tilanteissa joissa pelin säikeet keskustelevat paljon keskenään ja niitä luodaan tarpeeksi täyttämään myös toinen CCX tulee (vähän) latenssiongelmia jotka voivat pelikohtaisesti olla jopa marginaalinen haitta suhteessa nopeampaan varsinaiseen laskentaan. Se toisen CCX:n cache teknisesti ottaen voi vain nopeuttaa toisen CCX:n tekemiä muistihakuja - ei koskaan hidastaa.

 

[Juha Kokkonen]

Palailkaapas ketjun aiheeseen, vaikka mielenkiintoista keskustelua sinäänsä onkin.

 

[Cirrus]

Tämmöstäkin uutiusta ettei asus esim olisikaan tuomassa 5000-supporttia emoihinsa:

ASUS Seemingly Drops Support for AMD Ryzen 5000 Series CPUs on X470 Motherboards, the Company Responds

Today there is some quite interesting information circulating the web regarding ASUS and its alleged decision. Going a few months back, AMD released a statement regarding the support for its upcoming Ryzen 5000 series CPUs and said that it should enable compatibility with the last-generation...

www.techpowerup.com

 

[P c L A Y E R]

Tämmöstäkin uutiusta ettei asus esim olisikaan tuomassa 5000-supporttia emoihinsa:

ASUS Seemingly Drops Support for AMD Ryzen 5000 Series CPUs on X470 Motherboards, the Company Responds

Today there is some quite interesting information circulating the web regarding ASUS and its alleged decision. Going a few months back, AMD released a statement regarding the support for its upcoming Ryzen 5000 series CPUs and said that it should enable compatibility with the last-generation...

www.techpowerup.com

Vitun vittu. Olis pitäny ostaa vaan se x570 silloin 2019 kesällä, mutta ne piirisarja sirkkelit ei innostanut yhtään, ja x470:n "piti" tukea seuraavaksi prossua. Se on sitte taas pistettävä winukkakin uusiksi.

 

[Kizmo]

Asus on jo sanonut ettei tuo pidä paikkaansa

Tämän sisällön näkemiseksi tarvitsemme suostumuksesi kolmannen osapuolen evästeiden hyväksymiseen.
Lisätietoja löydät evästesivultamme.

Hyväksy kolmannen osapuolen evästeet

 

[Rogue85]

Tässähän joutuu nyt ihan pähkäilemään, että odottaisiko, että Ryzen 5700X tai 5800X tulee vai hankkisinko 3900X/XT:n. Koneella tulee tehtyä ihan kaikenlaista laidasta laitaan: pelaamista, virtualisointia (1-3 virtuaalista Windows Server 2019 testipannua), musahommia Cubase 10.5:lla (projekteissa useita kymmeniä raitoja, vst-efektejä yms. prosessointia). Pelihommiin odottelen CPU:n kaveriksi RTX 3080:aa. 3900 tuskin mikään pullonkaula olisi, vaikka yhden core suorituskyky taitaakin olla hieman heikompaa kuin Zen3 prossuissa.

 

[tenux]

5950X tulee itelle. Osta mun vanha Ser 3950X pois

 

[Rogue85]

Nyt Jimms laittoi hinnatkin julki. 5800X ois 479 eli sen 30e edullisempi kuin 3900XT

 

[Asmola]

Nyt Jimms laittoi hinnatkin julki. 5800X ois 479 eli sen 30e edullisempi kuin 3900XT

On ne näkyneet jo useamman päivän.

 

[taffeli]

Tekis mieli ostaa uus prossu, mutta nykyinen 3900x on kyllä kaikilla mittapuilla riitävä
Pitää oottaa Radeonit, että saa jotain hoitoa tähän raudanpuutteeseen.. (ilman anemiaa)

 

[Taneli-]

5950X tulee itelle. Osta mun vanha Ser 3950X pois

Siitä vaan @Rogue85 :lle 3900X:n hinnalla niin luulen että molemmat olette tyytyväisiä

Itse taidan edelleen tyytyä 5900X prosessoriin (nyt 3900X) enkä saa perusteltua niin suurta hyppyä hinnassa vaikka saisikin 4kpl ytimiä lisää. Onpahan ainakin sitten "todistetusti maailman paras peliprosessori" () koneessa jos ei muuta.

 

[jobbus]

Itseäkin kiinnostaisi hankkia toi R9 5900X mutta sitten joutuisi vaihtamaan myös tämän C6H emon johki MSI X570 tomahawk emoon, niin alkaa tulee liikaa päivitykselle hintaa. No kunhan joskus saan tilaamani RTX3080 kortin (ehkä ensi vuonna) niin sitten voi mieli muuttua jos alkaisi tuntua siltä että tämä R9 3900X prosu aiheuttaa pullonkaulaa tuolle näytönohjaimelle.
Tosin itse pidän toivoa yllä että joku joskus tekisi jonkun zen3 custom bioksen tälle C6H laudalle.

 

[tenux]

Ei tästä nyt pelikonetta saa hetkeen. Edelleen 1080 sisällä. Peruin ton 3080 tilauksen jimms:ltä. Rahat tuli ihan nopsaan takas tonne visakortille reilu 1pv. Tilataan uudestaan jahka saatavuus paranee.

Ja tuosta 5950X voi olla jopa parempi saatavuus, suurin osa ostaa noita pienempiä.
Tosin en nyt tiedä ostaako heti 16:00 ei viiti töistä olla pois aiemmin yhen hassun prossun takia. Mutta jos tuo suorituskyky ei sittenkään vakuuta niin sitten odotellaan ddr5 aikaa.

 

[JiiPee]

Vitun vittu. Olis pitäny ostaa vaan se x570 silloin 2019 kesällä, mutta ne piirisarja sirkkelit ei innostanut yhtään, ja x470:n "piti" tukea seuraavaksi prossua. Se on sitte taas pistettävä winukkakin uusiksi.

En kyllä ymmärrä että miks se windows pitäs uusiks laittaa?

Ittellä on windows 10 asennus joka on tehty edellisen koneen aikaan ja se kone oli Intel kokoonpano, i5 4670K. Heitin aseman rysen kokoonpanoon kiinni ja sen jälkeen on menty liki pari vuotta kovaa ajoa sillä samalla asennuksella.
Nyt jos 400 sarjalaisesta siirtyy 500 sarjalaiseen niin jopa piirisarjan ajurit pysyy samana eli ei kyllä pitäs olla niin mitään ongelmia.

Joskus XP aikana tuo windowsin siirto raudasta toiseen oli yhtä tuskaa ja helpompi oli vetää windowes uusiks. Mutta XP ajoista on kehitystä tapahtunut valtavasti.

 

[bahis]

Varsinkin Windows 10 paransi tuota koneesta toiseen siirtämistä. Toimii hyvin vaikka vaihtuu emo. Toki jos on OEM lisenssi niin sen aktivoinnin kanssa voi tulla säätöä.

 

[jkm]

^^^ #Offtopic.. Siinä kun päivittää Windows 10 uudempaan buildiin, niin se käytännössä asentaa Windowsin uudestaan. Eli rautavaihto on hyvä ajoittaa semmoseen hetkeen.

 

[Jarnis]

Oma win10 on alun perin instattu WinXP ja Athlon64 X2 4600+ / Nforce4... Updatettu XP -> Win 7 -> 10 ja rauta vaihtunut alta viis kertaa. Edelleen toimii. Win7-aikakaudella piti tehdä vähän preppiä ja loitsuja ennen emon vaihtoa mutta kympin kanssa ainoa efekti on että ensimmäinen bootti uudella emolla on vähän semmoine "ohhoh, mihis kaikki mun tutut ja turvalliset laitteet hävis, venaas hetki niin ponderaan" mutta kyllä se sieltä nousee.

 

[Raparipa]

Disclaimer : AMD seteistä kun en tiedä mitään.

Mitään tietoa milloin mahtaa tulla Zen3 sarjan prossuja korvaamaan nykyisiä 3100 ja 3300x prossuja, vai onko kenties tulossakaan? Mini ITX settiä NZXT H1 koteloon funtsimassa, mini-mini-mini budjetilla.

 

[Kaotik]

Disclaimer : AMD seteistä kun en tiedä mitään.

Mitään tietoa milloin mahtaa tulla Zen3 sarjan prossuja korvaamaan nykyisiä 3100 ja 3300x prossuja, vai onko kenties tulossakaan? Mini ITX settiä NZXT H1 koteloon funtsimassa, mini-mini-mini budjetilla.

Joskus keväällä aikaisintaan, veikkaisin.

 

[ratkakapu]

Disclaimer : AMD seteistä kun en tiedä mitään.

Mitään tietoa milloin mahtaa tulla Zen3 sarjan prossuja korvaamaan nykyisiä 3100 ja 3300x prossuja, vai onko kenties tulossakaan? Mini ITX settiä NZXT H1 koteloon funtsimassa, mini-mini-mini budjetilla.

Aika älytön kotelovalinta minibudjetille...

3100 ja 3300x tulivat myyntiin 10 kuukautta ensimäisten Zen 2 prossujen jälkeen. 7nm on oletettavasti tänään vielä parempi saantojen osalta kuin puolitoista vuotta sitten, jolloin Zen 2 prossuja alettiin tekemään ja niitäkin kerättiin siis yli vuoden verran varastoon ennen kuin 4-ytiminen prossu julkaistiin.
Toki leikattujen prosessoreiden saatavuus ja julkaisu ei ole puhtaasti rikkinäisistä piireistä kiinni, mutta aikalailla varma juttu on, että puoleen vuoteen ainakaan noita ei ole tulossa, mahdollisesti sitten kun Intel julkaisee Rocket Laket niin AMD julkaisee esim 4-ytimisiä alistamaan budjettiluokkaan

 

[leffo]

Tosin AMDllä ei ole yhtään modernia 4-ydin-APUa tuotannossa. Renoir on jo 8-ytiminen ja Banded Kestler on vain 2-ytiminen.

Renoir on myös 4 ja 6 ytimisiä? Vai tarkoititko kuluttajamyyntiä, kun suurin osa tai kaikki on OEM? (tällä hetkellä, ainakin suunnitelmissa pitäisi olla noiden APUjen kuluttajamyyntikin)

 

[Kaotik]

Renoir on myös 4 ja 6 ytimisiä? Vai tarkoititko kuluttajamyyntiä, kun suurin osa tai kaikki on OEM? (tällä hetkellä, ainakin suunnitelmissa pitäisi olla noiden APUjen kuluttajamyyntikin)

Ei vaan sirun fyysistä toteutusta.

 

[hkultala]

Renoir on myös 4 ja 6 ytimisiä? Vai tarkoititko kuluttajamyyntiä, kun suurin osa tai kaikki on OEM? (tällä hetkellä, ainakin suunnitelmissa pitäisi olla noiden APUjen kuluttajamyyntikin)

Tarkoitin piilastuja, joissa on tasan 4 ydintä olemassa.

4- ja 6-ytimisinä ytimisenä myytävät Renoirit on 8-ytimisiä joista on osa ytimistä kytketty pois päältä.

Matisse tai Vermeer on AMDlle halvempi valmistaa kuin Renoir, joten jos halutaan tehdä joku 4-ytiminen vähintään zen2-ytimillä oleva piiri jossa näyttistä ei tarvita, AMDlle tulee halvemmaksi tehdä se rampauttamalla Matisse tai Vermeer, kuin tehdä se rampauttamalla Renoir.

Mutta toki noita 4-ytimisiä myydään jonkin verran sellaisiin markkinasegmentteihin, joissa erillisnäyttistä ei (hinta-, tila- tai virrankulutussyistä) haluta, joilloin tarvitaan sitä Renoirin integroitua näyttistä.

Näköjään Renoiristakin on vain yhdet 4-ytimiseksi rampautetut mallit, pöytäkoneisiin 4300G ja läppäreihin 4300U, kaikki muut on vähintään 6-ytimisiä, ja suurin osa 4-ytimisistä on sitten vanhempaa sukupolvea.


Markkinanäkökulmasta vanha 4-ytiminen Picasso(Raven Ridge "12nm" tekniikalla) on edelleen tiettyyn markkinasegmenttiin (low-end muttei super-low-end?) AMDlle aika hyvä piiri, koska sen valmistus on selvästi halvempaa kuin Renoirin (koska "12nm" pii on n. 1.6x halvempaa kuin "7nm" pii, on 210mm^2 "12nm" piiri halvempi valmistaa kuin 156 mm "7nm" piiri) ja koska AMD WSAn takia maksaa kuitenkin Globalfoundriesille jostain piistä huomattava määrä, ja näissä Picassoissa on natiivisti se 4 ydintä.

Esim. suomalaisista verkkokaupoista ei pikavilkaisulla tunnu noita 4000G-sarjan ryzeneitä (pöytäkonemalleja Renoirista) löytyvän ollenkaan, kun taas Picassoja on jonkin verran (tosin ei hirveän paljon niitäkään) tarjolla. Taitaa mennä aika lailla pakettikonevalmistajille Renoirit.
Ja 3100:sta (4-ytimiseksi rampautettu Matisse) on oikein hyvin saatavilla.

 

[Mechanical Man]

Eikös WSAn mukaan nimenomaan 7nm ja siitä eteenpäin ei aiheuta kustannuksia AMDlle.

 

[Kaotik]

Eikös WSAn mukaan nimenomaan 7nm ja siitä eteenpäin ei aiheuta kustannuksia AMDlle.

Ei aiheuta ylimääräisiä kustannuksia mutta AMD:n pitää silti tietty ostaa tietty määrä kiekkoja GloFolta

 

[vemkki]

Tämä Zen 3 kyllä jotenkin ällistyttää. I/O-piiri on pysynyt samana. Chiplet näyttää suunnilleen samankokoiselta, ja prosessi ei ole muuttunut merkittävästi, joten transistoreja ei ilmeisesti ole tullut pahemmin lisää. Suorituskykyä on kuitenkin tullut reilusti lisää. Herää kysymys, että olisiko Zen 2 voinut periaatteessa olla lähes yhtä hyvä? Yleensä on tottunut siihen, että transistoreja tulee rutkasti lisää uudessa sukupolvessa, jos suorituskykyä on saatu lisättyä jotenkin muuten kuin kelloja nostamalla.

 

[Nerkoon]

Tämä Zen 3 kyllä jotenkin ällistyttää. I/O-piiri on pysynyt samana. Chiplet näyttää suunnilleen samankokoiselta, ja prosessi ei ole muuttunut merkittävästi, joten transistoreja ei ilmeisesti ole tullut pahemmin lisää. Suorituskykyä on kuitenkin tullut reilusti lisää. Herää kysymys, että olisiko Zen 2 voinut periaatteessa olla lähes yhtä hyvä? Yleensä on tottunut siihen, että transistoreja tulee rutkasti lisää uudessa sukupolvessa, jos suorituskykyä on saatu lisättyä jotenkin muuten kuin kelloja nostamalla.

Suunnitteluun kuluvasta ajasta tuossa on ollut puutetta. Kaikkea listalla olevaa ei keritty lisäämään Zen2 versioon

 

[Kizmo]

Tämä Zen 3 kyllä jotenkin ällistyttää. I/O-piiri on pysynyt samana. Chiplet näyttää suunnilleen samankokoiselta, ja prosessi ei ole muuttunut merkittävästi, joten transistoreja ei ilmeisesti ole tullut pahemmin lisää. Suorituskykyä on kuitenkin tullut reilusti lisää. Herää kysymys, että olisiko Zen 2 voinut periaatteessa olla lähes yhtä hyvä? Yleensä on tottunut siihen, että transistoreja tulee rutkasti lisää uudessa sukupolvessa, jos suorituskykyä on saatu lisättyä jotenkin muuten kuin kelloja nostamalla.

Eikös tuosta aikaisemmin jo puhuttu että kun alkuperäinen ZEN suunniteltiin niin suunnittelupöydälle jäi paljon asioita joita ei pystytty ajan tai rahan takia implementoimaan. Nyt sitten on pöytää tyhjennetty ja lisäilty asioita.

Ymmärtääkseni esimerkiksi tuo kahdeksalle ytimelle samanarvoinen 32M L3 välimuisti on todella paljon monimutkaisempi ja "maksaa" niin tehonkulutuksessa kuin monimutkaisten crossbar rakenteiden määrässä suhteettoman paljon enemmän kuin vanha 16M/4 ydintä.

 

[hkultala]

Eikös WSAn mukaan nimenomaan 7nm ja siitä eteenpäin ei aiheuta kustannuksia AMDlle.

WSAn mukaan AMDn pitää edelleen ostaa GF:ltä JOTAIN tai ainakin maksaa siitä.

Mikäli AMD ei keksisi "järkevää tuotettavaa GFlle" niin sitten AMD maksaisi GFlle tyhjästä.

Eli, AMDn kannattaa keksiä vähintään sen verran tuotettavaa GFn vanhoille prosesseille kuin mitä WSA pakottaa AMDn maksamaan "14nm/12nm" piistä.

Eli "rajakustannus" 12/14nm piistä on efektiivisesti ilmainen siihen pisteeseen asti, että tämä "kiintiö" saadaan täyteen, ja vasta tämän jälkeen se efektiivisesti maksaa jotain.

Tällä hetkellä AMD tekee GFn prosesseilla "uusia" tuotteita tietääkseni:
1) Matissen/Verneerin ryzenin IO-piirejä
2) EPYCien ja Threadripperien IO-piirejä
3) Emolevyjen eteläsiltapiirejä (osittain sama asia kuin 1)
4) Banded kestler/Dali -pikku-ryzenpiirejä

Sekä lisäksi on vanhempia tuotteita, joiden "tilalle" on jo tullut uudempia tuotteita, mutta jotka voi silti olla vielä tuotannossa ainakin:

5) Picasso (3000-sarjan APUt)

 

[vemkki]

Eikös tuosta aikaisemmin jo puhuttu että kun alkuperäinen ZEN suunniteltiin niin suunnittelupöydälle jäi paljon asioita joita ei pystytty ajan tai rahan takia implementoimaan. Nyt sitten on pöytää tyhjennetty ja lisäilty asioita.

Juu, mutta olin ymmärtävinäni että Zen 2 oli se, jossa nämä puutteet korjattiin. Ilmeisesti ei kuitenkaan kaikkea ehditty tehdä.

 

[pomk]

Juu, mutta olin ymmärtävinäni että Zen 2 oli se, jossa nämä puutteet korjattiin. Ilmeisesti ei kuitenkaan kaikkea ehditty tehdä.

Juu tuo pitää kaiketi paikkansa, että zen2 oli se johon käytännössä kaikki parannukset ehdittiin tekemään jotka jäi pöydälle kun zen1 prossuja suunniteltiin tuotantoon. Zen3 taas on ainakin amd:n mukaan täysin uusi arkkitehtuuri, vaikka perustuukin zen arkkitehtuuriin.

 

[Mechanical Man]

WSAn mukaan AMDn pitää edelleen ostaa GF:ltä JOTAIN tai ainakin maksaa siitä.

Mikäli AMD ei keksisi "järkevää tuotettavaa GFlle" niin sitten AMD maksaisi GFlle tyhjästä.

Eli, AMDn kannattaa keksiä vähintään sen verran tuotettavaa GFn vanhoille prosesseille kuin mitä WSA pakottaa AMDn maksamaan "14nm/12nm" piistä.

Eli "rajakustannus" 12/14nm piistä on efektiivisesti ilmainen siihen pisteeseen asti, että tämä "kiintiö" saadaan täyteen, ja vasta tämän jälkeen se efektiivisesti maksaa jotain.

Tällä hetkellä AMD tekee GFn prosesseilla "uusia" tuotteita tietääkseni:
1) Matissen/Verneerin ryzenin IO-piirejä
2) EPYCien ja Threadripperien IO-piirejä
3) Emolevyjen eteläsiltapiirejä (osittain sama asia kuin 1)
4) Banded kestler/Dali -pikku-ryzenpiirejä

Sekä lisäksi on vanhempia tuotteita, joiden "tilalle" on jo tullut uudempia tuotteita, mutta jotka voi silti olla vielä tuotannossa ainakin:

5) Picasso (3000-sarjan APUt)

Niin aivan, missasin tuon puolen asiasta.

Sitä kuvittelisi toki, että tuotettavaa olisi tarpeeksi kasvaneilla myynneillä jo io piireillä vs. mitä aiemmin oli. Mutta näitähän ei kukaan muu tietäne kuin AMD ja GF.