U drugom dijelu članka o simulatorima računalnih sustava nastavit ću u jednostavnoj uvodnoj formi govoriti o računalnim simulatorima, odnosno o full-platform simulaciji s kojom se prosječni korisnik najčešće susreće, kao i o clock-by -model sata i tragovi, koji su češći u programerskim krugovima.
В Govorio sam o tome što su simulatori uopće, kao io razinama simulacije. Sada, na temelju tog znanja, predlažem da zaronimo malo dublje i razgovaramo o simulaciji pune platforme, kako prikupiti tragove, što s njima kasnije učiniti, kao i o mikroarhitektonskoj emulaciji sat po sat.
Simulator pune platforme ili "Sam na terenu nije ratnik"
Ako želite proučiti rad jednog određenog uređaja, na primjer mrežne kartice, ili napisati firmware ili upravljački program za ovaj uređaj, tada se takav uređaj može simulirati zasebno. Međutim, korištenje izolirano od ostatka infrastrukture nije baš zgodno. Za pokretanje odgovarajućeg upravljačkog programa trebat će vam središnji procesor, memorija, pristup podatkovnoj sabirnici itd. Osim toga, upravljački program zahtijeva operativni sustav (OS) i mrežni skup kako bi funkcionirao. Dodatno, može biti potreban poseban generator paketa i poslužitelj odgovora.
Simulator pune platforme stvara okruženje za pokretanje kompletnog softverskog skupa, koji uključuje sve od BIOS-a i pokretačkog programa do samog OS-a i njegovih različitih podsustava, kao što je isti mrežni skup, upravljački programi i aplikacije na korisničkoj razini. Da bi to učinio, implementira softverske modele većine računalnih uređaja: procesor i memoriju, disk, ulazno/izlazne uređaje (tipkovnicu, miš, zaslon), kao i istu mrežnu karticu.
Ispod je blok dijagram x58 čipseta iz Intela. Računalni 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, kao što pokazuje praksa, nema mnogo uređaja koje ne koristi softver koji ćemo pokrenuti. Modele takvih uređaja nije potrebno izrađivati.
Najčešće se simulatori pune platforme implementiraju na razini instrukcija procesora (ISA, vidi dolje). ). To vam omogućuje relativno brzo i jeftino stvaranje samog simulatora. ISA razina je također dobra jer ostaje više-manje konstantna, za razliku od npr. API/ABI razine koja se češće mijenja. Osim toga, implementacija na razini instrukcija omogućuje vam pokretanje takozvanog nemodificiranog binarnog softvera, odnosno pokretanje već kompajliranog koda bez ikakvih promjena, točno onako kako se koristi na stvarnom hardveru. Drugim riječima, možete napraviti kopiju ("dump") vašeg tvrdog diska, odrediti je kao sliku za model u simulatoru pune platforme i voila! – OS i drugi programi učitavaju se u simulator bez ikakvih dodatnih radnji.
Izvedba simulatora
Kao što je gore navedeno, proces simulacije cijelog sustava, odnosno svih njegovih uređaja, prilično je spor. Ako sve ovo također implementirate na vrlo detaljnoj razini, na primjer, mikroarhitektonskoj ili logičkoj, tada će izvođenje postati iznimno sporo. Ali razina instrukcija je prikladan izbor i omogućuje operacijskom sustavu i programima da se izvršavaju brzinama dovoljnim da korisnik s njima može ugodno komunicirati.
Ovdje bi bilo prikladno dotaknuti se teme performansi simulatora. Obično se mjeri u IPS (instructions per second), točnije u MIPS (millions IPS), odnosno broju procesorskih instrukcija koje simulator izvrši u jednoj sekundi. Istovremeno, brzina simulacije ovisi i o performansama sustava na kojem se sama simulacija izvodi. Stoga je možda ispravnije govoriti o "usporenju" simulatora u usporedbi s izvornim sustavom.
Najčešći simulatori pune platforme na tržištu, kao što su QEMU, VirtualBox ili VmWare Workstation, imaju dobre performanse. Korisniku možda neće biti ni vidljivo da se u simulatoru odvija rad. To se događa zahvaljujući posebnim mogućnostima virtualizacije implementiranim u procesore, algoritmima binarnog prevođenja i drugim zanimljivim stvarima. Sve je to tema za poseban članak, ali ukratko, virtualizacija je hardverska značajka modernih procesora koja omogućuje simulatorima da ne simuliraju instrukcije, već da ih pošalju na izvršenje izravno stvarnom procesoru, ako, naravno, arhitekture simulator i procesor su slični. Binarno prevođenje je prevođenje koda gostujućeg stroja u kod glavnog računala i naknadno izvođenje na stvarnom procesoru. Kao rezultat toga, simulacija je samo malo sporija, 5-10 puta, a često čak radi istom brzinom kao pravi sustav. Iako na to utječu mnogi čimbenici. Na primjer, ako želimo simulirati sustav s nekoliko desetaka procesora, tada će brzina odmah pasti za tih nekoliko desetaka puta. S druge strane, simulatori poput Simicsa u najnovijim verzijama podržavaju višeprocesorski glavni hardver i učinkovito 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 izvođenja na običnom računalu, bez simulacije. A implementacije na razini logičkih elemenata su sporije za nekoliko redova veličine. Stoga se FPGA koristi kao emulator na ovoj razini, što može značajno povećati performanse.
Donji grafikon prikazuje približnu ovisnost brzine simulacije o detaljima modela.
Beat-by-beat simulacija
Unatoč njihovoj maloj brzini izvođenja, mikroarhitektonski simulatori su prilično česti. Simulacija unutarnjih blokova procesora je neophodna kako bi se točno simuliralo vrijeme izvršenja svake instrukcije. Ovdje može doći do nesporazuma - nakon svega, čini se, zašto jednostavno ne programirati vrijeme izvršenja za svaku instrukciju. Ali takav simulator bit će vrlo neprecizan, budući da se vrijeme izvršenja iste instrukcije može razlikovati od poziva do poziva.
Najjednostavniji primjer je instrukcija pristupa memoriji. Ako je tražena memorijska lokacija dostupna u predmemoriji, tada će vrijeme izvršenja biti minimalno. Ako ove informacije nisu u predmemori ("promašaj predmemorije"), to će uvelike povećati vrijeme izvršenja instrukcije. Stoga je za točnu simulaciju potreban model predmemorije. Međutim, stvar nije ograničena na model cache memorije. Procesor neće jednostavno čekati da se podaci dohvate iz memorije kada nisu u predmemorij. Umjesto toga, počet će izvršavati sljedeće upute, odabirući one koje ne ovise o rezultatu čitanja iz memorije. Ovo je takozvano "izvršenje izvan reda" (OOO, izvanrednog izvršavanja), neophodno za minimiziranje vremena mirovanja procesora. Modeliranje odgovarajućih procesorskih blokova pomoći će da se sve to uzme u obzir pri izračunavanju vremena izvršenja instrukcija. Među tim uputama, koje se izvršavaju dok se čeka rezultat čitanja iz memorije, može se dogoditi operacija uvjetnog skoka. Ako je rezultat uvjeta trenutno nepoznat, tada opet procesor ne zaustavlja izvršenje, već "pogađa", izvodi odgovarajuće grananje i nastavlja proaktivno izvršavati instrukcije od točke prijelaza. Takav blok, nazvan prediktor grana, također mora biti implementiran u mikroarhitektonski simulator.
Slika ispod prikazuje glavne blokove procesora, nije potrebno znati, prikazana je samo da bi se prikazala složenost mikroarhitektonske implementacije.
Rad svih ovih blokova u pravom procesoru sinkroniziran je posebnim taktnim signalima, a isto se događa i u modelu. Takav mikroarhitektonski simulator naziva se ciklički točan. Njegova je glavna svrha točno predvidjeti performanse procesora koji se razvija i/ili izračunati vrijeme izvršenja određenog programa, na primjer, benchmark. Ako su vrijednosti niže od potrebnih, tada će biti potrebno modificirati algoritme i blokove procesora ili optimizirati program.
Kao što je prikazano gore, simulacija sat po sat je vrlo spora, pa se koristi samo kada se proučavaju određeni trenuci rada programa, gdje je potrebno saznati stvarnu brzinu izvršavanja programa i procijeniti buduću izvedbu uređaja čiji prototip se simulira.
U ovom slučaju, funkcionalni simulator se koristi za simulaciju preostalog vremena rada programa. Kako se ova kombinacija korištenja događa u stvarnosti? Prvo se pokreće funkcionalni simulator na koji se učitava OS i sve što je potrebno za pokretanje programa koji se proučava. Uostalom, ne zanima nas sam OS, niti početne faze pokretanja programa, njegova konfiguracija itd. Međutim, također ne možemo preskočiti ove dijelove i odmah prijeći na izvršavanje programa od 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. Model možete zamijeniti modelom sat po ciklus i nastaviti s izvođenjem. Način simulacije koji koristi izvršni kod (to jest, regularne kompilirane programske datoteke) naziva se simulacija vođena izvršenjem. Ovo je najčešća opcija simulacije. Moguć je i drugi pristup - simulacija vođena tragom.
Simulacija temeljena na tragovima
Sastoji se od dva koraka. Korištenjem funkcionalnog simulatora ili na stvarnom sustavu, zapisnik radnji programa prikuplja se i zapisuje u datoteku. Ovaj dnevnik se naziva trag. Ovisno o tome što se ispituje, praćenje može uključivati izvršne instrukcije, memorijske adrese, brojeve priključaka i informacije o prekidu.
Sljedeći korak je "igranje" praćenja, kada simulator sat po sat čita praćenje i izvršava sve upute zapisane u njemu. Na kraju dobijemo vrijeme izvršavanja ovog dijela programa, kao i razne karakteristike ovog procesa, na primjer, postotak pogodaka u cacheu.
Važna značajka rada s tragovima je determinizam, odnosno pokretanjem simulacije na gore opisani način uvijek iznova reproduciramo isti slijed radnji. To omogućuje, promjenom parametara modela (veličine predmemorije, međuspremnika i reda čekanja) i korištenjem različitih internih algoritama ili njihovim podešavanjem, proučavanje kako određeni parametar utječe na performanse sustava i koja opcija daje najbolje rezultate. Sve se to može učiniti s prototipom modela uređaja prije stvaranja stvarnog hardverskog prototipa.
Složenost ovog pristupa leži u potrebi da se prvo pokrene aplikacija i prikupi trag, kao i golema veličina datoteke praćenja. Prednosti uključuju činjenicu da je dovoljno simulirati samo dio uređaja ili platforme od interesa, dok simulacija po izvedbi obično zahtijeva kompletan model.
Stoga smo u ovom članku pogledali značajke simulacije pune platforme, govorili o brzini implementacija na različitim razinama, simulaciji sat po ciklus i tragovima. U sljedećem članku opisat ću glavne scenarije za korištenje simulatora, kako za osobne potrebe tako i sa stajališta razvoja u velikim tvrtkama.
Izvor: www.habr.com
