Ho letto che i sistemi operativi come Android e iOS sono in qualche modo ottimizzati per migliorare la durata della batteria.
La mia comprensione è che una CPU esegue un certo numero di operazioni in un determinato momento, quindi penso che sia possibile accelerare le applicazioni riducendo il numero di operazioni richieste, ma poiché la CPU eseguirà comunque x operazioni in y tempo, ciò non dovrebbe influenzare il potere?
Inoltre, se un processo occupa più RAM, consuma più energia?
Risposte:
Le CPU comuni che vanno su smartphone, laptop e persino PC desktop hanno una frequenza di clock variabile. Quando lo scheduler rileva che ha un tempo di inattività, può ridurre la frequenza di clock e aumentarla di nuovo se ci sono più processi in competizione per il tempo della CPU.
Le CPU ottimizzate per i dispositivi alimentati a batteria tendono ad essere composte da molti componenti funzionali che hanno ciascuno il proprio clock (esempio: ARM Cortex A8 ). Quando un componente è inattivo, il sistema operativo può spegnerlo (o ridurne l'orologio), risparmiando energia. Ad esempio, su molte CPU multicore (come quelle nei dispositivi mobili di fascia alta), ogni core può essere acceso o spento separatamente. ARM è particolarmente bravo in questo gioco, che è uno dei motivi per cui la maggior parte degli smartphone ha CPU ARM.
Variare la frequenza di clock o spegnere l'orologio dei componenti elettronici è noto come gestione dell'alimentazione . Tende ad essere una parte complessa della scrittura e dell'ottimizzazione di un sistema operativo per un dispositivo alimentato a batteria, con molte dipendenze dal modello hardware esatto.
Ciò che vale per la CPU vale anche per le periferiche. Il display retroilluminato è un grande consumatore di energia su uno smartphone, ad esempio seguito dalla radio. Il sistema operativo della CPU può svolgere un ruolo nella gestione dell'alimentazione delle periferiche; i chip secondari eseguono anche un proprio firmware che esegue anche la gestione dell'alimentazione.
Le applicazioni hanno il loro ruolo da svolgere nel contenere i consumi energetici: devono consentire al sistema operativo di fare le sue cose. La cosa peggiore che un'applicazione possa fare è il polling: eseguire un ciclo simile while (not_ready()) {}. Anche introdurre un piccolo ritardo come in while (not_ready()) {usleep(100);}non aiuta perché non consente abbastanza tempo per il processore di passare alla modalità a basso consumo, o se lo fa, ogni sveglia infruttuosa significa spreco di energia. Pertanto, le API del sistema operativo devono essere progettate in modo tale che le applicazioni non debbano mai eseguire il polling, ma possano invece sottoscrivere un qualche tipo di meccanismo di evento e rimanere inattive fino a quando non vengono informate di un evento rilevante. Le applicazioni a loro volta devono sfruttare tali meccanismi, quindi la progettazione dell'intero stack software ha un impatto sul consumo energetico.
Puoi ottenere alcune informazioni su ciò che è responsabile del consumo energetico del tuo PC con l' utility Intel Powertop . Gli smartphone in genere hanno un modo per vedere quanta energia consumano anche le applicazioni. La contabilizzazione del consumo energetico per applicazione è precisamente difficile: se un componente si sveglia per due applicazioni, il tempo di sveglia può essere rappresentato in modo arbitrario in una di esse o in nessuna delle due; inoltre, il consumo energetico delle periferiche non è sempre facilmente rintracciabile per l'applicazione responsabile.
Un chip RAM non sa quale dei suoi bit memorizza i dati di un processo attivo, quindi non può essere disattivato selettivamente in questo modo. Il consumo di energia di un processo non è correlato alla quantità di memoria che utilizza (tranne nella misura in cui gli accessi RAM consumano energia, ma riutilizzare la stessa memoria o utilizzare aree RAM diverse non fa differenza rispetto al consumo energetico).
In termini di potenza del processore, la cosa principale che il sistema operativo può fare è fornire API che scoraggino le applicazioni dal polling. (E anche eliminare tutti i polling all'interno del kernel e dei driver di dispositivo, se presenti). Quindi il processore può essere messo in uno stato di sospensione a basso consumo ogni volta che non c'è nulla da fare.
Per ogni dispositivo deve esserci un modo per le app utente di andare a dormire dopo una richiesta e quindi svegliarsi di nuovo solo quando il risultato è pronto.
Ovviamente i cicli di polling stretti sono un disastro (perché mantengono il processore completamente sveglio ed eseguono noops e salti inutili.) Ma ci sono casi più sottili, ma quasi altrettanto negativi in cui l'app utente imposta i timer, si sveglia sull'allarme del timer, controlla qualche condizione, resettare il timer e tornare a dormire.
So di meno su questa parte, ma penso che potrebbero esserci anche modi creativi di usare controller DMA (accesso diretto alla memoria) per gestire lunghe stringhe di interruzioni ripetute senza riattivare il core del processore stesso.
Il ruolo principale del sistema operativo è fornire un ambiente di runtime il più indipendente possibile dall'hardware. Sa chi sta usando quale hardware, quando e come qualcuno sta usando l'hardware. Ciò consente al sistema operativo di ridurre il consumo di energia dell'hardware quando non viene utilizzato.
I moderni hardware offrono molti modi per ridurre il consumo energetico, come ad esempio
se un processo occupa più RAM, consuma più energia?
Non proprio. Tuttavia, se il tuo sistema ha 1 GB di DRAM, ma utilizzi solo 512 MB, con alcuni controller di memoria, è possibile interrompere l'aggiornamento della parte della DRAM, riducendo così il consumo di energia. LPDDR supporta Auto-aggiornamento dell'area parziale per fare lo stesso durante l'auto-aggiornamento (mentre il processore è fermo, il che è vero il più delle volte sui dispositivi mobili).
Come puoi vedere, ci sono molti modi per ridurre il consumo energetico delle architetture moderne, ma richiede al sistema operativo di gestirlo. Alcune funzionalità, come PASR, sono molto difficili da usare, ciò richiede molto lavoro sul sistema operativo per adattare la gestione della memoria, implementare procedure di sospensione / ripresa, ...
Come sicuramente saprai, il sistema operativo mantiene una varietà di elenchi. Due di questi elenchi sono l'elenco pronto e l'elenco timer. L'elenco pronto identifica quali attività / thread sono pronti per essere eseguiti. L'elenco dei timer identifica le attività / i thread che si trovano in uno stato bloccato con un timeout.
Immagina che il sistema operativo abbia un elenco pronto vuoto. Cioè, ha esaurito le attività che sono pronte per essere eseguite (è nello stato inattivo). Alcuni processori (come l'x86) hanno un'istruzione halt che il sistema operativo può invocare per far arrestare il processore fino a quando non viene risvegliato da un interrupt esterno (come un tick tick interrupt). Durante questo periodo di tempo, consuma meno energia. Questa tecnica può essere ulteriormente migliorata sbirciando nell'elenco dei timer. Se sei inattivo e sai che il più presto possibile che un'attività si riattivi da un timer è a 100 tick, la frequenza di tick può essere temporaneamente modificata per essere detta 100 volte più lenta. In questo modo, il processore può consumare ancora meno energia per un periodo di tempo più lungo perché non dovrà servire fino a 100 interruzioni di tick.
Una volta che arriva l'interrupt esterno, il tick rate dovrà essere ricalcolato. Se l'interruzione esterna ha reso pronta un'attività, il tick rate torna alla normalità. In caso contrario, il numero di tick per dormire deve essere ricalcolato insieme alla nuova frequenza di tick (rallentata).
Spero che questo ti aiuti.
Per aggiungere alle altre risposte: la
tua domanda riguarda iOS e Android come sistemi operativi ma il "Sistema operativo" è solo una parte di essi.
Sia Android che iOS sono framework e includono molte parti che non sono considerate parte del sistema operativo attuale ma sono attive nel ridurre il consumo energetico.
Ad esempio, Android di progettazione consente agli sviluppatori di applicazioni di salvare il proprio stato quando sono nascosti, quindi i processi possono essere interrotti quando non vengono utilizzati attivamente e quindi ridurre la quantità di thread pronti e consentire l'arresto del core e la riduzione della frequenza di clock.
Ci sono funzioni nel "sistema operativo" che impostano la luminosità adattiva, lo stato di sospensione del wi-fi, i thread di pulizia, il raggruppamento di programmi, gli indicatori LED, il comportamento in standby del cellulare e altri aspetti che incidono drasticamente sul consumo di energia.
Inoltre, alcune piattaforme mobili hanno lavorato duramente per ottimizzare il loro rapporto di utilizzo CPU / GPU, poiché la GPU è più adattata alla grafica ed è un'aggiunta relativamente nuova al panorama mobile, sempre più parti del sistema operativo legate alla grafica si stanno spostando verso la GPU, che cancella il lavoro dalla CPU e consente l'utilizzo delle ottimizzazioni di potenza della CPU (e in molti casi, velocizza anche il sistema nel suo insieme).