2013/06/12

Como o OS X Mavericks Poupa Bateria


A Apple fez uma apresentação impressionante com os seus novos MB Air, prometendo praticamente o dobro da autonomia relativamente aos modelos anteriores. Em parte isso é conseguido graças aos novos CPUs Haswell da Intel; mas o software tem também uma palavra a dizer, e o novo OS X Mavericks usa truques bem interessantes para poupar energia, como a compressão de memória, App Nap, e sincronização dos eventos (Timer Coalescing).

Vamos espreitar como funciona cada um deles mais em detalhe:



Com a compressão de memória, o novo OS X é capaz de comprimir os conteúdos menos utilizados que permanecem em memória, libertando memória para os processos activos, e evitando que essas páginas antigas tenham que ser "despejadas" para um paging file no disco. Mesmo quando se tratam de velozes discos SSD, o processo de compressão em RAM é muito mais eficiente - tornando-se ainda mais vantajoso em sistemas que usem discos mecânicos, que nem necessitarão entrar em funcionamento.


Para as Apps que estão a ser excutadas em background, o OS X pode limitar a utilização do CPU que lhes é atribuída usando o "App Nap" assim como baixar a frequência dos seus processos de funcionamento (embora os developers possam especificar que a app necessite de continuar a usar todo o processamento disponível). Para a maioria das apps significa que uma app em segundo plano não ficará a gastar recursos desnecessariamente, tanto em CPU, como em memória, como até na prioridade de acesso ao disco.


O Timer Coalescing é algo igualmente interessante (e que não imagino porque terá demorado tantas décadas para que um OS "popular" implementasse tal coisa). A grande maioria das apps utiliza temporizadores para funcionar. Embora para o utilizador uma App pareceça estar constantemente à nossa espera, internamente os processos passam a maior parte do tempo "parados", executando operações apenas a intervalos de tempo específicos, para saber se algo já foi processado, se há uma nova ligação WiFi disponível, etc. etc.



Isso faz com que um CPU esteja quase continuamente a responder a estas necessidades dos diversos processos e programas que estão a ser executados, fazendo com que só muito raramente possa entrar em modos de menor consumo de energia.

Com o Timer Coalescing, a coisa passa a ser feita de forma diferente.


Em vez de cada app estar a funcionar ao seu próprio ritmo, o OS X Mavericks é capaz de ajustar ligeiramente os seus temporizadores de forma a que ocorram ao mesmo tempo. Desta forma o CPU pode processar tudo de uma vez e regressar rapidamente a um modo de poupança de energia sem que seja imediatamente "acordado" devido a uma tarefa fora de tempo que pudesse surgir.

Muito provavelmente, será este o principal responsável pela maior fatia da poupança energética, a par das melhorias que os CPUs da série Haswell permitem.


... Eu só fico intrigado por ver este tipo de coisa só agora ser implementado (tanto a compressão da RAM, como esta sincronização dos temporizadores, como a redução da prioridade das apps em background) já que são coisas que eu consideraria como "lógicas" de implementar em qualquer sistema operativo.

Ainda no outro dia na nossa mailing list falávamos da "burrice" dos sistemas operativos não saberem tirar o melhor partido do hardware que têm: como por exemplo, a "necessidade" de manter um paging file no Windows mesmo que se tenham 32GB de RAM no sistema, ou a dificuldade de conseguir dizer que o sistema deveria usar a RAM para área temporária, um SSD para dados de acesso mais imediato e frequente, e um disco tradicional para dados de acesso menos frequente ou que não dependam da velocidade de acesso. (E torna-se ainda mais caricato quando se fala disto quase meia década depois de coisas como esta).

... Mas compreendo que sejam coisas que interessam apenas a um minoria que se preocupa com a máxima eficiência do sistema, e que ficam "irritados" quando vêem o hardware ser subaproveitado ou usado de forma pouco eficiente.

