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
