Ask HN: How to intentionally throttle CPU on a M1 MacBook?
I recently had no choice but to upgrade to an M1 Macbook from an Intel-based one. I did not want to upgrade, as I’m working on a software for which performance on mid-range machines is critical, but unfortunately the previous laptop gave up on me. Since M1 macbooks are so much more powerful than previous generations, is there a way to intentionally slow it down to be able to test my program on a slower machine? One way I can think of, is to run the program inside a VM, but that would slow down the development loop.
Thanks for all the suggestions. Now I have the following list of tricks to try (collected from the thread):
- taskpolicy -b -p [pid]
- macOS low power mode (which can even be enabled when plugged in)
- VM with limited CPU and RAM, and shared filesystem with host OS.
- Buy older laptop (not an option at this point, really)
- Stress the machine by compiling the Rust compiler in parallel :)
63 comments
[ 3.8 ms ] story [ 145 ms ] threadThat way you can verify that It's been properly reset, and that the description/picture are accurate.
:)
I haven't asked about that that I can recall, but my guess is they don't see a lot of margin on that stuff, especially with at least two Apple stores in easy driving distance and most Apple customers tending strongly to favor the latest and greatest. Disappointing, but with the streaming boom then being on the upswing, I really can't blame them for making space to cater to the open-walleted parents of a million infants in Fortnite t-shirts.
Still, if you have a Micro Center nearby and you haven't been, you should go there. It's like what computer stores used to be, back when those still existed.
I have a 2006 Intel MacBook that still works but I've also had 3 year old Macs just quit working.
And if you abuse things like https://github.com/dortania/OpenCore-Legacy-Patcher/releases you can keep running "modern" releases on older hardware.
But it depends on what you're trying to do.
It is often worth selling the dead one for parts to someone else; even if the logic board is dead the screen is likely to be useful.
I've also had 3 year old Dells, HPs, Lenovos, ASUS, you name it... all die prematurely. I don't honestly believe that any particular company uses any better quality hardware than another. Not measurably better, at least. You're just gonna win some, and lose some, no matter how much you pay for the hardware. This year's most reliable laptop could have a revision next year that makes it the worst laptop...
With laptops and proprietary desktops especially, it's sometimes worth paying for the extra warranty.
As a counter anecdote, I've done this three times for macs so far, and all of those still work for their intended purpose. The 2011 model even survived overheating due to user error and fried its internal graphics cables but works fine with an external monitor. And sure, they're all stuck on whatever their respective latest operating systems are, but that's fine: they're test/compile machines, not daily drivers. And not all of them: in 2022 the oldest realistic mac target you're looking at is the 2015 macbook pro (i.e. "the good one", that even today's models can still take design lessons from).
And here's the best part: if something in them breaks, replacing the entire machine is only a few hundred bucks. Which you don't have to: you just need to buy a "for parts" with the bits you need still working. Any model that's still being used in the wild still has a decent sized for parts market. You can tell when the world stops using a model when the parts dry up.
Geekbench scores with normal and low power mode
- Single core Normal/low power - 1749/1053
- Multi core - 7739/4491
https://www.reddit.com/r/MacOS/comments/qj13bv/m1_macbook_ai...
Geekbench scores with normal and low power mode
- Single core Normal/low power - 1749/1053
- Multi core - 7739/4491
https://www.reddit.com/r/MacOS/comments/qj13bv/m1_macbook_ai...
It is indeed possible to constrain a process to the Icestorm cores using taskpolicy:
> taskpolicy -b -p 567
where 567 needs to be replaced by the process id.
Reference: https://eclecticlight.co/2022/10/20/making-the-most-of-apple...
※ - https://www.stclairsoft.com/AppTamer/index.html
Actually, now that I think about it, I'm almost tempted to write a script to do just that, and either relegates CPU-hogging processes to the icestorm cpus or just kill -stop <process id> them
EDIT: Fixed url
[1] https://eclecticlight.co/2022/01/24/how-you-cant-promote-thr...
What do you mean mid-optimize?
I'm just saying if you're running on macOS and want to limit resource usage, running it in docker in order to limit resource usage, feels like solving the problem at the wrong layer as you already are using a VM in that case, so just put the resource limitation directly on the VM instead.
Hence the mid-optimization: don't go "the VM's already slow, tweak that", just keep going and tweak Docker, it's almost trivially easy, and trivially replicated on any other machine should you need to either scale or hand off.
It's just as easy as tuning docker. Every VM gets resources allocated to it, that you, as a user, can customize however you want. Most major VM implementations have this for you to use today already. Just as replicable as tuning docker container parameters.
A throttled high-end machine will not behave like a low-end machine. Sure, they'll superficially both be slow, but not slow in the same way. There are differences in IOPS, cache sizes, and so forth you simply can't escape from.
Especially in low-end laptops, you may also have uneven performance from thermal throttling.
Some people like to develop on a slower machine (do all their development work on the slow machine) so they catch things, others like to do all the work on the fastest machine they have, and only when nearing completion test things on the slower one. Both have arguments in favor - a decent compromise can be a "build on fast, deploy on slow" where it may be as simple as a shared folder between the two machines with Synergy or even Ventura's built-in equivalent for running the app.
Crippling a high Mac is still not going to effectively mimic a low end system. An end user device is a system of queues if you will think like that. The slowest/smallest/busiest link in the system determines the overall experience. Sounds like for your needs, you’re going to need a real low-end system that has real bottlenecks in CPU(speeds, caches, accelerators), mem(capacity and speeds), IO(capacity and speeds).
I fail to take a CPU offline on my M1 mac: "cpuctl: processor_exit(i) failed"
Moreover, I can't discern the core type from the cpuctl list since all cpus are of the same "type".
I assume it is easier to activate the "power safe mode" then. Of course, the disadvantage of these approaches is that the whole system gets slower.
I sometimes use a remote desktop tool (eg. teamviewer) to troubleshoot my software running on a users machine (with the user on the phone normally).
It's usually the quickest way to understand what issue a user is having, and the user walks away thinking they're getting great customer service.
It could be a good way to get a rough feeling for which areas of your software perform well/badly on a low end machine. One benefit is you get to experience it the way a user does - so the interactions with a 7 year old copy of norton antivirus, one of 13 programs running at once with 1GB of RAM, the fact the user has an always-on-top program that is blocking some of the UI but they don't know how to move it, etc.