European chipmakers need TSMC’s help to grow their own semiconductor supply chain, but the chip giant’s Taiwanese suppliers find Europe a tough place to do business.

© Milan Bures for The New York Times

Erasing SSDs securely has been a longstanding problem that has been solved in Macs with T2 or Apple silicon chips, with the introduction of Erase All Content and Settings (EACAS) four years ago in macOS Monterey. This article explains how it works, what it does, and when you should use it.

Boot disk

While Intel Macs are simpler, the internal SSD of an Apple silicon Mac is divided into three APFS containers/partitions.

Intel Macs have the same Apple APFS container with the Boot Volume Group in it, but the other two containers are replaced by a single small EFI partition.

macOS manages and uses the first two containers, ISC and Recovery, and that containing the Boot Volume Group is the one we’re concerned with. That includes the System and Data volumes, the former being made into a read-only snapshot that’s mounted as the Signed System Volume and contains macOS. Everything you install as a user, including apps and your Home folder, is in the Data volume, which is encrypted automatically even if you don’t have FileVault turned on.

Data volume

As the Data volume is invariably encrypted, the best way to securely erase its entire contents is to destroy its encryption key. Provided that can be performed robustly, so the key can never be recovered, no one will be able to decrypt its contents. (There is an expectation that one day it might be possible to break the encryption using quantum computing, but that’s not something you should be concerned with at present.)

The encryption key used to encrypt the Data volume is itself encrypted, and forms part of the mechanism used by FileVault when that’s enabled. To ensure that those encryption keys don’t leave the Secure Enclave, they’re encrypted again, and the key that’s destroyed by EACAS is one of those. macOS also employs anti-replay techniques to ensure that previous keys can’t be reused.

Additional features

In addition to destroying the encryption key for the Data volume, EACAS performs other useful tasks. These include signing out of your Apple Account, including iCloud and iCloud Drive, destroying all fingerprints used for Touch ID, and turning off Location Sharing to disable Find My and Activation Lock.

Although I can’t find any official account of additional data being erased by EACAS, I believe that all LocalPolicy records stored in Apple silicon Macs are also destroyed. LocalPolicy authorises access to external bootable disks, so those who have configured an external disk to boot their Mac are likely to be required to re-authorise it before it will boot that Mac again.

What EACAS doesn’t do, though, is sign you out of third-party cloud or other services such as Adobe’s Creative Cloud, or deauthorise that Mac for Apple media such as Music. Neither will it do anything to your Mac’s SSV: that’s left intact, still running the same version of macOS.

How to use EACAS

Start EACAS from System Settings > General > Transfer or Reset > Erase All Content and Settings…. In older versions of macOS still using System Preferences, open them and it’s offered as a command in the app menu.

If you continue, you should see one final warning before the contents of the Data volume are blown away into the great bit-bucket in the sky.

What’s left of your Data volume, shown here in Recovery mode, is a mere 300 MB or so.

When to use EACAS

If you want to wipe your Mac’s Data volume so you can reinstall its user(s), EACAS is the simplest and quickest way to do that, and doesn’t require starting up in Recovery. Its additional features ensure that, when you install its new primary user, everything should work properly and you don’t end up with ghost Macs left over from the past.

It’s the method of choice when preparing your Mac for disposal, particularly if you’re passing it on to someone else, as it ensures that no one can recover any of the data stored in your Home folder, or anywhere else on its Data volume. Performing that manually requires you to work through a list of additional procedures, almost all of which are automatic in EACAS.

The only time when you’re likely to prefer a different method is when you want to erase both the Data and System volumes, perhaps to return to an older version of macOS. Although you can do that using Disk Utility in Recovery mode, that doesn’t install the matching firmware. If you really want to return to factory-fresh conditions, the best way is to put that Mac into DFU mode, then restore it from the IPSW image file for that version of macOS. Although that does require a second Mac, it’s quick and comprehensive.

One other caution: never use EACAS on a macOS VM, as it’s unlikely to recover. It makes more sense just to delete the whole VM and be done with it.

Summary

• EACAS performs a secure erase of the Data volume, as well as some useful extras.
• It’s the method of choice for preparing your Mac for disposal.
• It’s also suitable for wiping user data before setting your Mac up afresh, using its existing macOS.
• If you want to wipe the System volume as well, to reinstall macOS, restore from an IPSW in DFU mode.

Having waded through dozens of CPU core frequencies for all current members of the M-series families of chips, you might be wondering what they mean for someone considering buying a new Mac. Is the M5 going to prove any faster than an M4, or should they wait until M5 Pro or Max variants become available?

All else being equal, a core that runs at a higher frequency should process instructions more quickly than a similar core running at a lower frequency. But these figures only apply to the CPU cores, and much of their most demanding code is now run on other co-processors and components, including the GPU and neural engine (ANE).

The M5 has specific enhancements to its GPU to accelerate its performance when running compute tasks that can be common in AI and other advanced code. That GPU runs Metal code, and because that’s compiled and prepared by the CPU cores, to obtain maximum performance from its enhanced GPU the CPU cores also need to perform well. CPU cores play other key roles in supporting specialist components, so matching their performance is essential to avoid bottlenecks and achieve balance. One consistently important factor is the speed of memory access: the faster everything goes, the faster data has to be moved around, and that’s why minimising movement using Unified Memory can prove so important, as is the M5’s faster bandwidth of 153 GB/s, compared with 120 GB/s in the base M4.

There’s also more to CPU core performance than just frequencies. Cores can execute instructions out of order, predict load addresses and values, and pull other tricks to ensure that best use is made of every clock cycle. For the M5, Apple has singled out claimed improvements in multithreaded performance, enabling a single core to run multiple threads significantly faster.

Looking just at CPU cores, the table above compares all the M-series chips released to date, ignoring ‘binned’ and other cut-price sub-variants. Columns labelled Σfn are a crude indicator of performance capacity for the whole CPU, obtained by totalling numbers of cores multiplied by their frequency,
(P x fP) + (E x fE)
where P and E are the numbers of P and E cores, and fP and fE are their respective maximum frequencies. It’s here worth mentioning what a monster the M3 Ultra is in comparison to any other M-series chip.

Because M5 core frequencies don’t currently include Pro or Max variants, those given are starting points. I’d expect to see P cores in the M5 Pro and Max variants reach a maximum frequency of at least 4.7 GHz, although their E cores may be restricted to a lower maximum than the 3.05 GHz of the base variant, to ensure they achieve good economy, as for the M4.

Base variants in Apple’s M-series chips have the fewest P cores in each family, only 4, typically half the number of their Pro variant. Although those should be ample for much of the time, when there are too many high priority (Quality of Service) threads running for user apps, some may overflow to be run on the E cores instead. This is where those frequency tables come into play, as those E cores will be run at higher frequencies to compensate. As the maximum frequency of the E cores in an M5 (3048 MHz) is significantly higher than that of a base M4 (2892 MHz), the base M5 should run those overflowed threads faster.

Another important aspect of the M5 that isn’t clear yet is which version of the Arm Instruction Set Architecture (ISA) it supports. The M4 surprised us with its support of the Armv9.2A ISA, and this year’s A19 and M5 chips are believed to support 9.4A or possibly 8.7. This is particularly relevant to security, as either of those should bring support for Arm’s Enhanced Memory Tagging Extension, which is required to support Apple’s new Memory Integrity Enforcement (MIE), already announced for the A19. Early reports are that the M5 does indeed support the required ISA and its extension, ready for the implementation of MIE in the coming months, if it’s not already built into macOS 26 Tahoe.

Like much else in the base M5 chip, frequencies and features are largely evolutionary, but its enhanced support for GPU compute, faster memory and improved multithreaded performance should deliver substantial improvements. If it’s also the first Mac chip to support Apple’s new security feature MIE, the base M4 is outclassed.

