OBSAH WEBU
ČTĚTE!
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 13:16] george |
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 ====== | ====== 04 - Hierarchie pamětí v počítači ====== | ||
Řádek 29: | Řádek 31: | ||
* **stálost obsahu** | * **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í | - __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 | * //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í** | * **fyzikální vlastnosti pamětí** | ||
- __polovodičové__ - tato kapitola | - __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 | - __magnetické__ - viz PZ | ||
- __optické__ | - __optické__ | ||
Řádek 213: | Řádek 215: | ||
- DDR2, DDR3 - zvyšuje se frekvence (2x) | - DDR2, DDR3 - zvyšuje se frekvence (2x) | ||
+ | ==== Flash ==== | ||
+ | * nevolatilní paměť | ||
+ | * od roku 1980 | ||
+ | * vylepšení paměti EEPROM => pouze jeden tranzistor na uchování jednoho bitu místo dvou (někdy i méně) | ||
+ | * vysoká kapacita | ||
+ | * když do paměti chceme něco zapsat, tak ji musíme nejdřív smazat (nahrají se všude jedničky) a tam, kde chceme zapisovat se pak nahrají nuly (lze mazat pouze po blocích) | ||
+ | * **dva typy:** | ||
+ | - __NOR__ | ||
+ | * podobné jako RAM (adresové a datové vodiče) | ||
+ | * používá se jako náhrada PROM, EEPROM | ||
+ | - __NAND__ | ||
+ | * nemá specializované adresové vodiče | ||
+ | * ovládá se pomocí příkazů | ||
+ | * 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 ===== | ||
+ | |||
+ | {{:temata:04-hierarchie_pameti:vykonova_mezera.jpeg|Výkonová mezera mezi DRAM a CPU}} | ||
+ | |||
+ | * 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í ===== | ===== Potvrzení ===== | ||