Cursurile 04 și 05 au tratat energia din perspectiva hardware-ului. Acest curs trece direct la codul pe care îl scrieți: cum influențează alegerea algoritmului, accesul la memorie și structura buclelor consumul măsurabil al unui program, cum se construiește o buclă software de management energetic, și cum poate un program să anticipeze încărcarea viitoare pentru a alege proactiv punctul DVFS potrivit.
1Obiectul și structura cursului6 min
Există o presupunere frecventă și greșită: că economia de energie e mai ales o problemă de hardware, iar software-ul „doar rulează" pe ce i se oferă. În realitate, aceleași cerințe pot fi implementate cu diferențe de consum de ordinul zecilor de procente, doar prin felul în care e scris codul - fără nicio schimbare de hardware.
- Puterea dinamică CMOS depinde pătratic de tensiune - DVFS exploatează exact asta (Curs 04-05)
- Legea lui Amdahl limitează beneficiul paralelismului (Curs 05)
- Timpul de break-even decide dacă o tranziție într-un mod de consum redus e rentabilă (Curs 05)
Rezultate ale învățării
- Să recunoașteți optimizări de algoritm, cod și memorie cu impact energetic real
- Să proiectați o buclă software de monitorizare și control energetic
- Să decideți când DMA e mai eficient energetic decât un transfer controlat de CPU
- Să alegeți între politici reactive, predictive și hibride de management energetic
- Să aplicați și să comparați metode simple de predicție a încărcării pentru DVFS software
2Rolul software-ului în consumul energetic6 min
Atenția se îndreaptă adesea, implicit, spre hardware când discutăm consum: procesor, memorii, convertoare, senzori. Dar software-ul decide cât timp rămân aceste componente active, cu ce frecvență, în ce ordine și cu ce date - deci decide cea mai mare parte a profilului energetic real al sistemului.
3Optimizarea energetică la nivel de algoritm și cod9 min
Cea mai eficientă metodă de reducere a energiei software e eliminarea activității care nu trebuie executată deloc - o optimizare la nivel de algoritm poate evita milioane de instrucțiuni, în timp ce o micro-optimizare locală economisește uneori doar câteva cicluri.
E_algoritm = N_op·E_op + N_mem·E_mem + E_control + E_I/O.
Complexitatea asimptotică (notația O) descrie evoluția numărului de operații, dar
nu include costul diferit al operațiilor, accesările de memorie sau optimizările
compilatorului - un algoritm „mai bun" teoretic poate fi mai costisitor energetic în practică.Pentru un vector ordonat cu N=1.000.000 elemente: căutarea liniară necesită, în cel mai nefavorabil caz, N=1.000.000 comparații; căutarea binară necesită ⌈log₂N⌉ ≈ 20 comparații - diferență de ordine de mărime. Dar: căutarea binară cere date ordonate și acces aleator; dacă vectorul trebuie sortat pentru o singură căutare, costul sortării poate depăși economia. Alegerea corectă depinde de numărul de căutări, frecvența modificării datelor și memoria disponibilă - nu doar de complexitatea asimptotică izolată.
Calcul incremental în loc de recalculare
O medie glisantă calculată „direct" însumează toate cele N elemente ale ferestrei la fiecare eșantion nou. Varianta incrementală actualizează doar diferența:
// S[k] = S[k-1] + x[k] - x[k-N] running_sum += new_value; running_sum -= oldest_value; const float average = running_sum / static_cast<float>(window_size);
Numărul de operații scade radical - dar trebuie păstrat un buffer circular cu valorile precedente, deci energia economisită prin calcul trebuie comparată cu energia accesărilor suplimentare ale buffer-ului. Tiparul „recunoașteți munca redundantă și eliminați-o" revine constant la optimizarea energetică software.
4Optimizări la nivel de cod8 min
| Tehnică | Idee | Atenție la... |
|---|---|---|
| Mutarea calculului invariant în afara buclei | nu recalcula o valoare constantă la fiecare iterație | compilatorul optimizant face asta automat, dacă poate demonstra invarianța |
| Tip de dată cu dimensiune explicită (uint8_t) | economisește memorie și lățime de bandă | procesorul poate oricum calcula pe registre de 32 biți - nu garantează viteză |
| Deplasare în loc de împărțire la 2ⁿ | o instrucțiune mai ieftină | compilatorul face de regulă transformarea automat; pentru valori cu semn, rezultatul poate diferi |
| Evaluare short-circuit (&&, ||) | plasați verificarea ieftină și des falsă prima | nu schimbați ordinea dacă funcțiile au efecte secundare |
| Loop unrolling | mai puține comparații/ramificații de control | codul mai mare poate crește accesările Flash - efect invers celui dorit |
Alocarea/dealocarea dinamică introduce timp de administrare, fragmentare, comportament temporal variabil și accesări suplimentare de memorie. În sistemele real-time și cu memorie limitată se preferă adesea buffere statice, pool-uri de obiecte sau alocare realizată o singură dată, la inițializare - previzibilitate în plus, cost de administrare în minus.
O activitate rulează inițial 20 ms la P_activ = 50 mW. După optimizarea codului, durează 12 ms. Care e economia de energie, doar din scurtarea timpului activ?
Vezi rezolvarea
E₁ = 50 mW × 20 ms = 1 mJ
E₂ = 50 mW × 12 ms = 0,6 mJ
Economie = (1 - 0,6)/1 × 100% = 40%
Dacă sistemul intră apoi în repaus, cele 8 ms eliberate produc o economie suplimentară, indirectă. Atenție însă: dacă scurtarea timpului a cerut creșterea tensiunii (pentru a rula mai repede), energia totală poate crește, nu scădea - evaluați mereu întregul punct de funcționare, nu doar timpul.
5Optimizarea accesului la memorie și a transferurilor de date13 min
În sistemele embedded moderne, energia deplasării datelor poate fi comparabilă sau chiar mai mare decât energia operațiilor aritmetice efectuate asupra lor - optimizarea memoriei e la fel de mult o problemă energetică pe cât e una de performanță.
E_transfer = N_accesări·E_acces + N_biți·E_bit. Se reduce prin
scăderea numărului de accesări, a numărului de biți transferați, sau a distanței dintre
memoria folosită și unitatea de calcul.Memoria e organizată ierarhic: registre (cele mai rapide, capacitate minimă) → cache/TCM → SRAM internă → Flash intern → RAM/Flash externe → stocare externă/rețea (cele mai lente, capacitate maximă, energie per acces cea mai mare). Principiul cheie e localitatea: localitatea temporală (o valoare folosită recent va fi probabil refolosită curând) și spațială (după accesarea unei locații, e probabilă accesarea vecinelor) - proprietăți pe care se bazează întreaga eficiență a memoriilor cache.
for (std::size_t i = 0; i < size; ++i) sum += data[i]; // secvențial - eficient for (std::size_t i = 0; i < size; ++i) sum += data[index[i]]; // indirect - mai multe ratări cache
Accesul secvențial folosește eficient liniile de cache și transferurile în rafală; accesul
indirect poate sări la locații îndepărtate, generând ratări cache suplimentare, plus costul
citirii vectorului de indici. Similar, pentru matrice în C/C++ (stocate pe linii), parcurgerea
for(row) for(column) e mult mai eficientă decât inversarea buclelor.
Procesarea în blocuri (blocking/tiling) păstrează o regiune de date în memoria locală
și o reutilizează înainte de a încărca următorul bloc - tehnica din spatele înmulțirii de
matrice, procesării de imagini și convoluțiilor eficiente. Reutilizarea se măsoară prin
R_reutilizare = N_operații / N_transferuri_externe - o valoare mare înseamnă că
fiecare valoare încărcată e folosită de multe ori înainte de a fi „aruncată".
DMA versus transfer controlat de procesor
E_DMA = E_configurare + E_transfer + E_finalizare versus
E_CPU = E_instrucțiuni + E_transfer + E_așteptare. DMA e avantajos dacă
E_DMA < E_CPU - pentru transferuri foarte scurte, configurarea DMA poate fi mai
costisitoare decât o simplă copiere; pentru blocuri mari sau transferuri periodice, DMA
câștigă aproape mereu, pentru că procesorul poate intra în repaus cât timp transferul are
loc.Chiar și structurile de date contează: câmpurile unei structuri pot fi aliniate de compilator cu spații libere (padding), mărind memoria ocupată. Reordonarea câmpurilor de la cel mai mare la cel mai mic tip reduce adesea acest padding, fără nicio schimbare funcțională a codului.
6Power-Aware Software și bucla de control energetic11 min
O aplicație eficientă energetic reduce simultan durata activității și numărul activărilor resurselor.
E_ciclu = Σ Pᵢ·Tᵢ + Σ E_tranziție,j - energia poate fi redusă
prin scurtarea stărilor cu putere ridicată, selectarea unor stări cu putere mai redusă,
reducerea numărului de tranziții, gruparea activităților și eliminarea activărilor inutile.Dacă un senzor trebuie citit de mai multe ori într-un interval scurt, poate fi mai eficient să rămână activ până la finalizarea întregului grup de măsurători, decât să fie pornit și oprit pentru fiecare eșantion individual. Dacă, în schimb, măsurătorile sunt separate de intervale lungi, menținerea senzorului activ între ele produce energie irosită - decizia depinde de durata inactivității, timpul de stabilizare și energia de pornire, exact logica timpului de break-even discutată în Cursul 05.
Bucla software de monitorizare și control energetic
Un software „power-aware" tipic funcționează ca o buclă de control cu cinci pași: (1) monitorizarea stării sistemului (încărcare CPU, nivel baterie, temperatură, evenimente), (2) estimarea necesarului de performanță, (3) alegerea configurației energetice (frecvență, tensiune, stare), (4) aplicarea configurației, (5) verificarea rezultatului și a deadline-urilor.
minimizează E_total, sub T_răspuns ≤ T_max,
N_deadline_ratate = 0, Q_serviciu ≥ Q_min. Politica nu
urmărește exclusiv minimizarea energiei - un sistem de control trebuie să răspundă la timp,
iar un dispozitiv de comunicație trebuie să respecte ferestrele protocolului.Calitatea serviciului (Q_serviciu) poate însemna rata de eșantionare, precizia măsurătorilor, debitul comunicației sau rata de cadre, în funcție de aplicație - definiția ei corectă e primul pas al oricărei bucle de control energetic bine proiectate.
7Modele software pentru estimarea consumului6 min
Pentru a lua decizii bune, bucla de control energetic are nevoie de o estimare a consumului - măsurarea directă, în timp real, cu instrumente de precizie, nu e mereu posibilă pe dispozitivul țintă. Există două abordări complementare: modele bazate pe instrucțiuni/blocuri de cod (fiecărui tip de instrucțiune sau bloc funcțional i se asociază o energie estimată, dintr-un tabel calibrat) și modele bazate pe profilare și stări (energie asociată direct stărilor de execuție observate: activ, acces memorie, periferic activ, sleep).
8Managementul software al stărilor energetice8 min
Gestiunea stărilor energetice discutată la nivel hardware în Cursul 05 (DPM) are un corespondent direct la nivel software: sistemul de operare sau firmware-ul trebuie să decidă explicit când schimbă starea unei resurse, ce context salvează înainte de tranziție, și cum restaurează contextul la trezire.
Sursele de trezire tipice (timer, pin extern, watchdog, periferic de comunicație) trebuie configurate explicit de software înainte de intrarea în modul de consum redus - o sursă de trezire uitată înseamnă un sistem care nu se mai trezește niciodată, sau unul care rămâne mereu activ „de siguranță", anulând orice beneficiu energetic.
9Break-Even Time, revizitat la nivel software6 min
Timpul de break-even (T_BE = E_tr / (P_A - P_S), introdus în Cursul 05) e, la
nivel software, criteriul explicit pe care o rutină de management energetic îl evaluează înainte
de fiecare tranziție posibilă. Diferența practică: la nivel software, T_BE trebuie estimat
online, din măsurători sau istoricul recent, nu doar citit static dintr-o foaie tehnică -
comportamentul real poate varia cu temperatura, starea bateriei sau versiunea de firmware.
Pentru sisteme cu mai multe stări succesive de consum (Idle → Sleep → Deep Sleep), fiecare prag are propriul T_BE, iar politica software trebuie să aleagă cea mai profundă stare al cărei T_BE e depășit de inactivitatea estimată - nu automat cea mai profundă disponibilă.
10Politici software: reactive, predictive și hibride8 min
Cursul 05 a introdus politicile reactive (timeout) și predictive la nivel conceptual. La nivel software, apar și variante hibride, cu mecanisme suplimentare de stabilizare.
| Politică | Principiu | Compromis |
|---|---|---|
| Reactivă (timeout) | intră în repaus după T_idle ≥ T_timeout | simplă, dar energie irosită în așteptarea timeout-ului |
| Predictivă | estimează inactivitatea viitoare din istoric/tipare | mai precisă, dar mai complexă și expusă erorilor de predicție |
| Hibridă cu histerezis | praguri diferite pentru intrare și ieșire din repaus | evită oscilația rapidă între stări ("chattering") |
Fără histerezis, un sistem aflat chiar la pragul de timeout poate oscila rapid între activ și repaus dacă încărcarea variază ușor în jurul pragului - fiecare tranziție costă energie (vezi T_BE), deci oscilația repetată poate consuma mai mult decât a rămâne pur și simplu activ. Politicile practice limitează explicit rata tranzițiilor, chiar cu prețul unei reacții ușor mai lente.
11Predicția încărcării și DVFS controlat software13 min
Pentru DVFS controlat software, sistemul trebuie să anticipeze încărcarea viitoare
pentru a alege proactiv frecvența potrivită, nu doar reactiv, după ce întârzierea a apărut deja.
Încărcarea unui interval se definește ca W_n = T_activ,n / T_interval (de exemplu,
W=0,7 înseamnă procesor ocupat 70% din interval).
| Metodă | Formulă | Caracter |
|---|---|---|
| PAST | Ŵ_{n+1} = W_n | reacție rapidă, sensibilă la variații bruște |
| FLAT | Ŵ_{n+1} = W_fix | stabilă, dar nu se adaptează la încărcarea reală |
| LONG_SHORT | Ŵ_{n+1} = α·W_scurt + (1-α)·W_lung | compromis reacție/tendință, reglabil prin α |
| AGED_AVERAGE | Ŵ_{n+1} = β·W_n + (1-β)·Ŵ_n | medie exponențială, filtrează variațiile |
| CYCLE | Ŵ_{n+1} = W_{n+1-k} | bună pentru sarcini periodice cu perioadă k cunoscută |
| PEAK | Ŵ_{n+1} = max(W_{n-k+1},...,W_n) | evită subestimarea, dar tinde spre frecvențe mai mari |
Încărcările recente: W_{n-2}=40%, W_{n-1}=55%, W_n=70%. Care e predicția pentru intervalul următor, cu metodele PAST, AGED_AVERAGE (β=0,3, predicție precedentă 50%) și PEAK (fereastră de 3)?
Vezi rezolvarea
PAST: Ŵ_{n+1} = 70% (ultima valoare observată)
AGED_AVERAGE: Ŵ_{n+1} = 0,3 × 70 + 0,7 × 50 = 56%
PEAK: Ŵ_{n+1} = max(40, 55, 70) = 70%
Cele trei metode produc rezultate vizibil diferite (56% vs. 70%) pentru aceeași secvență de observații - alegerea metodei potrivite depinde de cât de „zgomotoasă" sau periodică e sarcina reală a aplicației. Nu există o metodă universal superioară.
Odată aleasă o predicție a încărcării, selecția punctului DVFS trebuie să adauge o marjă de siguranță (similar cu M_f din Cursul 05), pentru a acoperi eroarea de predicție fără a rata deadline-uri - iar predictorul însuși trebuie evaluat continuu prin: energia consumată, eroarea de predicție, numărul de tranziții DVFS declanșate și numărul de deadline-uri ratate. Un predictor „precis" dar care declanșează tranziții DVFS foarte frecvente poate fi, per total, mai costisitor decât unul mai simplu și mai stabil.
12Management energetic în sistemele embedded moderne6 min
În sistemele embedded moderne, managementul energetic nu mai e o singură buclă izolată, ci o coordonare între mai multe niveluri: hardware-ul oferă stările și tranzițiile posibile, sistemul de operare (sau firmware-ul, pe bare-metal) planifică sarcinile ținând cont de energie - nu doar de prioritate - iar aplicația raportează constrângeri de calitate a serviciului către nivelurile de dedesubt.
Planificarea sarcinilor „energy-aware" poate grupa sarcini compatibile pentru a maximiza ferestrele de repaus comune, în loc să le trateze independent. Sistemele robuste adaugă și telemetrie (raportarea periodică a stării energetice reale) și moduri de funcționare degradată - un dispozitiv cu baterie aproape descărcată poate reduce explicit rata de eșantionare sau dezactiva funcții neesențiale, în loc să se oprească brusc și imprevizibil.
13Erori frecvente5 min
- „Un algoritm cu complexitate asimptotică mai bună e mereu mai eficient energetic." Fals - notația O ignoră costul diferit al operațiilor, accesările de memorie și optimizările compilatorului. Căutarea binară poate pierde în fața celei liniare dacă necesită sortare prealabilă costisitoare pentru o singură căutare. Evaluați întotdeauna scenariul complet (numărul de operații reale, frecvența lor, costul inițializării), nu doar formula de complexitate.
- „Optimizarea manuală agresivă a codului e mereu benefică." Compilatoarele moderne fac deja eliminarea codului mort, propagarea constantelor și vectorizarea automat - optimizarea manuală poate uneori împiedica aceste transformări. Măsurați întotdeauna efectul real (timp și energie), nu presupuneți-l - optimizarea prematură, neverificată, poate face mai mult rău decât bine.
- „Cea mai agresivă politică de intrare în repaus e mereu cea mai bună." Fără histerezis sau limitarea ratei de tranziții, o politică prea agresivă poate oscila rapid între stări, plătind costul de tranziție de multe ori fără beneficiu net. Adăugați întotdeauna histerezis sau o limită minimă de timp între tranziții consecutive.
14Rezumat și glosar5 min
Software-ul nu doar rulează pe hardware-ul disponibil - decide, prin fiecare alegere de algoritm, structură de date și tipar de acces la memorie, cât de aproape ajunge sistemul real de limitele energetice teoretice ale hardware-ului. O buclă explicită de monitorizare și control energetic, cu constrângeri clare de calitate a serviciului, transformă gestiunea energiei dintr-o preocupare implicită într-o parte activă a arhitecturii software. Iar pentru DVFS proactiv, alegerea metodei de predicție a încărcării (PAST, AGED_AVERAGE, CYCLE, PEAK etc.) are un impact măsurabil, care depinde de tiparul real al sarcinii aplicației.
15Întrebări de verificare6 min
- De ce complexitatea asimptotică nu descrie complet energia unui algoritm?
- Ce este batching-ul (gruparea activităților) și când e avantajos?
- Descrieți cei cinci pași ai unei bucle software de control energetic.
- Când este DMA mai eficient energetic decât un transfer controlat direct de procesor?
- Ce este histerezisul într-o politică de management energetic și de ce previne "chattering"?
- Comparați metodele PAST și AGED_AVERAGE de predicție a încărcării.
- De ce un predictor foarte "reactiv" (precum PAST) poate să nu fie cea mai bună alegere?
16Direcții de aprofundare2 min
Cursurile 04-06 au format un bloc coerent despre energie: de unde vine, cum se reduce prin hardware, și cum se reduce prin software. Cursul următor schimbă complet subiectul: modele de execuție și planificare în sistemele embedded de timp real - cum garantăm că o sarcină critică respectă întotdeauna termenul limită, indiferent de ce altceva rulează în paralel pe același procesor.
Tehnicile din acest curs (batching, structuri de date compacte, DMA) se aplică direct în Laboratorul 01 și Laboratorul 02, unde puteți măsura efectul lor real asupra consumului.