Thanks to your overwhelming response to my appeal for information about CPU core frequencies in M3 Ultra and M5 base chips, this article updates the data to cover those new models in addition to all previous M-series chips.

Performance (P) and Efficiency (E) CPU cores in Apple silicon Macs are run at a range of different frequencies so they can deliver optimum performance with a minimum power and energy use. Cores are grouped into clusters of 2-6, and macOS sets the frequency of each cluster according to workload, Quality of Service, power mode and thermal status. Maximum frequencies differ according to the family, variant within that family, and between E and P cores. Current values are:

• M1 E 2064 MHz or 2.1 GHz; P 3228 MHz or 3.2 GHz;
• M2 E 2424 MHz or 2.4 GHz; P 3696 MHz or 3.7 GHz;
• M3 E 2748 MHz or 2.7 GHz; P 4056 MHz or 4.1 GHz;
• M4 E 2892 MHz or 2.9 GHz; P 4512 MHz or 4.5 GHz.
• M5 E 3048 MHz or 3.0 GHz; P 4608 MHz or 4.6 GHz (base variant only).

As Pro and Max variants may have higher frequencies than base variants, it’s likely that future M5 Pro or M5 Max chips will be able to run their P cores at a higher maximum frequency than today’s base M5 chip.

The full table of frequencies reported by powermetrics is:

This is available for download as a Numbers spreadsheet and in CSV format here: mxfreqs1025

Earlier this year I published a detailed analysis of frequencies in the M1 to M4 families. The only addition to those is the M3 Ultra, whose frequencies are the same as those of the M3 Max, so they haven’t changed. The remainder of this article concentrates on the base variant in each family, from M1 to M5, the chips that power the most popular models and set the standard for what most folk will experience.

Frequency range

Over the last five years and five families of chips, their frequencies have increased steadily, as shown in the charts below. Each bar in those charts spans the range of frequencies from minimum (idle) to maximum, for the base variant in that family.

Idle frequency in E cores has risen from 600 MHz to 972 MHz, a rise of over 60%, and their maximum frequency has risen from 2064 MHz to 3048 MHz, a rise of nearly 50%.

P cores have seen more substantial change. Their idle frequency has risen from 600 MHz to 1308 MHz, a much larger rise of nearly 120%, and their maximum frequency has risen from 3204 MHz to 4608 MHz, just under 50%. The M5 is notable for its greater rise in idle frequency, and lesser rise in maximum frequency.

Frequency steps

Rather than macOS set an arbitrary frequency, it selects one from a list of steps that are distinctive to that family and variant. Looking at the table of frequency steps it might be easy to assume those numbers are chosen arbitrarily, but when expressed appropriately I think you can see there’s more to them.

To look at frequency steps and the frequencies chosen for them, let me explain how I have converted raw frequencies to make them comparable.

First, I work out the steps as evenly spaced points along a line from 0.0, representing idle, to 1.0, representing the core’s maximum frequency. For each of those evenly spaced steps, I calculate a normalised frequency, as
(Fmax – Fstep)/(Fmax – Fidle)
where Fidle is the idle (lowest) frequency value, Fmax is the highest, and Fstep is the actual frequency set for that step.

For example, say a core has an idle frequency of 500 MHz, a maximum of 1,500 MHz, and only one step between those. Its steps will be 0.0, 0.5 and 1.0, and if the relationship is linear, then the frequency set by that intermediate step will be 1,000 MHz. If it’s greater than that, the relationship will be non-linear, tending to a higher frequency for that step. The following charts compare those normalised frequencies with steps evenly spaced between idle and maximum frequencies.

This chart shows normalised frequencies and steps for E cores in base M1 and M5 chips, the latter in red. It shows how, over those five years, the number of steps (available frequencies) has increased. In the M1, the frequency selected in the middle of its five steps was half-way between idle and maximum. Not only does the M5 have more intermediate frequencies available, six instead of three, but frequencies used in the upper half of its steps are higher than in the M1 (when normalised).

This tends to boost higher frequencies used for running threads that can’t be accommodated on P cores, while running background threads at slightly lower frequencies than would be expected when at frequencies close to idle, as they are.

These curves have undergone evolution across different families, as shown here in a composite of the curves for all five families. The red curve of the M5 deviates more from the M1’s straight line of identity than any of the others, particularly at the top end.

The equivalent comparison between frequencies of P cores in M1 and M5 chips shows a different picture. The M1 is again the simpler, being linear until it reaches a step of 0.8, while the M5 has higher frequencies in all except the top few values.

Shown here alongside curves for all earlier families, the red curve for the M5 has higher frequencies for every step apart from the last few.

Taken with the trends seen in the frequency ranges (bar charts above), these demonstrate that the M5 is designed to improve performance by increasing the frequencies used to run threads with higher Quality of Service, as opposed to background threads.

Conclusions

• CPU core frequencies in the M3 Ultra are the same as the M3 Max.
• The base M5 continues the trend for higher frequencies in both E and P cores, with a marked rise in P core idle frequency.
• More subtle changes in intermediate frequencies boost them for higher frequencies of E cores, where they’re likely to improve performance of threads overflowed from P cores.
• Intermediate core frequencies continue to be selected to optimise performance and power use.

Apple silicon chips are designed to minimise the power and energy they use without compromising their performance. One of the many tricks they use is to run the cores in their CPUs at variable frequencies, and in more recent models to shut down those cores they don’t need. At the start of the year, thanks to the many who contributed information about their Macs, we were able to assemble a table of CPU core frequencies for all the M-series chips then available. Those demonstrated that frequencies differed between families such as M1 and M2, and between models within each family such as M2 Pro and Max, as well as between P and E cores.

Since then Apple has released two new chips, the M3 Ultra available in the current Mac Studio, and most recently the base M5 that has recently been impressing so many. This article briefly reviews what we know about CPU core frequencies, and appeals for information about those two new chips.

The best way to discover which frequencies are supported by the P and E cores in the CPU of an Apple silicon chip is using the output of the command tool powermetrics. This lists frequencies for P and E cores, and this article assumes that those it gives are correct. Although it’s most likely that these frequencies aren’t baked into silicon, so could be changed, I’ve seen no evidence to suggest that Apple has done that in any release Mac.

Frequencies

If powermetrics is to be believed, then the maximum frequencies of each of the CPU cores used in each generation differ from some of those you’ll see quoted elsewhere. Correct values should be:

• M1 E 2064 MHz or 2.1 GHz; P 3228 MHz or 3.2 GHz;
• M2 E 2424 MHz or 2.4 GHz; P 3696 MHz or 3.7 GHz;
• M3 E 2748 MHz or 2.7 GHz; P 4056 MHz or 4.1 GHz;
• M4 E 2892 MHz or 2.9 GHz; P 4512 MHz or 4.5 GHz.

However, not all variants within a family can use those maximum frequencies. The full table of frequencies reported by powermetrics is:

This is available for download as a Numbers spreadsheet and in CSV format here: mxfreqs

Why those frequencies?

Depending on workload, thread Quality of Service, power mode, and thermal status, macOS sets the frequency for each cluster of CPU cores. Those used range between the minimum or idle, and the maximum, usually given as the core’s ‘clock speed’ and an indication of its maximum potential performance. In between those are as many as 17 intermediate frequencies giving cores great flexibility in performance, power and energy use. Core design and development uses sophisticated models to select idle and maximum frequencies, and evidently to determine those in between.

Looking at the table, it would be easy to assume those numbers are chosen arbitrarily, but when expressed appropriately there are patterns. Apple’s engineers have clearly put considerable effort into picking optimised frequencies for each of the families and variants within them. If you think this is fine detail and only the maximum frequencies count, then bear in mind that both P and E cores spend a lot of their time running at those intermediate frequencies.

How to report frequencies

