Симулатори на компютърни системи: всички познатия пълноплатформен симулатор и никому неизвестните потъкови и трасови

Във втората част на статията за симулатори на компютърни системи ще продължа да разказвам по прост и запознавателен начин за компютърните симулатори, а именно за пълноплатформената симулация, с която най-често се сблъсква обикновеният потребител, а също така за потактовата модел и трасетата, които са по-разпространени сред разработчиците.

В първата част Разказах какво представляват симулаторите като цяло, както и за нивата на моделиране. Сега, на базата на тези знания, предлагам да се потопим малко по-дълбоко и да поговорим за пълноплатформената симулация, за това как да се изградят трасета, какво да се прави с тях след това, и също така за потактовата микроархитектурна еймулация.

Пълноплатформен симулатор (full platform simulator), или "Един в полето – не е войн"

Ако е необходимо да се изследва работата на едно конкретно устройство, например мрежова карта, или да се напише фърмуер или драйвер за това устройство, то това устройство може да се моделира отделно. Въпреки това, използването му извън останалата инфраструктура не е много удобно. За стартиране на съответния драйвер е необходим централният процесор, памет, достъп до шина за предаване на данни и друго. Освен това, за работата на драйвера е необходима операционна система (ОС) и мрежов стек. В допълнение към това може да е необходим отделен генератор на пакети и сървър за получаване на отговори.

Пълноплатформеният симулатор създава среда за стартиране на целия софтуерен стек, който включва всичко, започвайки от BIOS и зареждача, и завършвайки с ОС и различните й подсистеми, като същия мрежов стек, драйвери, приложения на потребителско ниво. За това в него са реализирани софтуерни модели на повечето устройства на компютъра: процесор и памет, диск, устройства за вход и изход (клавиатура, мишка, дисплей), както и онази мрежова карта.

По-долу е представена блок-схема на чипсета x58 от компания Intel. В пълноценен симулатор на компютър, базиран на този чипсет, е необходимо реализирането на повечето изброени устройства, включително и тези, които се намират в IOH (Input/Output Hub) и ICH (Input/Output Controller Hub), които не са детайлно изобразени на блок-схемата. Въпреки това, практиката показва, че има доста устройства, които не се използват от софтуера, който възнамеряваме да стартираме. Моделите на такива устройства могат да не бъдат създавани.

Най-често пълноценните симулатори се реализират на ниво процесорни инструкции (ISA, вижте предишната статия). Това позволява сравнително бързо и евтино създаване на самия симулатор. Нивото на ISA също е полезно, тъй като остава повече или по-малко постоянно, за разлика от, например, нивото на API/ABI, което се променя по-често. Освен това, реализирането на ниво инструкции позволява стартиране на така нареченото немодифицирано бинарно софтуерно, тоест стартиране на вече компилиран код без никакви промени, точно в онази форма, в която се използва на реален хардуер. С други думи, можете да направите копие („дамп“) на твърдия диск, да го зададете като образ за модела в пълноценния симулатор и – вуаля! – ОС и останалите програми се натоварват в симулатора без никакви допълнителни действия.

Производителност на симулаторите

Както бе споменато по-горе, самият процес на симулация на цялата система, тоест на всичките ѝ устройства, е доста бавен. Ако се реализира всичко това на изцяло детайлно ниво, например микроархитектурно или логическо, то изпълнението ще бъде екстремно бавно. Нивото на инструкциите е подходящ избор и позволява на ОС и програмите да се изпълняват с скорости, достатъчни за комфортно взаимодействие с тях от страна на потребителя.

Тук е уместно да се засегне темата за производителността на симулаторите. Обикновено тя се измерва в IPS (инструкции на секунда), по-точно в MIPS (милиони IPS), тоест в количеството инструкции на процесора, изпълнявани от симулатора за една секунда. В същото време скоростта на симулацията зависи и от производителността на системата, на която работи самата симулация. Поради това, може би е по-правилно да говорим за "забавяне" (slowdown) на симулатора спрямо оригиналната система.

Най-разпространените на пазара пълноплатформени симулатори, като QEMU, VirtualBox или VmWare Workstation, предлагат отлична производителност. За потребителя може дори да не е забележимо, че работата протича в симулатор. Това се дължи на реализираната в процесорите специална функция на виртуализация, алгоритмите за бинарен транслацион и други интересни аспекти. Всичко това е тема за отделна статия, но накратко, виртуализацията е хардуерна възможност на съвременните процесори, която позволява на симулаторите да не симулират инструкции, а да ги предават директно за изпълнение на реалния процесор, ако, разбира се, архитектурите на симулатора и процесора са сходни. Бинарната транслация е превод на гост машинен код в хостов и последващо изпълнение на реалния процесор. В резултат на това симулацията е само малко по-бавна, с около 5-10 пъти, а често дори работи със същата скорост като реалната система. Въпреки това, много фактори влияят на това. Например, ако искаме да симулираме система с десетки процесори, то скоростта веднага ще намалее с толкова много пъти. От друга страна, симулатори като Simics в последните версии поддържат многопроцесорно хостово „желязо“ и ефективно разпределят симулираните ядра на ядрата на реалния процесор.

Когато става въпрос за скоростта на микроархитектурната симулация, тя обикновено е с няколко реда, около 1000-10000 пъти, по-бавна от изпълнението на стандартен компютър, без симулация. А реализациите на логическо ниво са още по-бавни с няколко реда. Затова в качеството си на емулатор на това ниво се използват FPGA, което позволява значително увеличаване на производителността.

