U drugom dijelu članka o simulatorima računarskih sistema, nastavit ću u jednostavnom uvodnom obliku govoriti o kompjuterskim simulatorima, odnosno o simulaciji pune platforme, s kojom se prosječan korisnik najčešće susreće, kao i o clock-by-u. -model sata i tragovi, koji su češći u krugovima programera.
В Govorio sam o tome šta su simulatori uopšte, kao io nivoima simulacije. Sada, na osnovu tog znanja, predlažem da zaronim malo dublje i pričamo o simulaciji pune platforme, kako prikupiti tragove, šta s njima kasnije, kao i o mikroarhitektonskoj emulaciji sat po sat.
Simulator pune platforme, ili "Sam u polju nije ratnik"
Ako želite proučiti rad jednog određenog uređaja, na primjer, mrežne kartice, ili napisati firmver ili drajver za ovaj uređaj, onda se takav uređaj može simulirati zasebno. Međutim, korištenje u izolaciji od ostatka infrastrukture nije baš zgodno. Za pokretanje odgovarajućeg drajvera trebat će vam centralni procesor, memorija, pristup sabirnici podataka itd. Pored toga, drajveru je potreban operativni sistem (OS) i mrežni stog da bi funkcionisao. Osim toga, može biti potreban poseban generator paketa i server odgovora.
Simulator pune platforme stvara okruženje za pokretanje kompletnog softverskog steka, koji uključuje sve od BIOS-a i pokretača do samog OS-a i njegovih različitih podsistema, kao što su isti mrežni stog, drajveri i aplikacije na nivou korisnika. Da bi to učinio, implementira softverske modele većine računarskih uređaja: procesor i memoriju, disk, ulazno/izlazne uređaje (tastatura, miš, ekran), kao i istu mrežnu karticu.
Ispod je blok dijagram Intelovog x58 čipseta. Računarski simulator pune platforme na ovom čipsetu zahtijeva implementaciju većine navedenih uređaja, uključujući one unutar IOH (Input/Output Hub) i ICH (Input/Output Controller Hub), koji nisu detaljno prikazani na blok dijagramu . Iako, kako praksa pokazuje, nema mnogo uređaja koje ne koristi softver koji ćemo pokrenuti. Modele takvih uređaja nije potrebno kreirati.
Najčešće se simulatori pune platforme implementiraju na nivou instrukcija procesora (ISA, vidi dolje). ). Ovo vam omogućava da kreirate sam simulator relativno brzo i jeftino. ISA nivo je takođe dobar jer ostaje manje-više konstantan, za razliku od, na primer, API/ABI nivoa koji se češće menja. Pored toga, implementacija na nivou instrukcija omogućava vam da pokrenete takozvani neizmenjeni binarni softver, odnosno da pokrenete već kompajlirani kod bez ikakvih promena, tačno onako kako se koristi na stvarnom hardveru. Drugim riječima, možete napraviti kopiju (“dump”) vašeg tvrdog diska, navesti ga kao sliku za model u simulatoru pune platforme, i voila! – OS i drugi programi se učitavaju u simulatoru bez ikakvih dodatnih radnji.
Performanse simulatora
Kao što je već pomenuto, proces simulacije čitavog sistema, odnosno svih njegovih uređaja, je prilično spor poduhvat. Ako sve ovo implementirate na vrlo detaljnom nivou, na primjer, mikroarhitektonskom ili logičkom, tada će izvođenje postati izuzetno sporo. Ali nivo instrukcija je prikladan izbor i omogućava OS i programima da se izvršavaju brzinom koja je dovoljna da korisnik može da komunicira sa njima.
Ovdje bi bilo prikladno dotaknuti se teme izvođenja simulatora. Obično se mjeri u IPS (instrukcije u sekundi), tačnije u MIPS (milioni IPS), odnosno u broju procesorskih instrukcija koje izvršava simulator u jednoj sekundi. Istovremeno, brzina simulacije zavisi i od performansi sistema na kojem se sama simulacija izvodi. Stoga je možda ispravnije govoriti o „usporavanju“ simulatora u odnosu na originalni sistem.
Najčešći simulatori pune platforme na tržištu, kao što su QEMU, VirtualBox ili VmWare Workstation, imaju dobre performanse. Korisniku se možda neće ni primijetiti da se radi u simulatoru. To se događa zahvaljujući posebnim mogućnostima virtuelizacije implementiranih u procesorima, algoritmima binarnog prevođenja i drugim zanimljivim stvarima. Ovo je sve tema za poseban članak, ali ukratko, virtuelizacija je hardverska karakteristika modernih procesora koja omogućava simulatorima da ne simuliraju instrukcije, već da ih pošalju na izvršenje direktno stvarnom procesoru, ako su, naravno, arhitekture simulator i procesor su slični. Binarno prevođenje je prevođenje gostujućeg mašinskog koda u host kod i naknadno izvršenje na stvarnom procesoru. Kao rezultat toga, simulacija je samo malo sporija, 5-10 puta, a često čak i radi istom brzinom kao pravi sistem. Iako na to utječu mnogi faktori. Na primjer, ako želimo simulirati sistem sa nekoliko desetina procesora, tada će brzina odmah pasti za ovih nekoliko desetina puta. S druge strane, simulatori poput Simicsa u najnovijim verzijama podržavaju višeprocesorski host hardver i efektivno paraleliziraju simulirane jezgre na jezgre pravog procesora.
Ako govorimo o brzini mikroarhitektonske simulacije, onda je ona obično nekoliko redova veličine, oko 1000-10000 puta sporija od izvršavanja na običnom računaru, bez simulacije. A implementacije na nivou logičkih elemenata su sporije za nekoliko redova veličine. Stoga se FPGA koristi kao emulator na ovom nivou, što može značajno povećati performanse.
Grafikon ispod prikazuje približnu ovisnost brzine simulacije od detalja modela.
Simulacija otkucaja po ritmu
Uprkos maloj brzini izvršavanja, mikroarhitektonski simulatori su prilično česti. Simulacija unutrašnjih blokova procesora je neophodna kako bi se precizno simuliralo vrijeme izvršenja svake instrukcije. Ovdje može doći do nesporazuma - na kraju krajeva, čini se, zašto jednostavno ne programirati vrijeme izvršenja za svaku instrukciju. Ali takav simulator će biti vrlo neprecizan, budući da se vrijeme izvršavanja iste instrukcije može razlikovati od poziva do poziva.
Najjednostavniji primjer je instrukcija pristupa memoriji. Ako je tražena memorijska lokacija dostupna u kešu, tada će vrijeme izvršenja biti minimalno. Ako ove informacije nisu u keš memoriji (“cache miss”), onda će to uvelike povećati vrijeme izvršenja instrukcije. Stoga je za preciznu simulaciju potreban keš model. Međutim, stvar nije ograničena na model keša. Procesor neće jednostavno čekati da se podaci dohvate iz memorije kada nisu u kešu. Umjesto toga, počet će izvršavati sljedeće instrukcije, birajući one koje ne ovise o rezultatu čitanja iz memorije. Ovo je takozvano “out of order” izvršenje (OOO, out of order execution), neophodno za minimiziranje vremena mirovanja procesora. Modeliranje odgovarajućih blokova procesora pomoći će da se sve ovo uzme u obzir prilikom izračunavanja vremena izvršenja instrukcija. Među ovim uputstvima, izvršenim dok se čeka rezultat čitanja iz memorije, može doći do operacije uvjetnog skoka. Ako je rezultat uvjeta u ovom trenutku nepoznat, onda opet procesor ne zaustavlja izvršenje, već „pogađa“, izvodi odgovarajuće grananje i nastavlja proaktivno izvršavati instrukcije od tačke tranzicije. Takav blok, nazvan prediktor grananja, takođe mora biti implementiran u mikroarhitektonskom simulatoru.
Slika ispod prikazuje glavne blokove procesora, nije ih potrebno poznavati, prikazana je samo da bi se prikazala složenost mikroarhitektonske implementacije.
Rad svih ovih blokova u stvarnom procesoru je sinhronizovan posebnim taktnim signalima, a isto se dešava i u modelu. Takav mikroarhitektonski simulator naziva se precizan ciklus. Njegova glavna svrha je precizno predvidjeti performanse procesora koji se razvija i/ili izračunati vrijeme izvršenja određenog programa, na primjer, benčmark. Ako su vrijednosti niže od potrebnih, tada će biti potrebno izmijeniti algoritme i blokove procesora ili optimizirati program.
Kao što je gore prikazano, simulacija sat po sat je veoma spora, pa se koristi samo kada se proučavaju određeni momenti rada programa, gde je potrebno saznati stvarnu brzinu izvršavanja programa i proceniti buduće performanse uređaja čiji prototip se simulira.
U ovom slučaju, funkcionalni simulator se koristi za simulaciju preostalog vremena rada programa. Kako se ova kombinacija upotrebe dešava u stvarnosti? Prvo se pokreće funkcionalni simulator na koji se učitava OS i sve što je potrebno za pokretanje proučavanog programa. Uostalom, ne zanima nas ni sam OS, niti početne faze pokretanja programa, njegova konfiguracija itd. Međutim, također ne možemo preskočiti ove dijelove i odmah preći na izvršavanje programa iz sredine. Stoga se svi ovi preliminarni koraci izvode na funkcionalnom simulatoru. Nakon što je program izveden do trenutka koji nas zanima, moguće su dvije opcije. Možete zamijeniti model sa modelom sat po ciklus i nastaviti s izvođenjem. Način simulacije koji koristi izvršni kod (tj. obične kompajlirane programske datoteke) naziva se simulacija vođena izvršenjem. Ovo je najčešća opcija simulacije. Moguć je i drugi pristup - simulacija vođena tragovima.
Simulacija zasnovana na tragovima
Sastoji se od dva koraka. Koristeći funkcionalni simulator ili na stvarnom sistemu, skuplja se dnevnik radnji programa i upisuje u datoteku. Ovaj dnevnik se zove trag. Ovisno o tome šta se ispituje, praćenje može uključivati izvršne instrukcije, memorijske adrese, brojeve portova i informacije o prekidu.
Sljedeći korak je „reprodukcija“ traga, kada simulator sat po sat čita trag i izvrši sve instrukcije zapisane u njemu. Na kraju dobijamo vreme izvršenja ovog dela programa, kao i različite karakteristike ovog procesa, na primer, procenat pogodaka u kešu.
Važna karakteristika rada sa tragovima je determinizam, odnosno pokretanjem simulacije na gore opisani način, iznova i iznova reprodukujemo isti slijed radnji. Ovo omogućava da se promjenom parametara modela (keš memorije, bafera i veličine reda čekanja) i korištenjem različitih internih algoritama ili njihovim podešavanjem prouči kako određeni parametar utiče na performanse sistema i koja opcija daje najbolje rezultate. Sve ovo se može uraditi sa modelom prototipa uređaja prije kreiranja stvarnog hardverskog prototipa.
Složenost ovog pristupa leži u potrebi da se prvo pokrene aplikacija i prikupi trag, kao i velika veličina datoteke praćenja. Prednosti uključuju činjenicu da je dovoljno simulirati samo dio uređaja ili platforme od interesa, dok simulacija izvođenjem obično zahtijeva kompletan model.
Dakle, u ovom članku smo pogledali karakteristike simulacije pune platforme, govorili o brzini implementacije na različitim nivoima, simulaciji sat po ciklus i tragovima. U sljedećem članku ću opisati glavne scenarije za korištenje simulatora, kako u lične svrhe, tako i sa razvojne tačke gledišta u velikim kompanijama.
izvor: www.habr.com