Acompanhar os tempos de build dos desenvolvedores para decidir se o M3 MacBook vale o upgrade

Artigo original ↗ Discussão no Hacker News ↗

Engenheiros compartilham dados de milhares de builds em Go para decidir se faz sentido financeiro e de produtividade atualizar MacBook Pros de M1 e M2 para M3, concluindo que o M2 é um grande salto em relação ao M1, enquanto o M3 oferece ganhos apenas modestos sobre o M2, mas ainda justifica substituir máquinas M1 mais antigas. Comentadores debatem alternativas como builds distribuídos ou remotos, caixas de desenvolvimento na nuvem e desktops, e analisam criticamente os métodos estatísticos e a análise assistida por IA usados no estudo. Muitos também trazem experiência prática sobre o desempenho do Apple Silicon, limitações de RAM e os trade-offs entre ciclos de feedback locais mais rápidos e configurações remotas mais complexas.

Valor do upgrade: M1 vs M2 vs M3

  • Há amplo consenso de que o M1 é uma base sólida; o M2 muitas vezes parece ~20–60% mais rápido que o M1 para builds neste monólito Go desta organização e em algumas outras cargas de trabalho.
  • O M3 Pro é visto como apenas modestamente melhor que o M2 (~10% nestes dados e em alguns benchmarks de usuários), mas claramente melhor que o M1.
  • Para muitos comentadores, M2 → M3 não vale o upgrade; M1 → M3/M2 pode valer.
  • Várias pessoas relatam que o M3 Max oferece benefício limitado em relação ao M3 Pro para workloads típicos de build; os núcleos extras muitas vezes ficam subutilizados.
  • Alguns argumentam que um M1 Pro/Max usado ou com desconto oferece a maior parte do valor por um custo muito menor.

RAM, largura de banda de memória e workloads

  • RAM extra ajuda fortemente na ligação e no caching; há vários relatos de 16 GB fazendo page regularmente sob carga.
  • Diferenças de largura de banda de memória importam muito para LLMs locais e alguns builds pesados; M2 Ultra (800 GB/s) e partes Max (400 GB/s) são favorecidos para isso, enquanto algumas configurações M3 Pro/Max são vistas como tendo a largura de banda “nerfada”.
  • Debate sobre Macs com 8 GB: funcionam para projetos pequenos/médios com cuidado, mas podem sobrecarregar o SSD e parecer lentos para desenvolvimento sério.

Builds locais vs remotos / distribuídos

  • Algumas equipes dizem que laptops locais potentes com builds locais rápidos (<30s) são muito melhores para produtividade e depuração do que fluxos de trabalho remotos ou apenas via CI.
  • Outros relatam sucesso com caixas de desenvolvimento remotas, clusters de desenvolvimento baseados em Kubernetes ou builds distribuídos (distcc/sccache/Incredibuild), especialmente para codebases enormes em C++/monólitos.
  • O desenvolvimento na nuvem é criticado por ser caro, sujeito a latência e operacionalmente complexo, embora empresas muito grandes consigam fazê-lo funcionar bem.
  • O desenvolvimento apenas local de stacks de produto inteiros é elogiado como raro, mas muito eficaz.

Metodologia, estatísticas e telemetria

  • Vários comentadores gostam da ideia de telemetria de builds (acompanhar tempos de build, ambiente, bateria vs energia, RAM etc.) e usá-la para detectar regressões e informar compras de hardware.
  • Estatísticos e leitores com perfil mais orientado a dados criticam:
    • Possível viés de coorte (novos contratados com máquinas novas trabalhando em tipos diferentes de mudanças).
    • Uso de testes t sem modelar amostras não independentes; sugerem modelos de efeitos mistos ou testes não paramétricos.
    • Forte dependência de histogramas; recomendam boxplots ou CDFs para comparações mais claras.
  • Ainda assim, muitos veem o exercício como “bom o suficiente” para decisões internas e como aprendizado valioso para a organização.

Análise assistida por IA

  • O uso de um “assistant” da OpenAI para executar Python/pandas sobre dados CSV impressiona muitos; visto como reduzindo dramaticamente a energia de ativação para esse tipo de análise.
  • Alguns continuam céticos quanto à correção e à reprodutibilidade, preferindo fluxos explícitos em R/Python, mas observam que é possível inspecionar o código gerado ou exportar notebooks.

Mac vs alternativas e experiência de desenvolvimento

  • Forte sentimento pró-Apple Silicon: salto enorme em relação aos Macs Intel para VS Code, compilações e bateria; MacBook Pros Intel são frequentemente descritos como “pesos de papel” em comparação.
  • Alguns argumentam que MacBooks são símbolos de status caros e que desktops ou laptops não-Mac com computação remota são mais custo-efetivos.
  • Outros rebatem que, para laptops, os MacBooks ainda dominam em desempenho por watt, térmicas, ruído, tela, alto-falantes e desempenho sem estar ligado à tomada.
  • É relatado que agentes de segurança/gestão de endpoint em laptops corporativos degradam significativamente o desempenho, independentemente da geração do CPU.