If you have a Mac Studio M3 Ultra or MacBook Pro M5 you can add to this collection, please open Terminal and run the command
sudo powermetrics -n 1 -s cpu_power
which then prompts you for your admin password. A few seconds later the window will fill with a single set of measurements looking like this:

All I’d like is a copy containing 3 lines from that:

• Machine model at the top, to tell me which Mac it is, thus which chip.
• E-Cluster HW active residency, which contains a list of frequencies for the E cores.
• P-Cluster HW active residency, which contains a longer list of frequencies for the P cores.

To help, I have highlighted those three lines in the screenshot above.

Thank you.

All of us at some time or other find our mind has gone blank and we can’t remember the password we’ve typed in so often before. Or the person who did know that password may no longer be there to recall it for us. At times like these we may need to gain access to a locked Mac. This article looks at how you can do that in an Intel Mac with a T2 chip, or an Apple silicon Mac, running Big Sur or later, in particular macOS Tahoe. If you want information for an older Mac or macOS, this article should be more helpful.

Keyboard

If you’re certain you entered the correct password but it was refused, check the Caps Lock key isn’t on, and check the Mac is using the correct language keyboard in the menu at the top right.

Firmware password (Intel only)

Intel Macs can be protected using a firmware password set and removed in Recovery, and that can normally only be removed if you know the password. If you don’t, the most reliable way to achieve this is to take the Mac to an Apple store, together with proof of purchase or ownership, and ask them to remove the firmware password.

Further information is in this support note, and in Mr. Macintosh’s article.

Don’t just guess

Trying to guess a Mac’s password is doomed to failure: you only have ten attempts before you have to try in Recovery, and an absolute maximum of fifty attempts in total before access to its Data volume is permanently barred, and that Mac has to be restored in DFU mode. Time intervals are also added between attempts, starting at a minute after the third attempt, and rising to eight hours with the ninth.

Once you realise you don’t know the password, click on the ? to the right of the password entry box. If you keep trying to guess, your attempts will soon be delayed by lock periods that grow up to eight hours.

The Mac will then offer you the best option for resetting the password. If the Mac was opted into iCloud Recovery, you’ll then be asked for details of the Apple Account.

This is now handled by the Recovery Assistant, which also helps you use the Recovery Key if iCloud Recovery wasn’t chosen.

If you don’t have Apple Account details or the Recovery Key, the remaining option is to wipe the Mac. That’s offered in the Erase Mac command in Recovery Assistant’s menu.

For these the Mac needs an internet connection. Further details are in this support article. If you’ve forgotten your Apple Account password, Apple’s support article here should help.

Missing owner

Those methods all assume that you’re the owner/user, have simply forgotten your login password, and can recall your Apple Account details or Recovery Key. If the Mac belonged to someone who’s no longer there, and you don’t have access to their Apple Account, you won’t be able to use those options.

There are two further steps now available that you may find helpful. Provided your Apple Account has two-factor authentication enabled, if you’re unable to sign in or reset your password, you can ask Apple to perform account recovery. This isn’t immediate, but provided you can satisfy Apple that your request is genuine, it should prove possible.

As of macOS 12.1 and iOS/iPadOS 15.2, Apple has supported Legacy Contacts, but those must be set up before you need to use them. The Legacy Contact is then provided with an access key they can use in the event that you can’t because you’re dead. Apple also needs to see a copy of the death certificate before giving full access to the account for a period of three years. Full details are here.

Still no solution

If you want to access the Mac but not its contents, it’s straightforward to return Apple silicon and T2 models to factory condition by putting them into DFU mode and restoring them, as explained here. That may not always be a good step, though: when you try to set that Mac up again, it checks in with Apple. If it has been registered as stolen, you could find it becomes unusable.

If all else fails, get expert advice and help from Apple stores, authorised service providers, and from the many independent Mac technicians around the world who are often only too familiar with these problems.

Virtual machines

Depending on how they’re set up, macOS VMs can now support either iCloud Recovery, or a Recovery Key, provided the guest macOS can.

在过去的很长时间里，「用 Mac 打游戏」一直是网络上一个长久不衰的梗。

但是伴随着近几年苹果深耕 macOS 软件生态、开始主动加大和游戏厂商的合作力度之后，我们得以在 Mac 上见到越来越多经典 IP，「用 Mac 打游戏」听起来似乎不是那么离谱了。

而这背后的一切，除了苹果难得的主动合作态度之外，更要归功于 Apple Silicon 自身在性能和功耗方面的提升。

这不，苹果又在前两天发布了使用 M5 处理器的三款新品：iPad Pro、MacBook Pro 以及 Vision Pro。

爱范儿收到的这台 14 寸 MacBook Pro 是 10+10 核心的 M5 标准版，内存规格为 M5 所支持的最大容量 32GB，以及 1TB 的硬盘，和一块纳米纹理玻璃的抗眩光屏幕：

和今年有抗眩光涂层的 iPhone 17 Pro 相比，MacBook Pro 上纳米纹理玻璃 + 抗反射涂层的组合，无论是在泛光的室外还是充满点光源的室内，消除反光的效果都相当出色。

但 M5 MacBook Pro 的外围硬件和前代其实没有区别，真正让它脱颖而出的，还得是机身里的这块 M5 处理器。

今年的 M5，是继 M3 和 M4 以来，苹果连续第三年推出 3nm 处理器了。M5 的制造工艺换成了 A19 Pro 同款的第三代台积电 3 纳米工艺（N3P）。

换句话说，和 A19 Pro 师出同门的新架构，让 M5 的能效比得到了进一步提升，也让 MacBook 原本就很强的离电续航更上一层楼，哪怕是 14 寸机型也能做到「电脑续航比人长」。

更重要的是，今年 M5 处理器的升级大部分集中在 GPU 上。N3P 工艺优秀的能效比，让这一次 MacBook Pro 的性能释放更加大胆。

就拿 macOS 平台上最主流的 3A 大作《赛博朋克 2077》来说，M5 的 MacBook Pro 使用游戏默认的「for this mac」配置时，能够在大部分画质选项为中或高的前提下实现离电 30 帧的表现。

而打开 FSR 和帧生成后，2077 则可以以接近游戏默认的「中画质」配置里跑到稳定 50-60 帧左右，同时维持你在星巴克的座位不变，不用接电源。

类似的情况也出现在 App Store 上的《控制：终极合辑》，以及爱范儿编辑部最近都在玩的《逃离鸭科夫》中。只需要一点点画质微调，M5 MacBook Pro 都可以稳在 60 帧以上：

换个角度看，这个体验其实已经接近了当年 GTX 1660 的表现。App Store 和 Steam 上越来越丰富的游戏库，满足了 Mac 用户在出差高铁上也能玩玩搜打撤的愿望。

另一方面，M5 最大的升级点还在于它为每颗 GPU 核心都内置了「新一代神经网络加速器」，相当于让 M5 有了个 10 核的 NPU。

这样一来，M5 的 AI 性能——尤其是本地 AI 性能，就有了相当坚实的基础。

以苹果在官方视频中演示过的 Msty Studio 为例，作为一款功能类似 Ollama 但模型库更丰富的「开源模型本地化部署工具」，Msty Studio 最主要的功能，就是可以让你的 Mac 在断网情况下跑语言模型。

我们以最体现性能的「首词元响应速度」表现为标准可以看到，纯本地运行的 DeepSeek-R1:8b 在 10 核心 GPU 的 M5 上运行时，对于相同的一段生成指令，它的速度追平了 24 核 GPU 的 M1 Max：

相当于 M5 用不到一半的核心数量，就可以获得与两三年前 Pro 甚至 Max 规格的 Apple Silicon 相当，同时发热量和功耗还控制在一个相当优秀的水平。

更重要的是，类似的表现也可以在其他本地化的 AI 场景中复现。

