Software engineering deep level optimization - uvod u merenje - IV deo

Nastavljamo dalje sa merenjem te ovom prilikom prolazim kroz razloge zašto primenjena tehnika merenja prikazana u prošlom blog postu (broj III) nije tačna, te nam odokativno predočava koliko traje izvršavanje jednog dela programskog koda ili koda u celosti. Za analizu će se koristiti Concurrency Visualizer ekstenzija za Visual Studio.

Programski kod

Prvo ćemo napisati programski kod koji merimo. Dovoljno je koristiti for petlju koja ispisuje na konzoli Hello World!, jer ovde je zapravo poenta prikazati merenje, šta merimo i kako treba meriti koristeći Performance Counter-e umesto Start Date Time na početku izvršavanja main funkcije i End Date Time na kraju izvršavanja iste. Na screenshot-u dole prikazan je primer programskog koda koji se meri.
 
Programski kod koji se meri

Preemption Quantum i Interrupts

Koristeći Concurrency Visualizer za Visual Studio možemo grafički prikazati gde zapravo leži problem kod merenja ukoliko se ne koriste Performance Counter-i.

Concurrency Profiler
 
Zelenom bojom je uokviren main thread čiji ID je 6136. Main methoda u programskom kodu koji se meri se izvršava u okviru Windows OS procesa čiji je Main thread ID kao što je već spomenuto 6136. Pre nego što krene izvršavanje programa, Windows OS Threading Scheduler određuje na kojem procesorskom jezgru će se izvršavati dati thread (ukoliko isto nije programski određeno/forsirano), u isto vreme određuje se i time slice ili ti preemption quantum, to je vreme koje je Windows OS Threading Scheduler dodelio thredu koliko može maksimum da se izvršava na jezgru, te nakon isteka, sledi preemption i zamena sa drugim threadom nekog drugog procesa kao što je i Concurency Visualizer i prikazao, jer Windows OS je multitasking OS što znači da sa preemtpion-om (ukoliko imamo jedno procesorsko jezgro) simulira paralelno izvršavanje, samim tim što su vremenski quantum-i dovoljno mali, korisniku se daje utisak paralelizma, zapravo nije ukoliko se multitasking OS izvršava na jednom jezgru. Preemption Quantum se realizuje sistemskim tajmerom, što je hardware IRQ request prioriteta 0, što znači da kada istekne vremenski quantum, dolazi do sistemskog timer interrupta (prekid) koji Windows OS Threading Scheduler navodi da odabere koji je sledeći thread na redu za izvršavanje na istom jezgru. Izvršavanje main thread-a 6136 će biti prebačeno na drugo jezgro.

Upravo u tome i leži problem. Preemption, je Windows OS Threading Scheduler task, i njemu je takođe potrebno procesorsko vreme, sam context switch između jezgara jednog threada je takođe dodatni task te se dosta vremena gubi na OS specifik taskove čije vreme izvršavanja ne možemo uzimati u obzir, kada merimo koliko je vremena potrebno za izvršavanje našeg koda kojeg merimo. Vreme izvršavanja našeg koda je prikazano na slici zelenom bojom i samo to trebamo da uzimamo u obzir jer ostalo su OS specifik taskovi koji takođe zahtevaju procesorsko jezgro ali ne možemo da ih uzimamo u obzir. Ukoliko se koristi tehnika Start Date Time i End Date Time, onda se uzima u obzir kompletno izvršavanje, od trenutka startovanja do trenutka završetka, što znači da će to vreme biti mnogo veće jer računamo uz to i OS specifik taskove. Ukoliko koristimo Performance Countere, računamo samo vreme izvršavanja našeg programskog koda, prikazanog zelenom te dobijamo tačno koliko je potrebno vreme izvršavanja našeg programskog koda, dok sve ostale taskove, OS specifik, zanemarujemo.

CPU Cores Thread Context Switch

Slika gore, prikazuje, kako main thread naše aplikacije menja izvršavanje sa jezgra na jezgro, jer Windows OS Threading Scheduler određuje isto, usled isteka vremenskog quantuma ili usled interrupta većeg prioriteta.

U narednim blogovima o merenju nastavljamo dalje sa Performance Counter-ima.

Autor
Vladimir Savić
zilsel-invent

Comments

Popular posts from this blog

Electrolytic capacitors and design rules

Fake VC830L digital multimeter

How to design LM324 Astable Multivibrator