9 comentários:

  1. "A grande maioria das apps utiliza temporizadores para funcionar." What??? Já há muito tempo que as aplicações são orientados a eventos.
    Acho indiscutível que eles tenham conseguido espremer a bateria à custa principalmente de software, mas essa conversa parece treta.
    Vão sincronizar processos para quê?... para que corram ao mesmo tempo e fiquem à espera que os restantes libertem recursos?
    O CPU pode ter 4 cores, mas o resto é único e partilhado.

    ResponderEliminar
    Respostas
    1. Sabes que os eventos não acontecem por "magia" certo? Tirando os poucos eventos gerados directamente por interrupts de hardware, a grande maioria recorre a "soft-interrupts" que estão pendurados nos timers do sistema - ou seja, o "scheduler" que se encarregue em decidir quando e como atribuir tempo do CPU a cada processo.

      As vantagens são óbvias: será o equivalente a estares numa fila de trânsito em pára-arranca contínuo que te obriga a ter o motor a trabalhar e passares 5 minutos para fazer 100m; ou esperares que se acumulem "100 metros" de espaço livre à tua frente para ligares o carro e andares tudo de uma só vez em poucos segundos.

      Eliminar
    2. Bem, não sei se você sabe, mas a memoria cache não trabalha desse geito, até porque essa gambiarra só vai esgotar inutilmente os endereços.

      Isso só prova que o marketing da Apple morreu, o OSx é o sistema mais lerdo e pesado de todos, alem de não ser devidamente otimizado, portanto querem iludir o consumidor de que estão a melhor algo.

      Eliminar
    3. @molho

      Não percebi o teu comentário de "esgotar endereços" nem tão pouco o que "cache" tem a ver com "task-scheduling" que era o que se estava a falar).

      Nem tão pouco o que isto tem a ver com "marketing", já que é uma coisa que só programadores de nível médio-avançado irão perceber.

      Recomendo que quem esteja interessado espreite algo como isto, para ficar com uma noção mais técnica do que tentei explicar em termos mais comuns (neste caso é sobre o linux, mas o princípio é o mesmo em todos os kernel usados nos OS modernos): http://oreilly.com/catalog/linuxkernel/chapter/ch10.html

      Eliminar
    4. Este comentário foi removido pelo autor.

      Eliminar
    5. Não percebi... independentemente de hardware ou de soft-interrupts as threads não estão activas enquanto os listeneres não despertarem (os motores não estão ligados com o semáforo vermelho).
      Como tu disseste, são os schedulers e outros tipos de mecanismos do SO de gestão de acesso concorrencial aos recursos, que gerem isso... não são as aplicações que estão constantemente a perguntar "are we there yet?". Um install wizzard no ecrã de EULA está zombie até o utilizador carregar "next" ou "cancel", não está a gastar ciclos de CPU a perguntar se os botões foram premidos.

      O gráfico "diz" que o que estão a fazer é adormecer o sistema nos intervalos de tempo em "branco". Isso traduz-se numa coisa apenas: cortar a frequência do CPU. Se eu tenho um CPU de 1GHz a funcionar um segundo inteiro, se ele funcionar apenas durante 200ms, na prática tenho 200MHz de processamento útil. Isso já é feito em parte pelos cpu governors. Se realmente isso força o "adormecimento" do sistema, vamos ter um SO a trabalhar aos soluços, porque ora está adormecido, ora acordam as threads todas ao mesmo tempo.

      Voltando ao meu ponto inicial, esse Timer Coalescing parece-me bullshit... ao contrario do Project Butter explicado aqui: http://abertoatedemadrugada.com/2012/06/google-apresenta-android-41-jelly-bean.html agora que me lembrei de comprar, até esse gráfico, a somar a várias outras coisas anunciadas na WWDC, parece uma imitação do que já foi feito antes pela concorrência. xD

      Eliminar
    6. Tens "milhões" de casos com timers a correr. Desde um programa que use algo para mostrar uma animação no ecrã, ou actualizar o relógio, a coisas tão básicas como um tooltip que aparecem durante x tempo no ecrã quando passas com um rato por cima de um elemento; ou um browser com dezenas de tabs abertas, cada uma com uma "ligação aberta" como a que te permite fazer com que um Google te faça um instant search, ou o Facebook te diga que tens chats ou mensagens novas, ou o Twitter actualize o feed; ou coisas bem mais "profundas" nas centenas de processos do sistema.

      Mesmo com todos os timers activos a serem sincronizados, não me parece que seja suficiente para "soluçar" um sistema. Um CPU actual passa 90% do tempo desocupado (e estou a olhar para o meu que já é bem antiguinho) - para além de que o processamento pendurado em timers é logo à partida (ou deveria ser) "lightweight" para não atascar a máquina.

      E atenção que isto são coisas que não são específicas ou limitadas ao OS X (que calhou de ser o visado por ter sido apresentado com foco nestes elementos). Tal como o Marc Solèr referiu, também o Kernel 3.10 dá uso a técnicas semelhantes... Ou será que também consideras que o pessoal do Linux é dado a marketings de treta? ;)

      Eliminar
  2. Piada é como estas "novas" melhorias surgem com a release da Linux Kernel 3.10 com características semelhantes ;)

    ResponderEliminar
    Respostas
    1. Como disse, só fico surpreendido é por isto não ser algo já implementado há anos!

      Eliminar