Në pjesën e dytë të artikullit në lidhje me simulatorët e sistemeve kompjuterike, do të vazhdoj të flas në një formë të thjeshtë hyrëse për simulatorët kompjuterikë, përkatësisht për simulimin e plotë të platformës, me të cilin haset më shpesh përdoruesi mesatar, si dhe për orarin. -modeli i orës dhe gjurmët, të cilat janë më të zakonshme në rrethet e zhvilluesve.
В Unë fola për atë që janë simulatorët në përgjithësi, si dhe për nivelet e simulimit. Tani, bazuar në këtë njohuri, unë propozoj të zhytem pak më thellë dhe të flasim për simulimin e platformës së plotë, si të mbledhim gjurmët, çfarë të bëjmë me to më vonë, si dhe për emulimin mikroarkitekturor orë pas ore.
Simulator i plotë i platformës, ose "I vetëm në fushë nuk është një luftëtar"
Nëse dëshironi të studioni funksionimin e një pajisjeje specifike, për shembull, një kartë rrjeti, ose të shkruani firmware ose një drejtues për këtë pajisje, atëherë një pajisje e tillë mund të simulohet veçmas. Sidoqoftë, përdorimi i tij i izoluar nga pjesa tjetër e infrastrukturës nuk është shumë i përshtatshëm. Për të ekzekutuar drejtuesin përkatës, do t'ju duhet një procesor qendror, memorie, akses në një autobus të të dhënave, etj. Përveç kësaj, drejtuesi kërkon një sistem operativ (OS) dhe një grup rrjeti për të funksionuar. Përveç kësaj, mund të kërkohet një gjenerues i veçantë i paketave dhe një server përgjigjeje.
Një simulator me platformë të plotë krijon një mjedis për ekzekutimin e një grupi të plotë softuerësh, i cili përfshin gjithçka, nga BIOS dhe ngarkuesi i ngarkimit deri te vetë OS dhe nënsistemet e tij të ndryshme, të tilla si grupi i njëjtë i rrjetit, drejtuesit dhe aplikacionet e nivelit të përdoruesit. Për ta bërë këtë, ai zbaton modele softuerike të shumicës së pajisjeve kompjuterike: procesor dhe memorie, disk, pajisje hyrëse/dalëse (tastierë, maus, ekran), si dhe të njëjtën kartë rrjeti.
Më poshtë është një diagram bllok i çipit x58 nga Intel. Një imitues kompjuteri me platformë të plotë në këtë chipset kërkon zbatimin e shumicës së pajisjeve të listuara, duke përfshirë ato brenda IOH (Input/Output Hub) dhe ICH (Input/Output Controller Hub), të cilat nuk janë paraqitur në detaje në diagramin bllok. . Edhe pse, siç tregon praktika, nuk ka shumë pajisje që nuk përdoren nga softueri që do të ekzekutojmë. Modelet e pajisjeve të tilla nuk kanë nevojë të krijohen.
Më shpesh, simulatorët me platformë të plotë zbatohen në nivelin e udhëzimeve të procesorit (ISA, shih më poshtë). ). Kjo ju lejon të krijoni vetë simulatorin relativisht shpejt dhe me kosto të ulët. Niveli ISA është gjithashtu i mirë sepse mbetet pak a shumë konstant, ndryshe nga, për shembull, niveli API/ABI, i cili ndryshon më shpesh. Për më tepër, zbatimi në nivelin e instruksionit ju lejon të ekzekutoni të ashtuquajturin softuer binar të pamodifikuar, domethënë të ekzekutoni kodin e përpiluar tashmë pa asnjë ndryshim, saktësisht siç përdoret në harduerin real. Me fjalë të tjera, ju mund të bëni një kopje ("dump") të hard drive tuaj, ta specifikoni atë si një imazh për një model në një simulator me platformë të plotë dhe voila! – Sistemi operativ dhe programet e tjera ngarkohen në simulator pa ndonjë veprim shtesë.
Performanca e simulatorit
Siç u përmend më lart, procesi i simulimit të të gjithë sistemit, domethënë të gjitha pajisjeve të tij, është një ndërmarrje mjaft e ngadaltë. Nëse i zbatoni të gjitha këto në një nivel shumë të detajuar, për shembull, mikroarkitektonik ose logjik, atëherë ekzekutimi do të bëhet jashtëzakonisht i ngadaltë. Por niveli i udhëzimit është një zgjedhje e përshtatshme dhe lejon që OS dhe programet të ekzekutohen me shpejtësi të mjaftueshme që përdoruesi të ndërveprojë me to me lehtësi.
Këtu do të ishte e përshtatshme të prekim temën e performancës së simulatorit. Zakonisht matet në IPS (instruksione për sekondë), më saktë në MIPS (miliona IPS), domethënë numri i udhëzimeve të procesorit të ekzekutuara nga simulatori në një sekondë. Në të njëjtën kohë, shpejtësia e simulimit varet gjithashtu nga performanca e sistemit në të cilin funksionon vetë simulimi. Prandaj, mund të jetë më e saktë të flasim për "ngadalësimin" e simulatorit në krahasim me sistemin origjinal.
Simulatorët më të zakonshëm me platformë të plotë në treg, si QEMU, VirtualBox ose VmWare Workstation, kanë performancë të mirë. Mund të mos jetë as e dukshme për përdoruesin që puna po zhvillohet në simulator. Kjo ndodh falë aftësive speciale të virtualizimit të zbatuara në procesorë, algoritme të përkthimit binar dhe gjëra të tjera interesante. E gjithë kjo është një temë për një artikull të veçantë, por me pak fjalë, virtualizimi është një veçori harduerike e përpunuesve modernë që lejon simuluesit të mos simulojnë udhëzime, por t'i dërgojnë ato për ekzekutim drejtpërdrejt në një procesor të vërtetë, nëse, sigurisht, arkitekturat e simulatori dhe procesori janë të ngjashëm. Përkthimi binar është përkthimi i kodit të makinës mysafir në kodin pritës dhe ekzekutimi pasues në një procesor real. Si rezultat, simulimi është vetëm pak më i ngadalshëm, 5-10 herë, dhe shpesh madje funksionon me të njëjtën shpejtësi si sistemi real. Edhe pse kjo ndikohet nga shumë faktorë. Për shembull, nëse duam të simulojmë një sistem me disa dhjetëra procesorë, atëherë shpejtësia do të bjerë menjëherë me këto dhjetëra herë. Nga ana tjetër, simulatorët si Simics në versionet e fundit mbështesin harduerin pritës me shumë procesor dhe në mënyrë efektive paralelizojnë bërthamat e simuluara në bërthamat e një procesori të vërtetë.
Nëse flasim për shpejtësinë e simulimit mikroarkitektonik, atëherë zakonisht është disa rend të madhësisë, rreth 1000-10000 herë më i ngadalshëm se ekzekutimi në një kompjuter të rregullt, pa simulim. Dhe zbatimet në nivelin e elementeve logjike janë më të ngadalta me disa renditje të madhësisë. Prandaj, një FPGA përdoret si emulator në këtë nivel, i cili mund të rrisë ndjeshëm performancën.
Grafiku më poshtë tregon një varësi të përafërt të shpejtësisë së simulimit nga detajet e modelit.
Simulim rrahje pas rrahje
Pavarësisht shpejtësisë së tyre të ulët të ekzekutimit, simuluesit mikroarkitekturorë janë mjaft të zakonshëm. Simulimi i blloqeve të brendshme të procesorit është i nevojshëm për të simuluar me saktësi kohën e ekzekutimit të çdo instruksioni. Këtu mund të lindë keqkuptim - në fund të fundit, do të duket, pse të mos programoni thjesht kohën e ekzekutimit për secilin udhëzim. Por një imitues i tillë do të jetë shumë i pasaktë, pasi koha e ekzekutimit të të njëjtit udhëzim mund të ndryshojë nga thirrja në thirrje.
Shembulli më i thjeshtë është një udhëzim për qasje në kujtesë. Nëse vendndodhja e kërkuar e memories është e disponueshme në cache, atëherë koha e ekzekutimit do të jetë minimale. Nëse ky informacion nuk është në cache ("misa e cache"), atëherë kjo do të rrisë shumë kohën e ekzekutimit të udhëzimit. Kështu, një model cache kërkohet për simulim të saktë. Sidoqoftë, çështja nuk kufizohet vetëm në modelin e cache. Procesori nuk do të presë thjesht që të dhënat të merren nga memoria kur ato nuk janë në cache. Në vend të kësaj, ai do të fillojë të ekzekutojë udhëzimet e ardhshme, duke zgjedhur ato që nuk varen nga rezultati i leximit nga kujtesa. Ky është i ashtuquajturi ekzekutim "jashtë rregullit" (OOO, ekzekutimi jashtë rendit), i nevojshëm për të minimizuar kohën e papunë të procesorit. Modelimi i blloqeve përkatëse të procesorit do të ndihmojë për të marrë parasysh të gjitha këto gjatë llogaritjes së kohës së ekzekutimit të udhëzimeve. Ndër këto udhëzime, të ekzekutuara ndërkohë që pritet rezultati i leximit nga kujtesa, mund të ndodhë një operacion kërcimi i kushtëzuar. Nëse rezultati i kushtit është i panjohur për momentin, atëherë përsëri procesori nuk e ndalon ekzekutimin, por bën një "supozim", kryen degën e duhur dhe vazhdon të ekzekutojë në mënyrë proaktive udhëzimet nga pika e tranzicionit. Një bllok i tillë, i quajtur një parashikues i degëve, duhet të zbatohet gjithashtu në simulatorin mikroarkitekturor.
Fotografia më poshtë tregon blloqet kryesore të procesorit, nuk është e nevojshme ta njohësh atë, është treguar vetëm për të treguar kompleksitetin e zbatimit mikroarkitekturor.
Funksionimi i të gjitha këtyre blloqeve në një procesor real sinkronizohet me sinjale të veçanta të orës, dhe e njëjta gjë ndodh edhe në model. Një simulator i tillë mikroarkitekturor quhet i saktë i ciklit. Qëllimi i tij kryesor është të parashikojë me saktësi performancën e procesorit që po zhvillohet dhe/ose të llogarisë kohën e ekzekutimit të një programi specifik, për shembull, një pikë referimi. Nëse vlerat janë më të ulëta se sa kërkohet, atëherë do të jetë e nevojshme të modifikoni algoritmet dhe blloqet e procesorit ose të optimizoni programin.
Siç u tregua më lart, simulimi orë pas ore është shumë i ngadaltë, kështu që përdoret vetëm kur studiohen momente të caktuara të funksionimit të një programi, ku është e nevojshme të zbulohet shpejtësia reale e ekzekutimit të programit dhe të vlerësohet performanca e ardhshme e pajisjes së cilës prototipi është duke u simuluar.
Në këtë rast, një simulator funksional përdoret për të simuluar kohën e mbetur të funksionimit të programit. Si ndodh ky kombinim i përdorimit në realitet? Së pari, lëshohet simulatori funksional, mbi të cilin ngarkohet OS dhe gjithçka e nevojshme për të ekzekutuar programin në studim. Në fund të fundit, ne nuk jemi të interesuar për vetë OS, as për fazat fillestare të nisjes së programit, konfigurimin e tij, etj. Sidoqoftë, ne gjithashtu nuk mund t'i anashkalojmë këto pjesë dhe menjëherë të kalojmë në ekzekutimin e programit nga mesi. Prandaj, të gjithë këta hapa paraprak ekzekutohen në një simulator funksional. Pasi programi të jetë ekzekutuar në momentin e interesit për ne, dy opsione janë të mundshme. Mund ta zëvendësoni modelin me një model orë pas cikli dhe të vazhdoni ekzekutimin. Mënyra e simulimit që përdor kodin e ekzekutueshëm (d.m.th. skedarët e programit të përpiluar të rregullt) quhet simulim i drejtuar nga ekzekutimi. Ky është opsioni më i zakonshëm i simulimit. Një qasje tjetër është gjithashtu e mundur - simulimi i drejtuar nga gjurma.
Simulimi i bazuar në gjurmë
Ai përbëhet nga dy hapa. Duke përdorur një simulator funksional ose në një sistem real, një regjistër i veprimeve të programit mblidhet dhe shkruhet në një skedar. Ky regjistër quhet gjurmë. Në varësi të asaj që ekzaminohet, gjurmimi mund të përfshijë udhëzime të ekzekutueshme, adresa të memories, numra portash dhe informacione për ndërprerjen.
Hapi tjetër është "luajtja" e gjurmës, kur simulatori orë pas ore lexon gjurmën dhe ekzekuton të gjitha udhëzimet e shkruara në të. Në fund, marrim kohën e ekzekutimit të kësaj pjese të programit, si dhe karakteristikat e ndryshme të këtij procesi, për shembull, përqindjen e goditjeve në cache.
Një tipar i rëndësishëm i punës me gjurmët është determinizmi, domethënë, duke e drejtuar simulimin në mënyrën e përshkruar më sipër, ne riprodhojmë vazhdimisht të njëjtën sekuencë veprimesh. Kjo bën të mundur, duke ndryshuar parametrat e modelit (madhësitë e cache, buffer dhe radhë) dhe duke përdorur algoritme të ndryshme të brendshme ose duke i akorduar ato, të studiohet se si një parametër i veçantë ndikon në performancën e sistemit dhe cili opsion jep rezultatet më të mira. E gjithë kjo mund të bëhet me një model pajisjeje prototip përpara se të krijohet një prototip aktual i harduerit.
Kompleksiteti i kësaj qasjeje qëndron në nevojën për të ekzekutuar fillimisht aplikacionin dhe për të mbledhur gjurmën, si dhe në madhësinë e madhe të skedarit të gjurmës. Përparësitë përfshijnë faktin se mjafton të simulohet vetëm pjesa e pajisjes ose platformës me interes, ndërsa simulimi me ekzekutim zakonisht kërkon një model të plotë.
Pra, në këtë artikull ne shikuam tiparet e simulimit të platformës së plotë, folëm për shpejtësinë e zbatimeve në nivele të ndryshme, simulimin orë pas cikli dhe gjurmët. Në artikullin vijues do të përshkruaj skenarët kryesorë të përdorimit të simulatorëve, si për qëllime personale, ashtu edhe nga pikëpamja e zhvillimit në kompanitë e mëdha.
Burimi: www.habr.com