我开发了一个基于 Beancount 的账本托管服务 HostedBeans,欢迎大家来了解纯文本复式记账并试用我的服务。
标签 #购物

入手 MacBook Air (Apple Silicon)

最近两年几乎买齐了苹果的全线产品,越来越看好苹果,甚至买了一些苹果的股票,当然为什么选择苹果生态这个话题可以放在单独的文章里来说。

我在 Small talk 的第二期「聊聊用 M1 芯片的新 Mac」中也聊到了 Apple Silicon 的话题,欢迎大家收听,但这期播客录制时间较早,如有冲突还是以本文为准。

第一体验

在 11 月 17 日的发布会后我又观望了一周才下单,最后在 12 月 4 日拿到了搭载 M1 处理器 的 MacBook Air,我将内存升级到了 16G ,存储则还是低配的 256G。

选择这一款是因为从测评来看 Air 和 Pro 的性能差别并不显著,也不想为了 Touch Bar 和屏幕亮度支付额外 2000 元的价格,不如把这个钱加到内存上。

说到内存,新的 Mac 使用了「统一内存架构(UMA)」,可以消除 CPU 和显卡等专用计算单元之间的内存拷贝,既提高了速度,又减少了内存使用。一些朋友表示 8G 的内存对于不开虚拟机的中度使用也非常够用,但相信硬件的提升很快就会被软件消化,如果你希望新的 Mac 有一个比较长的使用周期,还是建议升到 16G 内存。对于新的 Mac 来说最高也只能选配 16G 内存,据说是因为总线 IO 的瓶颈,只有 2 个雷电接口也是这个原因。

至于存储空间,我属于最低的存储空间都够用的那一类人 —— 我希望设备上有最高性能的本地存储,但我并不会用这么昂贵的空间去存储冷数据,毕竟我才刚刚花了大功夫 自己搭了一个 NAS

拿到 MacBook Air 开始,最亮眼的还是发热和续航的表现,我偶尔会把 MacBook 放在腿上使用,之前的 Intel MacBook 十几分钟就会觉得烫,而 M1 Mac 则在日常使用时几乎感觉不到温度,在 CPU 跑满的情况下温热,只有 CPU 和 GPU 同时跑满才会有烫的感觉。相应地,M1 的续航表现也非常亮眼,后面的性能测试中会有详细的说明。

然后把它和我们家其他的 Mac 对比一下跑分,果然是用最低的价格提供了最高的分数:

Mac Air (M1) Pro (2020) Pro (2017) mini (2018)
CPU M1 I5-1038NG7 I5-7360U I7-8700B
GPU 7-Core Iris Plus Iris Plus 640 Intel UHD 630
Memory 16G 16G 8G 16G
Geekbench SC 1678 1136 852 1117
Geekbench MC 7225 4237 2020 5621
Geekbench Metal 19138 8498 4930 3776
Price ¥9499 ¥14499 ¥11888 ¥11909

数据来自 everymac.com 和 geekbench.com

其中 MacBook Pro 2020 是我 2020 年初时购买的最后一代 Intel MacBook,使用第十代 i5,倒是没什么问题,只是目前来看就买得实在太亏了;MacBook Pro 2017 是蛋黄一直在用,最近她开始学习 Swift 就一直在吐槽电脑实在太慢了,同时电池也进入了待维护状态;Mac mini 2018 是我目前工作用的电脑,当时虽然选了最高配的 i7 CPU,但没考虑到 Intel UHD 630 的性能实在太差了,即使我只是接了一块 4k 屏,系统的界面响应就已经非常卡顿了,现在 GPU 成为了整台电脑的瓶颈。

ARM 生态

应该说这次从 x86 到 ARM 的切换比我想象中的要顺利,苹果的第一方应用和 masOS 独占的应用都第一时间进行了适配,其他没有适配的应用则可以用 Rosetta 2 来运行。Rosetta 2 用起来是完全无感的,系统会自动将 x86 的应用以转译的方式来运行,无论是图形界面应用还是命令行的 binary 文件。性能上的差别对于大部分应用来说也并不明显,很多时候感觉不到自己是否使用了 Rosetta 2。

