Sa ikalawang bahagi ng artikulo tungkol sa mga simulator ng computer system, magpapatuloy akong makipag-usap sa isang simpleng panimulang anyo tungkol sa mga simulator ng computer, lalo na ang tungkol sa full-platform simulation, na madalas na nakakaharap ng karaniwang gumagamit, pati na rin ang tungkol sa orasan. -modelo ng orasan at mga bakas, na mas karaniwan sa mga lupon ng developer.
Π Napag-usapan ko kung ano ang mga simulator sa pangkalahatan, pati na rin ang tungkol sa mga antas ng simulation. Ngayon, batay sa kaalamang iyon, iminumungkahi kong sumisid ng kaunti at pag-usapan ang tungkol sa full-platform simulation, kung paano mangolekta ng mga bakas, kung ano ang gagawin sa mga ito sa ibang pagkakataon, pati na rin ang tungkol sa orasan-by-clock na microarchitectural emulation.
Full platform simulator, o "Ang nag-iisa sa field ay hindi isang mandirigma"
Kung gusto mong pag-aralan ang pagpapatakbo ng isang partikular na device, halimbawa, isang network card, o magsulat ng firmware o driver para sa device na ito, kung gayon ang naturang device ay maaaring i-simulate nang hiwalay. Gayunpaman, ang paggamit nito sa paghihiwalay mula sa natitirang imprastraktura ay hindi masyadong maginhawa. Upang patakbuhin ang kaukulang driver, kakailanganin mo ng isang sentral na processor, memorya, pag-access sa isang data bus, atbp. Bilang karagdagan, ang driver ay nangangailangan ng isang operating system (OS) at isang network stack upang gumana. Bilang karagdagan, maaaring kailanganin ang isang hiwalay na packet generator at response server.
Ang isang full-platform simulator ay lumilikha ng isang kapaligiran para sa pagpapatakbo ng isang kumpletong stack ng software, na kinabibilangan ng lahat mula sa BIOS at bootloader hanggang sa OS mismo at sa iba't ibang mga subsystem nito, tulad ng parehong network stack, mga driver, at mga application sa antas ng user. Upang gawin ito, nagpapatupad ito ng mga modelo ng software ng karamihan sa mga device sa computer: processor at memory, disk, input/output device (keyboard, mouse, display), pati na rin ang parehong network card.
Nasa ibaba ang isang block diagram ng x58 chipset mula sa Intel. Ang isang full-platform na computer simulator sa chipset na ito ay nangangailangan ng pagpapatupad ng karamihan sa mga nakalistang device, kabilang ang mga nasa loob ng IOH (Input/Output Hub) at ICH (Input/Output Controller Hub), na hindi inilalarawan nang detalyado sa block diagram . Bagaman, tulad ng ipinapakita sa pagsasanay, walang maraming mga aparato na hindi ginagamit ng software na aming tatakbo. Ang mga modelo ng naturang mga aparato ay hindi kailangang gawin.
Kadalasan, ang mga full-platform na simulator ay ipinatupad sa antas ng pagtuturo ng processor (ISA, tingnan sa ibaba). ). Pinapayagan ka nitong lumikha ng simulator mismo nang medyo mabilis at mura. Maganda rin ang antas ng ISA dahil nananatiling pare-pareho ito, hindi katulad, halimbawa, ang antas ng API/ABI, na mas madalas na nagbabago. Bilang karagdagan, ang pagpapatupad sa antas ng pagtuturo ay nagbibigay-daan sa iyo upang patakbuhin ang tinatawag na unmodified binary software, iyon ay, patakbuhin ang naipon na code nang walang anumang mga pagbabago, eksakto kung paano ito ginagamit sa tunay na hardware. Sa madaling salita, maaari kang gumawa ng kopya ("dump") ng iyong hard drive, tukuyin ito bilang isang imahe para sa isang modelo sa isang full-platform simulator, at voila! β Ang OS at iba pang mga programa ay na-load sa simulator nang walang anumang karagdagang mga aksyon.
Pagganap ng simulator
Tulad ng nabanggit sa itaas, ang proseso ng pagtulad sa buong sistema, iyon ay, lahat ng mga aparato nito, ay medyo mabagal na gawain. Kung ipapatupad mo rin ang lahat ng ito sa isang napaka-detalyadong antas, halimbawa, microarchitectural o lohikal, kung gayon ang pagpapatupad ay magiging lubhang mabagal. Ngunit ang antas ng pagtuturo ay ang naaangkop na pagpipilian at nagbibigay-daan sa OS at mga programa na isagawa sa bilis na sapat para sa user na makipag-ugnayan sa kanila nang kumportable.
Dito magiging angkop na hawakan ang paksa ng pagganap ng simulator. Karaniwan itong sinusukat sa IPS (mga tagubilin sa bawat segundo), mas tiyak sa MIPS (milyong IPS), iyon ay, ang bilang ng mga tagubilin ng processor na isinagawa ng simulator sa isang segundo. Kasabay nito, ang bilis ng simulation ay nakasalalay din sa pagganap ng system kung saan tumatakbo ang simulation mismo. Samakatuwid, maaaring mas tama na pag-usapan ang tungkol sa "paghina" ng simulator kumpara sa orihinal na sistema.
Ang pinakakaraniwang full-platform simulator sa merkado, tulad ng QEMU, VirtualBox o VmWare Workstation, ay may mahusay na pagganap. Maaaring hindi man lang mapansin ng user na ang trabaho ay nangyayari sa simulator. Nangyayari ito salamat sa mga espesyal na kakayahan sa virtualization na ipinatupad sa mga processor, binary translation algorithm at iba pang mga kawili-wiling bagay. Ang lahat ng ito ay isang paksa para sa isang hiwalay na artikulo, ngunit sa madaling salita, ang virtualization ay isang tampok na hardware ng mga modernong processor na nagpapahintulot sa mga simulator na hindi gayahin ang mga tagubilin, ngunit ipadala ang mga ito para sa pagpapatupad nang direkta sa isang tunay na processor, kung, siyempre, ang mga arkitektura ng ang simulator at ang processor ay magkatulad. Ang binary translation ay ang pagsasalin ng guest machine code sa host code at kasunod na pagpapatupad sa isang tunay na processor. Bilang resulta, ang simulation ay bahagyang mas mabagal, 5-10 beses, at madalas ay tumatakbo sa parehong bilis ng tunay na sistema. Bagaman ito ay naiimpluwensyahan ng maraming mga kadahilanan. Halimbawa, kung gusto nating gayahin ang isang system na may ilang dosenang mga processor, ang bilis ay agad na bababa ng ilang dosenang beses. Sa kabilang banda, ang mga simulator tulad ng Simics sa mga pinakabagong bersyon ay sumusuporta sa multiprocessor host hardware at epektibong i-parallelize ang simulate na mga core papunta sa mga core ng isang tunay na processor.
Kung pinag-uusapan natin ang bilis ng microarchitectural simulation, kadalasan ito ay ilang mga order ng magnitude, mga 1000-10000 beses na mas mabagal kaysa sa pagpapatupad sa isang regular na computer, nang walang simulation. At ang mga pagpapatupad sa antas ng mga lohikal na elemento ay mas mabagal sa ilang mga order ng magnitude. Samakatuwid, ang isang FPGA ay ginagamit bilang isang emulator sa antas na ito, na maaaring makabuluhang tumaas ang pagganap.
Ang graph sa ibaba ay nagpapakita ng tinatayang dependence ng bilis ng simulation sa detalye ng modelo.
Beat-by-beat simulation
Sa kabila ng kanilang mababang bilis ng pagpapatupad, ang mga microarchitectural simulator ay medyo karaniwan. Ang simulation ng mga panloob na bloke ng processor ay kinakailangan upang tumpak na gayahin ang oras ng pagpapatupad ng bawat pagtuturo. Maaaring lumitaw dito ang hindi pagkakaunawaan - pagkatapos ng lahat, tila, bakit hindi na lang i-program ang oras ng pagpapatupad para sa bawat pagtuturo. Ngunit ang gayong simulator ay magiging napaka hindi tumpak, dahil ang oras ng pagpapatupad ng parehong pagtuturo ay maaaring mag-iba mula sa tawag sa tawag.
Ang pinakasimpleng halimbawa ay isang memory access instruction. Kung ang hiniling na lokasyon ng memorya ay magagamit sa cache, kung gayon ang oras ng pagpapatupad ay magiging minimal. Kung ang impormasyong ito ay wala sa cache ("cache miss"), kung gayon ito ay lubos na magpapataas ng oras ng pagpapatupad ng pagtuturo. Kaya, ang isang modelo ng cache ay kinakailangan para sa tumpak na simulation. Gayunpaman, ang bagay ay hindi limitado sa modelo ng cache. Ang processor ay hindi lamang maghihintay para sa data na makuha mula sa memorya kapag ito ay wala sa cache. Sa halip, magsisimula itong isagawa ang mga susunod na tagubilin, pipiliin ang mga hindi nakadepende sa resulta ng pagbabasa mula sa memorya. Ito ang tinatawag na "out of order" execution (OOO, out of order execution), kinakailangan para mabawasan ang oras ng idle ng processor. Ang pagmomodelo ng kaukulang mga bloke ng processor ay makakatulong upang isaalang-alang ang lahat ng ito kapag kinakalkula ang oras ng pagpapatupad ng mga tagubilin. Kabilang sa mga tagubiling ito, na isinagawa habang hinihintay ang resulta ng pagbabasa mula sa memorya, maaaring mangyari ang isang conditional jump operation. Kung ang resulta ng kundisyon ay hindi alam sa ngayon, pagkatapos ay muli ang processor ay hindi huminto sa pagpapatupad, ngunit gumagawa ng isang "hulaan", gumaganap ng naaangkop na sangay at patuloy na proactive na pagpapatupad ng mga tagubilin mula sa punto ng paglipat. Ang nasabing block, na tinatawag na branch predictor, ay dapat ding ipatupad sa microarchitectural simulator.
Ang larawan sa ibaba ay nagpapakita ng mga pangunahing bloke ng processor, hindi kinakailangang malaman ito, ipinapakita lamang ito upang ipakita ang pagiging kumplikado ng pagpapatupad ng microarchitectural.
Ang pagpapatakbo ng lahat ng mga bloke na ito sa isang tunay na processor ay naka-synchronize ng mga espesyal na signal ng orasan, at ganoon din ang nangyayari sa modelo. Ang ganitong microarchitectural simulator ay tinatawag na cycle na tumpak. Ang pangunahing layunin nito ay upang tumpak na mahulaan ang pagganap ng processor na binuo at/o kalkulahin ang oras ng pagpapatupad ng isang partikular na programa, halimbawa, isang benchmark. Kung ang mga halaga ay mas mababa kaysa sa kinakailangan, pagkatapos ay kinakailangan na baguhin ang mga algorithm at mga bloke ng processor o i-optimize ang programa.
Tulad ng ipinakita sa itaas, ang simulation ng orasan sa bawat orasan ay napakabagal, kaya ginagamit lamang ito kapag pinag-aaralan ang ilang mga sandali ng pagpapatakbo ng isang programa, kung saan kinakailangan upang malaman ang tunay na bilis ng pagpapatupad ng programa at suriin ang pagganap sa hinaharap ng aparato na ang prototype ay ginagaya.
Sa kasong ito, ginagamit ang isang functional simulator upang gayahin ang natitirang oras ng pagpapatakbo ng programa. Paano nangyayari ang kumbinasyong ito ng paggamit sa katotohanan? Una, inilunsad ang functional simulator, kung saan na-load ang OS at lahat ng kailangan upang patakbuhin ang programa sa ilalim ng pag-aaral. Pagkatapos ng lahat, hindi kami interesado sa OS mismo, o sa mga unang yugto ng paglulunsad ng programa, pagsasaayos nito, atbp. Gayunpaman, hindi rin namin maaaring laktawan ang mga bahaging ito at agad na magpatuloy sa pagpapatupad ng programa mula sa gitna. Samakatuwid, ang lahat ng mga paunang hakbang na ito ay pinapatakbo sa isang functional simulator. Matapos maisakatuparan ang programa sa sandali ng interes sa amin, dalawang opsyon ang posible. Maaari mong palitan ang modelo ng isang clock-by-cycle na modelo at ipagpatuloy ang pagpapatupad. Ang simulation mode na gumagamit ng executable code (iyon ay, regular compiled program files) ay tinatawag na execution driven simulation. Ito ang pinakakaraniwang opsyon sa simulation. Posible rin ang isa pang diskarte - trace driven simulation.
Trace-based na simulation
Binubuo ito ng dalawang hakbang. Gamit ang isang functional simulator o sa isang tunay na sistema, ang isang log ng mga aksyon ng programa ay kinokolekta at nakasulat sa isang file. Ang log na ito ay tinatawag na bakas. Depende sa kung ano ang sinusuri, ang bakas ay maaaring magsama ng mga executable na tagubilin, memory address, port number, at interrupt na impormasyon.
Ang susunod na hakbang ay ang "i-play" ang bakas, kapag binasa ng clock-by-clock simulator ang bakas at isinasagawa ang lahat ng mga tagubiling nakasulat dito. Sa dulo, nakukuha namin ang oras ng pagpapatupad ng bahaging ito ng programa, pati na rin ang iba't ibang katangian ng prosesong ito, halimbawa, ang porsyento ng mga hit sa cache.
Ang isang mahalagang tampok ng pagtatrabaho sa mga bakas ay ang determinismo, iyon ay, sa pamamagitan ng pagpapatakbo ng simulation sa paraang inilarawan sa itaas, paulit-ulit na ginagawa namin ang parehong pagkakasunud-sunod ng mga aksyon. Ginagawa nitong posible, sa pamamagitan ng pagbabago ng mga parameter ng modelo (cache, buffer at mga laki ng queue) at paggamit ng iba't ibang mga panloob na algorithm o pag-tune sa mga ito, upang pag-aralan kung paano nakakaapekto ang isang partikular na parameter sa pagganap ng system at kung aling opsyon ang nagbibigay ng pinakamahusay na mga resulta. Ang lahat ng ito ay maaaring gawin gamit ang isang modelo ng prototype device bago lumikha ng isang aktwal na prototype ng hardware.
Ang pagiging kumplikado ng diskarte na ito ay nakasalalay sa pangangailangan na patakbuhin muna ang application at kolektahin ang bakas, pati na rin ang malaking sukat ng trace file. Kasama sa mga pakinabang ang katotohanan na sapat na upang gayahin lamang ang bahagi ng aparato o platform ng interes, habang ang simulation sa pamamagitan ng pagpapatupad ay karaniwang nangangailangan ng isang kumpletong modelo.
Kaya, sa artikulong ito, tiningnan namin ang mga tampok ng full-platform simulation, pinag-usapan ang bilis ng mga pagpapatupad sa iba't ibang antas, clock-by-cycle simulation at mga bakas. Sa susunod na artikulo ay ilalarawan ko ang mga pangunahing senaryo para sa paggamit ng mga simulator, kapwa para sa mga personal na layunin at mula sa isang punto ng pag-unlad ng view sa malalaking kumpanya.
Pinagmulan: www.habr.com