Në pjesën e dytë të artikullit mbi simulatoret e sistemeve kompjuterike, do të vazhdoj të flas në një mënyrë të thjeshtë informuese rreth simulatorëve kompjuterikë, konkretisht mbi simulimin e plotë të platformave, me të cilin përballen më së shpeshti përdoruesit e zakonshëm, si dhe mbi modelin e taktimeve dhe traset që janë më të zakonshme në qarqet e zhvilluesve.
Në Unë përmenda se çfarë janë simulatoret në përgjithësi, si dhe nivelet e modelimit. Tani, duke u bazuar në ato njohuri, propozoj të zhytemi pak më thellë dhe të flasim për simulimin e plotë të platformave, se si të mbledhim trase, çfarë mund të bëjmë më pas me to, si dhe mbi emulimin mikroarkitekturor të taktimeve.
Simulatori i plotë i platformës (full platform simulator), ose “Një në fushë - nuk është një luftëtar”
Nëse është e nevojshme të studiohet funksionimi i një pajisjeje të veçantë, për shembull, një kartë rrjeti, ose të shkruhet një firmware ose draguer për këtë pajisje, atëherë kjo pajisje mund të simullohet veçmas. Megjithatë, përdorimi i saj në ndarjen nga infrastruktura tjetër nuk është shumë i përshtatshëm. Për të ekzekutuar draguerin përkatës nevojitet një procesor qendror, memorie, qasje në autobus për transferim të të dhënave dhe të tjera. Përveç kësaj, një sistem operativ (OS) dhe një stek rrjeti janë të nevojshme për funksionimin e draguerit. Shtesë, mund të nevojitet një gjenerator i veçantë paketash dhe një server për pranimin e përgjigjeve.
Simulatori i plotë i platformës krijon një mjedis për ekzekutimin e gjithë softuerit, i cili përfshin gjithçka, nga BIOS dhe ngarkuesi deri te vetë OS dhe nën-sistemet e saj të ndryshme, të tilla si steku rrjetit, draguerët, aplikacionet e nivelit të përdoruesit. Për këtë, ai implementon modele programore të shumicës së pajisjeve të kompjuterit: procesori dhe memorja, disku, pajisjet e input-output (tastiera, miu, ekrani), si dhe ajo karta rrjeti.
Më poshtë është një diagram bllok për chipsetin x58 nga kompania Intel. Në një simulator të plotë të platformës për këtë chipset, është e nevojshme të implementoni shumicën e pajisjeve të përmendura, përfshirë ato që ndodhen brenda IOH (Input/Output Hub) dhe ICH (Input/Output Controller Hub), të cilat nuk janë vizatuar në detaje në diagramin bllok. Megjithatë, siç tregon praktika, nuk ka shumë pajisje që nuk përdoren nga softveri që ne planifikojmë të përmbahemi. Modelet e tillë pajisjesh mund të mos krijohen.
Më së shpeshti simulatorët e plotë të platformës zbatohen në nivelin e instruksioneve të procesorit (ISA, shiko ). Kjo lejon që të krijohet relativisht shpejt dhe me kosto të ulët vetë simulatori. Niveli ISA është gjithashtu i mirë sepse mbetet më shumë ose më pak konstant, në krahasim me, për shembull, nivelin API/ABI, i cili ndryshon më shpesh. Për më tepër, implementimi në nivelin e instruksioneve lejon ekzekutimin e ashtuquajtur programi binar të pa modifikuar, në kuptimin që mund të ekzekutohet kodin e përgatitur pa asnjë ndryshim, ashtu siç përdoret në harduerin real. Në fjalë të tjera, mund të bëni një kopje (“dump”) të hard diskut, ta përcaktoni atë si imazh për modelin në simulatorin e plotë të platformës dhe – voila! – OS dhe programet e tjera ngarkohen në simulator pa asnjë veprim shtesë.
Kapasiteti i simulatorëve
Siç u përmend më lart, vetë procesi i simulimit të tërë sistemit, pra të gjitha pajisjeve të tij, është një aktivitet mjaft i ngadaltë. Nëse implementohet gjithashtu në një nivel shumë të detajuar, për shembull në atë mikroarkitekturor ose logjik, ekzekutimi do të bëhet ekstremisht i ngadaltë. Megjithatë, niveli i instruksioneve është një zgjedhje e përshtatshme dhe lejon që OS dhe programet të ekzekutohen me shpejtësi të mjaftueshme për t'u ndjerë komod në ndërveprimin me to.
Këtu është e përshtatshme të prekim temën e kapacitetit të simulatorëve. Zakonisht, ai matet në IPS (instruksione për sekondë), më saktësisht në MIPS (miliona IPS), që do të thotë numri i instruksioneve të procesorit që ekzekutohet nga simulatori për një sekondë. Megjithatë, shpejtësia e simulimit varet gjithashtu nga kapaciteti i sistemit, mbi të cilin funksionon vetë simulimi. Prandaj, ndoshta është më e saktë të flasim për "ngadalësim" (slowdown) të simulatorit në krahasim me sistemin origjinal.
Simulatorët më të zakonshëm në treg, si QEMU, VirtualBox ose VmWare Workstation, kanë performancë të kënaqshme. Një përdorues mund edhe të mos e vë re se po punon në një simulator. Kjo ndodh falë mundësive speciale të virtualizimit të implementuara në procesorë, algoritmeve të translacionit binar dhe gjërave të tjera interesante. Kjo është një temë për një artikull të veçantë, por nëse e shpjegojmë shumë shkurt, virtualizimi është një mundësi harduerike e procesorëve modernë që lejon simulatorët të mos simulojnë instruktionet, por t'i dërgojnë ato për ekzekutim direkt në procesorin real, nëse, natyrisht, arkitekturat e simulatorit dhe procesorit janë të ngjashme. Translacioni binar është përkthimi i kodit të makinës së mysafirëve në kodin e hostit dhe ekzekutimi i tij në procesorin real. Si rezultat, simulimi është vetëm pak më i ngadalshëm, rreth 5-10 herë, dhe shpesh funksionon me të njëjtën shpejtësi si sistemi real. Megjithatë, shumë faktorë ndikojnë në këtë. Për shembull, nëse duam të simulojmë një sistem me disa dhjetëra procesorë, shpejtësia do të bjerë menjëherë disa dhjetëra herë. Nga ana tjetër, simulatorët si Simics në versionet e fundit mbështesin harduerin e mirëfilltë me shumë procesorë dhe e shpërndajnë efektivisht punën e simuluar në bërthamat e procesorit real.
Nëse flasim për shpejtësinë e simulimit të mikroarkitekturës, kjo është zakonisht disa renditje, rreth 1000-10000 herë, më e ngadaltë se ekzekutimi në një kompjuter të zakonshëm, pa simulim. Ndërsa realizimet në nivelin e elementeve logjike janë edhe më të ngadalta me disa renditje të tjera. Prandaj, si emulator në këtë nivel përdoren FPGA, e cila ndihmon për të rritur ndjeshëm performancën.
Grafiku më poshtë tregon varësinë e përafërt të shpejtësisë së simulimit nga detajizimi i modelit.
Simulimi me taktime
Pavarësisht shpejtësisë së ulët të ekzekutimit, simulatorët mikroarkitekturore janë mjaft të zakonshëm. Modelimi i blloqeve të brendshme të procesorit është i nevojshëm për të simuluar me saktësi kohën e ekzekutimit për çdo instruksion. Këtu mund të ndodhin keqkuptime – sepse, siç duket, pse thjesht nuk marrim dhe programojmë kohën e ekzekutimit për çdo instruksion. Por një simulator i tillë do të punonte shumë jo saktë, pasi koha e ekzekutimit për të njëjtin instruksion mund të ndryshojë nga thirrja në thirrje.
Një shembuj më i thjeshtë është instruksioni i qasjes në memorie. Nëse qeliza e memorjes e kërkuar është e arritshme në cache, atëherë koha e ekzekutimit do të jetë minimale. Nëse nuk ka informacion në cache ("mungesë cache", cache miss), atëherë kjo do ta rrisë ndjeshëm kohën e ekzekutimit të instruksionit. Pra, për një simulim të saktë, është e nevojshme një model cache. Megjithatë, modeli i cache-it nuk është i mjaftueshëm. Procesori nuk do të presë thjesht për të marrë të dhëna nga memoria në rast se ato nuk janë në cache. Në vend të kësaj, ai do të fillojë të ekzekutojë instruksione të tjera, duke zgjedhur ato që nuk varen nga rezultati i leximit nga memoria. Kjo quhet ekzekutimi "jashtë rendit" (OOO, out of order execution), e nevojshme për të minimizuar kohën e pritjes së procesorit. Marrja parasysh e të gjitha këtij gjatë llogaritjes së kohës së ekzekutimit të instrukcioneve do të ndihmojë modelimi i blloqeve përkatëse të procesorit. Ndër këto instrukcione, të ekzekutuara ndërkohë që pritet rezultati i leximit nga memoria, mund të ndodhet operacioni i kalimit kushtor. Nëse rezultati i ekzekutimit të kushtit nuk është i njohur në këtë moment, përsëri procesori nuk e ndalon ekzekutimin, por bën një "supozim", ekzekuton kalimin përkatës dhe vazhdon të ekzekutojë parazgjedhjen instruksioneve nga vendi i kalimit. Një bllok i tillë, i quajtur parashikues kalimi (branch predictor), gjithashtu duhet të zbatohet në simulatorin mikroarkitektural.
Imazhi më poshtë tregon blloqet kryesore të procesorit; njohja e saj nuk është e detyrueshme, ajo është e përfshirë vetëm për të treguar kompleksitetin e zbatimit mikroarkitektural.
Funksionimi i të gjithë këtyre blloqeve në një procesor real sinkronizohet me sinjale të veçanta takti, ashtu si ndodh edhe në model. Një simulator i tillë mikroarkitekturor quhet i saktë në cikle (cycle accurate). Qëllimi kryesor i tij është të parashikojë me saktësi performancën e procesorit të zhvilluar dhe/ose të llogarisë kohën e ekzekutimit të një programi të caktuar, për shembull, ndonjë bençmark. Nëse vlerat do të ishin më të ulëta se ato të nevojshme, do të kërkohej të përmirësohen algoritmet dhe blloqet e procesorit ose të optimizohet programi.
Siç u tregua më sipër, simulaimi në cikle është shumë i ngadalshëm, prandaj përdoret vetëm për hulumtimin e disa çështjeve të caktuara të funksionimit të programit, ku është e nevojshme të dihet shpejtësia reale e ekzekutimit të programeve dhe të vlerësohet performanca e ardhshme e pajisjes, prototipi i së cilës po simulohet.
Në këtë rast, për simulaimin e pjesës tjetër të kohës së punës së programit përdoret një simulator funksional. Si ndodh kjo përdorim i kombinuar në praktikë? Fillimisht запускësohet simulatori funksional, në të cilin ngarkohet sistemi operativ dhe të gjithë e nevojshëm për ekzekutimin e programit të hulumtimit. Ne nuk jemi të interesuar për vetë sistemin operativ, as për fazat fillestare të запускimit të programit, konfigurimin e tij dhe të tjera. Megjithatë, ne gjithashtu nuk mund ta kalojmë këto pjesë dhe të kalojmë direkt në ekzekutimin e programit nga mes. Prandaj, të gjithë këto etapa paraprake kalohen në simulatorin funksional. Pas ekzekutimit të programit deri në momentin që na intereson, ka dy mundësi. Mund të zëvendësohet modelin me një model të saktë në cikle dhe të vazhdohet ekzekutimi. Režimi i simulaimit, ku përdoret kodi ekzekutues (dmth. skedarët e zakonshëm të kompiluar të programeve), quhet simulacioni i bazuar në ekzekutim (execution driven simulation). Ky është varianti më i zakonshëm i simulaimit. Gjithashtu, është e mundur edhe një qasje tjetër – simulimi i bazuar në gjurmë (trace driven simulation).
Simulimi i bazuar në gjurmë
Ai përbëhet nga dy hapa. Me ndihmën e simulatorit funksional ose në një sistem të vërtetë, mblidhen dhe regjistrohen në një skedar log-un e veprimeve të programit. Ky log quhet gjurmë (trace). Në varësi të asaj që po hulumtohet, gjurma mund të përfshijë instrukcionet e ekzekutueshme, adresat e memories, numrat e porteve, informacionin për ndalesat.
Hapi tjetër është "përshkrimi" i gjurmuar, kur simuluesi me taksa lexon gjurmën dhe ekzekuton të gjitha udhëzimet e shkruara në të. Në fund, ne marrim kohën e ekzekutimit të këtij seksioni të programit, si dhe karakteristika të ndryshme të këtij procesi, për shembull, përqindjen e goditjeve në karak.
Një veçori e rëndësishme e punës me gjurmët është determinizmi, dmth, duke ekzekutuar simulimin në mënyrën e përshkruar më lart, herë pas here ne riprodhojmë një sekuencë të njëjtë veprimesh. Kjo ofron mundësinë, duke ndryshuar parametrat e modelit (masat e karak, buferëve dhe radhëve) dhe duke përdorur algoritme të ndryshme të brendshme ose duke i konfiguruar ato, të studiojmë se si një ose tjetër parametr ndikon në performancën e sistemit dhe cili opsion ofron rezultatet më të mira. Të gjitha këto mund të realizohen me modelin prototip të pajisjes deri në krijimin e një prototipi të vërtetë harduerik.
Sfidat e këtij qasje qëndrojnë në nevojën për një ekzekutim paraprak të aplikacionit dhe mbledhjen e gjurmës, si dhe madhësinë e madhe të skedarit të gjurmës. Një përfitim është se mjafton të modeloni vetëm pjesën interesante të pajisjes ose platformës, ndërkohë që simulimi i ekzekutimit kërkon zakonisht modelin e plotë.
Pra, në këtë artikull ne shqyrtuam veçoritë e simulimit të plotë të platformës, folëm për shpejtësinë e implementimeve në nivele të ndryshme, simulimin me taksa dhe gjurmët. Në artikullin tjetër do të përshkruaj skenarët kryesorë të përdorimit të simuluesve, si për qëllime personale, ashtu edhe nga pikëpamja e zhvillimit në kompani të mëdha.
Burimi: habr.com
