Jos LLC sovellusta ajattelee niin missähän mahtaisi mennä raja sille että tuo kirjanpidon koko tulee ylivoimaiseksi ongelmaksi?
Itse asiassa, nyt kun laskin itse enkä luottanut muualta lukemaani, niin ei tuo olekaan ihan niin paha kuin luulin:
Oletukset:
* 64 tavun välimuistilinjat
* 4 teran tuettu fyysinen muisti
* 8 gigan HBM-LLC
* 64-way set associative
4 teraa ja 64 tavua tarkoittaa että mahdollisia välimuistilinjojen osoitteita on 64 miljardia kappaletta.
8 gigaa välimuistia ja 64 tavua tarkoittaa, että välimuistilinjoja on 128 miljoonaa kappaletta.
64-way set associative tarkoittaa tällöin, että kussakin way:ssä on 2 miljoonaa välimuistilinjaa.
Mahdollisia osoitteita joita yksi välimuistilinja voi säilöä on 64 miljardia/2 miljoonaa eli 32768.
Eli TAGiin tarvisi 15 bittiä.
Tähän 3-4 tilabittiä, ja muutama bitti lisää avuksi kirjanpitoon replacement policylle.
Puhutaan luokkaa ~23 bittiä/välimuistilinja.
23b/64B =~0.045.
Eli siis, esimerkiksi 8 gigan HBM-LLC tarvisi n. 368 megaa TAGeja. Samalla asssiatiivisuudella pienempi 4 gigan HBM-LLC tarvisi yhden bitin enemmän TAGia, eli n. 24 bittiä/lohko, eli n. 192 megaa.
Tuo 4 gigaa olisi siis vielä sittenkin ihan mahdollinen määrä, joskin hyvin kallis. Tuli aiemmin vastaan jonkun AMDn tyypin esitys, jossa nuo oli laskettu "sinnepäin" pyöristäen parissa kohtaa pahasti ylöspäin, oletettu mm. fully associative cache, ja luin vaan päätelmät siitä silloin enkä tarkastanut itse lukuja.
Lisäksi tekemällä välimuistista "memory side cache" putoisi sen kirjanpidosta kolmisen bittiä/lohko eli n. 13% pois(*), ja lisäksi silloin välimuistilinjan koon voisi moninkertaistaa ilman että tarvii muuttaa sisempien tason välimuistien kokoja tai että tästä tulee ongelmia koherenttiusprotokollaan. Välimuistilinjan koon tuplaaminen pudottaisi heti kirjanpidon koon puoleen.
Ilmeisesti AMDllä tutkivat jotain sellaista, että
1) Se HBM-LLC olisi vain direct mapped, jolloin millä tahansa osoitteella on vain yksi mahdollinen paikka siellä.
2 ) varsinaiset TAGit olisivat siellä HBMllä, mutta sitten niillä olisi jotkut pienemmät tietorakenteet siellä itse piirillä ja niiden pohjalta tehty jonkinlainen ennustus siitä, löytyykö tämä data todennäköisesti välimuistista; Jos ennustus sanoo että todennäköisesti ei löydy, aloitetaan accessi itse päämuistiin, jos ennustus sanoo, että todennäköisesti löytyy, sitten accessoidaan rinnakkain sitä paikkaa siitä cachestä missä se on JOS se on siellä sekä TAGia joka kertoo, löytyikö se sieltä vai ei. (tämä siis vaatii sen direct mappedin, että on vain yksi mahdollinen paikka jossa se voi olla)
Mutta tämä on sitten vasta tutkimusjuttua, ei mitään varmuutta että tulossa mihinkään tuotteisiin.
Arvaisin että huonoimmillaankin se hbm välimuisti olisi nopeampi kuin dram voi ikinä olla mutta tuntuvasti hitaampi kuin sram cachet prossun lastulla. Onko sitten ero sellainen että hbm on oikeasti perusteltua.
HBM on DRAMia. Sillä on DRAMin hakuaika, sillä vaan on paljon leveämpi väylä. Se, että muisti on fyysisesti lähempänä voi kuitenkin hiukan lyhentää sitä hakuaikaa.
(*) Riippuen siitä, monenko soketin/NUMA-moden konfiguraatiot on tuettu; 1-2 bittiä lähtee koherenssiusprotokollan poistumisella, lisää bittejä lähtee sillä, että välimuistin tukema muistiavaruus on pienempi kun memory-side-cachessä se kakuttaa vain oman piirinsä muistiohjaimeen kytkettyä muistia. Toisaalta välimuistin oleminen memory side cache tarkoittaisi selvästi lisää liikennettä näiden sokettien välillä, ja datan hakemista kauempana olevasta välimuistista monen soketin systeemeissä.