Në pjesën e dytë të artikullit mbi simulatorët e sistemeve kompjuterike, do të vazhdoj të flas në një formë të thjeshtë informuese për simulatorët kompjuterikë, veçanërisht për simulimin e plotë të platformës, me të cilin shpesh përballet përdoruesi i zakonshëm, si dhe për modelin e ciklit dhe rrugët, të cilat janë më të zakonshme në rrethin e zhvilluesve.
Në Të kam treguar se çfarë janë simulatorët 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ë platformës, se si të ndërtojmë rrugët, çfarë duhet të bëjmë më pas me to, si dhe për emulimin mikroarkitekturor të ciklit.
Simulatori i plotĂ« i platformĂ«s (full platform simulator), ose "NjĂ« nĂ« fushĂ« â nuk Ă«shtĂ« luftĂ«tar"
NĂ«se Ă«shtĂ« e nevojshme tĂ« shqyrtohet funksionimi i njĂ« pajisjeje specifike, siç Ă«shtĂ« karta rrjetike, ose tĂ« shkruhet softueri i saj ose drejtuesi, atĂ«herĂ« kjo pajisje mund tĂ« simulohet ndaras. MegjithatĂ«, pĂ«rdorimi i saj nĂ« izolim nga infrastruktura tjetĂ«r nuk Ă«shtĂ« shumĂ« i ŃĐŽĐŸĐ±shĂ«m. PĂ«r tĂ« Đ·Đ°ĐżŃŃĐșŃar drejtuesin pĂ«rkatĂ«s, do tĂ« kĂ«rkohen njĂ« procesor qendror, kujtesĂ«, qasje nĂ« busin pĂ«r transmetimin e tĂ« dhĂ«nave dhe tĂ« tjera. PĂ«r mĂ« tepĂ«r, pĂ«r funksionimin e drejtuesit nevojitet njĂ« sistem operativ (OS) dhe njĂ« shtresĂ« rrjeti. PĂ«rveç kĂ«saj, mund tĂ« kĂ«rkohet njĂ« gjenerator i veçantĂ« paketash dhe njĂ« server pĂ«r pranimin e pĂ«rgjigjeve.
Simulatori me platformĂ« tĂ« plotĂ« krijon njĂ« ambient pĂ«r tĂ« Đ·Đ°ĐżŃŃĐșŃar tĂ«rĂ« grupin e softuerit, i cili pĂ«rfshin gjithçka, duke filluar nga BIOS dhe bootloader dhe duke pĂ«rfunduar me OS-nĂ« dhe sistemet e saj tĂ« ndryshme, siç Ă«shtĂ« ato tĂ« njĂ«jta, drejtuesit, aplikacionet e nivelit pĂ«rdorues. PĂ«r kĂ«tĂ«, nĂ« tĂ« janĂ« realizuar modele software tĂ« shumicĂ«s sĂ« pajisjeve tĂ« kompjuterit: procesori dhe kujtesa, disku, pajisjet e input-output (tastiera, mice, ekran), si dhe ajo karta rrjetike.
Më poshtë është një diagramë blloku e chipset-it x58 nga kompania Intel. Në një simulator të plotë të platformës kompjuterike mbi këtë chipset është e nevojshme realizimi i shumicës së pajisjeve të renditura, duke përfshirë edhe ato që ndodhen brenda IOH (Input/Output Hub) dhe ICH (Input/Output Controller Hub), të cilat nuk janë vizatuar në mënyrë të detajuar në diagramën e bllokut. Megjithatë, siç tregon praktika, nuk janë shumë pajisje që përdoren nga softueri që ne planifikojmë të ekzekutojmë. Modelet e këtyre pajisjeve mund të mos krijohen.
Shpesh, simulatorĂ«t e plotĂ« tĂ« platformĂ«s realizohen nĂ« nivelin e instrukcioneve tĂ« procesorit (ISA, shiko. ). Kjo lejon qĂ« tĂ« krijohet relativisht shpejt dhe me kosto tĂ« ulĂ«t vetĂ« simulatori. Niveli ISA gjithashtu Ă«shtĂ« i mirĂ« sepse mbetet mĂ« shumĂ« ose mĂ« pak konstant, nĂ« kundĂ«rshtim me, pĂ«r shembull, nivelin API/ABI, i cili ndryshon mĂ« shpesh. PĂ«r mĂ« tepĂ«r, implementimi nĂ« nivelin e instrukcioneve lejon ekzekutimin e ashtuquajturit softuer binar i modifikuar, domethĂ«nĂ« tĂ« ekzekutohet kodi i kompiliaur pa asnjĂ« ndryshim, nĂ« tĂ« njĂ«jtin format siç pĂ«rdoret nĂ« harduerin e vĂ«rtetĂ«. Me fjalĂ« tĂ« tjera, mund tĂ« bĂ«het njĂ« kopje (âdumpâ) e hard diskut, ta caktosh atĂ« si imazh pĂ«r modelin nĂ« simulatorin multifunksional dhe â voilĂ ! â OS dhe programet e tjera ngarkohen nĂ« simulator pa ndonjĂ« veprim shtesĂ«.
Performanca e simulatorëve
Siç u përmend më lart, procesi i simulimit të gjithë sistemit, domethënë të gjitha pajisjeve të tij, është një aktivitet që nuk është shumë i shpejtë. Nëse për më tepër e realizojmë këtë në një nivel shumë të detajuar, si në atë mikroarkitekturor apo logjik, përfundimi do të bëhet ekstremisht i ngadalshëm. Por niveli i instrukcioneve është një zgjedhje e përshtatshme dhe lejon që sistemi operativ dhe programet të funksionojnë me shpejtësi të mjaftueshme për një ndërveprim të rehatshëm me to.
Këtu është e përshtatshme të prekemi në temën e performancës së simuluesve. Zakonisht, ajo matet në IPS (instruksione për sekondë), më saktësisht në MIPS (miliona IPS), domethënë numri i instrukcioneve të procesorit që simuluesi ekzekuton brenda një sekonde. Në të njëjtën kohë, shpejtësia e simulimit varet gjithashtu nga performanca e sistemit në të cilin funksionon vetë simulimi. Prandaj, ndoshta, do të ishte më e saktë të flisnim për "ngadalësimin" (slowdown) e simuluesit në krahasim me sistemin origjinal.
Simulatorët më të njohur në treg, si QEMU, VirtualBox ose VmWare Workstation, kanë performancë të mirë. Për përdoruesin, nuk është e dukshme që puna po zhvillohet në një simulator. Kjo ndodh falë një mundësie të veçantë të virtualizimit e realizuar në procesorë, algoritme të përkthimit binar dhe gjërave të tjera interesante. Kjo është një temë për një artikull të veçantë, por nëse do ta thoshim shkurt, virtualizimi është një mundësi harduerike e procesorëve modernë që lejon simulatorët të mos simullojnë instrukcionet, por t'i japin ato për ekzekutimin direkt në procesorin real, nëse, sigurisht, arkitekturat e simulatorit dhe të procesorit janë të ngjashme. Përkthimi 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ë simullojmë 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 hostit shumëprocesor dhe efektivisht shpërndajnë bërthamat e simuluara në bërthamat e procesorit real.
Nëse flasim për shpejtësinë e simulimit të mikroarkitekturës, ajo është zakonisht disa renditje më e ulët, rreth 1000-10000 herë më e ngadalshme se sa ekzekutimi në një kompjuter të zakonshëm, pa simulim. Dhe implementimet në nivelin e elementëve logjikë janë akoma më të ngadalshme. Prandaj, si emulatore në këtë nivel përdoren FPGA, gjë që lejon një rritje të konsiderueshme të performancës.
Grafiku më poshtë tregon varësinë përafërsisht të shpejtësisë së simulimit nga detajizimi i modelit.
Simulimi me cikle
PavarĂ«sisht shpejtĂ«sisĂ« sĂ« ulĂ«t tĂ« ekzekutimit, simuluesit e mikroarkitekturĂ«s janĂ« mjaft tĂ« pĂ«rhapur. Modelimi i blloqeve tĂ« brendshme tĂ« procesorit Ă«shtĂ« i nevojshĂ«m pĂ«r tĂ« simuluar saktĂ«sisht kohĂ«n e ekzekutimit pĂ«r secilĂ«n instrukcion. KĂ«tu mund tĂ« lindĂ« njĂ« keqkuptim â sepse, duket sikur, pse thjesht tĂ« mos programosh kohĂ«n e ekzekutimit pĂ«r secilĂ«n instrukcion. Por njĂ« simulues i tillĂ« do tĂ« punojĂ« shumĂ« nĂ« mĂ«nyrĂ« tĂ« pasaktĂ«, pasi koha e ekzekutimit tĂ« tĂ« njĂ«jtĂ«s instrukcion mund tĂ« ndryshojĂ« nga njĂ« thirrje nĂ« tjetrĂ«n.
NjĂ« shembuj i thjeshtĂ« â udhĂ«zimi pĂ«r qasjen nĂ« memorie. NĂ«se qelia e kĂ«rkuar e memories Ă«shtĂ« e qasshme nĂ« cache, atĂ«herĂ« koha e ekzekutimit do tĂ« jetĂ« minimale. NĂ«se kjo informacion nuk ndodhet nĂ« cache («mangĂ«si cache», cache miss), atĂ«herĂ« kjo do ta rrisĂ« ndjeshĂ«m kohen e ekzekutimit tĂ« udhĂ«zimit. Prandaj, pĂ«r njĂ« simulim tĂ« saktĂ« Ă«shtĂ« e nevojshme njĂ« model cache. MegjithatĂ«, çështja nuk pĂ«rfundon me modelin e cache. Procesori nuk do tĂ« presĂ« thjesht pĂ«r tĂ« marrĂ« tĂ« dhĂ«nat nga memoria kur ato mungojnĂ« nĂ« cache. NĂ« vend tĂ« kĂ«saj, ai do tĂ« fillojĂ« tĂ« ekzekutojĂ« udhĂ«zime tĂ« ardhshme, duke zgjedhur ato qĂ« nuk varen nga rezultati i leximit nga memoria. Ky Ă«shtĂ« ekzekutimi i quajtur «jashtĂ« rendit» (OOO, out of order execution), e nevojshme pĂ«r tĂ« minimizuar kohĂ«n e pushimit tĂ« procesorit. TĂ« gjitha kĂ«to duhet tĂ« merren parasysh gjatĂ« llogaritjes sĂ« kohĂ«s sĂ« ekzekutimit tĂ« udhĂ«zimeve dhe do tĂ« ndihmojĂ« modelimi i blloqeve pĂ«rkatĂ«se tĂ« procesorit. NdĂ«rmjet kĂ«tyre udhĂ«zimeve, qĂ« ekzekutohen ndĂ«rsa pritet rezultati i leximit nga memoria, mund tĂ« hasĂ«sh njĂ« operacion kalimi tĂ« kushtĂ«zuar. NĂ«se rezultati i ekzekutimit tĂ« kushtit nuk Ă«shtĂ« i njohur nĂ« atĂ« moment, procesori pĂ«rsĂ«ri nuk ndalon ekzekutimin, por bĂ«n njĂ« «supozim», ekzekuton kalimin pĂ«rkatĂ«s dhe vazhdon tĂ« ekzekutojĂ« udhĂ«zimet nĂ« mĂ«nyrĂ« parazgjedhĂ«se nga vendi i kalimit. Ky bllok, i quajtur parashikues kalimi, gjithashtu duhet tĂ« implementohet nĂ« njĂ« simulator mikroarkitekturor.
Imazhi më poshtë tregon blloqet kryesore të procesorit, njohja e saj nuk është e domosdoshme, ajo është sjellë vetëm për të ilustruar kompleksitetin e implementimit mikroarkitekturor.
Puna e këtyre blloqeve në një procesor real sinkronizohet nga sinjale të veçanta taktimore, në mënyrë të ngjashme ndodh dhe në model. Një simulator i tillë mikroarkitekturor quhet i saktë në cikël (cycle accurate). Qëllimi i tij kryesor është të parashikojë saktësisht performancën e procesorit në zhvillim dhe/ose të llogarisë kohën e ekzekutimit të një programi të caktuar, për shembull, ndonjë benchmark. Nëse vlerat do të ishin më të ulëta se ato të nevojshme, do të duhej të rishikoheshin algoritmet dhe blloqet e procesorit ose të optimizohej programi.
Siç u tregua më sipër, simulimi i saktë në cikël është shumë i ngadalshëm, prandaj përdoret vetëm kur studiohen momente të caktuara të funksionit 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.
Për këtë, për simulimin e kohës së mbetur të funksionimit të programit përdoret një simulator funksional. Si ndodh një përdorim i tillë i kombinuar në realitet? Fillimisht, aktivizohet simulatori funksional, në të cilin ngarkohet sistemi operativ dhe gjithçka e nevojshme për të nisur programin e shqyrtuar. Ne nuk jemi të interesuar as për sistemin operativ vetë, as për fazat fillestare të nisjes së programit, konfigurimin e tij dhe të tjera. Megjithatë, nuk mund të kalojmë këto pjesë dhe të kalojmë menjëherë në ekzekutimin e programit nga mesi i tij. Prandaj, të gjitha këto faza preliminare kalohen në simulatorin funksional. Pasi programi të ekzekutohet deri në momentin që na intereson, ekzistojnë dy mundësi. Mund të zëvendësohet modeli me atë të taktimeve dhe të vazhdohet ekzekutimi. Rehimi i simulimit, ku përdoret kodi në ekzekutim (dmth. skedarët e zakonshëm të përpiluar të programeve), quhet simulim i udhëhequr nga ekzekutimi (execution driven simulation). Ky është variantet më i zakonshëm i simulimit. Një qasje tjetër e mundshme është simulimi i bazuar në gjurmë (trace driven simulation).
Simulimi i bazuar në gjurmë
Ajo është e ndarë në dy hapa. Me ndihmën e një simulatori funksional ose në një sistem real, krijohet dhe regjistrohet në një skedar logu i veprimeve të programit. Ky log quhet gjurmë (trace). Në varësi të asaj që po shqyrtohet, gjurma mund të përfshijë instrukcione ekzekutive, adresa memorjeje, numra portesh, informacione mbi ndërprerjet.
Hapi tjetër është "pasuese" e gjurmës, kur simulatori i ciklit lexon gjurmën dhe ekzekuton të gjitha instrukcionet e regjistruara në të. Në fund, merrni kohën e ekzekutimit të këtij segmenti të programit, si dhe karakteristika të ndryshme të këtij procesi, për shembull, përqindja e goditjeve në cache.
Një veçori e rëndësishme e punës me gjurmët është determinizmi, që do të thotë, duke nisur simulimin në mënyrën e përshkruar më arriba, herë pas here ne riprodhojmë të njëjtin rresht veprimesh. Kjo na jep mundësinë, duke ndryshuar parametrat e modelit (përmasat e ndihmës, buferëve dhe pritjeve) dhe duke përdorur algorithma të ndryshëm të brendshëm ose duke i konfiguruar ata, të shqyrtojmë se si një parametër i caktuar ndikon në performancën e sistemit dhe cili variant ofron rezultatet më të mira. Të gjitha këto mund të bëhen me modelin e prototipit të pajisjes përpara krijimit të prototipit të vërtetë harduerik.
Vështirësia e këtij qasjeje qëndron në nevojën për të kaluar paraprakisht aplikacionin dhe mbledhur gjurmën, si dhe madhësinë e madhe të skedarit me gjurmën. Një përfitim është se është e mjaftueshme të modelosh vetëm pjesën e interesit të pajisjes ose platformës, ndërsa simulimi sipas ekzekutimit zakonisht kërkon një model të plotë.
Pra ndaj, në këtë artikull ne shqyrtuam veçoritë e simulimit të plotë të platformës, biseduam për shpejtësinë e realizimeve në nivele të ndryshme, simulimin me takte dhe rrugët. Në artikullin e ardhshëm, do të përshkruaj skenarët kryesorë të përdorimit të simuluesve, si për qëllime personale, ashtu edhe nga këndvështrimi i zhvillimit në kompani të mëdha.
Burimi: habr.com
