Quão rápido pode ser um VM do macOS e quão pequeno ele pode ficar?

 (eclecticlight.co)
1 pontos por GN⁺ 1 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Ao medir novamente um VM do macOS 26.4.1 em um Mac mini M4 Pro, mesmo com configuração de 5 núcleos virtuais e 16 GB de vRAM, o desempenho de CPU single-core e de GPU ficou próximo ao do host
  • Segundo o Geekbench 6.7.1, a CPU single-core marcou 3.855 no VM vs. 3.948 no host, e a GPU Metal 106.896 no VM vs. 111.970 no host, o que corresponde a cerca de 98% e 95% do host, respectivamente
  • A CPU multi-core marcou 13.222 no VM vs. 23.342 no host; como o host tem 14 núcleos (10 P + 4 E) e o VM tem 5 núcleos virtuais, a comparação direta é difícil, mas o desempenho do VM é bastante bom
  • O ponto mais fraco foi o Neural Engine virtual, que ficou bem mais lento que o host em testes de meia precisão e quantização no CoreML; no VM, é razoável esperar que tarefas de IA sejam processadas por CPU e GPU
  • No teste de configuração mínima, mesmo com apenas 2 núcleos virtuais e 4 GB de memória, tarefas leves como Safari e a análise de armazenamento nos Ajustes funcionaram normalmente; considerando atualizações do macOS, o ideal é que o armazenamento do VM tenha pelo menos 60 GB

Contexto do teste

  • Os números de desempenho usados na análise sobre virtualização do macOS no Apple silicon eram medições anteriores e não abordavam as especificações mínimas para um VM utilizável
  • Com o aumento do interesse em executar VMs no MacBook Neo, o desempenho e a configuração mínima no macOS Tahoe foram verificados novamente

Medição e interpretação do desempenho

  • O host de teste é um Mac mini M4 Pro, com macOS 26.4.1, 14 núcleos (10 P + 4 E), 48 GB de RAM e SSD interno de 2 TB
  • Ao VM convidado foram atribuídos 5 núcleos virtuais e 16 GB de RAM virtual
  • As pontuações do Geekbench 6.7.1 ficaram ligeiramente melhores do que antes, tanto no host quanto no VM
  • Os resultados foram os seguintes
    • CPU single-core: VM 3.855, host 3.948
    • CPU multi-core: VM 13.222, host 23.342
    • GPU Metal: VM 106.896, host 111.970
    • Neural Engine CoreML: VM 5.291 / 8.577 / 6.877, host 5.973 / 41.251 / 56.616
  • Os três números do Neural Engine CoreML correspondem, nessa ordem, aos testes de precisão simples, meia precisão e quantização
  • O resultado de CPU multi-core é difícil de comparar diretamente, porque o host tem mais que o dobro de núcleos do VM, e 4 deles são núcleos E
  • A comparação de desempenho da GPU foi feita em condição na qual o host não estava competindo pelo uso da GPU ao mesmo tempo
  • Ao rodar no VM, é razoável esperar que o macOS processe tarefas de IA com CPU e GPU em vez de usar o Neural Engine

Teste de configuração mínima

  • Após o lançamento do MacBook Neo, surgiu interesse em saber se seria possível executar VMs nesse dispositivo
  • Para uso como host Linux, isso parecia viável, mas havia dúvida se seria possível fazer trabalho útil com um VM do macOS; nos testes reais, isso se mostrou possível
  • Para verificar a configuração mínima, o mesmo VM do macOS 26.4.1 foi executado no Viable com alocações progressivamente menores de núcleos de CPU e memória
  • A janela de exibição do VM foi configurada no padrão 1600 × 1000
  • Foram realizados usos variados do Safari e tarefas leves do dia a dia, incluindo a análise de armazenamento nos Ajustes
  • Os resultados por configuração foram os seguintes
    • Com 4 núcleos virtuais e 8 GB de vRAM, o VM funcionou com total fluidez, e o uso de memória ficou em cerca de 5 GB
    • Com 3 núcleos e 6 GB, o uso de memória caiu para 3,9 GB e todas as tarefas funcionaram bem
    • Com 2 núcleos e 4 GB de memória, foram usados apenas 3,1 GB, e tarefas leves continuaram funcionando normalmente
  • Um VM do macOS com apenas 2 núcleos virtuais e 4 GB de memória também parece viável no MacBook Neo e consegue lidar suficientemente bem com tarefas cotidianas
  • Esse tipo de VM não é um lugar para testar execução de LLMs, mas é plenamente utilizável para tarefas leves no macOS

Restrições de armazenamento e atualizações

  • Ao criar um VM em um Mac com SSD interno pequeno, é preciso ter cuidado com o tamanho do VM
  • Um VM do macOS muito menor que 50 GB acaba não conseguindo realizar atualizações do macOS
  • Para ter margem e segurança, o ideal é mirar em pelo menos 60 GB
  • No APFS, o VM é armazenado como arquivo esparso, então mesmo um VM padrão de 100 GB precisa de apenas cerca de 54 GB no disco real
  • Essa configuração pode ser acomodada de forma mais adequada em um MacBook Neo com SSD de 512 GB

Leituras relacionadas