Графикът по-долу показва примерна зависимост на скоростта на симулация от нивото на детайлност на модела.

Потактовата симулация

Въпреки относително ниската скорост на изпълнение, микроархитектурните симулатори са доста разпространени. Моделирането на вътрешните блокове на процесора е необходимо, за да се симулира точно времето за изпълнение на всяка инструкция. Тук може да възникне недоразумение - би изглеждало, че защо просто не се програмира времето за изпълнение на всяка инструкция. Но такъв симулатор ще работи много неточно, тъй като времето за изпълнение на една и съща инструкция може да се различава от извикване до извикване.

Най-простият пример е инструкцията за достъп до паметта. Ако исканата клетка в паметта е налична в кеша, времето за изпълнение ще бъде минимално. Ако в кеша няма информацията ("кеш пропуск", cache miss), това значително ще увеличи времето за изпълнение на инструкцията. По този начин, за точна симулация е необходима модел на кеша. Въпреки това, с модела на кеша не се изчерпва. Процесорът няма просто да изчака получаването на данни от паметта, когато те не са налични в кеша. Вместо това, той ще започне да изпълнява следващите инструкции, избирайки такива, които не зависят от резултата от четенето от паметта. Това е така нареченото "изпълнение извън ред" (OOO, out of order execution), необходимо за минимизиране на времето на празен ход на процесора. Вземането под внимание на всичко това при изчисляването на времето за изпълнение на инструкциите ще помогне моделиране на съответните блокове на процесора. Между тези инструкции, които се изпълняват, докато се чака резултатът от четенето от паметта, може да има операция на условен преход. Ако резултатът от условието в момента е неизвестен, отново процесорът не спира изпълнението, а прави "предположение", изпълнява съответния преход и продължава да извършва превентивно инструкциите от мястото на прехода. Такъв блок, наречен предсказвач на клонове (branch predictor), също трябва да бъде реализиран в микроархитектурния симулатор.

Изображението по-долу показва основните блокове на процесора, които не е необходимо да знаете, то е приведено само за да показва сложността на микроархитектурната реализация.

Работата на всички тези блокове в реалния процесор се синхронизира с помощта на специални тактови сигнали, подобно на това, което се случва в модела. Такъв микропроцесорен симулатор се нарича потактов (cycle accurate). Основната му цел е точно да предвиди производителността на разработвания процесор и/или да изчисли времето за изпълнение на определена програма, например, на някакъв бенчмарк. Ако стойностите са по-ниски от необходимите, ще се наложи доработка на алгоритмите и блоковете на процесора или оптимизиране на програмата.

Както беше показано по-горе, потактовата симулация е много бавна, поради което тя се използва само при изучаване на определени аспекти на работата на програмата, където е необходимо да се установи реалната скорост на изпълнение и да се оцени бъдещата производителност на устройството, чийто прототип се моделира.

В същото време за симулация на останалото време на работа на програмата се използва функционален симулатор. Как такова комбинирано използване се осъществява на практика? Първо, стартира се функционалният симулатор, на който се зарежда операционната система и всичко необходимо за стартиране на изследваната програма. Ние не сме заинтересовани от самата ОС, нито от началните етапи на стартиране на програмата, нейното конфигуриране и т.н. Въпреки това, не можем да пропуснем тези части и директно да преминем към изпълнение на програмата от средата. Затова всички тези предварителни етапи преминават на функционалния симулатор. След като програмата се изпълни до интересуващия ни момент, има два варианта. Може да се замени моделът с потактов и да продължи изпълнението. Режимът на симулация, при който се използва изпълняемият код (т.е. обикновени скомпилирани файлове на програми), се нарича симулация по изпълнение (execution driven simulation). Това е най-разпространеният вариант на симулация. Възможен е и друг подход – симулация на основата на трасс (trace driven simulation).

Симулация на основата на трасс

Тя се състои от два етапа. С помощта на функционален симулатор или на реална система се събира и записва в файл лог на действията на програмата. Такъв лог се нарича трасса (trace). В зависимост от това какво се изследва, трассата може да включва изпълнявани инструкции, адреси на паметта, номера на портовете, информация за прекъсванията.

Следващата стъпка е „възпроизвеждането“ на трасата, когато тактовият симулатор чете трасата и изпълнява всички инструкции, записани в нея. В края получаваме времето за изпълнение на този фрагмент от програмата, както и различни характеристики на този процес, например, процентът на попадането в кеша.

Важно предимство при работа с трасите е детерминираността, т.е. при стартиране на симулацията по описания по-горе начин, отново и отново произвеждаме еднаква последователност от действия. Това предоставя възможност, като се променят параметрите на модела (размери на кеша, буферите и опашките) и се използват различни вътрешни алгоритми или техните настройки, да се изследва как конкретен параметър влияе на производителността на системата и която опция дава най-добри резултати. Всичко това може да се направи с модел на прототипа на устройството преди създаването на реален хардуерен прототип.

Сложността на този подход се състои в необходимостта от предварително изпълнение на приложението и събиране на трасата, както и огромния размер на файла с трасата. Предимствата включват това, че е достатъчно да се моделира само интересуващата част от устройството или платформата, докато симулацията по изпълнение изисква, като правило, пълна модел.

И така, в тази статия разгледахме особеностите на пълноплатформената симулация, обсъдихме скоростта на реализациите на различни нива, тактовата симулация и трасите. В следващата статия ще опиша основните сценарии за използване на симулатори, както за лични цели, така и от гледна точка на разработката в големи компании.

Източник: habr.com