比如在纯本地运行的 AI 视频画质增强工具 VidHex 中，在进行视频细节增强时，10 核的 M5 同样出现了追平甚至反超 24 核 M1 Max 的现象。

但在测试过这么多本地 AI 工具之后，我们也不由得产生了一个疑惑：

开源的本地 AI 模型虽然免费，但部署起来比较麻烦，其中很多也没有非常直观的图形界面、必须在终端里面用 CLI（命令行界面）去微调——

而那些收费的本地 AI 工具，实际上就是在卖一个打包好的 GUI（图形界面）。现在云端模型不仅性能更强，价格也逐渐亲民，你觉得「本地化部署和运行 AI 模型」能够对你的电脑购买决策产生影响吗？

总之，对于 M5 的端侧 AI 性能，爱范儿认为：苹果官网上宣传的「相比 M1 有四到六倍的提升」是比较贴切的，不仅是可以稳定的「10 核打 24 核」，同时还有更优秀的发热和功耗控制。

M5 这样一来，就很难不让人期待明年 M5 Pro 和 M5 Max 的表现了，或许可以催生另一批多台 Mac Studio 组网做超算的潮流。

不过就在前两个月，M4 家族的 MacBook Pro 刚刚经历过一轮国补，新的 M5 基础款并不能和 M4 Pro/Max 形成替代关系。

因此今年值得升级 M5 基础版 MacBook Pro 的，更多还是那些仍在坚守 M1 或 M2 系列的老用户，就比如爱范儿编辑部那位还在用 M1 Max 的编辑。

至于爆料中那个模具更新、去除刘海的新 MacBook，则至少要到明年的 M6 机型才有希望了。如果你是 M4 家族的用户，那么小挤一管牙膏的 M5 并不是具有说服力的换机理由。

总之，爱范儿今年对于 M5 MacBook Pro 的结论，依然与前两代相同：

Mac 依然是一个「你必须非常明确自己的需求」才值得入手的优秀工具——如果你不确定自己需不需要一台 Mac，那么就是不需要。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

It has been 22 years since Apple’s first version of FileVault was introduced in Mac OS X 10.3 Panther. Since then it has changed beyond all recognition, and has been transformed from a questionable option to an essential feature of Apple silicon Macs. This article explains those changes, and how enabling FileVault is now a no-brainer.

The past

FileVault 1 was very different. For a start, it didn’t attempt to encrypt whole volumes, as that still isn’t built into HFS+ and only became possible in Mac OS X 10.7 Lion, when Apple added a logical volume manager, Core Storage. So this first effort stored your Home folder in an encrypted disk image, something that also proved easy to crack.

Apple’s second attempt at FileVault proved more successful, with Core Storage handling the encryption of whole HFS+ volumes. This required encryption and decryption to be performed in software, in the days when most CPUs didn’t have instructions to accelerate that. When you first enabled FileVault, macOS had to encrypt the entire contents of the boot volume, which before Catalina included the whole of the system as well as user data. Fortunately, Apple engineered this initial encryption to run in the background while you were still using your Mac. Even so, it could take several days before it was complete and FileVault became active.

This improved with time. Intel CPUs gained instructions to accelerate encryption and decryption, storage and processors got faster, and Apple’s new file system APFS has encryption designed into it from the start. What transformed FileVault, though, was the introduction of the T2 chip in 2017.

The T2 chip was designed for FileVault, among its other accomplishments. It contains a Secure Enclave to isolate and protect encryption keys, and a hardware AES encryption/decryption engine that sits between the internal SSD controller and memory. Those ensure that the contents of the internal SSD can be encrypted for FileVault without any detectable overhead. From Big Sur onwards, these are used to encrypt the whole contents of the Data volume when it’s in internal storage, but not the System volume or the SSV from which the Mac boots.

FileVault base encryption

In Macs with T2 or Apple silicon chips when FileVault is disabled, everything in the Data volume stored on their internal SSD is still encrypted, but without any user password.

Generating the key used to encrypt the volume, the Volume Encryption Key or VEK, requires two huge numbers, a hardware key unique to that Mac, and the xART key generated by the Secure Enclave as a random number. The former ties the encryption to that Mac, and the latter ensures that an intruder can’t repeat generation of the same VEK even if it does know the hardware key. When you use Erase All Content and Settings (EACAS), the VEK is securely erased, rendering the encrypted data inaccessible, and there’s no means to either recover or recreate it.

This scheme lets the Mac automatically unlock decryption, but doesn’t put that in the control of the user, who therefore needs to enable FileVault to get full protection.

FileVault full encryption

Rather than trying to incorporate a user password or other key into the VEK, like many other encryption systems FileVault does this by encrypting the VEK using a Key Encryption Key or KEK, a process known as wrapping.

When you enter your FileVault password, that’s passed to the Secure Enclave, where it’s combined with the hardware key to generate the KEK, and that’s then used together with hardware and xART keys to decrypt or unwrap the VEK used for decryption/encryption. This means that the primary user’s FileVault password is the same as their regular login password. It doesn’t have to be long and complicated either, as it’s combined with the hardware key to create the KEK.

This has several important benefits. When you first turn FileVault on, no data encryption is needed, as the VEK remains the same, so FileVault’s protection is effective immediately. Because the KEK can be changed without producing a new VEK, the user password can be changed without the contents of the protected volume having to be fully decrypted and encrypted again.

Recovery keys

It’s also possible to generate multiple KEKs to support the use of recovery keys that can be used to unlock the VEK when the user’s password is lost or forgotten. Institutional keys can be created to unlock multiple KEKs and VEKs where an organisation might need access to protected storage in multiple Macs.

When you enable FileVault, you’re given the option of being provided with a recovery key, which you should keep a copy of in a safe place, or using iCloud recovery if you prefer.

In the recent past, some macOS updates have played games with recovery keys, issuing new ones when they weren’t expected. When you first get your recovery key, and any time it changes, you should check to see if it will work correctly. Once your Mac is running fully, open Terminal and type in the command
sudo fdesetup validaterecovery
After entering your admin password, you’ll then be prompted to enter the recovery key to be checked. Type or paste that in carefully, and you’ll be told whether it’s correct or not. Note that Terminal doesn’t display the key when you type or paste it in, and you’ll have to press Return without being able to see or check what you’ve entered. If that new key fails, repeat the command using your previous recovery key instead.

FileVault on other disks

The Secure Enclave and AES engine are only wired up to protect volumes on your Mac’s internal SSD. You can still enable FileVault on bootable external disks, and even in macOS virtual machines. But in those cases, volumes that are protected use Encrypted APFS in software, which does impose a small overhead. In the case of VMs, FileVault is the only effective way to safeguard data in that VM, and is recommended. For external disks you’ll need to weigh up the pros and cons.

Summary

• FileVault in modern T2 and Apple silicon Macs is very different from in the past.
• It now provides excellent cost-free protection to your data when stored on the internal SSD.
• If you opt for a recovery key, check it then and whenever it has changed.
• If your T2 or Apple silicon Mac doesn’t have FileVault enabled, why not?

进入十月份的苹果动作频频。

前两天库克还在亲自下场，在 Apple Store 抖音直播间宣发国行 iPhone Air，这不，就在刚刚，苹果又直接在官网上架了今年的新款 MacBook——

搭载 M5 处理器的 MacBook Pro，「真的快，不是梦」：

只不过特别的是，往年的 Apple Silicon 处理器 Mac 都是全系列同时发布，但今年苹果的步调发生了一些变化——

在本次的 MacBook Pro 上，我们没有见到 M5 Pro 或者 M5 Max，而是只有 10+10 核规格的基础版 M5 处理器。

与前期的预测一致，M5 处理器基于 3nm 的台积电工艺打造，与今年能效提升明显的 A19 Pro 处理器属于同代制程，工艺红利明显。

