Raksta par datorsistēmu simulatoriem otrajā daļā turpināšu vienkāršā ievadformā runāt par datorsimulatoriem, proti, par pilnas platformas simulāciju, ar kuru visbiežāk saskaras vidusmēra lietotājs, kā arī par pulksteņa laiku. -pulksteņa modelis un pēdas, kas biežāk sastopamas izstrādātāju aprindās.
В Es runāju par to, kas vispār ir simulatori, kā arī par simulācijas līmeņiem. Tagad, balstoties uz šīm zināšanām, es ierosinu ienirt nedaudz dziļāk un runāt par pilnas platformas simulāciju, kā savākt pēdas, ko ar tām vēlāk darīt, kā arī par pulksteņa mikroarhitektūras emulāciju.
Pilnas platformas simulators jeb “Viens pats uz lauka nav karotājs”
Ja vēlaties izpētīt vienas konkrētas ierīces, piemēram, tīkla kartes, darbību vai rakstīt programmaparatūru vai draiveri šai ierīcei, tad šādu ierīci var simulēt atsevišķi. Tomēr to izmantot atsevišķi no pārējās infrastruktūras nav īpaši ērti. Lai palaistu atbilstošo draiveri, jums būs nepieciešams centrālais procesors, atmiņa, piekļuve datu kopnei utt. Turklāt, lai draiveris darbotos, ir nepieciešama operētājsistēma (OS) un tīkla steks. Turklāt var būt nepieciešams atsevišķs pakešu ģenerators un atbildes serveris.
Pilnas platformas simulators rada vidi pilnīgas programmatūras steka darbināšanai, kas ietver visu, sākot no BIOS un bootloader līdz pašai OS un tās dažādajām apakšsistēmām, piemēram, viena un tā pati tīkla steka, draiveri un lietotāja līmeņa lietojumprogrammas. Lai to izdarītu, tas ievieš programmatūras modeļus lielākajai daļai datoru ierīču: procesoru un atmiņu, disku, ievades/izvades ierīces (tastatūru, peli, displeju), kā arī to pašu tīkla karti.
Tālāk ir parādīta Intel x58 mikroshēmojuma blokshēma. Pilnas platformas datora simulatoram šajā mikroshēmojumā ir jāievieš lielākā daļa no uzskaitītajām ierīcēm, tostarp tās, kas atrodas IOH (ievades/izvades centrmezglā) un ICH (ievades/izvades kontrollera centrmezglā), kas nav detalizēti attēlotas blokshēmā. . Lai gan, kā liecina prakse, nav daudz ierīču, kuras neizmantotu programmatūra, kuru mēs gatavojamies palaist. Šādu ierīču modeļi nav jāizveido.
Visbiežāk pilnas platformas simulatori tiek ieviesti procesora instrukciju līmenī (ISA, skatīt zemāk). ). Tas ļauj salīdzinoši ātri un lēti izveidot pašu simulatoru. ISA līmenis ir arī labs, jo tas paliek vairāk vai mazāk nemainīgs, atšķirībā, piemēram, no API/ABI līmeņa, kas mainās biežāk. Turklāt ieviešana instrukciju līmenī ļauj palaist tā saukto nemodificēto bināro programmatūru, tas ir, palaist jau kompilētu kodu bez jebkādām izmaiņām, tieši tā, kā tas tiek izmantots reālajā aparatūrā. Citiem vārdiem sakot, varat izveidot sava cietā diska kopiju (“izgāztuvi”), norādīt to kā modeļa attēlu pilnas platformas simulatorā, un var! – OS un citas programmas tiek ielādētas simulatorā bez papildu darbībām.
Simulatora veiktspēja
Kā jau tika minēts iepriekš, visas sistēmas, tas ir, visu tās ierīču, simulācijas process ir diezgan lēns pasākums. Ja to visu arī ieviesīsi ļoti detalizētā līmenī, piemēram, mikroarhitektoniskā vai loģiskā, tad izpilde kļūs ārkārtīgi lēna. Taču instrukciju līmenis ir pareizā izvēle, un tas ļauj operētājsistēmai un programmām darboties ar ātrumu, kas ir pietiekams, lai lietotājs varētu ar tām ērti mijiedarboties.
Šeit būtu lietderīgi pieskarties simulatora darbības tēmai. To parasti mēra IPS (instrukcijas sekundē), precīzāk MIPS (miljonos IPS), tas ir, simulatora izpildīto procesora instrukciju skaits vienā sekundē. Tajā pašā laikā simulācijas ātrums ir atkarīgs arī no tās sistēmas veiktspējas, kurā darbojas pati simulācija. Tāpēc varētu būt pareizāk runāt par simulatora “palēnināšanos”, salīdzinot ar sākotnējo sistēmu.
Tirgū izplatītākajiem pilnas platformas simulatoriem, piemēram, QEMU, VirtualBox vai VmWare Workstation, ir laba veiktspēja. Lietotājs var pat nepamanīt, ka simulatorā notiek darbs. Tas notiek, pateicoties īpašajām virtualizācijas iespējām, kas ieviestas procesoros, binārajiem tulkošanas algoritmiem un citām interesantām lietām. Tas viss ir atsevišķa raksta tēma, bet īsi sakot, virtualizācija ir mūsdienu procesoru aparatūras funkcija, kas ļauj simulatoriem nevis simulēt instrukcijas, bet gan nosūtīt tās izpildei tieši uz reālu procesoru, ja, protams, tiek izmantotas simulators un procesors ir līdzīgi. Binārā tulkošana ir viesu mašīnas koda tulkošana resursdatora kodā un sekojoša izpilde reālā procesorā. Rezultātā simulācija ir tikai nedaudz lēnāka, 5-10 reizes, un bieži vien pat darbojas ar tādu pašu ātrumu kā reālā sistēma. Lai gan to ietekmē daudzi faktori. Piemēram, ja mēs vēlamies simulēt sistēmu ar vairākiem desmitiem procesoru, tad ātrums uzreiz samazināsies par šiem vairākiem desmitiem reižu. No otras puses, simulatori, piemēram, Simics jaunākajās versijās, atbalsta daudzprocesoru resursdatora aparatūru un efektīvi paralēli simulētos kodolus reāla procesora kodoliem.
Ja runājam par mikroarhitektūras simulācijas ātrumu, tad tas parasti ir vairākas kārtas, aptuveni 1000-10000 reižu lēnāks nekā izpilde parastajā datorā, bez simulācijas. Un ieviešana loģisko elementu līmenī ir par vairākām kārtām lēnāka. Tāpēc šajā līmenī kā emulators tiek izmantots FPGA, kas var ievērojami palielināt veiktspēju.
Tālāk redzamajā grafikā parādīta aptuvenā simulācijas ātruma atkarība no modeļa detaļām.
Simulācija pēc sitiena
Neskatoties uz to zemo izpildes ātrumu, mikroarhitektūras simulatori ir diezgan izplatīti. Procesora iekšējo bloku simulācija ir nepieciešama, lai precīzi simulētu katras instrukcijas izpildes laiku. Šeit var rasties pārpratumi - galu galā, šķiet, kāpēc gan vienkārši neieprogrammēt katras instrukcijas izpildes laiku. Bet šāds simulators būs ļoti neprecīzs, jo vienas un tās pašas instrukcijas izpildes laiks var atšķirties atkarībā no zvana.
Vienkāršākais piemērs ir atmiņas piekļuves instrukcija. Ja pieprasītā atmiņas vieta ir pieejama kešatmiņā, tad izpildes laiks būs minimāls. Ja šī informācija nav kešatmiņā (“cache miss”), tas ievērojami palielinās instrukcijas izpildes laiku. Tādējādi precīzai simulācijai ir nepieciešams kešatmiņas modelis. Tomēr jautājums neaprobežojas tikai ar kešatmiņas modeli. Procesors vienkārši negaidīs, līdz dati tiks izgūti no atmiņas, kad tie nav kešatmiņā. Tā vietā tas sāks izpildīt nākamos norādījumus, izvēloties tos, kas nav atkarīgi no nolasīšanas no atmiņas rezultāta. Šī ir tā sauktā “ārpus kārtības” izpilde (OOO, out of order execution), kas nepieciešama, lai samazinātu procesora dīkstāves laiku. Atbilstošo procesora bloku modelēšana palīdzēs to visu ņemt vērā, aprēķinot instrukciju izpildes laiku. Starp šiem norādījumiem, kas tiek izpildīti, kamēr tiek gaidīts nolasīšanas rezultāts no atmiņas, var notikt nosacīta lēciena darbība. Ja nosacījuma rezultāts šobrīd nav zināms, tad atkal procesors neaptur izpildi, bet izdara “minējumu”, izpilda atbilstošo atzaru un turpina proaktīvi izpildīt instrukcijas no pārejas punkta. Šāds bloks, ko sauc par zaru prognozētāju, ir jāievieš arī mikroarhitektūras simulatorā.
Zemāk esošajā attēlā redzami procesora galvenie bloki, tas nav jāzina, tas ir parādīts tikai, lai parādītu mikroarhitektūras realizācijas sarežģītību.
Visu šo bloku darbība reālā procesorā tiek sinhronizēta ar īpašiem pulksteņa signāliem, un tas pats notiek modelī. Šādu mikroarhitektūras simulatoru sauc par cikla precīzu. Tās galvenais mērķis ir precīzi paredzēt izstrādājamā procesora veiktspēju un/vai aprēķināt konkrētas programmas, piemēram, etalona, izpildes laiku. Ja vērtības ir zemākas par nepieciešamo, tad būs nepieciešams modificēt algoritmus un procesora blokus vai optimizēt programmu.
Kā redzams iepriekš, pulksteņa pēc pulksteņa simulācija ir ļoti lēna, tāpēc tiek izmantota tikai pētot noteiktus programmas darbības momentus, kur nepieciešams noskaidrot reālo programmas izpildes ātrumu un novērtēt tās ierīces turpmāko veiktspēju, kura prototips tiek simulēts.
Šajā gadījumā tiek izmantots funkcionāls simulators, lai simulētu atlikušo programmas darbības laiku. Kā šī izmantošanas kombinācija notiek patiesībā? Pirmkārt, tiek palaists funkcionālais simulators, kurā tiek ielādēta OS un viss nepieciešamais pētāmās programmas palaišanai. Galu galā mūs neinteresē ne pati OS, ne programmas palaišanas sākumposmi, tās konfigurācija utt. Tomēr mēs arī nevaram izlaist šīs daļas un nekavējoties pāriet uz programmas izpildi no vidus. Tāpēc visas šīs sākotnējās darbības tiek veiktas funkcionālā simulatorā. Pēc tam, kad programma ir izpildīta līdz mūs interesējošam brīdim, ir iespējami divi varianti. Varat aizstāt modeli ar pulksteņa cikla modeli un turpināt izpildi. Simulācijas režīmu, kurā tiek izmantots izpildāms kods (tas ir, regulāri kompilēti programmu faili), sauc par izpildes simulāciju. Šī ir visizplatītākā simulācijas iespēja. Iespējama arī cita pieeja – izsekot vadīta simulācija.
Uz izsekošanu balstīta simulācija
Tas sastāv no diviem posmiem. Izmantojot funkcionālu simulatoru vai reālā sistēmā, programmas darbību žurnāls tiek savākts un ierakstīts failā. Šo žurnālu sauc par izsekošanu. Atkarībā no tā, kas tiek pārbaudīts, izsekošana var ietvert izpildāmas instrukcijas, atmiņas adreses, portu numurus un pārtraukuma informāciju.
Nākamais solis ir trases “atskaņošana”, kad pulksteņa simulators nolasa trasējumu un izpilda visus tajā rakstītos norādījumus. Beigās mēs iegūstam šīs programmas daļas izpildes laiku, kā arī dažādus šī procesa raksturlielumus, piemēram, trāpījumu procentuālo daudzumu kešatmiņā.
Svarīga iezīme darbā ar pēdām ir determinisms, tas ir, veicot simulāciju iepriekš aprakstītajā veidā, mēs atkal un atkal atkārtojam vienu un to pašu darbību secību. Tas ļauj, mainot modeļa parametrus (kešatmiņas, bufera un rindu izmērus) un izmantojot dažādus iekšējos algoritmus vai tos regulējot, izpētīt, kā konkrēts parametrs ietekmē sistēmas veiktspēju un kura opcija dod vislabākos rezultātus. To visu var izdarīt ar ierīces modeļa prototipu, pirms tiek izveidots faktiskais aparatūras prototips.
Šīs pieejas sarežģītība ir saistīta ar nepieciešamību vispirms palaist lietojumprogrammu un apkopot izsekojumu, kā arī lielajā izsekošanas faila izmērā. Priekšrocības ietver to, ka pietiek tikai simulēt interesējošo ierīces vai platformas daļu, savukārt simulācijai ar izpildi parasti ir nepieciešams pilns modelis.
Tātad, šajā rakstā mēs apskatījām pilnas platformas simulācijas iespējas, runājām par ieviešanas ātrumu dažādos līmeņos, simulāciju pēc pulksteņa un izsekošanas. Nākamajā rakstā aprakstīšu galvenos simulatoru izmantošanas scenārijus gan personīgiem mērķiem, gan no attīstības viedokļa lielos uzņēmumos.
Avots: www.habr.com