M1 芯片之前对我来说最大的变数在于对 Docker 的支持,但就在前几天 Docker for Mac 也发布了 针对 M1 芯片的测试版本。测试版中默认会运行一个 ARM 架构的 Linux 虚拟机,默认运行 linux/arm64 架构的镜像(说起来在 M1 之前 linux/arm64 大概主要是被用在树莓派上吧);对于没有提供 linux/arm64 架构的镜像则会自动使用 QEMU 来运行 x64_64 的镜像,性能就比较差了。

macOS 吸引我的一大理由就是 Homebrew —— 可能是桌面开发环境中最好用的包管理器。在 M1 上 Homebrew 目前 推荐大家使用 Rosetta 2 来运行,所安装的包也都是需要 Rosetta 2 转译运行的 x86 版本,即使这个包已经提供了 ARM 版本。

这是因为 Rosetta 2 虽然可以完美运行 x86 的 binary,但当一个脚本中会以字符串的方式传递架构名、会调用多种不同的架构的程序,且这些程序同样关心当前的架构时就出问题了,不同的程序无法对这台机器的架构达成一致 —— 这往往发生在编译脚本里,也就是 Homebrew 的主要工作。解决这个问题目前只能是让整个脚本都运行在 x86(即 Rosetta 2)下,Homebrew 目前也是这样做的。

当然你可以选择在另外一个路径 安装 ARM 版的 Homebrew 来安装 ARM 版的包,但目前这种方式缺少官方指引、需要自己尝试一个包的 ARM 版是否可以工作、需要从源码编译。目前大多数无法工作的包是受限于上游依赖的发布周期(如支持 darwin/arm64 的 Go 1.16 要等到 2021 年二月才会发布),对于不涉及特定架构、或已经在其他平台提供有 ARM 版本的包,届时只需重新编译就可以提供 ARM 版本。

M1 的 Mac 可以直接安装 iOS 应用这一点我倒不是很在意,一方面是很多国内的毒瘤应用第一时间就从 Mac 商店下架,不允许安装。另一方面 iOS 基于触屏的交互逻辑本来就不适合 Mac,我也不觉得 Mac 之后会加入触屏的支持。

性能测试

以极低的功耗实现高于之前 MacBook 的性能是这次 M1 Mac 的亮点,在我购买之前实际上就已经看了很多视频自媒体的测评,在他们的测试中 M1 Mac 在使用 Final Cut Pro X 进行视频剪辑和导出有着碾压级的性能表现。

但显然这并不能代表 M1 在所有工作负载下的表现,因此我根据我日常的工作负载设计了 7 组共 15 项测试,主要将搭载 M1 的 MacBook Air 和我目前在使用的最后一代 Intel MacBook Pro (2020, i5 10th) 进行对比,以下数据均以后者为基准。

Name MacBook Pro (i5 10th) MacBook Air (M1, x86) MacBook Air (M1, ARM)
Node.js npm install 2m 41s 1m 38s (+39%) 1m 2s (+61%)
Node.js webpack build 54s 38s (+30%) 27s (+50%)
Xcode build Swift SDK 11m 30s N/A 6m 47s (+41%)
Xcode start iOS Simulator 49s N/A 16s (+67%)
Docker Redis benchmark 128k QPS 133k QPS (+4%) 261k QPS (+96%)
Docker build Node.js app 2m 56s 4m 43s (-61%) 3m 17s (-12%)
Visual Studio Code startup 7s 17s (-142%) 3s (+57%)
Visual Studio Code open and close tabs 36s 37s (-3%) 40s (-11%)
Chrome Speedometer 2.0 88 times/m 121 times/m (+38%) 214 times/m (+143%)
Safari Speedometer 2.0 111 times/m N/A 227 times/m (+105%)
Safari 10% battery for Bilibili 32m N/A 1h 50m (+244%)
Final Cut Pro X background rendering 9m N/A 6m 20s (+30%)
Final Cut Pro X export H.264 8m 25s N/A 7m 8s (+15%)
Steam Oxygen Not Included 25 ~ 40 fps 45 ~ 50 fps (+25 ~ 80%) Not support
Steam Sid Meier’s Civilization VI p99 22 fps p99 51 fps (+132%) Not support

