Tohle je definice Cache:
https://en.wikipedia.org/wiki/Cache_(computing)

Cache nefunguje JEN jako odkladiste. To si spatne pamatujete/vykladate. Cache slouzi jako pamet, skrze kterou tecou data. At uz primo skrze, coz znamena, ze se natahnou z pomalejsi pameti a pak zrychluji system tim, ze se nemusi do ni sahat, to je ten pre-fetch.

A nebo slouzi k odkladani dat, ktera se porad pouzivaji.

Predikce, prefetch je jeden ze zakladnich veci, ktere cache potrebuji aby plnili svou roli v CPU svete.

A ted doslova z AMD white-paperu o I$ v GPU svete:
"We propose shared L1 caches in GPUs. To the best of our knowledge, this is the first paper that performs a thorough characterization of shared L1 caches in GPUs and shows that they can significantly improve the collective L1 hit rates and reduce the bandwidth pressure to the lower levels of the memory hierarchy."

Vidite zcela jasne, ze to neni nic jineho, nez to co je v CPU svete zname uz dlouho. Cili jak jsem rikal, I$ neni zadna bozska cache, naprosto normalni sdilena keska. V GPU svete to je mozna novinka, pri spravne implementaci vyrazne zvysuje vykon, ale tohle je clanek o CPU, takze vas argument, ktery jste sem prinesl, je uplne spatny.

Uspesnost cache je primo umerna tomu, co kolik si muzete dovolit nacist, cili jakou ma relativni kapacitu. Neni to jediny parametr, ale je dulezity. A takhle velka (opakuji ohromna na pomery v GPU svete), sdilena "L1" cache v GPU prinasi podle AMD 22-52% vykonu navic, pri az 49% uspore energie (nejspis mineno pametoveho subsystemu).

Jenze tohle je clanek o CPU, specificky o tom, ze v jednom benchmarku je novy, 2kanalovy Ryzen rychlejsi, nez 8kanalovy predchudce. Ja tvrdim, ze to je hlavne proto, ze tenhle benchmark nedokaze zatizit to CPU vhodnymi ulohami, kde by tech 8 kanalu zazarilo. Naopak tim, ze novy Ryzen je rychlejsi o cca 20-30%, dokaze se pred nej dostat.

1) Mate problem neco vubec rici, natozpak neco smysluplneho. Pletete tuny blbosti dohromady, delate silene dlouhe posty, opakujete vecne stale stejne informace, ktere jsou jen "flavor". Napr. casto spamujete dlouhe posty o tom, jak dlouho trva AMDecku od finalniho poslani navrhu k dostupnosti v distribucnich kanale.
!!! Musite zacit u sebe. Nevim proc bych mel tolerovat kraviny.

2) Latence je prodleva mezi pozadavkem a vyrizenim. Je primo umerna velikosti/organizaci kesky. Cim mensi je keska, tim rychleji se ziskaji data z ni.

3) To ze jste tam zatahl a dal velky duraz na spozdeni (latence) ukazuje, ze se nedokazete dobre vyjadrovat a predavat informaci. Chtel jste nejspis rici, ze cim presneji se trefi do potrebnych dat v kesce, tim casteji se pouzije prava ta keska, a je ji spozdeni. A kdyz se netrefi, tak se musi jit do vetsi kesky (a nebo treba az uplne do RAM) a to spozduje system.

Jenze to je naprosto zrejmy koncept, ktery stacil rici jen jednou vetou.

Navic kdyz se nad tim zamyslite, tak si protirecite. Prvne rikate o Infinity Cache, jaky je to mega zrychlovac (pominu, ze se z nejakeho duvodu upinate k anglickemu slovu "infinite" a neresite, ze je to jen marketingove slovo a nemate zada data specificka prave pro I$) a pak ukazujete tabulku, kde ty latence byly zlepseny upravami kesky, nikoli predvidaciho algoritmu. Takze snizujete prave vahu toho co jste psal v prvni casti.

Proste a jednoduse...

Latency = spozdeni, nez se pozadavek na data/instrukce vyridi a dana data/instukce je procesu k dispozici.
Pre-fetch = system prednacitani dat.

Aby pre-fetch fungoval dobre, je potreba mi dobre "predvidaci" algoritmy. Zaroven pokud neni keska dost velka, tak ani sebelepsi predvidac neudela zazraky. Ale obecne plati, ze cim lepsi predvidac, tim lepe je ta keska vyuzivana. Kazdopadne ani "Infinity cache" neznamena, ze se vzdy trefi. To chapate spatne. Dulezitou soucasti I$ ale VELIKA, sdilena L3 keska u CPU a velka sdilena L1 u GPU (protoze tam doposud takovy koncept nebyl, L1 kesky meli ty bloky samostatne, nesdilene).

A na to ze "ak" na to se nehraje. Navic ten maly narast je osemetny termin. Pokud mate malou kesku, a trefujete se jen v 50% predpovedi, tak i male procento je relativne velky bonus. Pokud mate ale obri kesku a mate 95%, tak dalsich par procent uz neprinese tak velky bonus. A samozrejme jako vzdy, zalezi na uloze.

Proto ta I$ v GPU svete je tak velka vec. GPU tohle nemelo, ta keska je na pomery sveta GPU ohromna a navic v GPU svete jsou ty vypocty velmi dobre paralezovatelne, predpovidatelne, cili tam to dokaze mit velky uspech.

Ale tenhle clanek - opakuji uz po Xte - je o CPU svete. A cache v Zen2 nebyla nijak tragicka a v Zen3 sice dostala zlepseni, ale neni to tak radikalni zlepseni a skrze vsechny ulohy. Nekde to byl problem, tak to zlepseni je, az nakych 25% (protoze Lisa ukazovala, ze v idealnich pripadech je Zen3 az o 50% rychlejsi nez Zen2, ale z tech 50% je potreba vzit v uvahu obecne vetsi IPC, frekvenci a dalsi drobne upravy).

Nicmene porad to nevysvetluje, jak by mohl Zen3 takto vydrtit 8-kanalovy Zen2. Jedine mozne vysvetleni je, ze tento benchmark nedokazal vytizit 8-kanalovy Zen co se tyce pametoveho subsystemu, takze se neprojevil tenhle aspekt a Zen3 diky vylepseni dokazal prekonat Zen2.

Rozdil v kodu pro GPU a CPU je v objemu i strukture:
*objem* - pro GPU mate (compute) shader na par KB, pro CPU mate MB/GB kodu
*struktura* - pro GPU je shader 1 funkce, ktera se nejak spusti a sem tam vetvi (byt vetveni neni prilis zadouci), pripadne vola jine funkce, pro CPU je to totalni zmet kodu vcetne JIT kompilaci, knihoven, atd.

Takze zatimco nad 1 kodem pro GPU muzete spustit kompletni analyzu a offline profiling, jak se to asi bude vykonavat - nad nekonecnou kombinaci CPU kodu v ramci OS, to udelate tezko.

Struktura GPU prizpusobena byt muze - ale jen za dodrzeni stejneho pomeru. V soucasnych GPU je pocet vypocetnich jednotek vetsi o 1 rad nez bejvavalo, zatimco sirka pameti i latence pameti zustavaj kde jsou (fyzicke limity), zvysuje se jenom pripadna rychlost pameti - ale ne dostatecne rychle, takze holt ty vypocetni bloky hladovi..