Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- temata:04-hierarchie_pameti:main [2011/02/28 14:25]
george [Flash]
+++ temata:04-hierarchie_pameti:main [2012/01/26 14:25] (aktuální)
conyx [Základní pojmy]
@@ Řádek 1: / Řádek 1: @@
+~~ODT~~
 ====== 04 - Hierarchie pamětí v počítači ======
@@ Řádek 29: / Řádek 31: @@
   * **stálost obsahu**
-    - __volatnilní__ - potřebuje k uchování informací napájecí napětí
+    - __volatilní__ - potřebuje k uchování informací napájecí napětí
     - __nevolatilní__ - nepotřebuje k uchování informací napájecí napětí
     * //destruktivní// - po cyklu čtení se data vymažou - je třeba udělat cyklus zpětného zápisu
@@ Řádek 68: / Řádek 70: @@
   * **fyzikální vlastnosti pamětí**
     - __polovodičové__ - tato kapitola
-      - bipolární
+      - [[temata:01-polovodice:main#bipolarni_tranzistor|bipolární]]
-      - unipolární MOS resp. CMOS
+      - [[temata:01-polovodice:main#unipolarni_tranzistor|unipolární MOS resp. CMOS]]
     - __magnetické__ - viz PZ
     - __optické__
@@ Řádek 228: / Řádek 230: @@
       * lze realizovat extrémně velké kapacity na malé ploše
   * používá se __unipolární tranzistor s plovoucím hradlem__
+<note tip>NAND a NOR Flash nesouvisí s [[temata:01-polovodice:main#NAND|NAND]] a [[temata:01-polovodice:main#NOR|NOR]] u polovodičů. Název je odvozen pouze od podobné struktury</note>
 ===== Hierarchie =====
@@ Řádek 233: / Řádek 237: @@
 {{:temata:04-hierarchie_pameti:vykonova_mezera.jpeg|Výkonová mezera mezi DRAM a CPU}}
-<note tip>NAND a NOR Flash nesouvisí s [[temata:01-polovodice:main#NAND|NAND]] a [[temata:01-polovodice:main#NOR|NOR]] u polovodičů. Název je odvozen pouze od podobné struktury</note>
+  * problém neúměrného růstu rychlosti procesoru oproti růstu rychlosti DRAM
+    - rychlost procesorů se zvyšuje cca 2x za 1,5 roku => **Moorův zákon** („složitost součástek se každý rok zdvojnásobí při zachování stejné ceny.“ )
+    - doba přístupu u DRAM se zkrátí na polovinu zhruba za 10 let
+  * DRAM tedy nelze připojit přímo k procesoru => procesor by musel stále čekat na data => __mezi procesor a hlavní paměť se staví paměť cache - RVP = rychlá vyrovnávací paměť__
+==== Cache ====
+  * rychlá vyrovnávací paměť umístěná mezi procesorem a hlavní pamětí => vyrovnává velký rozdíl rychlostí těchto dvou komponent
+  * může být více RVP => L1, L2, ...
+  * rychlost SRAM roste rychleji jak u DRAM => proto se u pamětí cache používají SRAM => kapacita ovšem u nich roste znatelně pomaleji, jak u DRAM, proto mají cache mnohem menší kapacitu jak hlavní paměti => **problém rychlost/kapacita == cena**
+  * procesor tedy pracuje pouze s RVP, až když nenajde, hledá se dál v hierarchii
+{{:temata:04-hierarchie_pameti:hierarchie.jpeg|Hierarchie}}
+  * __problém koherence__ => pokud se něco změní blízko procesoru, je třeba to pak pozměňovat i dál v hierarchii
+    - //přímý zápis// => po změně okamžitě zapisuji do bloku v paměti (trvá dlouho)
+    - //zápis s mezipamětí// => kapacita až deset opravných zápisů (také se moc nepoužívá)
+    - //zpětný zápis vždy// => když přemazávám, vždy nahraji zpět původní => nepraktické (bloky pro čtení)
+    - //zpětný zápis podle příznaku změny// => když přemazávám, kouknu na příznak změny (__dirty bit/flag__) a podle toho rozhodnu (používá se)
+  * __problém velikosti bloku__
+    - //příliš malý// => je jich tam hodně
+    - //příliš velký// => často se musí vyměňovat (narůstá pravděpodobnost výpadku)
+  * je rozdělena do bloků stanovené velikosti => ideálně velikost, kterou můžeme z DRAM načíst jedním načtením (v jedné dávce => zvýší rychlost)
+  * základní parametr je **pravděpodobnost úspěchu** (hit rate) => v praxi 95-99% => 95-99% instrukcí se najde v paměti cache, ve zbytku (neúspěch - miss rate / miss penalty) je třeba hledat dál v hierarchii
+  * existují programy, pro které bude hit rate vysoký a programy, pro který bude hit rate nízký => __záleží tedy na programátorovi, jak efektivně program napíše__
+  * aby nedocházelo ke strukturním konfliktům, máme:
+    - datovou cache
+    - instrukční cache
+=== RVP s přímým mapováním ===
+{{:temata:04-hierarchie_pameti:rvp-prime_mapovani.jpeg?600|RVP - přímé mapování}}
+  * v tomto případě nemůžou být v paměti cache položky, které jsou od sebe v hlavní paměti vzdáleny o 8 bitů
+    * vyřeší se stupněm asociativity cache (asociativita 2 => můžu mít dvě položky, které končí stejně => dvoucestná cache)
+    * aby byla plně asociativní, potřeboval bych osmicestnou cache
+  * **informace uložené v RVP:**
+    - __data__
+    - __adresový příznak - tag__ - aby se rozpoznalo, jaká data jsou v RVP (pokud procesor žádá data na adrese 10110, tak tag je 10)
+    - __příznak platnosti__ - zda jsou data platná
+<note tip>
+**příklad**
+  - máme cache o velikosti 1024 položek
+  - máme paměť 32 bit kde každá položka má 4 Byty (berme, že se budou chtít adresovat jednotlivé Byty)
+  - máme 32-bit adresování
+**Jakou kapacitu je třeba vyhradit pro paměť cache?**
+</note>
+{{ :temata:04-hierarchie_pameti:rvp-prime_mapovani_32.jpeg?600 |RVP - přímé mapování - 32 bit}}
+<note>
+  * na adresování v položce budeme potřebovat 2 bity, protože položka má 4 Byty (pro každý Byte)
+  * na adresování v RVP budeme potřebovat 10 bitů (adresujeme 1024 položek)
+  * zbylých 20 bitů bude vymezeno pro tag
+  * **paměť tedy bude muset mít 20 bitů pro tag mít 20 bitů pro tag**
+  * **=> 1024 položek * (20 + 32 + 1 bit platnosti)**
+  * __práce procesoru, když hledá data:__
+    - vezme 10 bitů a naadresuje se příslušná položka
+    - porovná 20 bit tag s horními 20 bity adresy
+    - pokud OK, zkontroluje se bit platnosti, zda je nastaven na log 1
+      - pokud je nastaven do log 1 => generuje se hit
+      - pokud je nastaven na log 0 => musí se nahrát do paměti nový blok a starý blok se musí nahrát zpět, pokud byl měněn
+  * celkový počet bloků o velikosti 32 bit je __2<sup>30</sup>__ => do RVP se vejde takových bloků __2<sup>10</sup>__ => **dolní odhad pravděpodobnosti úspěchu je p<sub>hit</sub> = 2<sup>10</sup>/2<sup>30</sup> = 2<sup>-20</sup>** => díky lokalitě odkazů se v praxi dosahuje hodnot p<sub>hit</sub> **0,9 až 0,98**
+</note>
+=== Vícecestné RVP ===
+{{ :temata:04-hierarchie_pameti:rvp-4-cestna.jpeg?600 |RVP - přímé mapování - 32 bit}}
+  * pokud máme plno ve všech čtyřech položkách a potřebujeme nahrát novou položku => **musíme vybrat oběť**
+    - __LRU__ - Last recently used
+    - __MFU__ - Most frequently used
+    - __FIFO__ - First IN First OUT
+    - __RAND__ - Random
+  * => je třeba přidat další HW => dá se optimalizovat, pokud budeme používat jeden specifický program
+===== Virtuální paměť =====
+  * podobná problematika ja u pamětí cache
+  * dalo by se říci je to něco jako cache pro disk
+  * **proč chceme virtuální paměť?** __(otázka na státnice)__
+    - chceme udělat efektivní sdílení paměti M pro mnoho programů
+    - odstranit omezení fyzikální velikosti paměti M
+  * vychází z poznatku, že pouze malá část programů je současně aktivních
+  * pracuje se s pojmy
+    - __fyzický adresový prostor__ - v HW
+    - __logický (virtuální) adresový prostor__ - v OS
+<note tip>**Toto už předpokládám, že je v [[temata:34-souborovy_system:main|IOSu]].**</note>
+===== Zdroj =====
+<note>
+Při tvorbě tohoto tématu jsem čerpal především ze slajdů INP - [[https://wis.fit.vutbr.cz/FIT/st/course-files-st.php/course/INP-IT/lectures/inp2010_13pameti.pdf|inp2010_13pameti.pdf]] a [[https://wis.fit.vutbr.cz/FIT/st/course-files-st.php/course/INP-IT/lectures/inp2010_14pam_hier.pdf|inp2010_14pam_hier.pdf]]. K pochopení slajdů mi pomohly příslušné záznamy - [[https://video1.fit.vutbr.cz/av/records.php?id=11960&categ_id=571|INP_2009-11-10.avi]] a [[https://video1.fit.vutbr.cz/av/records.php?id=12342&categ_id=571|INP_2009-11-24.avi]]
+</note>
 ===== Potvrzení =====

temata/04-hierarchie_pameti/main.1298899543.txt.gz · Poslední úprava: 2011/02/28 14:25 autor: george

Zobrazit stránku Starší verze

Zpětné odkazy Nahoru