V druhé části článku o simulátorech počítačových systémů budu pokračovat jednoduchou úvodní formou o počítačových simulátorech, a to o celoplatformní simulaci, se kterou se běžný uživatel nejčastěji setkává, a také o taktování. -hodinový model a stopy, které jsou běžnější ve vývojářských kruzích.
В Mluvil jsem o tom, co jsou simulátory obecně, a také o úrovních simulace. Nyní, na základě těchto znalostí, navrhuji ponořit se trochu hlouběji a pohovořit o simulaci na plné platformě, o tom, jak sbírat stopy, co s nimi později dělat, a také o mikroarchitektonické emulaci hodin po hodinách.
Simulátor plné platformy aneb „Sám v poli není válečník“
Pokud chcete studovat činnost jednoho konkrétního zařízení, například síťové karty, nebo napsat firmware nebo ovladač pro toto zařízení, pak lze takové zařízení simulovat samostatně. Jeho použití v izolaci od zbytku infrastruktury však není příliš pohodlné. Pro spuštění odpovídajícího ovladače budete potřebovat centrální procesor, paměť, přístup k datové sběrnici atd. Ovladač navíc ke svému fungování vyžaduje operační systém (OS) a síťový zásobník. Kromě toho může být vyžadován samostatný generátor paketů a server odpovědí.
Plnoplatformní simulátor vytváří prostředí pro běh kompletní softwarové sady, která zahrnuje vše od BIOSu a bootloaderu až po samotný OS a jeho různé subsystémy, jako je stejný síťový zásobník, ovladače a aplikace na uživatelské úrovni. K tomu implementuje softwarové modely většiny počítačových zařízení: procesor a paměť, disk, vstupní/výstupní zařízení (klávesnice, myš, displej) a také stejnou síťovou kartu.
Níže je blokové schéma čipové sady x58 od Intelu. Plnoplatformní počítačový simulátor na této čipové sadě vyžaduje implementaci většiny uvedených zařízení, včetně těch uvnitř IOH (Input/Output Hub) a ICH (Input/Output Controller Hub), které nejsou na blokovém schématu podrobně znázorněny. . Ačkoli, jak ukazuje praxe, není mnoho zařízení, která nejsou používána softwarem, který budeme provozovat. Modely takových zařízení není třeba vytvářet.
Nejčastěji jsou plnoplatformní simulátory implementovány na úrovni instrukcí procesoru (ISA, viz níže). ). To umožňuje vytvořit samotný simulátor poměrně rychle a levně. Úroveň ISA je dobrá i proto, že zůstává víceméně konstantní, na rozdíl například od úrovně API/ABI, která se mění častěji. Implementace na úrovni instrukcí navíc umožňuje spouštět tzv. neupravený binární software, tedy spouštět již zkompilovaný kód bez jakýchkoliv změn, přesně tak, jak se používá na skutečném hardwaru. Jinými slovy, můžete vytvořit kopii („dump“) vašeho pevného disku, určit jej jako obrázek pro model v simulátoru plné platformy a voila! – OS a další programy jsou načteny do simulátoru bez jakýchkoliv dalších akcí.
Výkon simulátoru
Jak již bylo zmíněno výše, proces simulace celého systému, tedy všech jeho zařízení, je poměrně pomalý. Pokud toto vše implementujete také na velmi podrobné úrovni, například mikroarchitektonické nebo logické, bude provádění extrémně pomalé. Úroveň instrukcí je však vhodnou volbou a umožňuje operačnímu systému a programům spouštět se rychlostí dostatečnou k tomu, aby s nimi uživatel mohl pohodlně pracovat.
Zde by bylo vhodné dotknout se tématu výkonu simulátoru. Obvykle se měří v IPS (instrukcí za sekundu), přesněji v MIPS (miliony IPS), tedy v počtu instrukcí procesoru, které simulátor vykoná za jednu sekundu. Rychlost simulace přitom závisí i na výkonu systému, na kterém samotná simulace běží. Proto může být správnější mluvit o „zpomalení“ simulátoru ve srovnání s původním systémem.
Nejběžnější plnoplatformní simulátory na trhu, jako je QEMU, VirtualBox nebo VmWare Workstation, mají dobrý výkon. Pro uživatele nemusí být ani postřehnutelné, že v simulátoru probíhá práce. To se děje díky speciálním virtualizačním schopnostem implementovaným v procesorech, binárním překladovým algoritmům a dalším zajímavým věcem. To vše je téma na samostatný článek, ale stručně řečeno, virtualizace je hardwarová vlastnost moderních procesorů, která umožňuje simulátorům nesimulovat instrukce, ale posílat je k provedení přímo skutečnému procesoru, pokud ovšem architektura simulátor a procesor jsou podobné. Binární překlad je překlad strojového kódu hosta do kódu hostitele a následné spuštění na skutečném procesoru. Díky tomu je simulace jen o málo pomalejší, 5-10x a často dokonce běží stejnou rychlostí jako skutečný systém. I když je to ovlivněno mnoha faktory. Chceme-li například simulovat systém s několika desítkami procesorů, pak rychlost okamžitě klesne na několik desítek krát. Na druhou stranu simulátory jako Simics v nejnovějších verzích podporují víceprocesorový hostitelský hardware a efektivně paralelizují simulovaná jádra na jádra skutečného procesoru.
Pokud mluvíme o rychlosti mikroarchitektonické simulace, pak je obvykle o několik řádů, asi 1000-10000 krát pomalejší než provádění na běžném počítači, bez simulace. A implementace na úrovni logických prvků jsou o několik řádů pomalejší. Proto se na této úrovni používá jako emulátor FPGA, což může výrazně zvýšit výkon.
Níže uvedený graf ukazuje přibližnou závislost rychlosti simulace na detailu modelu.
Simulace po rytmu
Navzdory nízké rychlosti provádění jsou mikroarchitektonické simulátory poměrně běžné. Simulace vnitřních bloků procesoru je nezbytná pro přesnou simulaci doby provádění každé instrukce. Zde může dojít k nedorozumění - koneckonců by se zdálo, proč jednoduše nenaprogramovat dobu provádění každé instrukce. Ale takový simulátor bude velmi nepřesný, protože doba provádění stejné instrukce se může lišit volání od volání.
Nejjednodušším příkladem je instrukce pro přístup do paměti. Pokud je požadované paměťové místo dostupné v mezipaměti, bude doba provedení minimální. Pokud tato informace není v mezipaměti („cache miss“), výrazně se tím prodlouží doba provádění instrukce. Pro přesnou simulaci je tedy nutný model cache. Tato záležitost se však neomezuje pouze na model mezipaměti. Procesor nebude jednoduše čekat na načtení dat z paměti, když nejsou v mezipaměti. Místo toho začne provádět další instrukce a vybere ty, které nezávisí na výsledku čtení z paměti. Jedná se o takzvané provádění „mimo pořadí“ (OOO, provedení mimo pořadí), které je nezbytné pro minimalizaci doby nečinnosti procesoru. Modelování odpovídajících bloků procesoru pomůže toto vše zohlednit při výpočtu doby provádění instrukcí. Mezi těmito instrukcemi, prováděnými během čekání na výsledek čtení z paměti, může dojít k operaci podmíněného skoku. Pokud je výsledek podmínky v tuto chvíli neznámý, pak procesor opět nezastaví provádění, ale provede „hádání“, provede příslušnou větev a pokračuje v proaktivním provádění pokynů od bodu přechodu. Takový blok, nazývaný prediktor větve, musí být také implementován v mikroarchitektonickém simulátoru.
Obrázek níže ukazuje hlavní bloky procesoru, není nutné jej znát, je zobrazen pouze pro ukázku složitosti mikroarchitektonické implementace.
Činnost všech těchto bloků ve skutečném procesoru je synchronizována speciálními hodinovými signály a totéž se děje v modelu. Takový mikroarchitektonický simulátor se nazývá cyklicky přesný. Jeho hlavním účelem je přesně předpovídat výkon vyvíjeného procesoru a/nebo vypočítat dobu provádění konkrétního programu, například benchmarku. Pokud jsou hodnoty nižší, než je požadováno, bude nutné upravit algoritmy a bloky procesoru nebo optimalizovat program.
Jak je ukázáno výše, clock-by-clock simulace je velmi pomalá, proto se používá pouze při studiu určitých momentů činnosti programu, kdy je nutné zjistit skutečnou rychlost provádění programu a vyhodnotit budoucí výkon zařízení, jehož prototyp se simuluje.
V tomto případě je použit funkční simulátor pro simulaci zbývající doby běhu programu. Jak k této kombinaci použití dochází ve skutečnosti? Nejprve se spustí funkční simulátor, na který se nahraje OS a vše potřebné ke spuštění studovaného programu. Koneckonců nás nezajímá samotný OS, ani počáteční fáze spouštění programu, jeho konfigurace atd. Tyto části však také nemůžeme přeskočit a rovnou přejít ke spuštění programu od středu. Všechny tyto předběžné kroky proto probíhají na funkčním simulátoru. Po provedení programu do okamžiku, který nás zajímá, jsou možné dvě možnosti. Model můžete nahradit modelem s hodinovým cyklem a pokračovat v provádění. Simulační režim, který používá spustitelný kód (tj. běžné kompilované programové soubory), se nazývá simulace řízená provedením. Toto je nejběžnější možnost simulace. Je možný i jiný přístup – simulace řízená stopou.
Simulace založená na stopách
Skládá se ze dvou kroků. Pomocí funkčního simulátoru nebo na reálném systému se shromažďuje protokol akcí programu a zapisuje se do souboru. Tento protokol se nazývá trasování. V závislosti na tom, co je zkoumáno, může trasování obsahovat spustitelné instrukce, adresy paměti, čísla portů a informace o přerušení.
Dalším krokem je „přehrání“ trasování, kdy simulátor clock-by-clock čte trasování a provádí všechny instrukce v něm zapsané. Na konci získáme dobu provádění této části programu a také různé charakteristiky tohoto procesu, například procento zásahů do mezipaměti.
Důležitým rysem práce se stopami je determinismus, to znamená, že spuštěním simulace výše popsaným způsobem znovu a znovu reprodukujeme stejnou sekvenci akcí. To umožňuje změnou parametrů modelu (velikosti mezipaměti, vyrovnávací paměti a fronty) a použitím různých interních algoritmů nebo jejich vyladěním zkoumat, jak konkrétní parametr ovlivňuje výkon systému a která možnost poskytuje nejlepší výsledky. To vše lze provést pomocí prototypového modelu zařízení před vytvořením skutečného prototypu hardwaru.
Složitost tohoto přístupu spočívá v nutnosti nejprve spustit aplikaci a shromáždit trasování a také v obrovské velikosti trasovacího souboru. Mezi výhody patří skutečnost, že stačí simulovat pouze část zájmového zařízení nebo platformy, zatímco simulace provedením obvykle vyžaduje kompletní model.
V tomto článku jsme se tedy podívali na funkce simulace na plné platformě, hovořili jsme o rychlosti implementací na různých úrovních, simulaci hodin po cyklu a stopách. V příštím článku popíšu hlavní scénáře využití simulátorů jak pro osobní účely, tak z pohledu vývoje ve velkých společnostech.
Zdroj: www.habr.com