У другой частцы артыкула аб сімулятарах кампутарных сістэм працягну распавядаць у простай азнаямленчай форме аб кампутарных сімулятарах, а менавіта аб поўнаплатформеннай сімуляцыі, з якой часцей за ўсё сутыкаецца звычайны карыстач, а таксама аб патактавай мадэлі і трасах, якія больш распаўсюджаныя ў колах распрацоўнікаў.
В я расказаў, што такое сімулятары наогул, а таксама аб узроўнях мадэлявання. Зараз на аснове тых ведаў прапаную нырнуць крыху глыбей і пагаварыць аб поўнаплатформеннай сімуляцыі, аб тым, як сабраць трасы, што з імі потым рабіць, а таксама аб патактавай мікраархітэктурнай эмуляцыі.
Поўнаплатформавы сімулятар (full platform simulator), або "Адзін у поле – не воін"
Калі патрабуецца даследаваць працу адной пэўнай прылады, напрыклад, сеткавай карты, ці напісаць для гэтай прылады прашыўку ці драйвер, тая такая прылада можна змадэляваць асобна. Аднак выкарыстоўваць яго ў адрыве ад астатняй інфраструктуры не надта зручна. Для запуску які адпавядае драйвера запатрабуецца цэнтральны працэсар, памяць, доступ да шыны для перадачы дадзеных і іншае. Акрамя таго, для працы драйвера неабходныя аперацыйная сістэма (АС) і сеткавы стэк. У дадатак да гэтага можа запатрабавацца асобны генератар пакетаў і сервер прыёму адказаў.
Поўнаплатформавы сімулятар стварае асяроддзе для запуску поўнага софтвернага стэка, які складаецца з усё, пачынальна з BIOS і загрузніка і сканчаючы самай АС і рознымі яе падсістэмамі, такімі як той жа сеткавы стэк, драйверамі, прыкладаннямі карыстацкага ўзроўня. Для гэтага ў ім рэалізаваны праграмныя мадэлі большасці прылад кампутара: працэсар і памяць, дыск, прылады ўводу-высновы (клавіятура, мыш, дысплей), а таксама тая самая сеткавая карта.
Ніжэй прыведзена блок-дыяграма чыпсэта x58 ад кампаніі Intel. У поўнаплатформенным сімулятары кампутара на гэтым чыпсэце неабходна рэалізацыя большасці пералічаных прылад, у тым ліку і тых, што знаходзяцца ўсярэдзіне IOH (Input/Output Hub) і ICH (Input/Output Controller Hub), не намаляваных дэталёва на блок-дыяграме. Хоць, як паказвае практыка, не так ужо мала прылад, якія не выкарыстоўваюцца тым ПА, якое мы збіраемся запускаць. Мадэлі такіх прылад можна не ствараць.
Часцей за ўсё поўнаплатформенныя сімулятары рэалізуюцца на ўзроўні інструкцый працэсара (ISA, гл. ). Гэта дазваляе адносна хутка і нядорага стварыць сам сімулятар. Узровень ISA таксама добры тым, што застаецца больш ці меней сталым, у адрозненне ад, напрыклад, узроўня API/ABI, які змяняецца гушчару. Да таго ж, рэалізацыя на ўзроўні інструкцый дазваляе запускаць так званае немадыфікаванае бінарнае ПЗ, гэта значыць запускаць ужо скампіляваны код без якіх-небудзь змен, роўна ў тым выглядзе як ён выкарыстоўваецца на рэальным жалезе. Іншымі словамі, можна зрабіць копію ("дамп") цвёрдай кружэлкі, паказаць яго ў якасці выявы для мадэлі ў поўнаплатформенным сімулятары і - вуаля! - АС і астатнія праграмы загружаюцца ў сімулятары без усялякіх дадатковых дзеянняў.
Прадукцыйнасць сімулятараў
Як было згадана крыху вышэй, сам працэс сімуляцыі ўсёй сістэмы цалкам, гэта значыць усіх яе прылад, даволі няхуткае мерапрыемства. Калі яшчэ і рэалізаваць усё гэта на зусім дэталёвым узроўні, напрыклад, мікраархітэктурным ці лагічным, тое выкананне стане экстрэмальна павольным. А вось узровень інструкцый з'яўляецца падыходным выбарам і дазваляе АС і праграмам выконвацца на хуткасцях, дастатковых карыстачу для камфортнага ўзаемадзеяння з імі.
Тут якраз дарэчы будзе закрануць тэму прадукцыйнасці сімулятараў. Звычайна яе вымяраюць у IPS (instructions per second), дакладней у MIPS (millions 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