V druhej časti článku o simulátoroch počítačových systémov budem pokračovať v jednoduchom informačnom formáte o počítačových simulátoroch, konkrétne o plne platformovej simulácii, s ktorou sa najčastejšie stretáva bežný používateľ, ako aj o taktovej modelovej a trasách, ktoré sú viac rozšírené v kruhoch vývojárov.
V Rozprával som o tom, čo sú simulátory vôbec, ako aj o úrovniach modelovania. Teraz na základe týchto znalostí navrhujem potápať sa o niečo hlbšie a hovoriť o plne platformovej simulácii, o tom, ako zostaviť trasy, čo s nimi potom robiť, a taktiež o taktovej mikroarchitektonickej emulácii.
Plne platformový simulátor (full platform simulator), alebo “Jeden na poli — nie je vojak”
Ak je potrebné preskúmať fungovanie jedného konkrétneho zariadenia, napríklad sieťovej karty, alebo napísať pre toto zariadenie firmvér alebo ovládač, je možné takéto zariadenie modelovať samostatne. Avšak používať ho oddelene od zvyšku infraštruktúry nie je veľmi pohodlné. Na spustenie príslušného ovládača bude potrebný centrálny procesor, pamäť, prístup k zbernici na prenos dát a ďalšie. Okrem toho je na funkciu ovládača potrebný operačný systém (OS) a sieťový zásobník. Navyše môže byť potrebný aj samostatný generátor paketov a server na prijímanie odpovedí.
Plne platformový simulátor vytvára prostredie na spustenie kompletného softvérového zásobníka, ktorý zahŕňa všetko, počínajúc BIOS a zavádzačom a končiac samotným OS a rôznymi jeho podsystémami, ako je ten istý sieťový zásobník, ovládače, aplikácie používateľskej úrovne. Na tento účel realizuje programové modely väčšiny zariadení počítača: procesor a pamäť, disk, zariadenia vstupu a výstupu (klávesnica, myš, displej) a samozrejme aj uvedenú sieťovú kartu.
Nižšie je znázornená bloková schéma čipsetu x58 od spoločnosti Intel. V plnohodnotnom počítačovom simulátore tohto čipsetu je potrebné implementovať väčšinu uvedených zariadení, vrátane tých, ktoré sú vnútorné v IOH (Input/Output Hub) a ICH (Input/Output Controller Hub), ktoré nie sú podrobne nakreslené na blokovej schéme. Aj keď, ako ukazuje prax, nie je málo zariadení, ktoré sa nepoužívajú tým softvérom, ktorý plánujeme spustiť. Modely takýchto zariadení netreba vytvárať.
Najčastejšie sa plnohodnotné simulátory realizujú na úrovni inštrukcií procesora (ISA, pozri ). To umožňuje relatívne rýchlo a lacno vytvoriť samotný simulátor. Úroveň ISA je tiež dobrá v tom, že zostáva viac-menej stabilná, na rozdiel od, napríklad, úrovne API/ABI, ktorá sa mení častejšie. Navyše, implementácia na úrovni inštrukcií umožňuje spúšťať takzvaný nemodifikovaný binárny softvér, teda spúšťať už skompilovaný kód bez akýchkoľvek zmien, presne v tej podobe, v akej sa používa na skutočnom hardvéri. Inými slovami, môžeme urobiť kópiu („dump“) harddisku, určiť ho ako obraz pre model v plnohodnotnom simulátore a – voilà! – OS a ostatné programy sa načítajú do simulátora bez akýchkoľvek dodatočných úkonov.
Výkonnosť simulátorov
Ako bolo spomenuté vyššie, samotný proces simulácie celej sústavy, teda všetkých jej zariadení, je celkom pomalá záležitosť. Ak sa to ešte implementuje na celkom detailnej úrovni, napríklad mikroarchitektonickej alebo logickej, vykonávanie sa stane extrémne pomalým. Ale úroveň inštrukcií je vhodným výberom a umožňuje OS a programom fungovať rýchlosťou, ktorá je pre používateľa dostatočná na pohodlné interakcie s nimi.
Tu je vhodné sa dotknúť témy výkonnosti simulátorov. Obvykle sa meria v IPS (inštrukcie za sekundu), presnejšie v MIPS (milióny IPS), teda v počte inštrukcií procesora, ktoré simulátor vykonáva za jednu sekundu. Zároveň rýchlosť simulácie závisí aj od výkonnosti systému, na ktorom samotná simulácia prebieha. Preto by možno bolo správnejšie hovoriť o „spomalení“ (slowdown) simulátora v porovnaní s pôvodným systémom.
Najbežnejšie dostupné plne platformové simulátory, ako QEMU, VirtualBox alebo VmWare Workstation, majú slušný výkon. Pre používateľa môže byť dokonca neviditeľné, že práca prebieha v simulátore. K tomu prispieva špeciálna schopnosť virtualizácie implementovaná v procesoroch, algoritmy binárneho prekladu a iné zaujímavé aspekty. To všetko je téma na samostatný článok, ale ak to zhrnieme, virtualizácia je hardvérová funkcia moderných procesorov, ktorá umožňuje simulátorom nevykonávať inštrukcie simulácie, ale priamo ich odovzdávať na vykonanie reálnemu procesoru, ak je architektúra simulátora a procesora podobná. Binárny preklad je preklad kódu hostiteľského systému do kódu hosťa a jeho následné vykonanie na reálnom procesore. V dôsledku toho je simulácia len nepatrne pomalšia, raz za 5-10, a často funguje dokonca rovnako rýchlo ako skutočný systém. Na toto však vplýva mnoho faktorov. Napríklad, ak chceme simulovať systém s niekoľkými desiatkami procesorov, rýchlosť okamžite klesne o niekoľko desiatok ráz. Na druhej strane simulátory ako Simics v posledných verziách podporujú viacprocesorový hostiteľský hardvér a efektívne paralelizujú simulované jadrá na jadrá reálneho procesora.
Pri rýchlosti mikroarchitektonickej simulácie to zvyčajne znamená niekoľko rádov, približne 1000-10000 krát pomalšieho vykonania na bežnom počítači bez simulácie. Implementácie na úrovni logických prvkov sú ešte pomalšie o niekoľko rádov. Preto sa na úrovni emulátorov používajú FPGA, čo umožňuje výrazne zvýšiť výkon.
Graf nižšie ukazuje približnú závislosť rýchlosti simulácie od detailnosti modelu.
Potaktná simulácia
Napriek nízkym rýchlostiam vykonávania sú mikroarchitektonické simulátory dosť rozšírené. Modelovanie vnútorných blokov procesora je potrebné na presné simulovanie časov vykonávania každej inštrukcie. Tu môže vzniknúť nepochopenie – veď sa zdá, prečo jednoducho nezprogramovať čas vykonávania pre každú inštrukciu. Ale taký simulátor by fungoval veľmi nepresne, pretože čas vykonávania rovnakej inštrukcie sa môže líšiť od volania k volaniu.
Najjednoduchším príkladom je inštrukcia prístupu do pamäte. Ak je požadovaná bunka pamäte dostupná v cache, čas vykonávania bude minimálny. Ak daná informácia v cache nie je ("cache miss"), čas vykonávania inštrukcie sa výrazne predlžuje. Preto na presnú simuláciu potrebujeme model cache. Avšak modelom cache to nekončí. Procesor nebude len čakať na načítanie údajov z pamäte, ak nie sú v cache. Namiesto toho začne vykonávať nasledujúce inštrukcie, vyberajúc tie, ktoré nezávisia od výsledku čítania z pamäte. Toto je takzvané vykonávanie "nepodľa poradia" (OOO, out of order execution), potrebné na minimalizáciu času nečinnosti procesora. Zohľadnenie všetkého tohto pri výpočte času vykonávania inštrukcií pomôže modelovanie príslušných blokov procesora. Medzi týmito inštrukciami, ktoré sa vykonávajú, kým sa čaká na výsledok čítania z pamäte, sa môže nachádzať operácia podmieneného skoku. Ak je výsledok podmienky neznámy v danom momente, procesor opäť nezastavuje vykonávanie, ale robí "predpoklad", vykonáva príslušný skok a pokračuje v preventívnom vykonávaní inštrukcií z miesta skoku. Tento blok, nazývaný predikátor skokov, musí byť tiež implementovaný v mikroarchitektonickom simulátore.
Obrázok nižšie ukazuje hlavné bloky procesora, ich znalosť nie je nevyhnutná, je uvedená len preto, aby ukázala zložitosti mikroarchitektonickej implementácie.
Práca všetkých týchto blokov v reálnom procesore sa synchronizuje špeciálnymi taktnými signálmi, rovnako to funguje aj v modeli. Takýto mikroarchitektonický simulátor sa nazýva cyklický (cycle accurate). Jeho hlavným účelom je presne predpovedať výkon vyvíjaného procesora a/alebo vypočítať čas vykonávania konkrétneho programu, napríklad nejakého benchmarku. Ak budú hodnoty nižšie ako potrebné, bude potrebné vylepšiť algoritmy a bloky procesora alebo optimalizovať program.
Ako bolo uvedené vyššie, cyklická simulácia je veľmi pomalá, preto sa používa len pri skúmaní určitých aspektov práce programu, kde je potrebné zistiť skutočnú rýchlosť vykonávania programov a ohodnotiť budúci výkon zariadenia, prototyp ktorého je modelovaný.
Pre simuláciu zvyšku času vykonávania programu sa používa funkčný simulátor. Ako prebieha takéto kombinované použitie v praxi? Najprv sa spustí funkčný simulátor, na ktorom sa načíta operačný systém a všetko potrebné na spustenie skúmaného programu. Pozrieme sa len na program, neurčujú nás ani samotný operačný systém, ani počiatočné fázy spustenia programu, jeho konfigurácia a podobne. Avšak nemôžeme preskočiť tieto časti a okamžite prejsť k vykonávaniu programu od stredu. Preto sa všetky tieto predbežné fázy prevádzkujú na funkčnom simulátore. Po tom, čo sa program vykonal do zaujímavého momentu, existujú dva varianty. Môžeme nahradiť model cyklickým a pokračovať vo vykonávaní. Mód simulácie, pri ktorom sa používa vykonávací kód (t.j. bežné skompilované súbory programov), sa nazýva simulácia podľa vykonávania (execution driven simulation). Toto je najbežnejší variant simulácie. Možný je aj iný prístup – simulácia na základe stôp (trace driven simulation).
Simulácia na základe stôp
Skladá sa z dvoch krokov. Pomocou funkčného simulátora alebo na reálnom systéme sa zhromažďuje a zapisuje do súboru log činností programu. Tento log sa nazýva stopa (trace). V závislosti od toho, čo sa skúma, môže stopa obsahovať vykonávacie inštrukcie, adresy pamäte, čísla portov, informácie o prerušeniach.
Ďalším krokom je „prehrávanie“ stopy, keď taktický simulátor číta stopu a vykonáva všetky v nej zapísané inštrukcie. Na konci získavame čas vykonania tohto kusu programu, ako aj rôzne charakteristiky tohto procesu, napríklad percento zasahovania do vyrovnávacej pamäte.
Dôležitou vlastnosťou práce so stopami je determinovanosť, teda spúšťaním simulácie popísaným vyššie spôsobom, zakaždým reprodukujeme rovnakú postupnosť akcií. To umožňuje, meniac parametre modelu (veľkosti vyrovnávacej pamäte, bufferov a front), a používaním rôznych interných algoritmov alebo ich nastavením, skúmať, ako ten alebo onen parameter ovplyvňuje výkon systému a ktorá varianta prináša najlepšie výsledky. Toto všetko môžeme urobiť s modelom prototypu zariadenia pred vytvorením skutočného hardvérového prototypu.
Zložitost tohto prístupu spočíva v potrebe predbežného spustenia aplikácie a zhromaždenia stopy, ako aj obrovskom veľkosti súboru so stopou. K výhodám patrí to, že stačí modelovať iba zaujímavú časť zariadenia alebo platformy, zatiaľ čo simulácia vykonávania požaduje zvyčajne úplný model.
Takže v tomto článku sme sa venovali osobitnostiam plno-platformovej simulácie, porozprávali sme o rýchlosti realizácií na rôznych úrovniach, taktovej simulácii a stopách. V nasledujúcom článku popíšem hlavné scenáre používania simulátorov, ako v osobných záujmoch, tak z pohľadu vývoja vo veľkých spoločnostiach.
Zdroj: habr.com