M5 的架构也保持了 10 核心 CPU、10 核心 GPU 的组合。根据苹果官网的图表，今年 M5 的 LLM 提示词处理性能为 M1 的 6.4 倍、3D 渲染性能为 M1 的 6.8 倍：

这样的进步幅度，与更早期爆料出的 M5 iPad Pro 跑分之间相互印证——

是的，那个前阵子被俄罗斯老哥开盒的 M5 iPad Pro 也在今晚发布了，售价 8999 元起，而配置拉满的 2TB 版本售价则来到了让人咋舌的 22499 元。

总的来看，可以看到苹果自研的 GPU 在这一代得到了非常明显的提升，编辑部那个喜欢用 MacBook 玩 2077 的同事估计要坐不住了。

只不过在外观方面，M5 MacBook Pro 就完全没有什么惊喜了——

依然是这个从 2021 年开始陪伴我们的刘海屏模具，依然是 14 或 16 寸的 miniLED 屏幕，HDR 峰值亮度 1600 尼特，并且可以选配抗眩光的纳米纹理玻璃版本。

和 M4 时代的限制一样，这一次的 M5 MacBook Pro 仍然有 16/24/32GB 三档内存可选，最大可选的硬盘则升级到了 4TB。

这样选配下来，起步 16+512GB 的 14 寸 M5 MacBook Pro 售价仍然为 12999 人民币，各项配置全部拉满之后，售价最高可以顶到 2.6 万元——

虽然起步价格和 M4 版本的 MacBook Pro 一致，最重要的处理器升级相当于白送。但仔细想想，这仍然是一个相当让人肉疼的价格，仅凭 Apple Silicon 并不能摊平 miniLED 显示屏等等主要零件的成本。

我们可以看到的是，苹果为了维持 M 系列处理器的更新升级，投入了巨大研发经费。

除了依靠 iPad 去走量之外，就只能通过让 M 系列处理器共享近似制程这种方式，来尽量摊平前期的投入——

目前看来，今年的 M5 MacBook Pro 虽然在 GPU 和 NPU 性能上得到了大跃进，可以毫无疑问地加冕目前最强苹果游戏本，但它距离我们期待中的无刘海触屏 OLED 屏幕 MacBook Pro 仍然有着距离。

不过对于的国补大背景来说，「买新不买旧」依然是选购 Mac 时的金科玉律。

M5 的 MacBook Pro 虽然看上去强势，但下单时要为屏幕等等外围硬件付出很多额外成本，但是别忘了——

过不了多久，我们就可以等到 GPU 大进步、能效比更出色的 M5 MacBook Air 和 Mac mini 了。

除了 MacBook Pro 和 iPad Pro 之外，同样用上了 M5 处理器的，还有 2025 款 Apple Vision Pro：

搭配前文提到的 M5 处理器 GPU 性能大进步，今年的 M5 Vision Pro 虽然外形没有什么变化，但是「可提供更快的性能、更清晰的整个系统细节以及更长的电池续航时间」。

根据苹果 Newsroom 的介绍，使用 M5 处理器的 Vision Pro 可以在屏幕上渲染比上一代多 10% 的像素数量、实现 120Hz 的刷新率以及最低 12ms 的视频延迟，真实性更上一层楼。

苹果还宣称：M5 内部的 16 核神经网络引擎可以让 AI 功能在系统体验上的运行速度提升高达 50%（比如转换空间照片），第三方 app 的运行速度也有显著提升：

此外，M5 优秀的能效比也让 Vision Pro 的普通使用续航来到了 2.5 小时，纯视频播放则可以坚持 3 小时，让你能够沉浸在虚拟世界的时间更长了——

比如 Spectrum SportsNet 就借助 visionOS 的 Apple Immersive，将 NBA 赛场上的沉浸式空间视频带到了 Vision Pro 上。

并且不止 NBA，根据苹果宣布，包括棒球、MotoGP，甚至是奥迪 F1 和红牛的新影片都将在未来几个月上线 Apple Immersive，让 Vision Pro 的内容消费能力值回票价：

搭载 M5 芯片的 Vision Pro 将于 10 月 17 日接受预订、10 月 22 日起发售，起步的 256GB 机型售价仍为 29999 元人民币。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

Virtual Machines running macOS on Apple silicon Macs are more versatile than the host they run on. When you want to create a new VM, or modify an existing one, there are some powerful options available.

One of the most useful is to duplicate an existing VM: as APFS will do that using clone files, and the virtual disk in a VM is stored as a sparse file, that will use much less disk space than making a completely new VM. If you’re likely to need a supply of VMs running the same version of macOS, why not create a base VM using the IPSW for that version, duplicate it, then set up each clone as you require?

For even more flexibility, you can increase the size of the VM as I have already explained. The only remaining problem is how you can migrate the contents of one VM to another. Although my previous attempts to do this had been unsuccessful, Michael was kind enough to provide the solution, and this article explains how to use Migration Assistant in two VMs running concurrently to copy the contents of one VM to another, on the same host Mac. This should also enable you to migrate between a VM and a Mac.

To perform a successful migration, Migration Assistant needs to connect to a mounted Data volume on local storage, or over a network. It can’t use a VM shared folder on the host as the source (server). If your virtualiser supports root level access to USB storage, enabling it to mount an external disk in the VM, then you should be able to migrate from a Time Machine or other backup on that disk. Migration can be performed during initial setup and customisation of macOS, or by running Migration Assistant later. In this walkthrough, I’ll use the former.

You need

To do this, the virtualiser has two fundamental requirements:

• it must be able to run two macOS VMs concurrently,
• you must be able to assign them different MAC addresses.

Apple enforces a limit of two macOS VMs running concurrently on the same Mac, a rule written into the macOS license. Although that might seem stingy, macOS isn’t like Linux and you can’t run Tahoe on a single core with a mere 3-4 GB of memory. However, if you can spare at least 3 P cores and around 12 GB of memory for each, there should be ample to perform a migration. In practice, that means the host Mac should have a total of eight or more P cores, and at least 32 GB of memory.

MAC addresses are supposed to be unique. As the connection between these two VMs is over your local network, your DHCP server must allocate them two different IP addresses, or they won’t be able to migrate. The way to ensure that works is to assign each VM its own and different MAC address.

My own free Viable satisfies both requirements. Here I’ll use that to set up a new VM as the migration client, using an existing VM as the server. For the sake of simplicity, I’ll assume the MAC address of the server is the default, and won’t change that.

Procedure

This uses two macOS VMs running at the same time:

• the destination for the migrated files is a new VM and is the migration client,
• the source of those files is an existing VM and is the migration server.

Start by installing the IPSW to create your new VM. Rather than going straight on to its first run, at this stage open the server VM with the default MAC set, log into it, and locate Migration Assistant in /Applications/Utilities ready to run.

Now change the MAC address in Viable’s window to something different. I used d6:a7:58:8e:79:d4 instead of d6:a7:58:8e:78:d4. Then open the new VM, the migration client, and take it through its configuration, opting to migrate to it from another Mac.

When you reach the screen that sets that up, open Migration Assistant on the server VM, and set it to transfer data To another Mac. Then switch back to the client VM, and you should see that server offered as the source for your migration. Select it and perform the PIN authorisation so they can connect.

On the client, select the items you want to migrate to that VM, and proceed.

After a few minutes, the migration should complete, allowing the client to finish setting up with its new user account. You can then shut down the server and reset the MAC address and other settings in Viable.

Summary

Viable’s narrative documents the sequence:

• Install the IPSW to create the new client VM.
• Start up the server VM with 3 cores and 12 GB memory, and the default MAC of d6:a7:58:8e:78:d4.
• Start up the client VM, with the same cores and memory, and a different MAC of d6:a7:58:8e:79:d4
• When the new (client) VM reaches the Transfer information to this Mac window, open Migration Assistant on the server (old) VM and set it to transfer To another Mac.
• Select the items to migrate on the new (client) Mac and proceed.

