Új hozzászólás Aktív témák
-
Robitrix
senior tag
annyi igaz, hogy a program nem közvetlenül a a gyorsító tárat címzi, hanem a RAM-ot. de közben a hardver probálja mindig a gyorsítótátrban kéznél tartani a futó program aktuális környezetét, hogy gyorsabban elérje, Ha nincsen meg az adat, mert mundjuk egy vezérlés átadással túl messze kerülünk a korábbi cimtől, akkor marad a gyorsítótó tár újra töltése az új cim környzetével. A környezet ez esetben annyi adatot jelent, amit a cache tárolni képes. nyilván egy 256 kbájtos gyorsitó esetében nem tudom betölteni aktuális cim a mb-nyi környezetét. Persze a programok legtöbb esetben szekvenciálisan hajtják végre az utasitásokat. egymás mögött utasitásról utasitásra lépegetve sorban. Aztán persze van vezérlés átadás, mikor jó messze kell elugrani a programban mondjuk 1 MB távolságra a korábbi cimtől. Az persze nem lesz bent fizikailag a gyorsítóban így jön a újratöltés a RAM-ból. minnél nagyobb a tár annál esélyesebb, hogy az adat megtalélhatü a gyorsító tárban. kevesebb újra töltés. ezért gyorsul a proci nagyobb cache esetében. (legalább is egy határig.)
Na most ha elég nagy a cache mérte akko lehet, hogy a program párhuzamosan futó kéz szálának adati is megtalálhatóak egyszerre a gyorsítóban.
Viszont mivel a leforditott program relativ eltolási cimmel rendelkezik
Ha két program két kölön szála fut egy procin akkor az adatok keverednek egymással a gyorsítóban és nem tudni, hogy ha mind a két program éppen realtiv eltolás miatt nem tudni, hogy ha mind a két szál a saját magának a 17 ezredik bájtjának adatát akarná beolvasni, akkor kinek a az adata lesz bent??????? Az egyik program éppen Kovács Béla anyjának lánykori nevét akarná elolvasni, de a másik meg a PI 28 jegyre megadott lebegő pontos értékét akarná megkapni. Aztán majd mikor a kedves mama lánykori nevével akrná kiszámolni a kör területét gond lenne.
Na ezen okból egy adott pillanatban nem futhat két program egy mag két szálán. Ah van egy programom 5 szállal és van egy programom 3 szálon akkor az HT vagy SMT esetében nem 5+3 szál lesz, ami elférne 4 magon hanem 3 mag(amiből egy szál éppen üres) +2 mag (ahol szintén üres egy szál) lesz vagyis 5 mag(és 10 szál kell hozzá
persze mikor magon fut a két program és van 5+3 mag szabadon akkor nem zavarják egymást Minden magnak saját önálló gyorsítót terülte van ahol nem keverednak más programok adataival aktuálisa és mindenki a sajátjait látja.
Persze mi emberi szemmel azt látjuk, hogy folyamatosan terhelödnek nagyjából a magok összevissza. Ennek az oka, hogy időosztásban dolgoznak a rendszerek. Vagyis kis időszeleteket adnak oda a programok folyamatinak futni. Mondjuk felosztja az 1 mp futási időt 50 darab 20 msec időtartományokra. aztán a rendszer ezeket is a kis időtartományban engedi futni az adott folyamatot vagy program szálat egy proci magon. Aztán lehet a következő 20 msecre másik folyaamt kapja meg akár egy teljesen más program. Persze minnél nagyobb a prioritása egy programnak annál többször kap lehetőségek futni. de hogy egyik pillanatban az 1. magon fut majd más kap lehetőséget, aztán a 3. pillanatban kap lehetőséget futni a 6-os magon kétszer majd 1 időszeletre a 3. mag következik.... -
Robitrix
senior tag
természetesen a program nem látja a gyorsitótárat, de a hardver igyekszik oda tenni alá az aktuális futás helyének memoria környezetét. tehát ha a leforditott program aktuális utasitása a program elejétől számított 150 ezredik bájtnál van és a a programom mondjuk a memória 10 milliomodik bájtjától fut. Akkor a cachebe igyekszik betölteni a RAM 10 millió + 150 ezer cim környéki RAM tartalmat. Aztán olyan álnok leszek, hogy átugrom a programomban mondjuk egy a program elejétől számitott realtiv távolság 800 ezeredik bájtjára, hogy onnan fusson tovább mondjuk egy függvény. Persze mivel a gyorsítótár csaj 256 kbájtnyi így nem is található. meg a korábbi 150 ezer bájtnyi memoria környezet. na ilyenkor szopacs van és újra kell tölteni a gyorsítótárat a 800 ezerdig bájt környezetével. aztán végrehajtok ott 100 utasitást egymás után és véget ér a függvényem. és visszatér az eredeti meghivás helyére. na ismét szopacs mert megint a 150 ezer bájt környezetével kell feltötleni a gyorsitot, VAgyis a futó program valóban nem a cache-t cimzi közvetlenül de a hardver megprobálja mindig aktuális adatoka alárakni, hogy gyorsabban elérje. Szóval valóban nem a gyorsitótárat cimzi ennek ellenér mégis onnan kapja az aktuális adatokat(jól rosszul kiszolgálva)
fősulin az volt a "biblia"..Új hozzászólás Aktív témák
ph Egyelőre ez tűnik a legbiztosabb fegyvernek az AMD ellen 2020 második felére.
- Konzolokról KULTURÁLT módon
- BestBuy ruhás topik
- Milyen billentyűzetet vegyek?
- 3D nyomtatás
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Microsoft Excel topic
- Fujifilm X
- Renault, Dacia topik
- További aktív témák...
- Garanciális Intel Core i5-13600K
- BESZÁMÍTÁS! ÚJ Intel Core i5 11400F / i9 11900KF / i9 11900K tálcás processzorok 27% áfás számlával
- A legolcsóbb! Új bontatlan, dobozos, számlás, garanciális i9 13900K CPU akció!
- AMD Ryzen 5 1600X
- Beszámítás! Intel Core i3 10105 4 mag 8 szál processzor garanciával hibátlan működéssel