Új hozzászólás Aktív témák

• #188 Graphics Jómunkásember poci76 #187

  Új Válasz 2020-01-28 19:45:11 #188

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Graphics

  Jómunkásember

  LOGOUT blog

  válasz poci76 #187 üzenetére

  Óóó, a Tannenbaum könyv fősulin az volt a "biblia"..

• #183 Robitrix senior tag poci76 #173

  Új Válasz 2020-01-28 12:29:48 #183

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Robitrix

  senior tag

  válasz poci76 #173 üzenetére

  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)

• #182 Robitrix senior tag poci76 #173

  Új Válasz 2020-01-28 12:11:47 #182

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Robitrix

  senior tag

  válasz poci76 #173 üzenetére

  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....

Új hozzászólás Aktív témák