Apple’s instructions on migration are here.

This article lists the firmware versions of Macs that have been successfully upgraded to run macOS 26.0 Tahoe.

Apple doesn’t provide an official list of the current firmware versions which should be installed on each model of Mac. Intel models with T2 chips consist of two parts, the second covering iBridge in the T2. Apple silicon Macs just give an iBoot version.

Macs still running older versions of macOS are covered by information at:

• this page for Sequoia,
• this page for Sonoma,
• this page for Ventura,
• this page for Monterey,
• this page for Big Sur,
• this page Catalina,
• this page for High Sierra,
• this page for El Capitan and earlier.

Apple silicon Macs

The current iBoot version is 13822.1.2.

Intel Macs with T2 chips

The current EFI version is 2092.0.0.0.0 and iBridge is 23.16.10350.0.0,0.

Apple Studio Display

The current version remains 17.0 (build 21A329).

How to check your Mac’s firmware version

The simplest way is to run my free tool SilentKnight, available from its product page.

Alternatively, use the About This Mac command at the top of the Apple menu; hold the Option key and click on the System Information command. In the Hardware Overview listing, this is given as the Boot ROM Version or System Firmware Version.

What to do if your Mac’s firmware is different from that shown

If the version is higher than that given here, it indicates that Mac has installed a more recent version of macOS, which has installed a later version of the firmware. This is almost invariably the result of installing a beta-release of the next version of macOS. This occurs even when the newer macOS is installed to an external disk.

If the installed version of firmware has a version lower than that shown, you can try installing macOS again to see if that updates the firmware correctly. If it still fails to update, you should contact Apple Support.

Firmware updaters are now only distributed as part of macOS updates and upgrades: Apple doesn’t provide them separately.

All T2 and Apple silicon models automatically check the integrity of their firmware in the early part of the boot process anyway. If any errors are found then, the Mac should be put into DFU mode and firmware restored from the current IPSW image file. In Sonoma and later this can be performed in the Finder, and no longer requires Apple Configurator 2. Full instructions are provided in this article. If you don’t have a second Mac or don’t feel that you can perform this yourself, it should be easy to arrange with an Apple store or authorised service provider.

(Last updated 19 September 2025)

A couple of weeks ago I estimated how much power and energy were used when performing Visual Look Up (VLU) on an Apple silicon Mac, and was surprised to discover how little that was, concluding that “it’s not actually that demanding on the capability of the hardware”. This article returns to those measurements and looks in more detail at what the CPU cores and GPU were doing.

That previous article gives full details of what I did. In brief, this was performed on a Mac mini M4 Pro running macOS Sequoia 15.6.1, using an image of cattle in a field, opened in Preview. powermetrics collected samples in periods of 100 ms throughout, and a full log extract was obtained to relate time to logged events.

Power use by CPU cores, GPU and neural engine (ANE) are shown in this chart from that article. This tallies against log records for the main work in VLU being performed in samples 10-24, representing a time interval of approximately 1.0-2.4 seconds after the start. There were also briefer periods of activity around 3.2 seconds on the GPU, 4.2 seconds on the CPU, and 6.6-7.1 seconds on the CPU. The latter correlated with online access to Apple’s SMOOT service to populate and display the VLU window.

To gain further detail, powermetrics measurements of CPU core cluster frequencies, active residencies of each core, and GPU frequency and active residency, were analysed for the first 80 collection periods.

Frequency and active residency

Cluster frequencies in MHz are shown in the chart above for the one E and two P clusters, and the GPU. These show:

• The E cores (black) ran at a baseline of 1200-1300 MHz for much of the time, reaching their maximum frequency of 2592 MHz during the main VLU period at 1.0-2.4 seconds.
• The first P cluster (blue), P0, was active in short bursts over the first 1.5 seconds, and again between 6.3-7.0 seconds. For the remainder of the period the cluster was shut down.
• The second P cluster (red), P1, was most active during the three periods of high power use, although it didn’t quite reach its maximum frequency of 4512 MHz. When there was little core activity, it was left to idle at 1260 MHz but wasn’t shut down.
• The GPU (yellow) ran at 338 MHz or was shut down for almost all the time, with one brief peak at 927 MHz.

This chart shows the total active residencies for each of the three CPU clusters, obtained by adding their % measurements. Thus the maximum for the E cluster is 400%, and 500% for each of the two P clusters, and 1,400% in all. These are broadly equivalent to the CPU % shown in Activity Monitor, and take no account of frequency. These show:

• The E cores (pale blue) had the highest active residency throughout, ranging from as little as 30% when almost idle around 5 seconds, to just over 300% during the main VLU phase at 1.4 seconds.
• The first P cluster (purple) remained almost inactive throughout.
• The second P cluster (red) was only active during the periods of highest work, particularly between 1.0-2.4 seconds and again at 6.4-7.1 seconds. For much of the rest of the test it had close to zero active residency.

Taken together, these show that a substantial proportion of the processing undertaken in VLU was performed by the E cores, with shorter peaks of activity in some of the cores in the second P cluster. For much of the time, though, all ten P cores were either idle or shut down.

Load

Combining frequency and active residency into a single value is difficult for the two types of CPU core. To provide a rough metric, I have calculated ‘cluster load’ as
total cluster active residency x (cluster frequency / maximum core frequency)
where the maximum frequency of these E cores is taken as 2592 MHz, and the P cores as 4512 MHz. For example, in the sample period at 2.2 seconds, the P1 cluster frequency was 4449 MHz, and the total active residency for the five cores was 122%. Thus the P1 cluster load was 122 x (4449/4512) = 120.3%. Maximum load for that cluster would have been 500%.

The chart above shows load values for:

• The E cluster (black) riseing to 150-260% during the peak of VLU activity, from a baseline of 20-30%.
• The P0 cluster (blue) which never reached 10% after the initial sample at 0 seconds.
• The P1 cluster (red) spiking at 90-150% during the three most active phases, otherwise remaining below 10%.

Caution is required when comparing E with P cores on this measurement, as not only is E core maximum frequency only 57% that of P cores, but it’s generally assumed that their maximum processing capacity is roughly half that of P cores. Even with that reservation, it’s clear that a substantial proportion of the processing performed in this VLU was on the E cores, with just one cluster of P cores active in short spikes.

Finally, it’s possible to examine the correlation between total P cluster load and total CPU power.

This chart shows calculated total P load and reported total CPU power use. The linear regression shown is
CPU power = 4.1 + (42.2 x total load)
giving a power use of 4,200 mW for a load of 100%, equating to a single P core running at maximum frequency.

Conclusions

• Cluster frequencies and active residencies measured in CPU cores followed the same phases as seen in CPU power, with most of the processing load of VLU in the the early stage, between 1.0-2.4 seconds, a shorter peak at 6.6-7.1 seconds correlating with online lookup, and a small peak at about 4.2 seconds.
• A substantial proportion of the processing performed for VLU was run on E rather than P cores, with P cores only being used for brief periods.
• Visual Look Up used remarkably little of the capability of an M4 Pro chip.

Apple has announced that macOS 26 Tahoe will be released on Monday 15 September, slightly earlier than had been speculated. Even if you’re not intending to upgrade to that, you might instead be looking at moving from Sonoma to Sequoia, or perhaps dragging your feet and considering Sonoma as it enters its final year of support. This article considers what you should do when preparing to upgrade macOS.

One of the surgeons I worked for in my first internship in hospital taught me an important lesson in life: when considering the outcome of anything that could go wrong, assume that it will go wrong, and prepare for that. When it actually works out better than you planned for, you can enjoy your success.

Emergencies

