跟踪开发者构建时间，以决定 M3 MacBook 是否值得升级

原文 ↗ Hacker News 讨论 ↗

工程师们分享了数千次 Go 构建的数据，以决定将 MacBook Pro 从 M1 和 M2 升级到 M3 在财务和生产力上是否划算；结果发现 M2 相比 M1 是一次大幅提升，而 M3 相比 M2 只带来温和增益，但对于较旧的 M1 机器仍然值得更换。评论者还讨论了分布式或远程构建、云端开发机和台式机等替代方案，并审视了研究中使用的统计方法和 AI 辅助分析。许多人也结合实际经验讨论了 Apple Silicon 的性能、RAM 限制，以及更快的本地反馈循环与更复杂的远程方案之间的权衡。

升级价值：M1 vs M2 vs M3

  • 普遍认为 M1 是一个扎实的基线；对于本组织的 Go 单体以及其他一些工作负载，M2 的构建速度通常比 M1 快约 20–60%。
  • M3 Pro 被认为只比 M2 略有提升（在这份数据和一些用户基准中约 10%），但明显优于 M1。
  • 对许多评论者来说，M2 → M3 不值得升级；M1 → M3/M2 则可以。
  • 几位用户表示，M3 Max 对典型构建工作负载相较于 M3 Pro 的收益有限；更多核心经常得不到充分利用。
  • 有人认为，二手或打折的 M1 Pro/Max 以远低得多的成本就能提供大部分价值。

RAM、内存带宽与工作负载

  • 更多 RAM 对链接和缓存有明显帮助；多份报告显示 16 GB 在负载下经常发生分页。
  • 内存带宽差异对本地 LLM 和某些重型构建非常重要；M2 Ultra（800 GB/s）和 Max 芯片（400 GB/s）在这方面更受青睐，而一些 M3 Pro/Max 配置被认为带宽被“阉割”了。
  • 关于 8 GB Mac 的争论：对于小型/中型项目，在谨慎使用的情况下可用，但在严肃开发中可能会频繁击穿 SSD 并显得迟缓。

本地 vs 远程 / 分布式构建

  • 一些团队表示，强大的本地笔记本加上快速本地构建（<30 秒）在生产力和调试方面远胜于远程或仅 CI 的工作流程。
  • 其他人则表示，远程开发机、基于 Kubernetes 的开发集群或分布式构建（distcc/sccache/Incredibuild）很成功，尤其适用于巨大的 C++/单体代码库。
  • 云端开发被批评为成本高、延迟敏感且运维复杂，不过超大公司可以把它做得很好。
  • 对整个产品栈进行纯本地开发被称赞为罕见但非常有效。

方法、统计与遥测

  • 几位评论者喜欢构建遥测这个想法（跟踪构建时间、环境、电池/接电状态、RAM 等），并用它来发现回归和指导硬件采购。
  • 统计学家和数据敏感的读者批评：
    • 潜在的群组偏差（新入职员工使用更新机器，处理不同类型的变更）。
    • 在没有建模非独立样本的情况下使用 t 检验；建议使用混合效应模型或非参数检验。
    • 过度依赖直方图；建议用箱线图或 CDF 来进行更清晰的比较。
  • 尽管如此，很多人仍认为这一做法对内部决策来说“足够好”，并且对组织学习很有价值。

AI 辅助分析

  • 使用 OpenAI “assistant” 在 CSV 数据上运行 Python/pandas 令许多人印象深刻；被视为大幅降低了这类分析的启动门槛。
  • 一些人仍然对正确性和可复现性持怀疑态度，更偏好明确的 R/Python 工作流，但也指出你可以检查生成的代码或导出 notebook。

Mac vs 其他方案与开发体验

  • 对 Apple Silicon 的支持态度很强：与 Intel Mac 相比，在 VS Code、编译和电池续航上都有巨大飞跃；Intel MBP 常被形容为相较之下的“镇纸”。
  • 有人认为 MacBook 价格过高、只是身份象征，而台式机或非 Mac 笔记本加远程算力更具成本效益。
  • 也有人反驳说，就笔记本而言，MacBook 仍在每瓦性能、散热、噪音、屏幕、扬声器和拔电后的性能上占优。
  • 据称，公司笔记本上的终端安全/管理代理会显著拖慢性能，而这与 CPU 代际无关。