Toi eka nyt on periaatteessa jossain määrin ihan käyttäjänkin autettavissa pakottamalla peli puoliksi molempiin CCD:hin. Sä siis puhut havainnoista sellaisella prosessorilla, jossa on kaksi CCD:tä, mutta vain yksi cache toisella. Kuitenkin siinä skenaarioprosessorissa olisi kaksi cachea. (Tai ehkä pikemminkin todellisuudessa yhteinen iso L4, jos sellainen tulisi jossa molemmat CCD:t sisältäisivät ylimääräisen cachen)
Ramin ja (L3) cachen suhde on sellainen, että cache ja/tai ram sisältää saman asian. Mä olettaisin että erilliset CCD:t tietysti pystyvät kommunikoimaan suoraan keskenään. Siinähän ne nököttää vierekkäin prosssorisirulla.
Ne nimenomaan nököttävät eri siruilla, vain samassa paketissa.
Muistaakseni niiden CCD-piilastujen välillä ei mene mitään suoraa väylää, vaan kaikki liikenne kiertää IO-piirin kautta (voin olla väärässä tässä).
Mutta jos kumpikin käyttää, ja erityisesti voivat muokata sitä osaa RAM muistia, joka on molempien cachessa, niin ne molemmat cachet joudutaan pitämään erikseen ajan tasalla. Tämä on ajallisesti kallista.
Niin. Välimuisti nykyaikaisilla x86-prossuilla toimii 64 tavun lohkoissa, eli jos molemmat ronkkivat samaa osoitetta tai 64 tavun sisällä siitä mitä toinen on lähiaikoina ronkkinut, tämä ongelma ilmenee, tai jos ollaan vähän kauempana ja access patternit aktivoi prefetcherin, silloinkin voi ongelma ilmetä.
Mutta, jos useampi säie ronkkii tismalleen samaa dataa, siellä pitää joka tapauksessa softassa olla synkronointi jolla varmistetaan että ne ronkkivat sitä oikeassa järjestyksessä.
Mutta sitä synkronointia toki hidastaa, mikäli sen pitää kiertää DRAMin kautta.
Kuitenkaan ei ole mitään mieltä tehdä 2x CCD prossua kahdella cachella koska ne pelit hädin tuskin hyötyvät 8 ytimestä,
Odotetaan sitä civ7aa
ja lähes kaikki muut softat hyötyvät melko vähän siitä cachesta, siis sellaiset softat jotka voisivat käyttää kaikkia ytimiä.
Kyllä monet muutkin softat siitä välimuisteista hyötyy, EPYCeistä on sellaisiakin malleja joissa on aktivoitu vaan 2 ydintä/CCD ja sitten CCD-piirejä on monta, että voidaan maksimoida se, paljonko L3-välimuistia kukin ydin saa käyttöönsä, ja EPYCit ei ole peliprossuja.
Ja sitten kun pelejä aletaan rinnakkaistaa kunnnolla suuremmalle kun 8 säikeelle (civ7?) niin alkaa sitä suurempaa välimuistia kaivata siellä toisellakin CCDllä.
Ja käyttiksen säieskedulerille olisi paljon helpompaa jos kaikki ytimet olisi samalla kellotaajuuspotentiaalilla ja samalla L3-kakulla, kuin arpoa, että onkohan tälle softalle parempaa vähän suuremmat kellot vai suurempi L3-kakku.
Pelit hyötyvät niin paljon enemmän siitä cachesta. Kaksi cachea olisi vain hieman enemmän L3 muistia yhteensä, osin kuvaamasi haitan kanssa. Eli niin kauan kuin tuo korostettu osa on totta, on täysin turha haaveilla kahden CCD:n prossusta jossa molemmilla olisi ylimääräinen cache.
Markkinoilla on jo piirejä, joissa on 12 CCDtä, joista jokaisella on tuo 3d-cache.
Lisäksi löytyy malli, jossa on 8 CCDtä, joista jokaisella on tuo 3d-cache,
mutta vain 2 ydintä/CCD aktiivisena
Oletettavasti seuraava isompi hyppy on joku 3-5x kertainen ylimääräinen cache nykyisen 64 megan sijaan, ja ellei tämä tapahdu vasta 10 vuoden päästä, se varmasti isketään 6-10 ytimen päälle koska enempää ei ne pelit vielä pitkään hyödynnä tehokkaasti. Voisi olettaa että kun tuohon määrään päädyttiin monta vuotta sitten, että se oli kompromissi hinnan ja koon suhteen. Mutta sirut koko ajan pienenee, ja vastaavasti Intelin prossujen pelisuorituskyky heikkenee ja täten ero AMD:n x3d cache malleihin kasvaa. Siitä saadaan se hinta, parempi tuote on aina kalliimpi, joka sitten näppärästi kustantaa sen suuremman cachen ilman että tärkein eli omistajien tuotto heikkenee.
Itse taas lähinnä odottaisin sitä, että sinne IO-piirille tulisi L4-cache memory side cachenä (samaan tyyliin kuin AMDllä on RDNA3ssa se muistiohjaipiirillä oleva L3-cache, ja IBMllä on myös power-sarjan prossuissaan muistiohjainpiireillä viimeisen tason välimuisti). Tämä samalla
1) kakuttaisi myös kaiken IOn ja apuprosssorien (igpu, npu) muistiliikenteen, sekä
2) tuo ytimien välinen synkronointi toimisi luonnollisesti tämän kautta varsinaista DRAMia pienemmällä viiveellä.
Applellahan tällainen on ollut jo muutaman vuoden ja Intel toi tällaisen juuri julkaistuissa arrow lake-prossuissaan.
Ja AMDllä, kun se IO-piiri tehdään joka tapauksessa vanhemmalla valmistusprosessilla, tämä tulisi edullisemmaksi kuin CCD-piirillä olevan kakun suurentaminen, tosin toki erillisellä cache-piirillä voi päästä vielä halvemmaksi itse piilastun hinnassa, mutta kalliimmalla paketoinnilla.
Mutta tämä L4-kakku olisi toki viiveiltään paljon suurempi kuin CCDn oma L3-kakku. Tämän merkittävät hyödyt tulee enemmän energiatehokkuuden paranemisesta kun DRAM-accessit vähenee, eikä niinkään keskimääräisen viiveen pienenemisestä ja suorasta suorituskyvystä.