Ve druhé části článku o simulátorech počítačových systémů budu pokračovat v jednoduše srozumitelném vyprávění o počítačových simulátorech, konkrétně o plnohodnotné simulaci, se kterou se běžný uživatel setkává nejčastěji, a také o taktickém modelu a tratích, které jsou populárnější mezi vývojáři.
V Hovořil jsem o tom, co simulátory vlastně jsou, a také o úrovních modelování. Nyní, na základě těchto znalostí, navrhuji ponořit se o něco hlouběji a probrat plnohodnotnou simulaci, jak sestavit tratě, co s nimi pak dělat, a také o taktické mikroarchitektonické emulaci.
Plnohodnotný simulátor (full platform simulator), nebo "Jeden v poli — není voják"
Pokud je třeba prozkoumat funkci jednoho konkrétního zařízení, například síťové karty, nebo napsat pro toto zařízení firmware nebo ovladač, mohou být tato zařízení modelována samostatně. Nicméně používat je mimo ostatní infrastrukturu není příliš pohodlné. Pro spuštění příslušného ovladače je potřeba centrální procesor, paměť, přístup k sběrnici pro přenos dat a další. Kromě toho je pro fungování ovladače nezbytný operační systém (OS) a síťový zásobník. Může být rovněž nutný samostatný generátor paketů a server pro příjem odpovědí.
Plnohodnotný simulátor vytváří prostředí pro spuštění celého softwarového zásobníku, který zahrnuje všechno, počínaje BIOS a bootloaderem až po samotný operační systém a různé jeho podsystemy, jako je zmíněný síťový zásobník, ovladače a aplikace na úrovni uživatele. K tomu je v něm implementováno softwarové modelování většiny zařízení počítače: procesor a paměť, disk, vstupně-výstupní zařízení (klávesnice, myš, displej), jakož i samotná síťová karta.
Níže je uveden blokový diagram čipové sady x58 od společnosti Intel. V plnoplošné simulaci počítače na této čipové sadě je nutné realizovat většinu z uvedených zařízení, včetně těch, které se nacházejí uvnitř IOH (Input/Output Hub) a ICH (Input/Output Controller Hub), ale které nejsou na blokovém diagramu podrobně nakresleny. I když, jak ukazuje praxe, existuje poměrně málo zařízení, která nejsou použita softwarem, který hodláme spustit. Modely takových zařízení není nutné vytvářet.
Nejčastěji se plnoplošné simulátory realizují na úrovni instrukcí procesoru (ISA, viz ). To umožňuje relativně rychle a levně vytvořit samotný simulátor. Úroveň ISA je také dobrá v tom, že zůstává více či méně konstantní, na rozdíl od například úrovně API/ABI, která se mění častěji. Kromě toho realizace na úrovni instrukcí umožňuje spouštět takzvaný nemodifikovaný binární software, to znamená spouštět již zkompilovaný kód bez jakýchkoliv změn, přesně v té podobě, jak je používán na reálném hardwaru. Jinými slovy, můžete vytvořit kopii („dump“) pevného disku, uvést jej jako obraz pro model v plnoplošném simulátoru a – voilà! – operační systém a další programy se načtou v simulátoru bez jakýchkoli dalších akcí.
Výkon simulátorů
Jak bylo již zmíněno, samotný proces simulace celého systému, tedy všech jeho zařízení, je poměrně pomalý. Pokud navíc realizujete vše na velmi detailní úrovni, například mikroarchitektonické nebo logické, pak se výkon stane extrémně pomalým. Úroveň instrukcí je však vhodným výběrem a umožňuje operačním systémům a programům běžet rychlostmi, které jsou pro uživatele dostatečné pro pohodlnou interakci s nimi.
Zde je vhodné se dotknout tématu výkonu simulátorů. Obvykle se měří v IPS (instrukce za sekundu), přesněji v MIPS (miliony IPS), tedy v počtu instruktáží procesoru provedených simulátorem za jednu sekundu. Zároveň však rychlost simulace závisí také na výkonu systému, na kterém samotná simulace běží. Proto by bylo možná správnější mluvit o „zpomalování“ (slowdown) simulátoru ve srovnání s původním systémem.
Nejběžnější plnohodnotné simulátory na trhu, jako jsou QEMU, VirtualBox nebo VmWare Workstation, mají dobrou výkonnost. Pro uživatele může být téměř nepostřehnutelné, že práce probíhá v simulátoru. K tomu přispívá speciální schopnost virtualizace implementovaná v procesorech, algoritmy binární translace a další zajímavé aspekty. To je vše téma pro samostatný článek, ale pokud bychom to měli shrnout, virtualizace je hardwarová schopnost moderních procesorů, která umožňuje simulátorům neprovádět simulaci instrukcí, ale předávat je přímo k vykonání do skutečného procesoru, pokud se samozřejmě architektury simulátoru a procesoru shodují. Binární translace je překlad kódu hostitelské strojové architektury do kódu cílového a jeho následné vykonání na skutečném procesoru. Výsledkem je, že simulace je jenom o něco pomalejší, přibližně 5-10krát, a často dokonce běží se stejnou rychlostí jako skutečný systém. Na to však má vliv mnoho faktorů. Například, pokud chceme simulovat systém s několika desítkami procesorů, rychlost se okamžitě sníží na několik desítekkrát. Na druhou stranu, simulátory jako Simics v posledních verzích podporují vícejádrový hostitelský hardware a efektivně paralelizují simulované jádra na jádra skutečného procesoru.
Pokud jde o rychlost mikroarchitektonické simulace, je obvykle o několik řádů pomalejší, přibližně 1000-10000krát, než vykonání na běžném počítači bez simulace. A implementace na úrovni logických prvků jsou ještě o několik řádů pomalejší. Proto se jako emulátor na této úrovni používají FPGA, což výrazně zvyšuje výkonnost.
Graf níže ukazuje přibližnou závislost rychlosti simulace na detailech modelu.
Ciklová simulace
Ačkoli mají mikroarchitektonické simulátory nízkou rychlost provádění, jsou poměrně rozšířené. Modelování interních bloků procesoru je nezbytné k přesné simulaci doby provádění každé instrukce. Může dojít k nedorozumění – protože se může zdát, proč jednoduše nezprogramovat dobu provádění pro každou instrukci. Takový simulátor by však pracoval velmi nepřesně, protože doba provádění stejné instrukce se může lišit mezi jednotlivými vyvoláními.
Prvním příkladem je instrukce přístupu do paměti. Pokud je požadovaná buňka paměti dostupná v cache, doba provádění bude minimální. Pokud dané informace v cache nejsou ("cache miss"), výrazně to prodlouží dobu provádění instrukce. Proto je pro přesnou simulaci nezbytný model cache. Nicméně model cache to není. Procesor nebude prostě čekat na získání dat z paměti, pokud nejsou v cache. Místo toho začne provádět následující instrukce, vybírá ty, které nejsou závislé na výsledku čtení z paměti. Toto se nazývá provádění "mimo pořadí" (OOO, out of order execution), které je nezbytné k minimalizaci doby nečinnosti procesoru. Zohlednění všeho tohoto při výpočtu doby provádění instrukcí napomůže simulace odpovídajících bloků procesoru. Mezi těmito instrukcemi, které se provádějí, zatímco se čeká na výsledek čtení z paměti, může být i podmíněný skok. Pokud výsledek podmínky není v současnosti známý, procesor opět nezastaví provádění, ale udělá "předpoklad", provádí příslušný skok a pokračuje preventivně v provádění instrukcí od místa skoku. Tento blok, nazývaný branch predictor, by měl být rovněž implementován v mikroarchitektonickém simulátoru.
Obrázek níže ukazuje hlavní bloky procesoru, jejich znalost není nezbytná, je uvedena pouze k tomu, aby ukázala složitost mikroarchitektonické realizace.
Práce všech těchto bloků v reálném procesoru je synchronizována pomocí speciálních taktových signálů, podobně jako u modelu. Takovému mikroarchitektonickému simulátoru se říká cyklický (cycle accurate). Jeho hlavním účelem je přesně předpovědět výkon vyvíjeného procesoru a/nebo spočítat čas provádění určitého programu, například nějakého benchmarku. Pokud budou hodnoty nižší než potřebné, bude třeba upravit algoritmy a bloky procesoru nebo optimalizovat program.
Jak bylo uvedeno výše, cyklická simulace je velmi pomalá, a proto se používá pouze při zkoumání určitých aspektů práce programu, kde je nutné zjistit skutečnou rychlost provádění programů a posoudit budoucí výkon zařízení, jehož prototyp je modelován.
Přitom pro simulaci zbylého času práce programu je použit funkční simulátor. Jak probíhá takové kombinované použití v reálném životě? Nejprve se spustí funkční simulátor, na kterém se načte operační systém a vše potřebné pro spuštění zkoumaného programu. Nezajímá nás ani samotný operační systém, ani počáteční fáze spuštění programu, jeho konfigurace a podobně. Ovšem ani tyto části nemůžeme přeskočit a okamžitě přejít k provádění programu od poloviny. Proto jsou všechny tyto předběžné fáze provozovány na funkčním simulátoru. Jakmile program dosáhne zajímavého okamžiku, existují dvě možnosti. Můžeme model vyměnit za cyklický a pokračovat v provádění. Režimu simulace, při kterém se používá prováděný kód (tj. běžné zkompilované soubory programů), se říká simulace podle provedení (execution driven simulation). To je nejběžnější forma simulace. Je také možný jiný přístup – simulace na základě stop (trace driven simulation).
Simulace na základě stop
Skládá se ze dvou kroků. Pomocí funkčního simulátoru nebo na reálném systému se shromáždí a zapíše do souboru záznam činností programu. Tento záznam se nazývá stopa (trace). V závislosti na tom, co se zkoumá, může stopa zahrnovat prováděné instrukce, adresy paměti, čísla portů, informace o přerušení.
Dalším krokem je „přehrání“ stopy, kdy cyklický simulátor čte stopu a vykonává všechny pokyny, které jsou v ní zaznamenány. Na konci získáme čas vykonání daného kusu programu a také různé charakteristiky tohoto procesu, například procento zásahu do cache.
Důležitou vlastností práce se stopami je determinovanost, tedy že při spuštění simulace výše uvedeným způsobem opakovaně reprodukujeme stejnou sekvenci akcí. To nám umožňuje, při změně parametrů modelu (velikosti cache, bufferů a front) a používání různých vnitřních algoritmů nebo jejich nastavení, prozkoumat, jaký konkrétní parametr ovlivňuje výkon systému a která varianta přináší nejlepší výsledky. To vše lze provést s modelem prototypu zařízení před vytvořením skutečného hardwarového prototypu.
Složitost tohoto přístupu spočívá v nutnosti předchozího běhu aplikace a sběru stopy, stejně jako obrovské velikosti souboru se stopou. Mezi výhody patří to, že stačí modelovat pouze tu zajímavou část zařízení nebo platformy, zatímco simulace vykonání obvykle vyžaduje kompletní model.
Takže v tomto článku jsme se podívali na zvláštnosti plnohodnotné platformové simulace, hovořili jsme o rychlosti implementací na různých úrovních, cyklické simulaci a stopách. V dalším článku popíšu hlavní scénáře použití simulátorů, jak pro osobní účely, tak z pohledu vývoje ve velkých společnostech.
Zdroj: habr.com