对于 Node.js 依赖安装、前端项目构建、Swift 代码编译这些 CPU 密集且内存访问频繁、其中一些步骤依赖单核性能的场景,M1 有着非常明显的提升,即使使用 Rosetta 2 转译也要显著好于 i5。

最值得一提的是得益于 M1 的统一内存架构的高带宽和低延迟,Redis 跑出了 26 万 QPS 的成绩(无论是否在 Docker 中这个数据都差不多),而 i5 仅有 6 万。在调整 redis-benchmark 的数据长度参数时,M1 的结果几乎没有什么变化,而 i5 则随着数据长度的增加 QPS 逐步下降。说不定未来搭载 M1 的 Mac mini 会成为运行遇到 CPU 瓶颈的 Redis 的最佳硬件。

而使用 Docker for Mac 构建镜像则没有提升,这可能是因为构建的过程有很多零散的 IO,CPU 会有比较多的时间休息。而如果使用 Docker 去构建 x86_64 架构的镜像的话,性能损失就非常严重了(-61%)。

我编写了一个反复开关标签页的脚本来测试 VSCode 的性能,结果表明对于这类负载并不重的 GUI 程序,Rosetta 2 转译并不会影响性能,同样编译到 ARM 也不会对性能有多少提升,Rosetta 2 主要是会比较明显地增加启动速度。在 VSCode 的测试数据中出现了比较奇怪的现象 —— Rosetta 2 转译的版本竟然比 ARM 还快,我目前倾向于这是实验的误差,两者的速度实际上是几乎相同的。

在浏览器的测试中我们选择了 Speedometer,它会运行上百个由主流 Web 框架编写的 Todolist。结果显示无论是 Chrome 还是 Safari,其 ARM 版本都有一倍以上的性能提升,同样即使经过 Rosetta 2 转译也仍然比 i5 要快。浏览器的场景其实和前面 Node.js、Swfit 和 Redis 很像,都是 CPU 密集且内存访问频繁、其中一些步骤依赖单核性能,这也是 Intel CPU 之前的痛点。

我还基于浏览器进行了续航测试,我在中等亮度下播放 Bilibili 上 4K 120 帧的视频,开启弹幕的情况下 M1 使用前 10% 的电池播放了惊人的 1 小时 50 分钟,在这段时间的日常使用体验也是如此,我毫不怀疑官网给出的 18 小时视频播放时间。

在 Final Cut Pro X 的视频渲染和导出上,虽然 M1 确实有提升,但远不如之前一些媒体宣传的那么夸张,目前我还不清楚原因。

游戏方面我测试了我经常玩的 Oxygen Not Included(缺氧)和 Sid Meier’s Civilization VI(文明 6),我使用的都是中后期的存档、默认画面预设,在大多数时间都有 50 帧以上,是完全可以流畅游玩的。

可以看到 M1 的 Mac 在之前低配的价位上实现了中配甚至高配的计算性能,得益于专用的加速芯片,在苹果第一方和 macOS 独占的应用上有非常惊人的表现,而对于必须经过 Rosetta 2 转译的应用,仍有可以接受的性能表现,也是远高于之前同一价位的 Mac 的。

多用户模式

因为蛋黄和我对新的 MacBook 都很有兴趣,因此我们各建了一个账户,这段时间是在轮流使用这台 MacBook,这也是我第一次使用 macOS 的多用户模式。整体体验还是很不错的,macOS 允许两个用户同时登录,在不退出程序的情况下在两个用户间切换,这使得我和蛋黄同时使用一台电脑的体验非常流畅。

16G 的内存也非常够用,即使另外一个用户运行了 XCode、Final Cut Pro X 或大量标签页的 Chrome,也不会有任何感觉。倒是 256G 的存储空间对于两个用户同时使用有些不够,不过这样的状态应该不会持续太久,后面我也会入手一台 M1 的 Mac。

对 Mac 的展望

