În a doua parte a articolului despre simulatoarele de sisteme informatice, voi continua să vorbesc într-o formă introductivă simplă despre simulatoarele computerizate, și anume despre simularea cu platformă completă, pe care o întâlnește cel mai des utilizatorul obișnuit, precum și despre trecerea ceasului. -model de ceas și urme, care sunt mai frecvente în cercurile dezvoltatorilor.
В Am vorbit despre ce sunt simulatoarele în general, precum și despre nivelurile de simulare. Acum, pe baza acestor cunoștințe, îmi propun să mă aprofundez puțin și să vorbim despre simularea pe platformă completă, cum să colectezi urme, ce să faci cu ele mai târziu, precum și despre emularea microarhitecturală ceas cu ceas.
Simulator complet de platformă sau „Singur pe câmp nu este un războinic”
Dacă doriți să studiați funcționarea unui anumit dispozitiv, de exemplu, o placă de rețea, sau să scrieți firmware sau un driver pentru acest dispozitiv, atunci un astfel de dispozitiv poate fi simulat separat. Cu toate acestea, utilizarea sa izolat de restul infrastructurii nu este foarte convenabilă. Pentru a rula driverul corespunzător, veți avea nevoie de un procesor central, memorie, acces la o magistrală de date etc. În plus, driverul necesită un sistem de operare (OS) și o stivă de rețea pentru a funcționa. În plus, poate fi necesar un generator de pachete și un server de răspuns separat.
Un simulator cu platformă completă creează un mediu pentru rularea unei stive complete de software, care include totul, de la BIOS și bootloader la sistemul de operare însuși și diferitele sale subsisteme, cum ar fi aceeași stivă de rețea, drivere și aplicații la nivel de utilizator. Pentru a face acest lucru, implementează modele software ale majorității dispozitivelor computerizate: procesor și memorie, disc, dispozitive de intrare/ieșire (tastatură, mouse, afișaj), precum și aceeași placă de rețea.
Mai jos este o diagramă bloc a chipset-ului x58 de la Intel. Un simulator de computer cu platformă completă pe acest chipset necesită implementarea majorității dispozitivelor enumerate, inclusiv a celor din interiorul IOH (Input/Output Hub) și ICH (Input/Output Controller Hub), care nu sunt descrise în detaliu în diagrama bloc . Deși, după cum arată practica, nu există multe dispozitive care să nu fie folosite de software-ul pe care îl vom rula. Nu este necesar să fie create modele de astfel de dispozitive.
Cel mai adesea, simulatoarele cu platformă completă sunt implementate la nivelul instrucțiunilor procesorului (ISA, vezi mai jos). ). Acest lucru vă permite să creați simulatorul în sine relativ rapid și ieftin. Nivelul ISA este de asemenea bun pentru că rămâne mai mult sau mai puțin constant, spre deosebire, de exemplu, de nivelul API/ABI, care se modifică mai des. În plus, implementarea la nivel de instrucțiuni vă permite să rulați așa-numitul software binar nemodificat, adică să rulați codul deja compilat fără nicio modificare, exact așa cum este folosit pe hardware real. Cu alte cuvinte, puteți face o copie („dump”) a hard diskului, o puteți specifica ca imagine pentru un model într-un simulator cu platformă completă și voila! – Sistemul de operare și alte programe sunt încărcate în simulator fără acțiuni suplimentare.
Performanța simulatorului
După cum am menționat mai sus, procesul de simulare a întregului sistem, adică a tuturor dispozitivelor sale, este o întreprindere destul de lentă. Dacă implementați toate acestea la un nivel foarte detaliat, de exemplu, microarhitectural sau logic, atunci execuția va deveni extrem de lentă. Dar nivelul de instrucțiuni este o alegere adecvată și permite sistemului de operare și programelor să se execute la viteze suficiente pentru ca utilizatorul să interacționeze confortabil cu ele.
Aici ar fi potrivit să abordăm subiectul performanței simulatorului. De obicei se măsoară în IPS (instrucțiuni pe secundă), mai exact în MIPS (milioane IPS), adică numărul de instrucțiuni de procesor executate de simulator într-o secundă. În același timp, viteza simulării depinde și de performanța sistemului pe care rulează simularea în sine. Prin urmare, ar putea fi mai corect să vorbim despre „încetinirea” simulatorului în comparație cu sistemul original.
Cele mai comune simulatoare cu platformă completă de pe piață, precum QEMU, VirtualBox sau VmWare Workstation, au performanțe bune. Este posibil să nu fie observat de utilizator că se lucrează în simulator. Acest lucru se întâmplă datorită capabilităților speciale de virtualizare implementate în procesoare, algoritmi de traducere binară și alte lucruri interesante. Acesta este tot un subiect pentru un articol separat, dar pe scurt, virtualizarea este o caracteristică hardware a procesoarelor moderne care permite simulatoarelor să nu simuleze instrucțiuni, ci să le trimită spre execuție direct la un procesor real, dacă, desigur, arhitecturile de simulatorul și procesorul sunt similare. Traducerea binară este traducerea codului mașinii oaspete în cod gazdă și execuția ulterioară pe un procesor real. Ca rezultat, simularea este doar puțin mai lentă, de 5-10 ori și adesea chiar rulează la aceeași viteză ca sistemul real. Deși acest lucru este influențat de mulți factori. De exemplu, dacă dorim să simulăm un sistem cu câteva zeci de procesoare, atunci viteza va scădea imediat de câteva zeci de ori. Pe de altă parte, simulatoarele precum Simics din cele mai recente versiuni acceptă hardware-ul gazdă multiprocesor și paralelizează efectiv nucleele simulate pe nucleele unui procesor real.
Dacă vorbim despre viteza simulării microarhitecturale, atunci aceasta este de obicei de câteva ordine de mărime, de aproximativ 1000-10000 de ori mai lentă decât execuția pe un computer obișnuit, fără simulare. Iar implementările la nivelul elementelor logice sunt mai lente cu câteva ordine de mărime. Prin urmare, un FPGA este folosit ca emulator la acest nivel, ceea ce poate crește semnificativ performanța.
Graficul de mai jos arată o dependență aproximativă a vitezei de simulare de detaliile modelului.
Simulare ritm cu ritm
În ciuda vitezei reduse de execuție, simulatoarele de microarhitectură sunt destul de comune. Simularea blocurilor interne ale procesorului este necesară pentru a simula cu exactitate timpul de execuție al fiecărei instrucțiuni. Aici pot apărea neînțelegeri - la urma urmei, s-ar părea, de ce să nu programați pur și simplu timpul de execuție pentru fiecare instrucțiune. Dar un astfel de simulator va fi foarte inexact, deoarece timpul de execuție al aceleiași instrucțiuni poate diferi de la apel la apel.
Cel mai simplu exemplu este o instrucțiune de acces la memorie. Dacă locația de memorie solicitată este disponibilă în cache, atunci timpul de execuție va fi minim. Dacă această informație nu se află în cache („cache miss”), atunci acest lucru va crește foarte mult timpul de execuție al instrucțiunii. Astfel, este necesar un model de cache pentru o simulare precisă. Cu toate acestea, problema nu se limitează la modelul de cache. Procesorul nu va aștepta pur și simplu ca datele să fie preluate din memorie atunci când nu se află în cache. În schimb, va începe să execute următoarele instrucțiuni, alegându-le pe cele care nu depind de rezultatul citirii din memorie. Aceasta este așa-numita execuție „în afara ordinii” (OOO, out of order execution), necesară pentru a minimiza timpul de inactivitate a procesorului. Modelarea blocurilor de procesor corespunzătoare va ajuta să luați în considerare toate acestea la calcularea timpului de execuție a instrucțiunilor. Printre aceste instrucțiuni, executate în timp ce rezultatul citirii din memorie este așteptat, poate apărea o operație de salt condiționat. Dacă rezultatul condiției este necunoscut în acest moment, atunci din nou procesorul nu oprește execuția, ci face o „ghicire”, efectuează ramura corespunzătoare și continuă să execute în mod proactiv instrucțiunile din punctul de tranziție. Un astfel de bloc, numit predictor de ramificație, trebuie implementat și în simulatorul de microarhitectură.
Imaginea de mai jos prezintă principalele blocuri ale procesorului, nu este necesar să-l cunoaștem, este arătată doar pentru a arăta complexitatea implementării microarhitecturale.
Funcționarea tuturor acestor blocuri într-un procesor real este sincronizată prin semnale speciale de ceas și același lucru se întâmplă și în model. Un astfel de simulator microarhitectural se numește exact ciclu. Scopul său principal este de a prezice cu precizie performanța procesorului în curs de dezvoltare și/sau de a calcula timpul de execuție al unui program specific, de exemplu, un benchmark. Dacă valorile sunt mai mici decât cele necesare, atunci va fi necesar să modificați algoritmii și blocurile procesorului sau să optimizați programul.
După cum se arată mai sus, simularea ceas cu ceas este foarte lentă, deci este utilizată numai atunci când se studiază anumite momente ale funcționării unui program, unde este necesar să se afle viteza reală de execuție a programului și să se evalueze performanța viitoare a dispozitivului a cărui prototipul este simulat.
În acest caz, un simulator funcțional este utilizat pentru a simula timpul de rulare rămas al programului. Cum se întâmplă această combinație de utilizare în realitate? În primul rând, este lansat simulatorul funcțional, pe care se încarcă sistemul de operare și tot ceea ce este necesar pentru a rula programul în studiu. La urma urmei, nu ne interesează sistemul de operare în sine, nici etapele inițiale de lansare a programului, configurarea acestuia etc. Cu toate acestea, nu putem sări peste aceste părți și trece imediat la executarea programului de la mijloc. Prin urmare, toți acești pași preliminari sunt rulați pe un simulator funcțional. După ce programul a fost executat până în momentul de interes pentru noi, sunt posibile două opțiuni. Puteți înlocui modelul cu un model ceas cu ciclu și puteți continua execuția. Modul de simulare care utilizează cod executabil (adică fișiere de program compilate obișnuite) se numește simulare condusă de execuție. Aceasta este cea mai comună opțiune de simulare. O altă abordare este, de asemenea, posibilă - simularea condusă de urme.
Simulare bazată pe urme
Constă din doi pași. Folosind un simulator funcțional sau pe un sistem real, un jurnal al acțiunilor programului este colectat și scris într-un fișier. Acest jurnal se numește urmă. În funcție de ceea ce este examinat, urmărirea poate include instrucțiuni executabile, adrese de memorie, numere de port și informații despre întrerupere.
Următorul pas este să „redați” urma, când simulatorul ceas cu ceas citește următorul și execută toate instrucțiunile scrise în ea. La sfârșit, obținem timpul de execuție al acestei părți a programului, precum și diverse caracteristici ale acestui proces, de exemplu, procentul de accesări din cache.
O caracteristică importantă a lucrului cu urme este determinismul, adică prin rularea simulării în modul descris mai sus, reproducem din nou și din nou aceeași secvență de acțiuni. Acest lucru face posibil, prin modificarea parametrilor modelului (cache, buffer și dimensiuni de coadă) și folosind diferiți algoritmi interni sau reglarea acestora, să se studieze modul în care un anumit parametru afectează performanța sistemului și care opțiune oferă cele mai bune rezultate. Toate acestea se pot face cu un model de dispozitiv prototip înainte de a crea un prototip hardware real.
Complexitatea acestei abordări constă în necesitatea de a rula mai întâi aplicația și de a colecta urmele, precum și dimensiunea uriașă a fișierului de urmărire. Avantajele includ faptul că este suficient să se simuleze doar o parte a dispozitivului sau a platformei de interes, în timp ce simularea prin execuție necesită de obicei un model complet.
Deci, în acest articol ne-am uitat la caracteristicile simulării cu platformă completă, am vorbit despre viteza implementărilor la diferite niveluri, simularea ceas cu ciclu și urme. În articolul următor voi descrie principalele scenarii de utilizare a simulatoarelor, atât în scop personal, cât și din punct de vedere al dezvoltării în marile companii.
Sursa: www.habr.com