He leído que los sistemas operativos como Android e iOS están optimizados de alguna manera para mejorar la duración de la batería.
Según tengo entendido, una CPU ejecuta una cierta cantidad de operaciones en un tiempo determinado, por lo que creo que puede acelerar las aplicaciones reduciendo la cantidad de operaciones requeridas, pero dado que la CPU aún realizará x operaciones en y tiempo, eso no debería afectar el poder?
Además, si un proceso ocupa más RAM, ¿consume más energía?
Respuestas:
Las CPU comunes que se usan en teléfonos inteligentes, computadoras portátiles e incluso PC de escritorio tienen una frecuencia de reloj variable. Cuando el planificador detecta que tiene tiempo de inactividad, puede reducir la velocidad del reloj y aumentarla nuevamente si hay más procesos que compiten por el tiempo de CPU.
Las CPU optimizadas para dispositivos alimentados por batería tienden a estar compuestas de muchos componentes funcionales que tienen cada uno su propio reloj (ejemplo: ARM Cortex A8 ). Cuando un componente está inactivo, el sistema operativo puede apagarlo (o reducir su reloj), lo que ahorra energía. Por ejemplo, en muchas CPU multinúcleo (como las de los dispositivos móviles de gama alta), cada núcleo se puede encender o apagar por separado. ARM es particularmente bueno en este juego, que es una de las razones por las cuales la mayoría de los teléfonos inteligentes tienen CPU ARM.
Variar la frecuencia del reloj o apagar el reloj de los componentes electrónicos se conoce como administración de energía . Tiende a ser una parte compleja de la escritura y la optimización de un sistema operativo para un dispositivo alimentado por batería, con muchas dependencias del modelo de hardware exacto.
Lo que se aplica a la CPU también se aplica a los periféricos. La pantalla retroiluminada es un gran consumidor de energía en un teléfono inteligente, por ejemplo, seguido de la radio. El sistema operativo de la CPU puede desempeñar un papel en la administración de energía de los periféricos; los chips secundarios también ejecutan su propio firmware que también realiza la administración de energía.
Las aplicaciones tienen su papel en mantener el consumo de energía bajo: deben permitir que el sistema operativo haga lo suyo. Lo peor que puede hacer una aplicación es sondear: ejecutar un ciclo como while (not_ready()) {}. Incluso la introducción de un pequeño retraso while (not_ready()) {usleep(100);}no ayuda, ya que no permite suficiente tiempo para que el procesador entre en modo de bajo consumo de energía, o si lo hace, cada despertador infructuoso significa energía desperdiciada. Por lo tanto, las API del sistema operativo deben estar diseñadas para que las aplicaciones nunca necesiten sondear, sino que pueden suscribirse a algún tipo de mecanismo de evento y permanecer inactivas hasta que se les notifique un evento relevante. Las aplicaciones a su vez deben aprovechar dichos mecanismos, por lo que el diseño de toda la pila de software tiene un impacto en el consumo de energía.
Puede obtener información sobre los responsables del consumo de energía de su PC con la utilidad Intel Powertop . Los teléfonos inteligentes generalmente tienen una manera de ver cuánta energía han consumido las aplicaciones también. Es difícil tener en cuenta el consumo de energía por aplicación con precisión: si un componente se activa para dos aplicaciones, el tiempo de activación puede contabilizarse a una de ellas de manera arbitraria o a ninguna; El consumo de energía de los periféricos tampoco siempre se puede rastrear fácilmente a la aplicación responsable.
Un chip RAM no sabe cuál de sus bits almacena datos de un proceso activo, por lo que no se puede apagar selectivamente de esta manera. El consumo de energía de un proceso no está relacionado con la cantidad de memoria que usa (excepto en la medida en que los accesos de RAM consumen energía, pero volver a usar la misma memoria o usar diferentes áreas de RAM no hace ninguna diferencia con respecto al consumo de energía).
En términos de potencia del procesador, lo principal que puede hacer el sistema operativo es proporcionar API que desalienten el sondeo de las aplicaciones. (Y también elimine todos los sondeos dentro del núcleo y los controladores de dispositivo si hubiera alguno). Luego, el procesador puede ponerse en un estado de reposo de baja potencia siempre que no haya nada que hacer.
Para cada dispositivo, debe haber una manera de que las aplicaciones del usuario se suspendan después de una solicitud y luego se despierten nuevamente solo cuando el resultado esté listo.
Obviamente, los bucles de sondeo ajustados son un desastre (porque mantienen el procesador completamente despierto y ejecutan saltos y saltos inútiles). Pero hay casos más sutiles, pero casi tan malos, en los que la aplicación del usuario está configurando temporizadores, activando la alarma del temporizador, verificando alguna condición, reiniciando el temporizador y volviendo a dormir.
Sé menos sobre esta parte, pero creo que también puede haber formas creativas de usar controladores DMA (acceso directo a memoria) para manejar largas cadenas de interrupciones repetidas sin despertar el núcleo del procesador.
La función principal del sistema operativo es proporcionar un entorno de tiempo de ejecución lo más independiente posible del hardware. Sabe quién está usando qué hardware, cuándo y cómo alguien lo está usando. Esto permite que el sistema operativo reduzca el consumo de energía del hardware cuando no se usa.
Los hardwares modernos ofrecen muchas formas de reducir el consumo de energía, como
Si un proceso ocupa más RAM, ¿consume más energía?
Realmente no. Sin embargo, si su sistema tiene 1 GB de DRAM, pero solo usa 512 MB, con algunos controladores de memoria, es posible dejar de actualizar parte de la DRAM, reduciendo así el consumo de energía. LPDDR admite la actualización automática de área parcial para hacer lo mismo mientras se actualiza automáticamente (mientras el procesador está detenido, lo cual es cierto la mayoría de las veces en dispositivos móviles).
Como puede ver, hay muchas formas de reducir el consumo de energía en arquitecturas modernas, pero requiere que el sistema operativo lo maneje. Algunas características, como PASR, son muy difíciles de usar, esto requiere mucho trabajo en el sistema operativo para adaptar la gestión de memoria, implementar procedimientos de suspensión / reanudación, ...
Como sin duda sabe, el sistema operativo mantiene una variedad de listas. Dos de estas listas son la lista lista y la lista del temporizador. La lista lista identifica qué tareas / subprocesos están listos para ejecutarse. La lista del temporizador identifica las tareas / subprocesos que están en estado bloqueado con un tiempo de espera.
Imagine que el sistema operativo tiene una lista lista vacía. Es decir, se ha quedado sin tareas que están listas para ejecutarse (está en estado inactivo). Algunos procesadores (como el x86) tienen una instrucción de detención que el sistema operativo puede invocar para hacer que el procesador se detenga hasta que sea despertado por una interrupción externa (como una interrupción por tic). Durante este período de tiempo, consume menos energía. Esta técnica se puede mejorar aún más al mirar la lista del temporizador. Si está inactivo y sabe que lo más pronto que una tarea puede despertarse de un tic del temporizador está a 100 tics de distancia, la tasa de tick puede modificarse temporalmente para decir 100 veces más lento. De esta manera, el procesador puede gastar incluso menos energía durante un período de tiempo más largo porque no tendrá que atender hasta 100 interrupciones de tic.
Una vez que llega la interrupción externa, la tasa de tick tendrá que ser recalculada. Si la interrupción externa preparó una tarea, la tasa de tics vuelve a la normalidad. De lo contrario, se debe volver a calcular el número de tics para dormir junto con la nueva tasa de tics (más lenta).
Espero que esto ayude.
Para agregar a las otras respuestas:
su pregunta considera a iOS y Android como sistemas operativos, pero el "Sistema operativo" es solo una parte de ellos.
Tanto Android como iOS son marcos e incluyen muchas partes que no se consideran parte del sistema operativo real pero que son activas para reducir el consumo de energía.
Por ejemplo, Android, por diseño, permite a los desarrolladores de aplicaciones guardar su estado cuando están ocultos, por lo que los procesos pueden finalizar cuando no se usan activamente y, por lo tanto, reducir la cantidad de subprocesos listos y permitir el apagado del núcleo y la reducción de la frecuencia de reloj.
Hay características en el "SO" que configuran el brillo adaptativo, el estado inactivo de la conexión wi-fi, los hilos de limpieza, la agrupación programada, los indicadores LED, el comportamiento de espera celular y otros aspectos que afectan drásticamente el consumo de energía.
Además, algunas plataformas móviles han estado trabajando arduamente para optimizar su relación de uso de CPU / GPU, ya que la GPU está más adaptada a los gráficos y es una adición relativamente nueva al panorama móvil, cada vez más partes del sistema operativo relacionadas con gráficos se están moviendo a la GPU, que elimina el trabajo de la CPU, y permite el uso de optimizaciones de potencia de la CPU (y en muchos casos, también acelera el sistema en su conjunto).