Minulla ei ole kumpaakaan, AMD:tä tai Cyberpunkkia, mutta näin sivusta huutelen ihan mielenkiinnosta.
Kannattaa mitata ennen ja jälkeen tulokset ja seurata cpu context switchien määrää (kuinka paljon suorittavat softasäikeet loikkivat rautasäikeeltä toiselle). Context switchin kustannus on pienen latenssin softissa ihan älytön, koska käytännössä CPU välimuistit pitää aina synkata context switchissä uudestaan (ccNUMA, ja eikös Ryzen/ZEN ollut joku corepaketointiviritelmä).
Ei tarvi synkata mitään L2-välimuisteja uusiksi context switchissä
CPU-käskykantojen speksi suunnitellaan aina siten että välimuistin olemassaolo on käytännössä läpinäkyvää, välimuistillisen prosessorin pitää tuottaa aivan samat tulokset kuin välimuistiton prosessori laskisi.
Se välimuistien tila pidetään
jatkuvasti sellaisena, että siellä ei voi olla eri ytimien/säikeiden mielestä eri järjestyksessä tapahtuvia kirjoituksia samaan osoitteeseen. Tätä tarkoittaa välimuistin koherenssius. Tämä tehdään jotta ylläoleva periaate siitä että välimuisti ei vaikuta laskennan tulokseen toteutuisi.
Ja tällä ei ole
mitään tekemistä context switchin/virtuaalimuistin kanssa, tämä mekanismi toimii täysin fyysisillä muistiosoitteilla.
Välimuistit on kaikissa yleisissä CPUissa tagattu fyysisillä osoitebiteillä (vaikka yksi henkilö täällä yrittää Zenin L1D:n osalta väittää muuta kun lukee rivien välistä asioita, joita siellä ei sanota). (virtuaalinen tägays löytyy nykyaikana suurinpiirtein ainoastaan IBMn mainframeprossuista, mutta niitä ei voi sanoa yleiseksi prossuksi)
Ainoa asia miten context switch suoraan vaikuttaa välimuistien flushaamiseen on, että data jonka yksi prosessi on ladannut tai tallettanut AMDn Zenin L1D-kakkuun on käyttökelvotonta toiselle prosessille (koska way-predictionin microtagit riippuu virtuaaliosoitteesta, ja ne vaihtuu context switchissä, ja ilman vlaidia mikrotagia välimuistista tulee huti vaikka data siellä fyysisesti olisi), vaikka sillä olisi oikeudet sen käyttämiseen. Tämä voi johtaa siihen, että
pieni määrä likaista dataa tarvii sieltä flushata sen L2-kakkuun, mutta tämä ei vaikuta
millään tavalla siihen, miten se lähtee sieltä kohti muita ytimiä.
Tämä saattaa aiheuttaa myös vakauteen/eheyteen ongelmia, jos asiaan ei ole kiinnitetty huomiota tuotekehitysvaiheessa.
Systeemit suunnitellaan siten, että ne toimii oikein ihan riippumatta siitä, kuinka monta conxtext switchiä siellä tapahtuu, tai paljonko dataa joudutaan siirtämään välimuistien välillä.
Softa on yksinkertaisesti rikki jso se voi hajota context switcehin tai liialliseen välimuistin koherenssiliikenteeseen (joilla ei siis ole mitään tekemistä keskenään).
Jos se hajoaa jollain isolla määrällä, ei ole
mitään takeita ettei se voisi hajota myös pienemmällä määrällä. Suurempi määrää ainoastaan
nostaa todennäköisyyttä että tähdet asettuu asentoon, jossa bugi ilmenee.
Voi olla, että kehittäjät ovat tehneet rajoitusratkaisun ihan tarkoitusella.
Ei. Tai siis ei mistään tällaisesta syystä.
Syy on se, että
1) haluttiin että säikeitä on optimaalinen määrä sekä phenomilla, bulldozerilla että intelin SMTtä tukevilla prossuilla, eikä yhtään varauduttu siihen, että AMDltä voi joskus tulla prossu joka toimii tämän osalta samalla tavalla kuin intelin prossut
2) kirjoitettiin tämä valintakoodi typerästi (lähinnä koska kukaan ei uskaltanut kirjoittaa sitä kokonaan uusiksi, lisättiin vaan uusia erikoistapauksia eri prossuille). Sen olisi saanut helposti kirjoiteitettua siten, että se olisi ollut optimaalinen kaikilla (valita katsoa vaan suoraan loogisten ytimien määrää, ignoraten fyysisten määrä), ja tämä optimaalinen koodi olisi ollut jopa lyhempi kuin nykyinen epäoptimaalinen koodi.
