Симулатори рачунарских система: познати симулатор пуне платформе и непознати у смеру казаљке на сату и трагови

У другом делу чланка о симулаторима рачунарских система, наставићу у једноставном уводном облику да говорим о рачунарским симулаторима, односно о симулацији пуне платформе, са којом се просечни корисник најчешће сусреће, као и о цлоцк-би -модел сата и трагови, који су чешћи у круговима програмера.

В први део Говорио сам о томе шта су симулатори уопште, као и о нивоима симулације. Сада, на основу тог сазнања, предлажем да зароним мало дубље и причамо о симулацији пуне платформе, како прикупити трагове, шта са њима касније радити, као и о микроархитектонској емулацији сат по сат.

Симулатор пуне платформе, или "Сам у пољу није ратник"

Ако желите да проучите рад једног одређеног уређаја, на пример, мрежне картице, или да напишете фирмвер или драјвер за овај уређај, онда се такав уређај може симулирати засебно. Међутим, његово коришћење изоловано од остатка инфраструктуре није баш згодно. Да бисте покренули одговарајући драјвер, биће вам потребан централни процесор, меморија, приступ магистрали података итд. Поред тога, драјвер захтева оперативни систем (ОС) и мрежни стек да би функционисао. Поред тога, може бити потребан посебан генератор пакета и сервер одговора.

Симулатор пуне платформе ствара окружење за покретање комплетног софтверског стека, који укључује све од БИОС-а и покретача до самог ОС-а и његових различитих подсистема, као што су исти мрежни стек, драјвери и апликације на нивоу корисника. Да би то урадио, имплементира софтверске моделе већине рачунарских уређаја: процесор и меморију, диск, улазно/излазне уређаје (тастатура, миш, екран), као и исту мрежну картицу.

Испод је блок дијаграм к58 чипсета компаније Интел. Рачунарски симулатор пуне платформе на овом чипсету захтева имплементацију већине наведених уређаја, укључујући оне унутар ИОХ (Инпут/Оутпут Хуб) и ИЦХ (Инпут/Оутпут Цонтроллер Хуб), који нису детаљно приказани на блок дијаграму . Иако, како пракса показује, нема много уређаја које не користи софтвер који ћемо покренути. Моделе таквих уређаја није потребно креирати.

Најчешће се симулатори пуне платформе имплементирају на нивоу инструкција процесора (ИСА, види доле). претходни чланак). Ово вам омогућава да креирате сам симулатор релативно брзо и јефтино. ИСА ниво је такође добар јер остаје мање-више константан, за разлику од, на пример, АПИ/АБИ нивоа који се чешће мења. Поред тога, имплементација на нивоу инструкција вам омогућава да покренете такозвани неизмењени бинарни софтвер, односно да покренете већ компајлирани код без икаквих промена, тачно онако како се користи на стварном хардверу. Другим речима, можете направити копију („думп“) свог чврстог диска, навести га као слику за модел у симулатору са пуном платформом, и воила! – ОС и други програми се учитавају у симулатору без икаквих додатних радњи.

Перформансе симулатора

Као што је већ поменуто, процес симулације целог система, односно свих његових уређаја, је прилично спор подухват. Ако све ово имплементирате на веома детаљном нивоу, на пример, микроархитектонском или логичком, онда ће извршење постати изузетно споро. Али ниво инструкција је одговарајући избор и омогућава оперативном систему и програмима да се извршавају брзином која је довољна да корисник може да комуницира са њима.

Овде би било прикладно да се дотакнемо теме перформанси симулатора. Обично се мери у ИПС (инструкције у секунди), тачније у МИПС (милиони ИПС), односно у броју процесорских инструкција које извршава симулатор у једној секунди. Истовремено, брзина симулације зависи и од перформанси система на коме се сама симулација ради. Стога је можда исправније говорити о „успоравању“ симулатора у поређењу са оригиналним системом.

Најчешћи симулатори пуне платформе на тржишту, као што су КЕМУ, ВиртуалБок или ВмВаре Воркстатион, имају добре перформансе. Кориснику можда неће ни бити приметно да се у симулатору ради. Ово се дешава захваљујући специјалним могућностима виртуелизације имплементираних у процесорима, алгоритмима бинарног превођења и другим занимљивим стварима. Ово је све тема за посебан чланак, али укратко, виртуелизација је хардверска карактеристика савремених процесора која омогућава симулаторима да не симулирају инструкције, већ да их пошаљу на извршење директно стварном процесору, ако су, наравно, архитектуре симулатор и процесор су слични. Бинарно превођење је превођење гостујућег машинског кода у хост код и накнадно извршење на стварном процесору. Као резултат тога, симулација је само мало спорија, 5-10 пута, а често чак и ради истом брзином као прави систем. Иако на то утичу многи фактори. На пример, ако желимо да симулирамо систем са неколико десетина процесора, онда ће брзина одмах пасти за ових неколико десетина пута. С друге стране, симулатори као што је Симицс у најновијим верзијама подржавају вишепроцесорски хардвер и ефикасно паралелизују симулирана језгра на језгра правог процесора.

Ако говоримо о брзини микроархитектонске симулације, онда је она обично неколико редова величине, око 1000-10000 пута спорија од извршавања на обичном рачунару, без симулације. А имплементације на нивоу логичких елемената су спорије за неколико редова величине. Због тога се ФПГА користи као емулатор на овом нивоу, што може значајно повећати перформансе.