Rosetta 2 为什么会有这么好的性能呢?之前 Surface 等 x86 模拟器性能不佳的一个原因是 x86 与 ARM 在一个有关内存顺序的机制上有着不同的行为,在 ARM 上模拟这一行为会导致很大的性能损失。而苹果选择直接 在 M1 芯片中实现了一套 x86 的内存机制,大大加速了 Rosetta 2 的性能。据说苹果同样在芯片层面对 JavaScript 和 Swfit 中一些特定场景进行了优化,还有大量的专用计算芯片来加速编视频编解码、密码学计算等特定的任务。

这是一个非常有趣的方向,过去很长一段时间都是应用来适配芯片,但只要对硬件和操作系统的控制力足够强,芯片也可以反过来去对最常用、性能问题最突出的应用进行芯片层面的优化或加入专用的计算芯片,和应用程序一起进行迭代更新。M1 中有的是对 Rosetta 2 的优化,而下一代的 M2 芯片则可能不再需要 Rosetta 2,而是可以根据需要去优化当时的热门场景。

对于苹果来说切换到 ARM 最重要的是提升了其垂直整合的能力、自主控制 Mac 产品线的更新周期。因为苹果对于操作系统的控制力和对应用生态的号召力,可以最大限度地发挥出自主设计的 ARM 芯片的效果。Windows 阵营当然可以切换到 ARM,会享受到前面提到的一些好处,毕竟苹果已经证明了这条路是可行的。但因为软硬件不是同一家公司控制、Windows 对应用生态的号召力弱,微软又不敢破釜沉舟地投入到 ARM 上,因此短期内可能 Windows 阵营还很难实现。

加湿器选购指南

我从小一直生活在湿度很低的北方,常年鼻子和咽喉不舒服,经常流鼻血,但因为从小如此,也没觉得有什么不对劲。而来到苏州之后,我就觉得苏州湿润的空气真是好呀,鼻炎和咽炎的症状几乎没有了。但等到冬天开空调的时候就觉得无法再回到那么干燥的环境了,于是开始疯狂地买加湿器,这么多年下来,应该买过差不多十个加湿器了。

加湿原理

超声波 加湿器使用超声波将水打散成为非常小的小液滴,然后用风扇吹出,小水珠通常会在落地之前蒸发为水蒸汽,溶解至空气中。超声波加湿器是使用最普遍、价格最低、同价位加湿量最大的加湿器类型。其主要缺点是超声波会将水中的固体颗粒物和溶解物一起吹出,且容易有颗粒较大的液滴未能在落地之前完全溶解到空气中。虽说超声波加湿器被认为并没有耗材,但实际上其核心组件雾化片的寿命只有两年左右,且难以更换。

冷蒸发 加湿器使用风扇将空气吹过吸水的多孔材料,加速水的蒸发。冷蒸发是近一段时间中被高端的加湿器所采用的技术,不会有固体颗粒物进入空气,加湿量随湿度变化有一定自我调节的能力。其主要缺点是单位价格加湿量较低(且加湿量和噪音成正比),用于吸水的多孔材料作为耗材需要定时更换。

热蒸发 加湿器简单地通过加热水来产生水蒸汽。热蒸发加湿量较大(和功率成正比),同样没有固体颗粒物进入空气。其主要缺点是耗电较多,会增加室内温度(冬天倒是不要紧),且高温蒸汽遇到低温物体会产生水珠凝结。

类型 价格 水珠凝结 耗电 耗材和使用寿命 固体颗粒物 加湿量(同价位)
超声波 无耗材 寿命短
冷蒸发 有耗材
热蒸发 中等 无耗材 中等

在加湿原理上面我觉得很难一概而论,需要具体情况具体分析。但如果你不知道怎么选的话,可以先买个性价比最高的超声波加湿器试试看。

湿度

我们通常说的湿度其实是指相对湿度,即相对于当前空气中能溶解水蒸汽的最大量来说的湿度。人在不同的温度下对于同一相对湿度的感受是完全不同的,在 28 度下 40% 的相对湿度会比较舒适,而在 22 度下则需要 60% 的相对湿度才能达到相同的感受。

