A la segona part de l'article sobre simuladors de sistemes informàtics, continuaré parlant d'una forma introductòria senzilla sobre simuladors d'ordinador, és a dir, sobre la simulació de plataforma completa, amb la qual es troba més sovint l'usuari mitjà, així com sobre el pas del rellotge. -model de rellotge i traces, que són més comuns als cercles de desenvolupadors.
В Vaig parlar de què són els simuladors en general, així com dels nivells de simulació. Ara, a partir d'aquests coneixements, proposo aprofundir una mica més i parlar de la simulació de plataforma completa, de com recollir rastres, què fer-ne després, així com de l'emulació microarquitectònica rellotge a rellotge.
Simulador de plataforma completa, o "Sol al camp no és un guerrer"
Si voleu estudiar el funcionament d'un dispositiu específic, per exemple, una targeta de xarxa, o escriure firmware o un controlador per a aquest dispositiu, aquest dispositiu es pot simular per separat. Tanmateix, utilitzar-lo de manera aïllada de la resta de la infraestructura no és gaire convenient. Per executar el controlador corresponent, necessitareu un processador central, memòria, accés a un bus de dades, etc. A més, el controlador requereix un sistema operatiu (SO) i una pila de xarxa per funcionar. A més, pot ser necessari un generador de paquets i un servidor de resposta separats.
Un simulador de plataforma completa crea un entorn per executar una pila de programari completa, que inclou des de la BIOS i el carregador d'arrencada fins al propi sistema operatiu i els seus diferents subsistemes, com ara la mateixa pila de xarxa, controladors i aplicacions a nivell d'usuari. Per fer-ho, implementa models de programari de la majoria de dispositius informàtics: processador i memòria, disc, dispositius d'entrada/sortida (teclat, ratolí, pantalla), així com la mateixa targeta de xarxa.
A continuació es mostra un diagrama de blocs del chipset x58 d'Intel. Un simulador informàtic de plataforma completa en aquest conjunt de xips requereix la implementació de la majoria dels dispositius enumerats, inclosos els de l'IOH (Input/Output Hub) i ICH (Input/Output Controller Hub), que no es mostren amb detall al diagrama de blocs. . Encara que, com demostra la pràctica, no hi ha molts dispositius que no siguin utilitzats pel programari que anem a executar. No cal crear models d'aquests dispositius.
Molt sovint, els simuladors de plataforma completa s'implementen al nivell d'instrucció del processador (ISA, vegeu més avall). ). Això us permet crear el propi simulador de manera relativament ràpida i econòmica. El nivell ISA també és bo perquè es manté més o menys constant, a diferència, per exemple, del nivell API/ABI, que canvia més sovint. A més, la implementació a nivell d'instruccions permet executar l'anomenat programari binari no modificat, és a dir, executar codi ja compilat sense cap canvi, exactament com s'utilitza en el maquinari real. En altres paraules, podeu fer una còpia ("bocament") del vostre disc dur, especificar-lo com a imatge per a un model en un simulador de plataforma completa i voilà! – El sistema operatiu i altres programes es carreguen al simulador sense cap acció addicional.
Rendiment del simulador
Com s'ha esmentat abans, el procés de simulació de tot el sistema, és a dir, tots els seus dispositius, és una empresa força lenta. Si també implementeu tot això a un nivell molt detallat, per exemple, microarquitectònic o lògic, l'execució serà extremadament lenta. Però el nivell d'instrucció és una opció adequada i permet que el sistema operatiu i els programes s'executin a velocitats suficients perquè l'usuari pugui interactuar amb ells còmodament.
Aquí seria apropiat tocar el tema del rendiment del simulador. Normalment es mesura en IPS (instruccions per segon), més precisament en MIPS (milions d'IPS), és a dir, el nombre d'instruccions del processador executades pel simulador en un segon. Al mateix temps, la velocitat de la simulació també depèn del rendiment del sistema sobre el qual s'executa la simulació. Per tant, pot ser més correcte parlar de la "alentiment" del simulador en comparació amb el sistema original.
Els simuladors de plataforma completa més comuns del mercat, com ara QEMU, VirtualBox o VmWare Workstation, tenen un bon rendiment. Pot ser que ni tan sols se noti per a l'usuari que s'està treballant al simulador. Això passa gràcies a les capacitats especials de virtualització implementades en processadors, algorismes de traducció binària i altres coses interessants. Tot això és un tema per a un article separat, però en resum, la virtualització és una característica de maquinari dels processadors moderns que permet als simuladors no simular instruccions, sinó enviar-les per a l'execució directament a un processador real, si, per descomptat, les arquitectures de el simulador i el processador són semblants. La traducció binària és la traducció del codi màquina convidada en codi amfitrió i la posterior execució en un processador real. Com a resultat, la simulació és només una mica més lenta, de 5 a 10 vegades, i sovint fins i tot funciona a la mateixa velocitat que el sistema real. Encara que això està influenciat per molts factors. Per exemple, si volem simular un sistema amb diverses dotzenes de processadors, la velocitat baixarà immediatament en aquestes diverses dotzenes de vegades. D'altra banda, els simuladors com Simics en les últimes versions admeten el maquinari host multiprocessador i paral·lelitzen eficaçment els nuclis simulats als nuclis d'un processador real.
Si parlem de la velocitat de la simulació microarquitectònica, aleshores sol ser de diversos ordres de magnitud, unes 1000-10000 vegades més lenta que l'execució en un ordinador normal, sense simulació. I les implementacions a nivell d'elements lògics són més lentes en diversos ordres de magnitud. Per tant, s'utilitza un FPGA com a emulador en aquest nivell, que pot augmentar significativament el rendiment.
El gràfic següent mostra una dependència aproximada de la velocitat de simulació del detall del model.
Simulació ritme a ritme
Malgrat la seva baixa velocitat d'execució, els simuladors de microarquitectura són força habituals. La simulació dels blocs interns del processador és necessària per simular amb precisió el temps d'execució de cada instrucció. Aquí pot sorgir un malentès; després de tot, sembla, per què no programar simplement el temps d'execució de cada instrucció. Però aquest simulador serà molt imprecís, ja que el temps d'execució de la mateixa instrucció pot diferir d'una trucada a una altra.
L'exemple més senzill és una instrucció d'accés a la memòria. Si la ubicació de memòria sol·licitada està disponible a la memòria cau, el temps d'execució serà mínim. Si aquesta informació no es troba a la memòria cau ("cache miss"), això augmentarà molt el temps d'execució de la instrucció. Per tant, es requereix un model de memòria cau per a una simulació precisa. Tanmateix, la qüestió no es limita al model de memòria cau. El processador no només esperarà que les dades es recuperin de la memòria quan no estiguin a la memòria cau. En canvi, començarà a executar les instruccions següents, escollint aquelles que no depenguin del resultat de la lectura de la memòria. Aquesta és l'anomenada execució "fora d'ordre" (OOO, out of order execution), necessària per minimitzar el temps d'inactivitat del processador. La modelització dels blocs processadors corresponents ajudarà a tenir-ho en compte a l'hora de calcular el temps d'execució de les instruccions. Entre aquestes instruccions, executades mentre s'espera el resultat de la lectura de la memòria, es pot produir una operació de salt condicional. Si el resultat de la condició es desconeix en aquest moment, de nou el processador no atura l'execució, sinó que fa una "endevinació", realitza la branca adequada i continua executant les instruccions de manera proactiva des del punt de transició. Aquest bloc, anomenat predictor de branques, també s'ha d'implementar al simulador de microarquitectura.
La imatge següent mostra els blocs principals del processador, no cal conèixer-lo, només es mostra per mostrar la complexitat de la implementació microarquitectònica.
El funcionament de tots aquests blocs en un processador real està sincronitzat per senyals de rellotge especials, i el mateix passa en el model. Aquest simulador de microarquitectura s'anomena cicle precís. El seu objectiu principal és predir amb precisió el rendiment del processador que s'està desenvolupant i/o calcular el temps d'execució d'un programa específic, per exemple, un punt de referència. Si els valors són inferiors als requerits, caldrà modificar els algorismes i els blocs del processador o optimitzar el programa.
Com es mostra anteriorment, la simulació rellotge a rellotge és molt lenta, de manera que només s'utilitza quan s'estudien determinats moments del funcionament d'un programa, on cal esbrinar la velocitat real d'execució del programa i avaluar el rendiment futur del dispositiu del qual s'està simulant el prototip.
En aquest cas, s'utilitza un simulador funcional per simular el temps d'execució restant del programa. Com es produeix aquesta combinació d'ús en la realitat? En primer lloc, es posa en marxa el simulador funcional, on es carrega el SO i tot el necessari per executar el programa en estudi. Al cap i a la fi, no ens interessa el propi sistema operatiu, ni les etapes inicials de llançament del programa, la seva configuració, etc. Tanmateix, tampoc no podem saltar aquestes parts i passar immediatament a executar el programa des del centre. Per tant, tots aquests passos preliminars s'executen en un simulador funcional. Després d'executar el programa fins al moment que ens interessa, hi ha dues opcions possibles. Podeu substituir el model per un model rellotge per cicle i continuar amb l'execució. El mode de simulació que utilitza codi executable (és a dir, fitxers de programa compilats regulars) s'anomena simulació impulsada per l'execució. Aquesta és l'opció de simulació més comuna. També és possible un altre enfocament: simulació impulsada per traça.
Simulació basada en traça
Consta de dos passos. Mitjançant un simulador funcional o en un sistema real, es recull un registre d'accions del programa i s'escriu en un fitxer. Aquest registre s'anomena rastre. Depenent del que s'està examinant, el rastre pot incloure instruccions executables, adreces de memòria, números de port i informació d'interrupció.
El següent pas és "reproduir" el rastre, quan el simulador rellotge rellotge llegeix el rastre i executa totes les instruccions escrites en ell. Al final, obtenim el temps d'execució d'aquesta peça del programa, així com diverses característiques d'aquest procés, per exemple, el percentatge de visites a la memòria cau.
Una característica important de treballar amb traces és el determinisme, és a dir, executant la simulació de la manera descrita anteriorment, reproduïm una i altra vegada la mateixa seqüència d'accions. Això fa possible, canviant els paràmetres del model (mida de la memòria cau, del buffer i de la cua) i utilitzant diferents algorismes interns o ajustant-los, estudiar com afecta un paràmetre concret al rendiment del sistema i quina opció dóna els millors resultats. Tot això es pot fer amb un model de dispositiu prototip abans de crear un prototip de maquinari real.
La complexitat d'aquest enfocament rau en la necessitat d'executar primer l'aplicació i recollir la traça, així com la gran mida del fitxer de traça. Els avantatges inclouen el fet que n'hi ha prou amb simular només la part del dispositiu o plataforma d'interès, mentre que la simulació per execució sol requerir un model complet.
Així doncs, en aquest article hem analitzat les característiques de la simulació de plataforma completa, hem parlat de la velocitat de les implementacions a diferents nivells, la simulació rellotge per cicle i les traces. En el següent article descriuré els principals escenaris d'ús de simuladors, tant per a finalitats personals com des del punt de vista del desenvolupament a les grans empreses.
Font: www.habr.com