Графикон испод приказује приближну зависност брзине симулације од детаља модела.

Симулација ударца по ритму

Упркос малој брзини извршавања, микроархитектонски симулатори су прилично чести. Симулација унутрашњих блокова процесора је неопходна да би се тачно симулирало време извршења сваке инструкције. Овде може доћи до неспоразума - на крају крајева, чини се, зашто једноставно не програмирати време извршења за сваку инструкцију. Али такав симулатор ће бити веома нетачан, јер се време извршавања исте инструкције може разликовати од позива до позива.

Најједноставнији пример је инструкција за приступ меморији. Ако је тражена меморијска локација доступна у кешу, онда ће време извршења бити минимално. Ако ове информације нису у кешу („промашај кеша“), то ће у великој мери повећати време извршења инструкције. Дакле, за тачну симулацију потребан је кеш модел. Међутим, ствар није ограничена на модел кеша. Процесор неће једноставно чекати да се подаци преузму из меморије када нису у кешу. Уместо тога, он ће почети да извршава следеће инструкције, бирајући оне које не зависе од резултата читања из меморије. Ово је такозвано „оут оф ордер“ извршење (ООО, оут оф ордер екецутион), неопходно да се минимизира време мировања процесора. Моделирање одговарајућих блокова процесора ће помоћи да се све ово узме у обзир приликом израчунавања времена извршења инструкција. Међу овим упутствима, извршеним док се чека резултат читања из меморије, може доћи до операције условног скока. Ако је резултат услова тренутно непознат, онда опет процесор не зауставља извршење, већ „погађа“, врши одговарајућу грану и наставља да проактивно извршава инструкције од тачке транзиције. Такав блок, назван предиктор гранања, такође мора бити имплементиран у микроархитектонском симулатору.

На слици испод су приказани главни блокови процесора, није неопходно да се зна, приказана је само да би се приказала сложеност микроархитектонске имплементације.

Рад свих ових блокова у стварном процесору је синхронизован посебним тактним сигналима, а исто се дешава и у моделу. Такав микроархитектонски симулатор назива се прецизан циклус. Његова главна сврха је да тачно предвиди перформансе процесора који се развија и/или израчуна време извршења одређеног програма, на пример, бенчмарк. Ако су вредности ниже од захтеваних, биће потребно изменити алгоритме и блокове процесора или оптимизовати програм.

Као што је горе приказано, симулација сат по сат је веома спора, па се користи само када се проучавају одређени моменти рада програма, где је потребно сазнати стварну брзину извршавања програма и проценити будуће перформансе уређаја чији прототип се симулира.

У овом случају, функционални симулатор се користи за симулацију преосталог времена рада програма. Како се ова комбинација употребе дешава у стварности? Прво се покреће функционални симулатор на који се учитава ОС и све што је потребно за покретање проучаваног програма. На крају крајева, не занима нас ни сам ОС, нити почетне фазе покретања програма, његова конфигурација итд. Међутим, такође не можемо прескочити ове делове и одмах прећи на извршавање програма из средине. Стога се сви ови прелиминарни кораци изводе на функционалном симулатору. Након што је програм изведен до тренутка који нас занима, могуће су две опције. Можете заменити модел са моделом по циклусу и наставити са извршењем. Режим симулације који користи извршни код (то јест, обичне компајлиране програмске датотеке) назива се симулација вођена извршењем. Ово је најчешћа опција симулације. Могућ је и други приступ - симулација вођена трагом.

Симулација заснована на траговима

Састоји се од два корака. Користећи функционални симулатор или на реалном систему, прикупља се дневник радњи програма и уписује у датотеку. Овај дневник се зове траг. У зависности од тога шта се испитује, праћење може укључивати извршне инструкције, меморијске адресе, бројеве портова и информације о прекиду.

Следећи корак је „играње“ трага, када симулатор сат по сат чита траг и изврши све инструкције записане у њему. На крају добијамо време извршења овог дела програма, као и различите карактеристике овог процеса, на пример, проценат погодака у кешу.

Важна карактеристика рада са траговима је детерминизам, односно покретањем симулације на горе описани начин, изнова и изнова репродукујемо исти редослед радњи. Ово омогућава, променом параметара модела (кеш меморије, бафера и величине реда) и коришћењем различитих интерних алгоритама или њиховим подешавањем, да се проучи како одређени параметар утиче на перформансе система и која опција даје најбоље резултате. Све ово се може урадити са моделом прототипа уређаја пре креирања стварног хардверског прототипа.

Сложеност овог приступа лежи у потреби да се прво покрене апликација и прикупи траг, као и огромна величина датотеке праћења. Предности укључују чињеницу да је довољно симулирати само део уређаја или платформе од интереса, док симулација извршењем обично захтева комплетан модел.

Дакле, у овом чланку смо погледали карактеристике симулације пуне платформе, разговарали о брзини имплементације на различитим нивоима, симулацији сат по циклус и траговима. У следећем чланку ћу описати главне сценарије за коришћење симулатора, како у личне сврхе, тако и са развојне тачке гледишта у великим компанијама.

Извор: ввв.хабр.цом