The worst case is that your Mac dies during the upgrade. Although that’s also the least likely, you need to think through your disaster plan. I ensure that all my most essential files and data are shared or copied up to iCloud so that I could get by for a day or three without that Mac. A recent full backup is also essential: if your Mac needs to go away to be resuscitated, one way or another that’s what you’ll be restoring from.

Upgrades do bring a tiny but significant risk of bricking your Mac in a way that only a full Restore will recover it. Although this can apply to Intel Macs with T2 chips if a T2 firmware update goes wrong, this is more the preserve of Apple silicon Macs. I’ve recently stepped through your options with full details here. Your first DFU Restore is daunting, but once you’ve done one, you’ll realise that they’re not that challenging if you have the right cable and DFU port. When you’ve restored firmware and macOS, you’ll then be restoring from that last backup, emphasising its importance.

In the days before the SSV, when there was only one boot volume and that could so readily be corrupted during upgrades, you also needed to have an emergency toolkit handy to repair an upgrade that went wrong. These days, the whole of the System in the SSV is either perfect, or macOS has to be reinstalled. Minor glitches are almost invariably corrected by restarting after the upgrade has completed, or starting up in Safe mode (remember on Apple silicon Macs that’s performed from Recovery).

Reverting macOS

The other possibility that you should plan for is beating a hasty retreat and reverting to an older version of macOS. Provided that you’re fully aware of the changes to the macOS interface brought in Tahoe, I think this is less likely for those upgrading from Sequoia, but if you’re skipping a version or two you could still find yourself unable to use a vital peripheral or one of your key apps, leaving you with reversion as your only option.

I’m sometimes asked by eternal optimists whether you can revert to your previous macOS simply by using its SSV snapshot. Sadly, snapshots are of no help: the only way back is to wipe and reinstall that macOS.

On Intel Macs, you’ll need to do this when booted from an external bootable installer, which doesn’t have to be on a USB ‘thumb’ drive, but does still require its own HFS+ volume to work. Apple explains this here, and Mr. Macintosh has links to all available installer apps.

Although you can do that with an Apple silicon Mac, if you have a second Mac and the right USB-C cable, it’s usually quicker and simpler to do this by restoring from the appropriate IPSW file in DFU mode, then restoring your files from your latest backup, as explained here. This is particularly valuable, as it also restores the original firmware, which may be the root of your problems. Unfortunately, that doesn’t seem possible with Intel Macs. Once their firmware has been upgraded, the user isn’t able to downgrade it.

Checklist

• Check you’re prepared to use your disaster plan if needed.
• Consider sharing and copying to iCloud to help you use another Mac or device temporarily.
• Make a full backup immediately before starting the upgrade.
• Restart, or start up in Safe mode, if the upgrade leaves your Mac with problems.
• Reverting to an older macOS isn’t trivial, and will require you to restore from your backup.
• Revert an Intel Mac using a bootable external installer.
• Consider reverting an Apple silicon Mac by restoring it in DFU mode, using an older IPSW.

Whatever you choose to do, I wish you success, and hope that your preparations prove completely unnecessary.

Why is it that a fast Apple silicon Mac takes so long to tar and Gzip a large folder? Surely, with all those fast Performance cores, even GB should be compressed in the twinkling of an eye? Could it be that macOS is running the tar command on its Efficiency cores instead, eking out the power? This article explores and explains how macOS sets the priority for command tools and similar binaries.

Threads

There are two key factors at work here. The first is threading, division of the work done by a process into single flows of execution run on one CPU core at a time. Every process has its main thread, and many can also create additional threads that can be scheduled to run in parallel. While macOS can and often will move threads around its cores, a single-threaded process can only run on a single CPU core at a time.

QoS

macOS also allocates threads to cores. Although neither you nor the process control that absolutely, processes can influence it by setting a Quality of Service, QoS, for each of their threads. QoS is chosen from the standard list:

• QoS 9 (binary 001001), named background and intended for threads performing maintenance, which don’t need to be run with any higher priority.
• QoS 17 (binary 010001), utility, for tasks the user doesn’t track actively.
• QoS 25 (binary 011001), userInitiated, for tasks that the user needs to complete to be able to use the app.
• QoS 33 (binary 100001), userInteractive, for user-interactive tasks, such as handling events and the app’s interface.

There’s also a ‘default’ value between 17 and 25, an unspecified value, and you might come across others used by macOS.

If all your Mac’s CPU cores are free and idling, macOS will normally allocate threads with a QoS of 17 (utility) and higher to P cores, and those of 9 (background) and lower to E cores. That isn’t guaranteed, and there are circumstances when all threads are allocated to E cores alone, for example when a laptop’s battery is very low and it goes into energy-saving mode.

CPU History

It’s therefore tempting to assume that when a process runs very slowly, it’s being given a low QoS and is pottering along on the E cores. Although that might be correct, it’s a dangerous assumption to make. In this case, to investigate it further, I’ll take a different compressor that offers control over the QoS used for its working threads, such as my free Cormorant or the wonderful Keka.

When compressing an IPSW file of just over 18 GB, using Apple Archive’s LZFSE method in Cormorant takes 7.4 seconds at the maximum QoS of 33, but 114.7 seconds at the minimum QoS of 9. Performing exactly the same compression using aa from the command line takes about 9 seconds, so is clearly being run at high QoS. But using tar to create a tar.gzip takes forever, even longer than Cormorant running at minimum QoS.

Activity Monitor’s CPU History window is a quick and simple way to see what’s going on here, although you must be cautious when trying to interpret values such as CPU %., because those shown don’t take into account the frequency cores are run at.

This is Cormorant compressing at high QoS on all 10 of the P cores.

And this is the same compression performed at low QoS, so confined to the 4 E cores.

Compressing using aa in Terminal also makes full use of all the P cores available.

Running tar in Terminal does use the P cores, but runs in a single thread that’s shuffled between cores and takes more than 10 times as long as it would if it could be run in 10 threads.

Thus, the reason that tar is so slow isn’t because it’s given a low QoS and run on the E cores, but that it’s single-threaded (and not performant either). If you want better performance, look for a substitute that can make good use of multiple threads running in multiple P cores.

Exceptions

There are plenty of binaries that are run at low QoS, hence on the E cores, including most of those that are run in the background or scheduled using LaunchAgents and LaunchDaemons. Their property lists should specify a QoS name for their Priority key, which is often Background or Maintenance, for them to be run at a QoS of 9 or lower on the E cores alone.

There’s also the possibility that a command tool may run its own threads and assign a low QoS to them, although that should always be documented.

Summary

• By default, command tools run in Terminal aren’t assigned low QoS and run on E cores.
• Tools that run in single threads will invariably be slower than multi-threaded equivalents.
• Use Activity Monitor’s CPU History window to see which core types threads are run on.

If you’ve read any of my articles here about the inner workings of CPU cores in Apple silicon chips, you’ll know I’m no stranger to using the command tool powermetrics to discover what they’re up to. Last week I attempted something more adventurous when trying to estimate how much power and energy are used in a single Visual Look Up (VLU).

My previous tests have been far simpler: start powermetrics collecting sample periods using Terminal, then run a set number of core-intensive threads in my app AsmAttic, knowing those would complete before that sampling stopped. Analysing dozens of sets of measurements of core active residency, frequency and power use is pedestrian, but there’s no doubt as to when the tests were running, nor which cores they were using.

VLU was more intricate, in that once powermetrics had started sampling, I had to double-click an image to open it in Preview, wait until its Info tool showed stars to indicate that stage was complete, open the Info window, spot the buttons that appeared on recognised objects, select one and click on it to open the Look Up window. All steps had to be completed within the 10 seconds of sampling collections, leaving me with the task of matching nearly 11,000 log entries for that interval against sampling periods in powermetrics' hundred samples.

