Se você usa um Apple Silicon Mac, tenho certeza de que ficou impressionado com seu desempenho. Esteja você trabalhando com imagens, áudio, vídeo ou software de construção, desfrutamos de uma nova velocidade desde o M1 no primeiro dia. Embora a maioria atribua isso aos seus núcleos de desempenho, como acompanha o nome, na verdade, muito é o resultado dos desconhecidos núcleos de eficiência e como eles mantêm as tarefas em segundo plano onde deveriam estar.
Para entender o que quero dizer, inicie o Apple Silicon Mac do frio e abra o Activity Monitor na visualização da CPU, com a janela Histórico da CPU aberta também. Durante os primeiros cinco a dez minutos, você verá que seus núcleos E são uma parede vermelha e verde com os serviços de indexação do Spotlight, CGPDFService, media analyzed, BackgroundShortcutRunner, componentes Siri, seu backup inicial do Time Machine e, muitas vezes, uma verificação do XProtect Remediator. Enquanto isso, seus núcleos P estão praticamente ociosos e, se você começar a usar seus aplicativos de trabalho, há bastante capacidade para que eles funcionem sem serem afetados por toda aquela confusão em segundo plano.
É essa fase que assusta quem ainda está acostumado a usar Macs Intel. Ver processos usando mais de 100% da CPU é assustador, porque eles sabem que os núcleos da Intel podem sofrer com tanta carga, afetando os aplicativos dos usuários. Mas em um Apple Silicon Mac, quem percebe ou se importa que há mais de uma dúzia de processos mdworker, cada um consumindo bons 50% da CPU simultaneamente? Afinal, é para isso que a arquitetura de silício da Apple foi projetada. É certo que a impressão não é ajudada por um terrível pedaço de psicologia, já que os núcleos E a 100% estão provavelmente funcionando a uma frequência de um quarto dos núcleos P mostrados aos mesmos 100%, tornando a comparação visual completamente falsa.
Isso não é novidade. A Apple o trouxe para o iPhone 7 em 2016, em seu primeiro SoC com núcleos P e E separados. Essa é uma implementação do big.LITTLE da Arm anunciada em 2011, e um trabalho de desenvolvimento na Cray e em outros lugares na década anterior. O que faz a diferença nos Macs de silício da Apple é como os threads são alocados para os dois tipos diferentes de núcleos de CPU com base em uma métrica conhecida como Qualidade de Serviço, ou QoS.
Tal como acontece com tantas outras coisas nos Macs de hoje, o QoS existe desde o OS X 10.10 Yosemite, seis anos antes de se tornar tão central no desempenho. Quando todos os núcleos da CPU são iguais, a utilidade é limitada em relação aos controles mais tradicionais, como o do Posix. nice prioridade de agendamento. Todas essas tarefas em segundo plano ainda precisam ser concluídas, e dar-lhes uma prioridade mais baixa apenas prolonga o tempo que ocupam nos núcleos da CPU e o período em que os aplicativos do usuário competem com eles pelos ciclos da CPU.
Com a experiência adquirida com seus iPhones e outros dispositivos, os engenheiros da Apple tiveram uma solução melhor para futuros Macs. Além de fornecer filas baseadas em prioridade, a QoS faz uma distinção fundamental entre os threads executados em primeiro plano e os de segundo plano. Embora os threads de primeiro plano sejam executados em núcleos P quando estiverem disponíveis, eles também podem ser agendados em núcleos E quando necessário. Mas normalmente não é permitido que threads em segundo plano sejam executados em núcleos P, mesmo que sejam atrasados pela carga nos núcleos E aos quais estão restritos. Sabemos disso devido à nossa incapacidade de promover threads de segundo plano existentes para execução em núcleos P usando o App Tamer da St. Clair Software e a ferramenta de comando taskpolicy.
É por isso que, mesmo se você sentar e observar todos os processos em segundo plano carregando os núcleos E imediatamente após a inicialização, deixando os núcleos P quase ociosos, o macOS não tentará executá-los em seus núcleos P. Se isso acontecesse, mesmo que você quisesse, a distinção entre primeiro e segundo plano, os núcleos P e E começariam a desmoronar, nossos aplicativos sofreriam como consequência e a duração da bateria diminuiria. Já se foram os dias em que os processos do mdworker travavam, deixando nossos Macs de joelhos com uma bola de praia girando a cada poucos segundos.
Se ver todos esses processos usando alta porcentagem de CPU pode parecer assustador, a consequência inevitável em termos de arquitetura de software pode parecer assustadora. Em vez de criar aplicativos monolíticos, muitas de suas tarefas agora são divididas em processos discretos executados em segundo plano sob demanda, nos núcleos E, quando apropriado. O fato de um Mac inativo ter mais de 2.000 threads em execução em mais de 600 processos é uma boa notícia, e quanto mais deles forem executados nos núcleos E, mais rápidos serão nossos aplicativos. Os primeiros e últimos chips da série M a ter apenas dois núcleos E foram o M1 Pro e o Max, desde quando cada um tinha pelo menos quatro núcleos E, e alguns até seis ou oito.
Porque os núcleos de eficiência retiram os threads de segundo plano dos núcleos que precisamos para desempenho.
Fonte: theverge