于是我找到了一个单一指标来衡量体感湿度 —— 露点,露点描述的是在当前温度和相对湿度的条件下,空气中的水蒸汽遇到多冷的物体时会凝结成小水珠,综合了温度、相对湿度和大气压力的影响。

对于我而言我觉得理想的露点是在 13 度左右,也就是我前面说的 28 度下 40%、22 度下 60%。如果你不像我这么喜欢湿润的空气,可以调低一点,例如 10 度左右。

加湿量

首先我们根据房间容积(这里以我家客厅 90 立方米计算)、目标温度和目标湿度来计算所需要的加湿量。我这里的计算并没有扣除家具所占用的空间,主要是考虑到家具本身(尤其是织物)也是会吸水的,所以综合考量下来不加也不减。

先计算不开空调和加湿器时的基准值,按室外温度 10 度,相对湿度 60% 计算,查表可得每立方米有 5.63g 的水蒸汽,总共就是 90m^2 * 5.63g = 506.7g,相当于我们房间里本来就有这么多水。

然后按照目标温度 24 度,目标露点 13 度,算出目标相对湿度是 50%,查表可得每立方米有 10.85g 的水蒸汽,总共就是 90m^2 * 10.85g = 976.5g,相当于我们的目标是房间里有这么多水。

这意味着我们需要补充差不多 500g 的水到空气中,但需要注意的是房间并不是密闭的,房间里的空气一直在和外界进行着交换,水蒸汽会流失到外界,也会在低温物体(如玻璃)上凝结为小水珠。以我个人的经验,如果你需要补充 500g 的水到空气中的话,那差不多你就需要一个加湿量 500ml/h 的加湿器 —— 相当于每小时房间里的水分都会流失掉一遍。如果加湿器的加湿量不够的话,就会出现即使一直开到最大,湿度也升不上去的情况。

500ml/h 已经算是加湿量比较大量的加湿器了,你需要考虑是使用多个加湿器还是单个加湿器。多个加湿器的话维护成本会比较高,你需要单独为每个加湿器加水、进行清洗和维护;单个加湿器的话则要考虑如何增加空气的对流,让整个房间保持相对均匀的湿度,例如冬天开空调的话,可以把加湿器放在空调可以直接吹到的地方。

功能

在购买加湿器的时候需要留意这些功能:

  • 上加水 极大地提升了加水的便利性,直接关系到使用体验。
  • 水箱 注意确认容量是否足够、水箱的形状是否容易清洗。
  • 通电自动启动 有些加湿器在接通电源后还需要触摸按键才能启动,这样便无法与智能插座配合使用。
  • 出雾高度和方向 出雾方向是否可调,这会影响加湿器放置的灵活性。
  • 紫外线除菌 见后面「固体颗粒物」小节。

可有可无的功能:

  • 红外线遥控 可以和智能家居组件配合使用。
  • 指示灯 如果是放在卧室的话,需要确认指示灯的亮度以及是否可以关闭,否则可能关灯后会显得太亮。
  • 智能控制 大多需要专门的应用,难以和既有的智能家居一同工作,不如用智能插座或红外遥控来解决。
  • 恒湿 位于机器本体上的湿度传感器非常不准确,效果有限(尤其对于超声波加湿器)。

不太需要关注的功能:

  • 静音 大多数超声波加湿器都没多大差别。
  • 缺水保护 所有加湿器都有的功能。

没什么用的功能:

  • 银离子 效果要比紫外线差很多,而且需要耗材。
  • 净水滤芯 本来加的都是干净的水,没有必要过滤,而且需要耗材。
  • 负离子 并没有可靠的资料表明这个功能有什么作用。

关于大雾量加湿器:

单个超声波雾化片可以提供 300ml/h - 400ml/h 的加湿量,再大的加湿量就需要考虑多个雾化片的加湿器了。

固体颗粒物

超声波加湿器会将水打成小液滴,这会导致家用的固体颗粒物传感器瞬间爆表,但实际上家用的传感器是无法区分小液滴和真正的固体颗粒物的,因此这个传感器的数值并不能说明有多少固体颗粒物进入到了空气中。