1 comentários

 
GN⁺ 1 시간 전
Comentários do Hacker News

  • É um bom lembrete de que existe certa quantidade de memória atrelada a cada núcleo. Provavelmente isso tem mais a ver com cache de páginas ou coisas como tratamento de concorrência

    • Eu apostaria na hipótese nula. Se mantivessem fixo o número de núcleos e ajustassem apenas o tamanho da memória da VM, provavelmente teria aparecido a mesma variação no uso de memória
    • Em geral, a quantidade de memória física instalada no computador também deveria ser proporcional ao número de threads de hardware que a CPU oferece
      Não só porque o sistema operacional pode alocar alguma memória por thread, mas também porque apps multithread que usam todas as threads, como a compilação de grandes projetos de software, muitas vezes consomem memória de trabalho proporcional ao número de threads ativas
      Já vi muitos apps multithread funcionarem bem apenas com algo como 2 GB por thread no máximo, então para uma CPU desktop de 32 threads como o Ryzen 9 9950X, 64 GB faz bastante sentido
      Ao compilar projetos como Chrome/Chromium, se você tiver uma CPU de 16 núcleos/32 threads e só 32 GB de RAM, precisa reduzir o paralelismo da compilação com parâmetros adequados, como make -j, e deixar alguns núcleos ociosos. Caso contrário, pode acabar encontrando erros de falta de memória
    • É verdade que existe um overhead por núcleo, mas essa redução no uso provavelmente tem mais a ver com a mudança na forma como o kernel aloca memória quando a memória disponível diminui
      Quando há bastante memória, o kernel mantém o cache de leitura por mais tempo, prefere compressão de memória a swap em disco e limpa memória recuperável com menos frequência. O tamanho de buffers internos e da tabela de vnode também é ajustado com base na memória total
      Isso é bom no sentido de aproveitar dinamicamente ao máximo os recursos disponíveis, mas tem o custo de dificultar enxergar a linha de base mínima necessária para o funcionamento real
      Um comando interessante para conferir é vm_stat, que permite ver valores como páginas free/active/inactive/wired/purgeable, compressor, pagein/pageout e swapin/swapout. Edit: não sei se o suporte a Markdown com cerca de código não funciona, ou se fui eu que fiz algo errado

  • Comprei recentemente um M5 Air e, como é meu primeiro macOS, estou tentando entender essa parte, mas parece praticamente impossível ter ao mesmo tempo pytorch, aceleração por GPU e isolamento no nível de VM/contêiner
    A camada virtio-gpu parece ser a opção mais próxima, mas ao que tudo indica ela repassa apenas GPU gráfica, não GPU de computação, então não serve para pytorch

    • Eu também precisava disso e pesquisei bastante há cerca de um ano. Ainda não tive tempo de verificar as mudanças recentes em Docker Model Runner (vllm-metal) ou em podman libkrun, mas nenhum dos dois funcionou?
    • Consegui executar torch em uma instância Tart da Cirruslabs

  • A única experiência que tive com VM no macOS foi com colima+docker, e foi relativamente dolorosa e ineficiente. Ainda assim, dá para usar

    • Vale a pena testar a container CLI da Apple. Algumas semanas atrás, durante um fim de semana, consegui migrar um dos meus projetos de colima+docker com bastante facilidade
      https://github.com/apple/container
    • Comprei um Mac Mini para CI local e, querendo usá-lo com Forgejo Actions, examinei o ecossistema de forma ampla, mas no fim acabei optando por fazer o build no host
      Isolar do host a configuração de assinatura e notarização parecia difícil demais de administrar, mesmo usando um agente. Ainda assim, agora os builds no macOS estão realmente rápidos, e assinatura/notarização cabem em cerca de 200 linhas de Bash
    • OrbStack é bem bom. Não me parece particularmente ineficiente

  • https://github.com/trycua/cua/tree/main/libs/lume mostrou uma abordagem interessante para esse problema

  • Mesmo que use só 5 GB na inicialização da VM, quando você executa apps dentro dela, não vai acabar querendo os 8 GB inteiros alocados, e não apenas os 5 GB usados no início?

    • Eu não achava que a virtualização do macOS fosse sofisticada o bastante para suportar memory ballooning, então não é disso que se trata?
      Edit: eu estava errado

  • Acho que eu tenho o menor deles. docker.io/gotson/crossbuild latest d96ea9b7054b 3 years ago 6.71 GB, e estou usando para cross-build de Darwin

  • Sinceramente, parece que o macOS poderia ir bem mais para baixo do que isso se você desativasse as coisas de que uma VM realmente não precisa
    O primeiro iPhone tinha só 128 MiB de RAM e, pelo que eu saiba, rodava uma versão reduzida do macOS Tiger. Até agora, a RAM era abundante o bastante para não haver motivo para enxugar isso, mas certamente é possível e provavelmente nem tão difícil assim. Basta tentarem de novo

    • Os primeiros iPhones não tinham multitarefa de apps, então isso faz uma boa diferença. Os apps eram encerrados quando fechados

  • Dá para rodar macOS em um PC? Ou pelo menos fazer desenvolvimento para Mac em um PC de alguma forma?

    • Dá para inicializar macOS com QEMU, mas você não terá gráficos com aceleração por hardware nem alguns outros recursos

  • Pergunta talvez meio aleatória, mas será que é possível registrar no Intune uma VM de macOS como dispositivo pessoal?

  • Fico pensando por que ninguém cria um ambiente de agente dedicado a macOS. Seria legal se o agente fosse spawnado já dentro de um ambiente Mac