V drugem delu članka o simulatorjih računalniških sistemov bom nadaljeval v preprosti uvodni obliki o računalniških simulatorjih, in sicer o simulaciji na celotni platformi, s katero se povprečen uporabnik najpogosteje srečuje, ter o clock-by -model ure in sledi, ki so pogostejše v razvijalskih krogih.
В Govoril sem o tem, kaj so simulatorji na splošno, pa tudi o stopnjah simulacije. Zdaj, na podlagi tega znanja, predlagam, da se potopimo malo globlje in spregovorimo o simulaciji celotne platforme, kako zbirati sledi, kaj z njimi narediti pozneje, pa tudi o mikroarhitekturni emulaciji ure za uro.
Simulator celotne platforme ali "Sam na terenu ni bojevnik"
Če želite preučiti delovanje ene določene naprave, na primer omrežne kartice, ali napisati vdelano programsko opremo ali gonilnik za to napravo, potem lahko takšno napravo simulirate ločeno. Vendar pa uporaba ločeno od preostale infrastrukture ni zelo priročna. Za zagon ustreznega gonilnika boste potrebovali centralni procesor, pomnilnik, dostop do podatkovnega vodila itd. Poleg tega gonilnik za delovanje potrebuje operacijski sistem (OS) in omrežni sklad. Poleg tega bosta morda potrebna ločen generator paketov in odzivni strežnik.
Simulator celotne platforme ustvari okolje za izvajanje celotnega sklada programske opreme, ki vključuje vse od BIOS-a in zagonskega nalagalnika do samega OS in njegovih različnih podsistemov, kot so isti omrežni sklad, gonilniki in aplikacije na ravni uporabnika. Za to implementira modele programske opreme večine računalniških naprav: procesor in pomnilnik, disk, vhodno/izhodne naprave (tipkovnica, miška, zaslon), pa tudi isto omrežno kartico.
Spodaj je blokovni diagram Intelovega nabora čipov x58. Računalniški simulator s polno platformo na tem naboru čipov zahteva implementacijo večine navedenih naprav, vključno s tistimi znotraj IOH (Input/Output Hub) in ICH (Input/Output Controller Hub), ki niso podrobno prikazane na blokovnem diagramu. . Čeprav, kot kaže praksa, ni veliko naprav, ki jih programska oprema, ki jo bomo izvajali, ne uporablja. Modelov takšnih naprav ni treba ustvariti.
Najpogosteje so simulatorji celotne platforme implementirani na ravni ukazov procesorja (ISA, glej spodaj). ). To vam omogoča relativno hitro in poceni izdelavo samega simulatorja. Raven ISA je dobra tudi zato, ker ostaja bolj ali manj konstantna, za razliko od na primer ravni API/ABI, ki se pogosteje spreminja. Poleg tega vam implementacija na ravni navodil omogoča zagon tako imenovane nespremenjene binarne programske opreme, to je zagon že prevedene kode brez kakršnih koli sprememb, točno tako, kot se uporablja na pravi strojni opremi. Z drugimi besedami, lahko naredite kopijo (»dump«) vašega trdega diska, jo določite kot sliko za model v simulatorju polne platforme in voila! – OS in drugi programi se naložijo v simulator brez dodatnih dejanj.
Učinkovitost simulatorja
Kot že omenjeno, je proces simulacije celotnega sistema, torej vseh njegovih naprav, precej počasen podvig. Če vse to izvajate tudi na zelo podrobni ravni, na primer mikroarhitekturni ali logični, bo izvedba postala izjemno počasna. Toda raven navodil je ustrezna izbira in omogoča operacijskemu sistemu in programom, da se izvajajo s hitrostjo, ki zadostuje za udobno interakcijo uporabnika z njimi.
Tukaj bi bilo primerno, da se dotaknemo teme delovanja simulatorja. Običajno se meri v IPS (instructions per second), natančneje v MIPS (millions IPS), to je število ukazov procesorja, ki jih simulator izvede v eni sekundi. Hkrati pa je hitrost simulacije odvisna tudi od zmogljivosti sistema, na katerem teče sama simulacija. Zato je morda bolj pravilno govoriti o "upočasnitvi" simulatorja v primerjavi z originalnim sistemom.
Najpogostejši simulatorji polne platforme na trgu, kot so QEMU, VirtualBox ali VmWare Workstation, imajo dobro zmogljivost. Uporabnik morda niti ne opazi, da v simulatorju poteka delo. To se zgodi zaradi posebnih zmožnosti virtualizacije, implementiranih v procesorje, algoritmov binarnega prevajanja in drugih zanimivih stvari. Vse to je tema za poseben članek, a na kratko, virtualizacija je strojna lastnost sodobnih procesorjev, ki simulatorjem omogoča, da ne simulirajo navodil, ampak jih pošljejo v izvedbo neposredno pravemu procesorju, če seveda arhitektura simulator in procesor sta podobna. Binarno prevajanje je prevajanje strojne kode gosta v kodo gostitelja in kasnejša izvedba na pravem procesorju. Posledično je simulacija le nekoliko počasnejša, 5-10-krat, pogosto pa celo teče z enako hitrostjo kot realni sistem. Čeprav na to vpliva veliko dejavnikov. Na primer, če želimo simulirati sistem z več deset procesorji, potem bo hitrost takoj padla za teh nekaj desetkrat. Po drugi strani pa simulatorji, kot je Simics v najnovejših različicah, podpirajo strojno opremo večprocesorskega gostitelja in učinkovito vzporedijo simulirana jedra na jedra pravega procesorja.
Če govorimo o hitrosti mikroarhitekturne simulacije, potem je ta običajno več velikosti, približno 1000-10000-krat počasnejša od izvajanja na običajnem računalniku, brez simulacije. In implementacije na ravni logičnih elementov so počasnejše za več velikosti. Zato se na tej ravni kot emulator uporablja FPGA, ki lahko bistveno poveča zmogljivost.
Spodnji graf prikazuje približno odvisnost hitrosti simulacije od podrobnosti modela.
Beat-by-beat simulacija
Kljub nizki hitrosti izvajanja so mikroarhitekturni simulatorji precej pogosti. Simulacija notranjih blokov procesorja je potrebna za natančno simulacijo časa izvajanja vsakega ukaza. Tukaj lahko pride do nesporazuma - navsezadnje se zdi, zakaj ne bi preprosto programirali časa izvajanja za vsako navodilo. Toda takšen simulator bo zelo nenatančen, saj se lahko čas izvajanja istega ukaza razlikuje od klica do klica.
Najenostavnejši primer je navodilo za dostop do pomnilnika. Če je zahtevana pomnilniška lokacija na voljo v predpomnilniku, bo čas izvajanja minimalen. Če te informacije niso v predpomnilniku (»cache miss«), bo to močno podaljšalo čas izvajanja ukaza. Zato je za natančno simulacijo potreben model predpomnilnika. Zadeva pa ni omejena na model predpomnilnika. Procesor ne bo preprosto čakal, da se podatki pridobijo iz pomnilnika, ko niso v predpomnilniku. Namesto tega bo začel izvajati naslednja navodila, pri čemer bo izbral tista, ki niso odvisna od rezultata branja iz spomina. To je tako imenovana izvedba »izven reda« (OOO, izvajanje izven reda), ki je potrebna za zmanjšanje časa mirovanja procesorja. Modeliranje ustreznih procesorskih blokov bo pomagalo upoštevati vse to pri izračunu časa izvajanja navodil. Med temi ukazi, ki se izvajajo med čakanjem na rezultat branja iz pomnilnika, lahko pride do operacije pogojnega skoka. Če rezultat pogoja trenutno ni znan, potem procesor spet ne ustavi izvajanja, ampak "ugiba", izvede ustrezno vejo in nadaljuje s proaktivnim izvajanjem navodil od točke prehoda. Takšen blok, imenovan prediktor vej, mora biti implementiran tudi v mikroarhitekturni simulator.
Na spodnji sliki so prikazani glavni bloki procesorja, ni ga treba poznati, prikazan je le za prikaz kompleksnosti mikroarhitekturne izvedbe.
Delovanje vseh teh blokov v pravem procesorju je sinhronizirano s posebnimi signali ure in enako se dogaja v modelu. Tak mikroarhitekturni simulator se imenuje ciklično natančen. Njegov glavni namen je natančno napovedati zmogljivost procesorja, ki se razvija, in/ali izračunati čas izvajanja določenega programa, na primer merila uspešnosti. Če so vrednosti nižje od zahtevanih, bo treba spremeniti algoritme in procesorske bloke ali optimizirati program.
Kot je prikazano zgoraj, je simulacija od ure do ure zelo počasna, zato se uporablja le pri proučevanju določenih trenutkov delovanja programa, kjer je treba ugotoviti dejansko hitrost izvajanja programa in oceniti prihodnje delovanje naprave, katere prototip se simulira.
V tem primeru se uporabi funkcionalni simulator za simulacijo preostalega časa delovanja programa. Kako se ta kombinacija uporabe zgodi v resnici? Najprej se zažene funkcionalni simulator, na katerega se naloži OS in vse, kar je potrebno za izvajanje proučevanega programa. Navsezadnje nas ne zanima sam OS, niti začetne faze zagona programa, njegove konfiguracije itd. Vendar tudi teh delov ne moremo preskočiti in takoj preiti na izvajanje programa od sredine. Zato se vsi ti predhodni koraki izvajajo na funkcionalnem simulatorju. Ko je program izveden do trenutka, ki nas zanima, sta možni dve možnosti. Model lahko zamenjate z modelom od ure do cikla in nadaljujete z izvajanjem. Način simulacije, ki uporablja izvršljivo kodo (to je običajne prevedene programske datoteke), se imenuje simulacija, ki jo poganja izvajanje. To je najpogostejša možnost simulacije. Možen je tudi drug pristop - simulacija na podlagi sledi.
Simulacija na podlagi sledi
Sestavljen je iz dveh korakov. Z uporabo funkcionalnega simulatorja ali v realnem sistemu se zbere dnevnik programskih dejanj in zapiše v datoteko. Ta dnevnik se imenuje sled. Odvisno od tega, kaj se pregleduje, lahko sled vključuje izvršljiva navodila, pomnilniške naslove, številke vrat in informacije o prekinitvah.
Naslednji korak je "predvajanje" sledi, ko simulator od ure do ure prebere sled in izvede vsa navodila, zapisana v njem. Na koncu dobimo čas izvajanja tega dela programa, pa tudi različne značilnosti tega procesa, na primer odstotek zadetkov v predpomnilniku.
Pomembna značilnost dela s sledmi je determinizem, to pomeni, da z izvajanjem simulacije na zgoraj opisani način znova in znova reproduciramo isto zaporedje dejanj. To omogoča, da s spreminjanjem parametrov modela (velikosti predpomnilnika, vmesnega pomnilnika in čakalne vrste) ter z uporabo različnih notranjih algoritmov ali njihovim prilagajanjem proučimo, kako določen parameter vpliva na zmogljivost sistema in katera možnost daje najboljše rezultate. Vse to je mogoče narediti s prototipnim modelom naprave, preden ustvarite dejanski prototip strojne opreme.
Zapletenost tega pristopa je v tem, da je treba najprej zagnati aplikacijo in zbrati sledenje, ter v ogromni velikosti datoteke sledenja. Prednosti vključujejo dejstvo, da je dovolj simulirati samo del naprave ali platforme, ki vas zanima, medtem ko simulacija z izvedbo običajno zahteva celoten model.
Tako smo v tem članku preučili značilnosti simulacije celotne platforme, govorili o hitrosti implementacij na različnih ravneh, simulaciji od ure do cikla in sledeh. V naslednjem članku bom opisal glavne scenarije uporabe simulatorjev, tako za osebne namene kot z razvojnega vidika v velikih podjetjih.
Vir: www.habr.com