Na segunda parte do artigo sobre simuladores de sistemas informáticos, seguirei falando dunha forma sinxela de introdución sobre simuladores informáticos, é dicir, sobre a simulación de plataforma completa, coa que se atopa o usuario medio con máis frecuencia, así como sobre o paso do reloxo. -modelo de reloxo e trazos, que son máis comúns nos círculos de desenvolvedores.
В Falei sobre o que son os simuladores en xeral, así como sobre os niveis de simulación. Agora, partindo dese coñecemento, propoño afondar un pouco máis e falar sobre a simulación de plataforma completa, como recoller trazos, que facer con elas despois, así como sobre a emulación microarquitectónica reloxo a reloxo.
Simulador de plataforma completa ou "Só no campo non é un guerreiro"
Se desexa estudar o funcionamento dun dispositivo específico, por exemplo, unha tarxeta de rede, ou escribir firmware ou controlador para este dispositivo, pódese simular este dispositivo por separado. Non obstante, usalo illado do resto da infraestrutura non é moi cómodo. Para executar o controlador correspondente, necesitará un procesador central, memoria, acceso a un bus de datos, etc. Ademais, o controlador require un sistema operativo (SO) e unha pila de rede para funcionar. Ademais, pode ser necesario un xerador de paquetes e un servidor de resposta separados.
Un simulador de plataforma completa crea un ambiente para executar unha pila de software completa, que inclúe desde a BIOS e o cargador de arranque ata o propio sistema operativo e os seus diversos subsistemas, como a mesma pila de rede, controladores e aplicacións de nivel de usuario. Para iso, implementa modelos de software da maioría dos dispositivos informáticos: procesador e memoria, disco, dispositivos de entrada/saída (teclado, rato, pantalla), así como a mesma tarxeta de rede.
A continuación móstrase un diagrama de bloques do chipset x58 de Intel. Un simulador informático de plataforma completa neste chipset require a implementación da maioría dos dispositivos listados, incluídos os que están dentro do IOH (Input/Output Hub) e ICH (Input/Output Controller Hub), que non se describen en detalle no diagrama de bloques. . Aínda que, como mostra a práctica, non hai moitos dispositivos que non sexan utilizados polo software que imos executar. Non é necesario crear modelos deste tipo de dispositivos.
Na maioría das veces, os simuladores de plataforma completa impléntanse a nivel de instrución do procesador (ISA, vexa a continuación). ). Isto permítelle crear o propio simulador de xeito relativamente rápido e económico. O nivel ISA tamén é bo porque se mantén máis ou menos constante, a diferenza, por exemplo, do nivel API/ABI, que cambia con máis frecuencia. Ademais, a implementación a nivel de instrucións permítelle executar o chamado software binario non modificado, é dicir, executar código xa compilado sen ningún cambio, exactamente como se usa no hardware real. Noutras palabras, podes facer unha copia ("vorcado") do teu disco duro, especificalo como imaxe para un modelo nun simulador de plataforma completa e listo! – O SO e outros programas cárganse no simulador sen ningunha acción adicional.
Rendemento do simulador
Como xa se mencionou anteriormente, o proceso de simulación de todo o sistema, é dicir, todos os seus dispositivos, é unha empresa bastante lenta. Se tamén implementas todo isto nun nivel moi detallado, por exemplo, microarquitectónico ou lóxico, a execución será extremadamente lenta. Pero o nivel de instrución é a opción axeitada e permite que o sistema operativo e os programas se executen a velocidades suficientes para que o usuario interactúe con eles comodamente.
Aquí sería apropiado tocar o tema do rendemento do simulador. Normalmente mídese en IPS (instrucións por segundo), máis precisamente en MIPS (millóns de IPS), é dicir, o número de instrucións do procesador que executa o simulador nun segundo. Ao mesmo tempo, a velocidade da simulación tamén depende do rendemento do sistema no que se executa a propia simulación. Polo tanto, pode ser máis correcto falar da "desaceleración" do simulador en comparación co sistema orixinal.
Os simuladores de plataforma completa máis comúns do mercado, como QEMU, VirtualBox ou VmWare Workstation, teñen un bo rendemento. Pode nin sequera ser perceptible para o usuario que se está a traballar no simulador. Isto ocorre grazas ás capacidades especiais de virtualización implementadas nos procesadores, algoritmos de tradución binaria e outras cousas interesantes. Todo isto é un tema para un artigo separado, pero en resumo, a virtualización é unha característica de hardware dos procesadores modernos que permite aos simuladores non simular instrucións, senón envialas para a súa execución directamente a un procesador real, se, por suposto, as arquitecturas de o simulador e o procesador son similares. A tradución binaria é a tradución do código da máquina convidada a un código host e a súa posterior execución nun procesador real. Como resultado, a simulación é só lixeiramente máis lenta, 5-10 veces, e moitas veces ata corre á mesma velocidade que o sistema real. Aínda que isto está influenciado por moitos factores. Por exemplo, se queremos simular un sistema con varias ducias de procesadores, entón a velocidade baixará inmediatamente nestas varias ducias de veces. Por outra banda, simuladores como Simics nas últimas versións admiten hardware host multiprocesador e paralelizan eficazmente os núcleos simulados cos núcleos dun procesador real.
Se falamos da velocidade da simulación microarquitectónica, entón adoita ser varias ordes de magnitude, unhas 1000-10000 veces máis lenta que a execución nun ordenador normal, sen simulación. E as implementacións a nivel de elementos lóxicos son máis lentas en varias ordes de magnitude. Polo tanto, úsase un FPGA como emulador a este nivel, o que pode aumentar significativamente o rendemento.
O seguinte gráfico mostra unha dependencia aproximada da velocidade de simulación do detalle do modelo.
Simulación ritmo a ritmo
A pesar da súa baixa velocidade de execución, os simuladores de microarquitectura son bastante comúns. A simulación dos bloques internos do procesador é necesaria para simular con precisión o tempo de execución de cada instrución. Aquí pode xurdir un malentendido; despois de todo, ao parecer, por que non simplemente programar o tempo de execución de cada instrución. Pero tal simulador será moi impreciso, xa que o tempo de execución da mesma instrución pode diferir dunha chamada a outra.
O exemplo máis sinxelo é unha instrución de acceso á memoria. Se a localización de memoria solicitada está dispoñible na caché, entón o tempo de execución será mínimo. Se esta información non está na caché ("cache miss"), isto aumentará moito o tempo de execución da instrución. Polo tanto, é necesario un modelo de caché para unha simulación precisa. Non obstante, o asunto non se limita ao modelo de caché. O procesador non agardará simplemente a que os datos sexan recuperados da memoria cando non estean na caché. Pola contra, comezará a executar as seguintes instrucións, escollendo aquelas que non dependen do resultado da lectura da memoria. Esta é a chamada execución "fora de orde" (OOO, out of order execution), necesaria para minimizar o tempo de inactividade do procesador. A modelización dos bloques de procesadores correspondentes axudará a ter todo isto en conta á hora de calcular o tempo de execución das instrucións. Entre estas instrucións, executadas mentres se agarda o resultado da lectura da memoria, pode producirse unha operación de salto condicional. Se o resultado da condición é descoñecido polo momento, entón de novo o procesador non detén a execución, senón que fai unha "suposición", realiza a rama adecuada e continúa executando as instrucións de forma proactiva desde o punto de transición. Un bloque deste tipo, chamado predictor de ramas, tamén debe implementarse no simulador de microarquitectura.
A imaxe de abaixo mostra os principais bloques do procesador, non é necesario coñecelo, móstrase só para mostrar a complexidade da implementación microarquitectónica.
O funcionamento de todos estes bloques nun procesador real está sincronizado por sinais de reloxo especiais, e o mesmo ocorre no modelo. Tal simulador microarquitectónico chámase ciclo preciso. A súa finalidade principal é predicir con precisión o rendemento do procesador que se está a desenvolver e/ou calcular o tempo de execución dun programa específico, por exemplo, un benchmark. Se os valores son inferiores aos necesarios, entón será necesario modificar os algoritmos e os bloques do procesador ou optimizar o programa.
Como se mostra anteriormente, a simulación reloxo a reloxo é moi lenta, polo que só se usa cando se estudan determinados momentos do funcionamento dun programa, onde é necesario coñecer a velocidade real de execución do programa e avaliar o rendemento futuro do dispositivo cuxo está a ser simulado o prototipo.
Neste caso, utilízase un simulador funcional para simular o tempo de execución restante do programa. Como ocorre esta combinación de usos na realidade? En primeiro lugar, lánzase o simulador funcional, no que se carga o SO e todo o necesario para executar o programa en estudo. Despois de todo, non nos interesa o propio SO, nin as fases iniciais do lanzamento do programa, a súa configuración, etc. Non obstante, tampouco podemos saltar estas partes e pasar inmediatamente a executar o programa desde o medio. Polo tanto, todos estes pasos preliminares execútanse nun simulador funcional. Despois de executar o programa ata o momento do noso interese, son posibles dúas opcións. Pode substituír o modelo por un modelo reloxo por ciclo e continuar coa execución. O modo de simulación que usa código executable (é dicir, ficheiros de programas compilados habituais) chámase simulación dirixida á execución. Esta é a opción de simulación máis común. Tamén é posible outro enfoque: simulación guiada por trazos.
Simulación baseada en trazas
Consta de dous pasos. Usando un simulador funcional ou nun sistema real, recóllese un rexistro de accións do programa e escríbese nun ficheiro. Este rexistro chámase rastro. Segundo o que se estea examinando, o rastrexo pode incluír instrucións executables, enderezos de memoria, números de porto e información de interrupción.
O seguinte paso é "reproducir" o trazo, cando o simulador reloxo a reloxo le o trazo e executa todas as instrucións escritas nel. Ao final, obtemos o tempo de execución desta peza do programa, así como varias características deste proceso, por exemplo, a porcentaxe de acertos na caché.
Unha característica importante de traballar con trazos é o determinismo, é dicir, executando a simulación do xeito descrito anteriormente, reproducimos unha e outra vez a mesma secuencia de accións. Isto fai posible, modificando os parámetros do modelo (tamaños de caché, búfer e fila) e utilizando diferentes algoritmos internos ou axustándoos, estudar como afecta un determinado parámetro ao rendemento do sistema e que opción dá os mellores resultados. Todo isto pódese facer cun modelo de dispositivo prototipo antes de crear un prototipo de hardware real.
A complexidade deste enfoque reside na necesidade de executar primeiro a aplicación e recoller o rastrexo, así como o enorme tamaño do ficheiro de rastrexo. As vantaxes inclúen o feito de que abonda con simular só a parte do dispositivo ou plataforma de interese, mentres que a simulación por execución normalmente require un modelo completo.
Entón, neste artigo analizamos as características da simulación de plataforma completa, falamos da velocidade das implementacións en diferentes niveis, da simulación reloxo por ciclo e das trazas. No seguinte artigo describirei os principais escenarios de uso de simuladores, tanto para fins persoais como dende o punto de vista do desenvolvemento nas grandes empresas.
Fonte: www.habr.com