The first problem is syncing time between the log, which gives each entry down to the microsecond, and the sampling periods. Although the latter are supposed to be 100 ms duration, in practice powermetrics is slightly slower, and most ranged between about 116 and 129 ms. As the start time of each period is only given to the nearest second, it’s impossible to know exactly when each sample was obtained.

Correlating log entries with events apparent in the time-course of power use is also tricky. Some are obvious, and the start of sampling was perhaps the easiest giveaway as powermetrics has to be run using sudo to obtain elevated privileges, which leaves unmistakeable evidence in the log. Clicks made on Preview’s tools are readily missed, though, even when you have a good estimate of the time they occurred.

Thus, the sequence of events is known with confidence, and it’s not hard to establish when VLU was occurring. As a result, estimating overall power and energy use for the whole VLU also has good confidence, although establishing finer detail is more challenging.

The final caution applies to all power measurements made using powermetrics, that those are approximate and uncalibrated. What may be reported as 40 mW could be more like 10 or 100 mW.

In the midst of this abundance of caution, one fact stands clear: VLU hardly stresses any part of an Apple silicon chip. Power used during the peak of CPU core, GPU and neural engine (ANE) activity was a small fraction of the values measured during my previous core-intensive testing. At no time did the ten P cores in my M4 Pro come close to the power used when running more than one thread of intensive floating-point arithmetic, and the GPU and ANE spent much of time twiddling their thumbs.

Yet when Apple released VLU in macOS Monterey, it hadn’t been expecting to be able to implement it at all in Intel chips because of its computational demand. What still looks like magic can now be accomplished with ease even in a base M1 model. And when we care to leave our Macs running, mediaanalysisd will plod steadily through recently saved images performing object recognition and classification to add them to Spotlight’s indexes, enabling us to search images by labels describing their contents. Further digging in Apple’s documentation reveals that VLU and indexing of discovered object types is currently limited by language to English, French, German, Italian, Spanish and Japanese.

Some time in the next week or three, when Apple releases macOS Tahoe, we’ll start seeing Apple silicon Macs stretch their wings with the first apps to use its Foundation Models. These are based on the same Large Language Models (LLMs) already used in Writing Tools, and run entirely on-device, unlike ChatGPT. This has unfortunately been eclipsed by Tahoe’s controversial redesign, but as more developers get to grips with these new AI capabilities, you should start to see increasingly novel features appearing.

What developers will do with them is currently less certain. These LLMs are capable of working with text including dialogue, thus are likely to appear early in games, and should provide specialist variants of more generic Writing Tools. They can also return numbers rather than text, and suggest and execute commands and actions that could be used in predictive automation. Unlike previous support for AI techniques such as neural networks, Foundation Models present a simple, high-level interface that can require just a few lines of code.

If you’ve got an Apple silicon Mac, there’s a lot of potential coming in Tahoe, once you’ve jiggled its settings to accommodate its new style.

Look in the log, and Visual Look Up (VLU) on an Apple silicon Mac apparently involves a great deal of work, in both CPU cores and the neural engine (ANE). This article reports a first attempt to estimate power and energy use for a single VLU on an image.

To estimate this, I measured CPU, GPU and ANE power in sampling periods of 100 ms using powermetrics, and correlated events seen there with those recorded in a log extract over the same period, obtained using LogUI. The test was performed on a Mac mini M4 Pro running macOS 15.6.1, using Preview to perform the VLU on a single image showing a small group of cattle in an upland field. Power measurements were collected from a moment immediately before opening the image, and ceased several seconds after VLU was complete.

When used like this, powermetrics imposes remarkably little overhead on the CPU cores, but its sampling periods are neither exact nor identical. This makes it difficult to correlate log entries and their precise timestamps with sampling periods. While powermetrics gives power use in mW, those measurements aren’t calibrated and making assumptions about their accuracy is hazardous. Nevertheless, they remain the best estimates available.

Log narrative

The first step in log analysis was to identify the starting time of powermetrics sampling periods. Although execution of that command left no trace in its entries, as it has to be run with elevated privileges using sudo, its approval was obvious in entries concluding
30.677182 com.apple.opendirectoryd ODRecordVerifyPassword completed
A subsequent entry at 30.688828 seconds was thus chosen as the start time for sampling periods, and all times given below as given in seconds after that time zero.

The following relevant events were identified in the log extract at elapsed times given in seconds:

• 1.3 com.apple.VisionKit Signpost Begin: “VisionKit MAD Parse Request”
• 1.3 com.apple.mediaanalysis Running task VCPMADServiceImageProcessingTask
• 1.4 ANE started and an ObjectDetectionModel run for 0.2 s
• 1.6 ANE activity and a NatureWorldModel run for 0.25 s
• 2.0 ANE activity for 0.15 s
• 2.4 ANE activity for 0.1 s
• 8.1 ANE activity and a UnifiedModel run for 0.01 s
• 8.1 PegasusKit queried Apple’s SMOOT service, the external connection used to populate the VLU window.

Thus, the ANE was run almost continuously from 1.4-2.2 seconds after the start of sampling, otherwise was used little over the total period of about 9 seconds. Over that period of activity, an initial model used to detect objects was succeeded by a later model to identify objects in a ‘nature world’.

Power and energy estimates

From the log record, it was deduced that the VLU was started in powermetrics sample 10 (1.0 seconds elapsed), and essentially complete by sample 75 (7.5 seconds elapsed), a period of approximately 6.5 seconds, following which power use was low until the end of the sampling periods. All subsequent calculations refer to that series of samples and period of time.

Sums, averages and maxima of power measurements for that period of 6.5 seconds are:

• CPU 64,289 mW total, 989 mW average, 7,083 mW maximum (10 P cores)
• GPU 3,151 mW total, 48 mW average, 960 mW maximum (20 cores)
• ANE 1,551 mW total, 24 mW average, 671 mW maximum
• total 68,991 mW total, 1,061 mW average, 7,083 mW maximum.

Thus for the whole VLU, 93% of power was used by the CPU, 4.6% by the GPU, and only 2.2% by the ANE.

For comparison, in the M4 Pro chip running maximal in-core loads, each P core can use 1.3 W running floating point code, and 3 W running NEON code. The chip’s 20-core GPU was previously measured as using a steady maximum power of 20 W, with peaks at 25 W.

As each power sample covers 0.1 seconds, energy used during each sampling period is power/0.1, thus the total energy used over the 6.5 second period of VLU is:

• CPU 6.4 J
• GPU 0.3 J
• ANE 0.2 J
• total 6.9 J.

Those are small compared to the test threads used previously, which cost 3-8 J for each P core used.

Power over time

Power used in each 100 ms sampling period varied considerably over the whole 10 seconds. The chart below shows total power for the CPU.

Highest power was recorded between samples 10-25, corresponding to 1.0-2.5 seconds elapsed since the start of measurements, and most events identified in the log. Later bursts of power use occurred at about 4.2 seconds, and between 6.6-7.1 seconds, which most probably corresponded to opening the info window and performing the selected look-up.

Almost all power use by the neural engine occurred between 1.5-2.1 seconds, correlating well with the period in which substantial models were being run.

Peak GPU power use occurred around 1.0-1.5 seconds when the image was first displayed, at 3.1-3.2 seconds, and between 6.5-7.4 seconds. It’s not known whether any of those were the result of image processing for VLU as GPU-related log entries are unusual.

Composite total power use demonstrates how small and infrequent ANE and GPU use was in comparison to that of the CPU.

Conclusions

Given the limitations of this single set of measurements, I suggest that, on Apple silicon Macs

• power and energy cost of VLU is remarkably low;
• the great majority of work done in VLU is performed in the CPU;
• although use of the neural engine may result in substantial performance improvements, VLU doesn’t make heavy demands on the neural engine in terms of power or energy use;
• VLU may appear impressive, but it’s not actually that demanding on the capability of the hardware.