但我们仍有必要考虑微生物在加湿器内滋生并随着小液滴进入空气的情况,市场上目前有紫外线和银离子两种方案来解决这一问题。

经过我的调查,紫外线的除菌效果要远优于银离子,且不需要耗材:

  • 紫外线被标注为「除菌」,而银离子被标注为「抑菌」
  • 网络上一些细菌培养实验显示紫外线的除菌效果更好
  • 高端的加湿器通常采用紫外线除菌

下一个问题就是加湿器中到底应该加什么水呢?

一派观点认为自来水中的余氯有助于减少加湿器中的细菌;另一派观点认为有条件加纯水当然应该加纯水,可以减少被超声波打入空气中的溶解物数量(尤其一些地区自来水的 TDS 非常高),也可以延长超声波雾化片、冷蒸发的多孔材料、热蒸发的电热管的使用寿命。

所以综合考虑,建议大家选择有紫外线除菌功能的加湿器,然后向加湿器中添加净水器产生的纯水来避免自来水中的溶解物进入空气。

参考资料

入手 Macbook Air

已经用了半个月了。

在此之前,我没用过苹果的任何产品,对 OS X 的了解也非常少,另外在此之前我从未使用过笔记本,即使是用别人的也没超过十分钟。

OS X 的使用门槛感觉很低了,没有什么不习惯,大概也是因为我前前后后用过的桌面环境太多了,并不排斥切换到一个新的桌面环境。

在我买来的第二天,Air 就出现了各种诡异的问题,比如:

  • 无法开机 (个案,更新 OS X 10.9 后解决)
  • 从休眠唤醒后没有声音 (经搜索应该是普遍现象)
  • Chrome 中多点触摸操作间歇性失灵 (普遍现象)

问了几个用 Mac 的朋友,他们表示从未遇到这些情况,为毛我这么倒霉。

如果除去这些诡异的问题,我觉得它还是值这个价钱的,Air 有几点恐怕是其他笔记本绝对比不了的:

  • 电池,正常使用 10 个小时绝对没问题
  • 厚度,和手机差不多薄
  • 散热,除非开游戏,否则永远冰凉冰凉的
  • 噪音,风扇不工作时,没有任何声音

这也是我决定买它的原因,即使这样拿到手里还是让我很是吃惊。

然后还有随时合上盖就可以休眠,SSD 的硬盘,触摸板等等,都非常完美。

再说 OS X, 之前不断徘徊于 Linux 和 Windows 之间,OS X 像是吸取了他们两个的优势:既有类 Linux(Unix) 的底层,又有比 Windows 更好用的桌面环境。

触摸板相当好用,完全不需要鼠标,尤其是在程序之间切换,比 Linux 和 Windows 都要方便,再加上快捷键,很少需要鼠标去做精确地定位。

然后为了更高效的写代码,我已经投奔 Vim 了。其实我很讨厌 Vim 的脑残粉,就是宣称 Vim 什么都可以做的那些人——我只是把 IDE 的编辑区域换成了 Vim 而已。

Dash 是个很好用的东西,不知道有没有其他平台的类似软件。

比较失望的一点是 OS X 的软件包管理比 Linux 要差远了,即使是 brew 也不是很好用,不过比 Windows 还是要强一点的。

说起来现在我每天要横跨三大平台,学校的 Linux(Arch/KDE), 家里台式机的 Windows, Air 的 OS X, 因为用的都是跨平台的软件,竟完全没有问题 …

前两天把台式机装成了 Windows Server 2012 R2, Dreamspark 搞到的正版授权,至此为止我已经没有在使用任何盗版软件了。

精子生于 1995 年,英文 ID jysperm.

订阅推送

通过 Telegram Channel 订阅我的博客日志、产品和项目的动态:

王子亭的博客 @ Telegram


通过邮件订阅订阅我的博客日志、产品和项目的动态(历史邮件):

该博客使用基于  Hexo  的  simpleblock  主题。博客内容使用  CC BY-NC-ND  授权发布。最后生成于 2024-04-08.