How M1 Macs feel faster than Intel models: it’s about QoS | Hacker News Reader

How M1 Macs feel faster than Intel models: it’s about QoS

eclecticlight.co

It does not just feel faster, in many cases it is faster.

E.g. compiling Rust code is so much faster that it is not even funny. cargo install -f ripgrep takes 22 seconds on a Mac Book Air with M1, same on a hexacore 2020 Dell XPS 17 with 64GB RAM takes 34 seconds.

I did a side-by-side comparing with my friends' M1 macbook and my (more expensive, nearly brand new) ryzen 5800x workstation compiling rust. The ryzen was faster - but it was really close. And the macbook beats my ryzen chip in single threaded performance. For reference, the ryzen compiles ripgrep in 19.7 seconds.

The comparison is way too close given the ryzen workstation guzzles power, and the macbook is cheaper, portable and lasts 22 hours on a single charge. If Apple can keep their momentum going year over year with CPU improvements, they'll be unstoppable. For now it looks like its not a question of if I'll get one, but when.

I've done a side by side with my Ryzen 3700x compiling a Go project.

6 seconds on the Ryzen, vs 9 seconds on the M1 air.

`time go build -a`, so not very scientific. Could be attributed to the multicore performance of the Ryzen.

Starting applications on the M1 seems to have significant delays too, but I'm not sure if that's a Mac OSX thing. Overall it's very impressive, I just don't see the same lunch eating performance as everyone else.

The battery life and lack of fans is wonderful.

edit: Updated with the arm build on OSX. 16s -> 9 seconds.

> `time go build -a`, so not very scientific.

A tool I have enjoyed using to make these measurements more accurate is hyperfine[0].

In general, the 3700X beating the M1 should be the expected result... it has double the number of high performance cores, several times as much TDP, and access to way more RAM and faster SSDs.

The fact that the M1 is able to be neck and neck with the 3700X is impressive, and the M1 definitely can achieve some unlikely victories. It'll be interesting to see what happens with the M1X (or M2, whatever they label it).

[0]: https://github.com/sharkdp/hyperfine

I find M1 optimized apps load quickly while others vary. But what really varies is website load times. Sometimes instant, sometimes delayed.

All this said, there really is no comparison. I don’t even think about battery for the M1, I leave the charger at home, and it’s 100% cool and silent. It’s a giant leap for portable creative computing.

> Starting applications on the M1 seems to have significant delays too, but I'm not sure if that's a Mac OSX thing.

That's a Mac OSX thing. It's verifying the apps.

https://appletoolbox.com/why-is-macos-catalina-verifying-app...

I’d like to point out that compiling stuff is usually disk/io intensive. Could this not just be that the Apple machine has a faster hard drive/memory?

update:

time GOARCH=amd GOOS=linux go build -a

6s for the M1 too!

Did both machines compile to the same target architecture? If you did native compiles, then perhaps LLVM's ARM backend is simply faster than its x86 backend...

I think this is potentially a huge part of it - I'd do the benchmark by doing a native compile and a cross compile of each, and also do the same on a RAM disk instead of SSD (a large compile can end up just being a disk speed test if the CPU is waiting around for the disk to find files).

Maybe that would have been the case if only compilation times were reported to be good. But no, this is across many different kinds of workloads. Even Blender running in Rosetta can beat native x86 processors, which is bonkers.

I think these performance metrics are somewhat limited in their usefulness. A Ryzen workstation might not have the same single-core performance or energy efficiency—however, a ryzen workstation can have gobs of memory for massive data-intensive workloads for the same cost as a baseline M1 device.

In addition: let’s talk upgradability or repairability. Oh wait, Apple doesn’t play that game. You’ll get more mileage on the workstation hands-down.

The only win for those those chips I think is battery efficient for a laptop. But, then why not just VNC into a beastmode machine on a netbook and compile remotely? After all, that’s what CI/CD pipeline is for.

granted they charge exorbitant prices for their hardware, but I can’t believe how my 2010 MacBook Pro is still functioning perfectly fine.. except for them making it unsupported. I can’t say that about any other pc/laptop I have had. Not even desktops

I don't know, I feel other laptops at the same price point as Apple Macbooks do this too, sometimes even better. I bought a HP 8530w in 2009 or so and it still works. Replacing the DVD drive for a SSD required just a common Philips screwdriver and battery replacements are sold by HP themselves or many others.

My "writing desk" PC is a Thinkpad X201 tablet from 2010, with the same SSD upgrade I put in my own 2010 Macbook Pro (a dedicated Logic Pro machine these days). There have always been manufacturers for whom that's the case on the PC side of things--you just kinda had to pay for it up front.

My two main PCs are a Phenom II-based desktop and a Thinkpad X220i (with the lowly Core i3, even!). Both are perfectly functional and usable today, with a few minor upgrades here and there, the usual SSDs, more RAM and a Radeon RX560 for the desktop.

The Thinkpad is obviously no powerhouse, but still works great for general desktop use, ie. browsing, email, document editing, music, video (1080p h264 is no problem). The desktop plays GTA V at around 40-50 FPS at 1080p with maximum settings. And this isn't some premium build, it's a pretty standard Asrock motherboard with Kingston ValueRAM and a Samsung SSD.

Decade-old hardware is still perfectly viable today.

I just had storage fail on my first gen touchbar macbook. It's a PITA, the storage is soldered onto a board. They replace the board, the can't recover the data (didn't expect them to). I'd pay the extra mm or two it would require them to just use a standard like m2. SSD storage just fails after awhile, especially if you do lots of things that thrash the disk.

Using 2011 sandybridge motherboard with a xeon-1230 i bought in 2012. I Had to replace 2 HDD + started using ssd for OS partition. It's working great, need to replace my nvidia GPU that is EOL but still working great.

I have an old gaming ASUS laptop from 2010. Still works like a charm after hard drive was switched to SSD. I have an even older Asus Netbook (15 years old eee PC I think) that still works. Netbook is too slow for modern software and I do not really use it but it works.

> But, then why not just VNC into a beastmode machine on a netbook and compile remotely? After all, that’s what CI/CD pipeline is for.

Is this how you work?

> Is this how you work?

This is exactly how I've worked for a number of years now, for my home/personal/freelance work. Usually using a Chromebook netbook ssh'ing into my high spec home server. I'd do the same for work, but work usually requires using a work laptop (MacBook).

I've worked that way for 10 years. My current desktop is a 5 year old Intel i3 NUC with a paltry 8G of memory. Granted, it uses all that memory (and a bit more) for a browser and slack, and the fan spins up any time a video plays. But usually it's silent, can drive a 4k monitor, and most of the time I'm just using mosh and a terminal, which require nearly nothing.

OTOH, the machine that I'm connecting to has 32c/64t, half a terabyte of RAM and dozens of TB of storage.

My work takes place at a beefy desktop machine. I wouldn't want it any other way... I get to plug in as many displays as I need, I get all the memory I need, I can add internal drives, there's no shortage of USB ports or expansion - and I get them cheap. For meetings or any kind of work away from my desk I'll remote in from one of my laptops.

All that and my preferred OS (Manjaro/XFCE), which runs on anything, has been more stable than any Mac I've ever owned. Every update to macOS has broken something or changed the UI drastically and in a way I have no control over...

If I ever switch away from desktops, it will be for a Framework laptop or something similar.

Well, actually I have a beastmode mobile workstation that gets maybe 3 hours of battery life on high intensity. And when the battery is depleted I find a table with an outlet and I plug it in.

Everything in the machine can be upgraded/fixed so it should be good for a while.

I’m not saying this to be snarky. I just want to emphasize that while M1 is great innovation, I put repairability/maintainability and longevity on a higher pedestal than other things. I also highly value many things a computer has to offer: disk, memory, CPU, GPU, etc. I want to be able to interchange those pieces; and I want to have a lot of each category at my disposal. Given this, battery life is not as important as the potential functionality a given machine can provide.

That's 90% how I've worked in ~15 years as an SWE.

> The only win for those those chips

I suspect the number of people, even developers, for whom 16GB memory is plenty probably greatly exceeds the number who need a beast mode Ryzen. But even then, a large proportion of the devs who might need a Build farm on the back end would be doing that anyway so they might as well have an M1 Mac laptop regardless.

Anyway Mac Pro models will come.

Power consumption is a good point. I wonder what the M1's power consumption is during those 19.7 seconds of compiling ripgrep compared to other platforms.

Low.

For me, SoC power draw when compiling apps is usually around 15 to 18W on a M1 mac mini.

My example app (deadbeef) compiles in about 60 seconds on that mac mini.

On a 2019 i7 16” MBP (six core), it takes about 90 seconds, and draws ~65W for that period.

So… radically more power efficient.

edit: this is the same version of macOS (big sur), xcode, and both building a universal app (intel and ARM).

I'm seeing a big different when compiling our project, with the M1 Macbook Pro beating the iMac Pro when building our projects (23min vs 38 mins).

Is it all CPU though, or is building ARM artefacts less resource intensive than bulding ones for Intel ?

iMac Pro has a large variety of performance, going from 8 to 18 cores and it uses a 4+ year old Xeon CPU. Unsurprisingly the 18 core handily beats the M1 in multi-core benchmarks:

18 core iMac Pro 13339: https://browser.geekbench.com/macs/imac-pro-late-2017-intel-...

M1 Mac mini 7408: https://browser.geekbench.com/macs/mac-mini-late-2020

>For now it looks like its not a question of if I'll get one, but when.

My exact sentiments. I've been looking for a gateway into Apple and the M1 Air seems like it. It has now become a matter of time and not just a fleeting thought.

> If Apple can keep their momentum going year over year with CPU improvements

I’ve been blown away with games running on M1. If Apple could up their GPU game as well, that’d be really cool.

Are you sure Rust compilation can use multiple cores to the fullest?

I don't use Rust, but a quick search returned for example this issue:

https://github.com/rust-lang/rust/issues/64913

My cpu usage graph shows all cores at 100% for most of the compilation. But near the end it uses fewer and fewer cores. Then linking is a single core affair. It seems like a reasonable all-round benchmark because it leans on both single- and multi- core performance.

And I really care about rust compile times because I spend a lot of small moments waiting for the compiler to run.

How long is the battery life on both if compiling non-stop? Assuming both keep similar compile from start of battery to end it would be interesting to see if the ryzen is truly guzzling batteries.

I'm guessing the 5800x work station is a desktop, not battery powered...

You are right. Missed then when i was angerly responding.

I have a Ryzen 7 4700g. I wanted to compare this to the GPU side of the M1. On Geekbench OpenGL test, it was slightly faster than the M1. I would like to find a better test.

> macbook … and lasts 22 hours on a single charge

I keep hearing this but have not experienced this in person. I usually get about 5 hours of life out of it. My usual open programs are CLion, WebStorm, Firefox (and Little Snitch running in the background).

However, even with not having IDEs open all the time, and switching over from Firefox to Safari, I’m only seeing about 8 hours of battery life (which is still nice compared with my 2013 MBP that has about 30 minutes of battery life).

>However, even with not having IDEs open all the time, and switching over from Firefox to Safari, I’m only seeing about 8 hours of battery life (which is still nice compared with my 2013 MBP that has about 30 minutes of battery life).

I would consider getting a warranty replacement. Something is wrong.

For reference, my M1 Air averages exactly 12 hours of screen-on time (yes, I've been keeping track), and the absolute worst battery life I've experienced is 8.5 hours, when I was doing some more intense dev workflows.

The Macbook Air does not get 22 hours but the Macbook Pro gets kinda close under the conditions specified in the test.

I'm still unconvinced it's the M1's design and not TSMC's fab process.

When you move to a smaller process node, you have a choice between improving performance or cutting power. (or some mix of both)

Apple seems to have taken the power reduction with the A14 and M1 on TSMC 5nm, not the performance increase.

>The one explanation and theory I have is that Apple might have finally pulled back on their excessive peak power draw at the maximum performance states of the CPUs and GPUs, and thus peak performance wouldn’t have seen such a large jump this generation, but favour more sustainable thermal figures.

https://www.anandtech.com/show/16088/apple-announces-5nm-a14...

I think the latest Ryzen 5800x CPUs kind of prove it's the TSMC fab process. You've now got M1s, Graviton2s, and Ryzens all crushing it to similar levels.

I dunnoh... the Ryzen 5800x laptops seem to be able to stay ahead of the M1's for most tasks.

Huh? 5800x laptop? The 5800x is a desktop chip.

The 'X' was meant to be "various letter extensions on the 5800 series", such as 5800U, 5800H, 5800HS. I probably should have used different terminology from the model number, as there are other Zen 3 mobile processors like the 5900HX, 5980HS and 5980HX that if anything make the point stronger.

After buying my M1 and benchmarking it against the top of the line i9 I considered shorting Intel's stock, alas they're so large it'll take a while for the decline to catch up with them.

In previous discussions about this it was pointed out that LLVM may be significantly faster at producing ARM code versus x86. The comparison may still be the one that actually matters to you but at least in part be an advantage of ARM in general and not just the M1. rust is very good at cross-compiling so compiling to ARM on Dell and to x86 on the M1 may add some interesting comparisons.

So then the next question is, is this really an apples-to-apples comparison? It wouldn't surprise me at all if the x86 back-end takes more time to run because it implements more optimizations.

Are you compiling for ARM in both cases (or x86 in both cases)? Otherwise you are building 2 completely different programs, one is ripgrep for ARM and the other is ripgrep for Intel.

The programs would be pretty much identical until they are lowered, which is generally not a bottleneck for Rust compiles…

In native Typescript compile of a very large angular app I see an even more dramatic 1:20s to 40s compared to a desktop i9. I feel as if the M1 may have been designed around a detailed and careful look at how computers and compliers work and then designed a CPU around that rather than the other way around.

It's like buying a car and modifying to take it racing vs buying a race car, the race car was designed to do this.

>> I feel as if the M1 may have been designed around a detailed and careful look at how computers and compliers work and then designed a CPU around that rather than the other way around.

This is the position that Apple have set up for themselves with their philosophy and process. It would seem that Intel and AMD have to play a very conservative game with compatibility and building a product that increments support for x86 and x64. They can't make some sweeping change because they have to think about Linux and Windows.

Apple own their ecosystem and can move everything at once (to a large degree.) This also gives an opportunity to design how the components should interact. Incompatibility won't be heavily penalized unless really important apps get left behind. The improvements also incentivize app makers to be there since their developer experience will improve.

> It would seem that Intel and AMD have to play a very conservative game with compatibility and building a product that increments support for x86 and x64.

Talk to people who design chips. The compatibility barely impacts the chip transistor budget these days, and since the underlying CPU isn't running x86 or x64 instructions, it really doesn't impact the CPU design. There may be some intrinsic overhead coming from limitations of the ISA itself, but even there they keep adding new instructions for specialized operations when opportunities allow.

Exactly this. Apple has spent decades drilling a message into third-party developers: Update your apps regularly or get left behind.

Everyone who develops for one of their platforms is just used to running that treadmill. An ARM transition is just another thing to update your apps for.

App developers are incentivized in another way: software that takes advantage of new features or performance are often what Apple chooses to promote in a keynote or in an App Store’s featured section.

Typescript compilation doesn't use all the cores available on the CPU; I think it maxes out at 4 as of now [1]. This might be working well for M1, which has 4 high performance cores and 4 efficiency cores.

[1]: https://github.com/microsoft/TypeScript/issues/30235

What OS are you running on the Dell though? Windows is notoriously slower for file system operations even without AV and the default there is to prefer foreground apps vs something like compile tasks.

Yep, see below. With WSL and an ext4 virtual disk it takes only 29 seconds. Still quite a bit more than the 22 seconds on the Macbook.

WSL2 right? Given the virtualization overhead for IO I would expect native Linux to be faster.

Hard to compare without mentioning the actual CPU in it. FWIW my Ryzen 3900X completes that compile in 15s.

To be fair, that is a relatively high-end desktop CPU, but it's also a massive margin for a last-gen model.

We also have to consider the i7 and M1 run at about 1/7 the TDP of the Ryzen. Just underscores the good design behind the QoS and judicious use of the Performance cores vs Efficiency cores.

My water-cooled 3900XT is locked to 4.4ghz all cores with relatively fast double banked 2x16GB c15 3600mhz memory. (It never drops under 4.4 on any of the 12/24 cores.)

Also has a Samsung 980 1TB drive, and a 3070 GPU; the system truly is extremely quick. (Win10+WSL2).

(I'll have to try that compile in the next day or so; will reply to myself here).

OS matters for this comparison. If your Dell XPS was running Windows, that might explain the discrepancy.

For instance Windows on NTFS etc. is notoriously slow at operations that involve a lot of small files compared to Linux or whatever on ext4.

Unless your Dell was also running OSX, you're probably not comparing hardware here.

For me, it takes 34 seconds on M1 (MBP13):

    Finished release [optimized + debuginfo] target(s) in 34.50s
    ...
    cargo install -f ripgrep  137,66s user 13,00s system 435% cpu 34,632 total

For comparison TR1900x (yeah, desktop, power-guzzler, but also several years old), Fedora 34:

    Finished release [optimized + debuginfo] target(s) in 25.15s
    ...
    real        0m25,271s
    user        4m41,553s
    sys         0m7,216s

Thank you for the perspective.

Here's r7 4800HS (35w) on linux:

Finished release [optimized + debuginfo] target(s) in 24.98s

real 0m25.151s

user 4m54.987s

sys 0m6.764s

I just did a test on my old Lenovo laptop... Intel i7-8565U CPU @ 1.80GHz

# git clone https://github.com/BurntSushi/ripgrep && cd ripgrep

# cargo clean

# time cargo build

real 0m23,805s

user 1m11,260s

sys 0m3,806s

How is my crappy laptop on par with your M1? :)

You are not doing a release build.

thanks, problem solved - now it's 1 minute...

Are you counting download time as well? It took 8.30 sec on hexacore now when I tried it.

Nope, pure compile time on a Core i7-10750H with Windows and Rust 1.52.1, antivirus disabled. WSL did not make much of a difference though (29 seconds).

The Windows filesystem is extremely slow, even without WSL. It can be mitigated to some extent by using completion ports, but I doubt the Rust compiler is architectured that way--

You should benchmark against Linux as well.

> Windows

There's your problem.

Even Microsoft concedes that Windows is legacy technology now.

And here I thought that having a desktop CPU like Ryzen 5 2400G with loads of RAM would take me somewhere. It took the machine around 71 seconds.

EDIT: could you measure C compilation. For example:

  git clone --depth 1 --branch v5.12.4 "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
  cd linux
  make defconfig
  time make -j$(getconf _NPROCESSORS_ONLN)

For me it's slightly below 5 minutes.

It took the machine around 71 seconds.

Are you including download time? On my Ryzen 7 3700X, it's done in 17 seconds.

Specifically I did it two times to not see the download/syncing time. Also to a fresh home. 3700X has 16 threads, 2400G has 8, that probably makes up for the most of the difference. But M1 has 8 cores (4× high-performance + 4× high-efficiency. Maybe rust version also counts? I'm on rust 1.48.

EDIT: I checked on 1.52.1, which is latest stable and it went down to 54 seconds. So that also makes up a significant difference.

It's been amazing for me.... EXCEPT for when resuming from sleep, for some reason it would be very slow for a minute.

I have since FIXED THIS! The solution is to just not let it sleep. I'm using Amphetamine and since then it has been amazingly fast all the time.

> I'm using Amphetamine and since then it has been amazingly fast all the time.

I think these app makers might need to start focus grouping some of these app names. Not only is it going to be harder to search for this app, but it'll inevitably also lead to some humorous misunderstandings.

They already got pulled from the App Store (although Apple reversed course after significant badgering): https://news.ycombinator.com/item?id=25605880

Is 22 seconds insetad of 34 seconds so much faster ? The difference does not feel huge to me

yes, it compiled the project in 35% less time. doesn't really matter much for such a small project, but imagine if on a larger project the intel part took an hour and the m1 did it in 39 minutes. that's a substantial speedup. of course, we might see different results after leaving the turbo window.

I'd gladly spend 14 seconds if it helps me avoid Apple products!

How long does it take on a Ryzen 9 5950X

Note that's a 16 core CPU with 105W TDP compared to a quad core < 10W M1

Ran a few cycles on my 5950x hackintosh:

  invaderfizz@FIZZ-5950X:~$ hyperfine 'cargo -q install -f ripgrep'
  Benchmark #1: cargo -q install -f ripgrep
    Time (mean ± σ):     19.190 s ±  0.392 s    [User: 294.890 s, System: 17.144 s]
    Range (min … max):   18.352 s … 19.803 s    10 runs

The CPU was averaging about 50% load, the dependencies go really fast when they can all parallel compile, but then the larger portions are stuck with single-thread performance.

Okay, compiling is faster. But you compile once and run many times. What about running it?

Well, they don't just "feel" faster. They also complete lots of real-world tasks in shorter times, often significantly shorter than the last Intel Macbook Pro.

It’s funny how many articles that just won’t say the obvious - it’s a faster computer.

I have two laptops side by side, one is an M1, the other a HP in a slightly higher price point (more memory, bigger SSD). The challenges Intel has in the form factor are obvious — it’s a 1.2Ghz chip that turbos almost 2x as heat allows.

In any dimension that it can do what you need, the Apple wins. Cheaper, faster, cooler, longer battery endurance. The detriments are the things it cannot do — run Windows/Linux or VMs or tasks that need more memory than is currently available.

It can't run Intel-based OSs or VMs, of course, but the latest version of Parallels Desktop runs ARM-based Linux guests on M1 Macs, as well as the Windows 10 ARM preview. (VMware has implied that the next release of Fusion will support Apple silicon as well.)

linux is comming

I was an unbeliever, but we got some M1 Mac Mini's and this is the result. They even beat the dedicated workstation many of our people have set up. I get when people say it won't quite match a new ryzen for compute power, but in all of our tests, the M1 beat out all our workstations.

What workloads do you run? I’ve got a 16GiB M1 mbp and a 2019 maxed intel and when compiling Java/sbt projects the intel is significantly quicker, albeit also much loader and power hungry.

The author’s analysis sounds less like an explanation of how the M1 is faster, and more like an explanation of how it gets such amazing battery life.

If someone could figure out a way to get all MacOS apps —including the system — to use the performance cores, perhaps the battery life would be back down to Intel levels?

>If someone could figure out a way to get all MacOS apps —including the system — to use the performance cores, perhaps the battery life would be back down to Intel levels?

Other than to prove an utterly useless point - why would you want to even remotely do that?!?

If my time machine backup takes four times as long but my battery lasts longer still why would I care? The overall experience is a HUGE net improvement.

That's the point being glossed over by the majority of commenters and the point the original author is making - benchmarks are interesting, but nothing beats real world experience and in real world experience there are a suite of factors contributing to the M1 and Apples SOC approach spanking the crap out of their competitors.

There is more to life than rAw PoWeR ;)

curiosity? proving the thesis? knowledge that could improve competing laptops?

yah never mind I don't care why these computers are impressive let’s just play macos chess and browse facebook jfc if you’re not interested why did you even join this conversation

I don't care? "That's the point being glossed over by the majority of commenters and the point the original author is making - benchmarks are interesting, but nothing beats real world experience and in real world experience there are a suite of factors contributing to the M1 and Apples SOC approach spanking the crap out of their competitors."

I don't know what point would be proved by maxing out the cores other than confirming what seems to be pretty obvious - a hybrid approach has multiple benefits - not just in power efficiency but the user experience as well.

It's not just one aspect of the design choices - but all of them in concert.

I'm sure someone has run the battery dead using benchmarks that exercise the performance cores - I suspect that Apple designed a fast chip and an efficient chip and then married them together - that an M1Max with only performance cores wouldn't be that interesting power-budget-wise (though likely still an improvement).

Anecdotes of very heavy users suggest 4-6 hours if CPU use remains high.

Sounds like the consensus here is that the M1 feels faster, and is actually faster, for a lot of tasks. So, for a lot of engineers, the M1 is the better choice over Intels. (Faster compile times are a good thing for devs, among other things)

In that regard, the moment feels similar to the mid 2000s, when you suddenly saw a huge uptick in Macbooks at technical conferences: software developers seemed to gravitate in droves to the Mac platform (over windows or linux). Over the last 5+ years, that's cooled a bit. But I wonder if the M1 will solidify or grow Apple's (perceived) dominance among developers?

I switched away from Macs to Thinkpads when the butterfly keyboards came out. Just happily switched back to Macs and loving my M1 Air.

It’s amazing how much of a dumpster fire the butterfly keyboard was, but perhaps more bewilderingly how long they persisted with it. That keyboard might well have done more than any other product design decision in the last decade to push people away from the Mac platform.

If the M1 MBA (or early 2020 Intel MBA) didn't exist, when my 2013 MBP started dying last month I would have dropped Apple for an Ubuntu XPS.

I don't understand how a company of that size kept up a blunder of that magnitude for half a decade, but a half-broken keyboard with an entire missing row of keys was just a nonstarter.

I think it did, and the touch bar was a close second. Thankfully, whoever was in charge of those decisions seems to have lost decision-making power and Apple has walked back both.

> whoever was in charge of those decisions seems to have lost decision-making power

I guess we're both speculating here, but even if the same people were in charge, I think they breathed a sigh of relief when they realized that the personal computing segment had spiced up again. From about 2014 to 2019, Mac revenue basically plateaued in line with the entire laptop market. People were crazy about phones but laptops had hit a wall.

When you have to sell laptops to people whose yesteryear laptops do everything they need, you start adding random bullshit to the product because you have to capture the market's attention somehow. I think this is how we ended up with the touch bar. It's a step backward, but it's flashy and made the product look fresh(er) despite the form factor being identical to what they were selling in 2013.

the touch bar still ships with every current-gen MBP though; the Air never had one

That really confused me until I discovered that Macs had something called a "butterfly keyboard" as well. At first I thought you switched to Thinkpads in the mid 90s:

https://en.wikipedia.org/wiki/IBM_ThinkPad_701

> So, for a lot of engineers, the M1 is the better choice over Intels.

I don't know which engineers you hang out with, but the only "engineer" I know who uses an M1 Mac does web design. Besides that, the M1 doesn't support most of the software that most engineers are using (unless you're working in a field already focused on ARM), and the fragility of a Macbook isn't really suited for a workshop environment. Among them, Thinkpads still reign supreme (though one guy has a Hackintosh, so maybe you were right all along?)

> But I wonder if the M1 will solidify or grow Apple's (perceived) dominance among developers?

Developers are going to be extremely split on this one. ARM is still in it's infancy right now, especially for desktop applications, so unless your business exclusively relies on MacOS customers, there's not much of a value proposition in compiling a special version of your program for 7% of your users. Because of that, MacOS on ARM has one of the worst package databases in recent memory. Besides, there's a lightning round full of other reasons why MacOS is a pretty poor fit for high-performance computing:

- BSD-styled memory management causes frequent page faults and thrashes memory/swap

- Quartz and other necessary kernel processes consume inordinate amounts of compute

- MacPorts and Brew are both pretty miserable package managers compared to the industry standard options.

- Macs have notoriously terrible hardware compatability

- Abstracting execution makes it harder to package software, harder to run it, and harder to debug it when something goes wrong

...and many more!

In other words, I doubt the M1 will do much to corroborate Apple's perceived superiority among the tech-y crowd. Unless people were really that worried about Twitter pulling up a few dozen milliseconds faster, I fail to see how it's any better of an "engineering" laptop than it's alternatives. If anything, it's GPU is significantly weaker than most other laptops on the market.

This is a lot of really well expressed information that completely fails to grapple with the fact that most developers write code for the web and apple computers are extremely popular among web developers.

All of the things you mentioned are also true of intel macs, which again are wildly popular among web devs of all kinds.

If you can't explain the popularity of those machines in spite of those limitations, I don't see why I should accept those as reasons why apple arm computers won't be popular.

And developers will often be willing to take a grab at a new thing - and even if you're not doing web dev lots of your code likely runs on build farms anyway - the chance to play around with a workable ARM machine might be attractive.

> This is a lot of really well expressed information

Well, no, it's all totally made up.

I was trying to be nice.

I dewelop machine learning data pipelines. My dev environment of choice is a Macbook running JetBrains suite, Alfred, BetterTouchTool, and an iTerm pane or 3 with Mosh and Tmux running on an Ubuntu Server. HID is a tricked out Ergodox EZ, right hand mouse, left hand Magic Trackpad. Prior to that I developed directly on Ubuntu 18/20, and windows well before that. The experience unparalleled. The OS/windowed desktop is smoother and less buggy than Gnome 3, more responsive than Win 7 or 10.

I'm talking a 16GB Intel i7 8-thread Macbook vs a 32 thread twin-socket 72GB RTX2080 beast running Ubuntu 20. The Mac crushes it in terms of feel, fit and finish. I haven't tried M1 yet but I bet it'll one-up my current Intel macbook. I'm quite eager to get one.

> Besides that, the M1 doesn't support most of the software that most engineers are using...

??? Other than CUDA, the macbook meets my needs 95% of the time. I'm mostly want for a native Docker networking experience a small minority of the time. I need a responsive GUI head to act as my development environment. All the heavy lift compute is done on servers/on-prem/in-cloud.

> - BSD-styled memory management causes frequent page faults and thrashes memory/swap

Only under super heavy memory demand. I close some browser tabs or IDE panes (I normally have dozens of both).

> - Abstracting execution makes it harder to package software, harder to run it, and harder to debug it when something goes wrong

Almost everything I do is containerized anyways, so this is moot.

I was squarely one of those "why would anyone use mac? It's overpriced, lock in, $typical_nerd_complaints_about_mac" until COVID happened and it became my daily driver. Now I can't go back.

> - MacPorts and Brew are both pretty miserable package managers compared to the industry standard options.

No snark intended - Like what? I'm not exactly blown away by Brew, but it's been generally on par with Apt(get). Aptitude is marginally better. There's not a single package manager that doesn't aggravate me in some way.

This is pretty disconnected from reality.

> BSD-styled memory management causes frequent page faults and thrashes memory/swap

You're basically pulling this out of nowhere. Not once in six years of using MacOS has this ever happened to me.

> Quartz and other necessary kernel processes consume inordinate amounts of compute

Yes, because Windows is so much better. This is sarcasm. Just pull `services.msc` and take a look at everything that's running.

> MacPorts and Brew are both pretty miserable package managers compared to the industry standard options.

In your opinion, what is industry standard? `apt-get` and `yum`? I have yet to come across a better package manager than Brew. Brew just works. Additionally, most binaries that are installed in Brew don't require elevation. Which is fantastic because almost every program installation requires elevation in Windows.

> Macs have notoriously terrible hardware compatability

Hardware compatibility in what sense? As in, plug-and-play devices on a MacOS powered machine?

I'd argue the inverse; I often just plug in devices to my MacBook without having to install a single driver. Imagine my shock years ago when I plugged in a printer to my MacBook and I was able to immediately start printing without installing a single driver. Same with webcams, mice, etc.

Do you mean hardware compatibility in terms of build targets? I think here you might be correct, but even then you can compile for different operating systems from within MacOS... so again, I'm not entirely sure what you mean here.

I guess if you're talking about legacy devices where the hardware manufacturer hasn't bothered to create drivers for anything other than Windows, then your point might be valid, but how often does this happen...?

> Abstracting execution makes it harder to package software, harder to run it, and harder to debug it when something goes wrong

...more disingenuous statements. What do you mean by this? Under the hood, MacOS is Unix. Everything that runs on a MacOS machine is a process. You can attach to processes just as you would on a Windows machine. Similarly, if you have the debugging information for a binary you can inspect the running code as well.

MacOS is not a perfect operating system; for one, I do wish that it was better for game development. But I'm really struggling to understand your points here. Every single one is either not applicable or just straight up wrong.

> - BSD-styled memory management causes frequent page faults and thrashes memory/swap

macOS doesn't use the BSD VM.

> If anything, it's GPU is significantly weaker than most other laptops on the market.

You meant to say "stronger" at the task of not burning your lap.

My company seems intent on switching to M1 as soon as we can. I can't see it being very long until it's possible to develop and run our backend services locally (Go, Docker, IntelliJ, maybe a couple other small things).

I'm a VP of a small software shop focused on IoT. We do embedded, cloud, mobile, web and ML. My entire department is 100% mac.

This certainly makes a lot of sense, and it's a brilliant strategy to improve overall performance. But it doesn't account for the full picture either. My M1 Macbook Pro feels about as responsive as my desktop system with an AMD Ryzen 3900X, which is impressive to say the least. It doesn't quite have the raw computing power of the 3900X, but given that it's a portable device that's something else.

Well, they did it first in iOS which is more responsive than Android even when compared to devices that win benchmarks vs the iPhone.

It's just doable when you care enough to optimize the OS for responsiveness.

Much like the M1, I don't think anything actually wins benchmarks vs the iPhone. There's display refresh rate and a few multicore stores that are closer but in any real world test, Single core dominance wins out. (Plus the big/little design in the A series chips is better than the three scales seen in QC chips as QC backfills the single large core with a ton of little cores to make the multicore numbers look competitive when in reality, any multithreaded task of two cores is much faster and you don't end up with mismatched race conditions.)

Are you sure? iOS has been more responsive from day 1 (I mean the first 2-3 iphone versions), when they were using an off the shelf CPU that everyone else had.

I think the commenter is saying that iOS provides no discernible performance advancements over Android. If you ran Android on an M1, it likely would score just as well as an iOS/MacOS machine.

Try a low latency kernel on your desktop if you use Linux, that should improve responsiveness some more. Apparently the increase in power consumption is minimal - I use (K)Ubuntu's low-latency kernel even on laptops these days.

You can also do some "nice"-level management. My XMonad environment is simpler than most, so it's easier for me than someone running a full desktop environment with dozens of processes running around, but I got a lot of responsiveness improvements by nice-ing and ionice-ing my browser down in priority. It does mean that occasionally I switch back to it and it hiccups, but on the flip side it has stopped consuming so many resources and everything else feels much more responsive.

I'm actually not sure why it has the effect it does, entirely, because at least in terms of raw resource use the browser doesn't seem to be eating that much stuff, but the effect in practice has been well beyond what can be explained by perceptual placebo. (Maybe there's too many things competing to get the processor at the VBlank interval or something? Numerically, long before the CPUs are at 100% they act contended, even in my rather simple setup here.)

Or, to perhaps put it another way, Linux already has this sort of prioritization built in, and it works (though it's obviously not identical since we don't have split cores like that), but it seems underutilized. It's split into at least two parts, the CPU nice and the IO nice. CPU nice-ing can happen somewhat automatically with some heuristics on a process over time, but doing some management of ionice can help too, and in my experience, ionice is very effective. You can do something like a full-text index on the "idle" nice level and the rest of the system acts like it's hardly even happening, even on a spinning-rust hard drive (which is pretty impressive).

I feel it's kind of sad this doesn't happen automatically for distros specially geared to be installed on workstations. You sacrifice a tiny bit of throughput for making the computer continually smooth even under heavy load.

This, automatically turning on battery optimizations when an internal battery is detected, and automatically applying a 'small speaker' EQ to internal speakers are a few changes that would make Linux feel so much better on a laptop.

I run KUbuntu, how can I enable this?

EDIT: I searched a bit and, although I haven't found instructions anywhere, I did find people saying that the low-latency kernel decreases throughput as a tradeoff to lower latency. Have you found this to be the case?

Also, another source says that the preempt kernel might be better for some workloads: https://itectec.com/ubuntu/ubuntu-choose-a-low-latency-kerne...

Can anyone comment on these?

I have not tried the preempt kernel. I have tried the lowlatency kernel and found that it improved overall performance, not just latency.

Turns out that the cost of NUMA balancing (https://www.kernel.org/doc/Documentation/sysctl/kernel.txt) was outweighing any benefit we might get from it. The problem is that NUMA balancing is implemented by periodically unmapping pages, triggering a page fault if the page is accessed later. This lets the kernel move the page to the NUMA node that is accessing the memory. The page fault is not free, however; it has a measurable cost, and happens even for processes that have never migrated to another core. The lowlatency kernel turns off NUMA balancing by default.

Instead of switching to the lowlatency kernel, we set `kernel.numa_balancing = 0` in `sysctl.conf` and accepted the consequences.

There's an interesting Stack Overflow question/answers: https://askubuntu.com/q/126664.

In general terms, one either just installs the specifically recompiled package (-preempt, -lowlatency etc.), or recompiles their own. The related parameters can't be enabled, because they're chosen as kernel configuration, and compiled in.

I'd take such changes with a big grain of salt, because they're very much subject to perceptive bias.

If there were one simple trick to make your computer feel faster without downsides, defaults would change.

True in general, but there is seriously little downside to using a low-latency kernel. Sometimes it even improves throughput, usually the effect is tiny either way.

I think most people just don't care or don't know that they care about responsiveness.

Basically you install linux-lowlatency and reboot. Grub will prefer it over the generic kernel. Make sure that you also get linux-modules-extra in the lowlatency version or you might boot into a system with missing drivers. Happened on my laptop when I switched to lowlatency.

Oh very cool! I had no idea about this. I'm traveling for awhile but I'll definitely check that out once I'm back and working with my desktop machine again!

Yes - I sold my Ryzen desktop because I no longer feel the need to go to the 'more powerful' machine. The Air is just as fast.

That's true, although I do miss the memory! And realistically, when it comes to heavy compute or multi-tasking the 3900X really shows its power. I'm honestly very interested to see AMD tech at 5nm. I think the next few years are going to be fairly mind-blowing in terms of CPU technology.

This is a pretty smart strategy. I'd say the majority of the time when something is slow on my machine, it's because there's a resource intensive background process (that I don't really need to complete quickly) eating up all my system resources.

It seems like the same strategy would also make sense on Intel processors, although it probably requires at least 4 cores to make sense?

> It seems like the same strategy would also make sense on Intel processors

Intel agrees!

https://en.wikipedia.org/wiki/Alder_Lake_(microprocessor)

You really want those "efficiency" cores in addition to your regular ones, otherwise dividing your processor costs you a lot of throughput.

You also want them to be low-power even when saturated, otherwise you gain responsiveness from the "performance" cores but your "efficiency" cores aren't actually efficient.

It seems at least Linux's x86_energy_perf_policy tool lets you set multiplier ranges and some performance-vs-power values per-core, which means such a setup doesn't seem impossible on current Intel hardware.

You could clock down the background cores and make them run more efficiently even if they're identical.

You can do it on one processor with a process/thread scheduler. This is what makes multitasking possible in general.

This is extraordinarily basic stuff. We knew how to do this kind of multitasking, with priorities, back in the 80s (or earlier). Yet people still don't understand it.

As an example, a while back I ran a multi-threaded process on a shared work server with 24 cores. It used zero I/O and almost no RAM, but had to spend a couple of days with 24 threads to get the result. I ran it inside "chrt -i", which makes Linux only run it when there is absolutely nothing else it could do. I had someone email and complain about how I was hogging the server, because something like 90% of the CPU time was being spent on my process. That's because their processes spent 90% of their time waiting for disc/network. My process had zero impact on theirs, but it took some explaining.

That's a useful command to know, thanks! However, shouldn't `nice` be handling that sort of stuff? Do you know why there are two commands for the same thing (as far as I can see)?

I would love to know why nice doesn't do this, and why top/ps doesn't show something more sensible when you do.

Well yes, but presumably this impacts responsiveness. The whole point of this strategy is to keep cores free for interactive tasks.

Interesting, enjoyable read.

The conclusions seem a bit off though

-Low QoS tasks are limited to certain cores. This doesn't necessitate efficiency cores (though it makes sense if you want power efficiency in a mobile configuration) and they could as easily be performance cores. The core facet is that the OS has core affinity for low priority tasks and quarantines them to a subset of cores. And it has properly configured low priority tasks as such.

-It also has nothing to do with ARM (as the original title surmised). It's all in the operating system and, again, core affinity. Windows can do this on Intel. macOS/iOS has heavily pushed priorities as meaningful and important, so now with the inclusion of efficiency cores they have established their ecosystem to be able to use it widely.

If it has nothing to do with ARM, why doesn't Mac do it at similar speed on Intel?

The focus of the linked article is responsiveness/user interaction, attributing that to efficiency cores. Apple can achieve exactly the same responsiveness benefit on their Intel devices by, as mentioned, limiting low priority tasks to a subset of cores. Say 2 of 6 real cores on a MBP with an i7.

Apple actually pushes low priority tasks to the efficiency cores for power efficiency reasons (per the name), not user responsiveness. So that MBP runs for longer, cooler on a battery because things that can take longer run on more efficient, slower cores. They do the same with the efficiency cores on modern iOS devices.

The "feeling faster" is a side effect. I am talking about that side effect which isn't ARM specific.

And FWIW, Intel is adding efficiency/"little" cores to their upcoming architectures. Again for efficiency reasons.

There's no point in shuffling background processes to a subset of cores if it doesn't provide power-savings.

It sounds like upcoming Intel chips will have the ability to run efficiency-mode on some cores, at which case OS-level code to do shuffling makes sense.

Because there are no Intel Mac with heterogeneous cores. Lakefield is first CPU with LITTLE cores, but not available for mac.

Interesting, the article isn't clear how it's implemented and whether they dynamically adjust the QoS/Core, so I wonder if they solved the inversion problem. Basically you don't want a high-priority process to be dependent on a lower-priority process that's locked on a LITTLE core.

Windows solves this by placing basically everything onto the LITTLE cores, and user interactions serve as a priority bump up to the big cores. The key (which is difficult to implement in practice) is that they pass that priority along to every other called thread in the critical path so that every path necessary to respond to the user can be placed on the big cores. This means that if you are waiting for a response from the computer, every thread necessary to provide that response, including any normally low-priority background services, is able to run on the big cores.

I'd expect all the other OS's do a similar optimization for the big.LITTLE architectures. It seems to be the natural solution if you've worked in that space long enough.

As of recently, macOS does support priority inheritance for a bunch of synchronization primitives [1], ranging from pthread mutexes to Mach IPC. But it's not perfect. For instance, read-write locks currently don't support priority inheritance, though they could. More problematically, when userland processes use any kind of custom synchronization scheme based on condition variables or similar, there's no way for the kernel to know which thread is expected to signal the condition variable and thus should inherit priority. That includes when libraries implement their own mutexes on top of that [2]...

[1] https://opensource.apple.com/source/xnu/xnu-4903.241.1/osfmk...

[2] https://github.com/Amanieu/parking_lot/issues/205

You should look into libdispatch, in my understanding, essentially everyone is expected to use libdispatch, and it may have something special to somehow help with priority inheritance.

On macOS and iOS, when you want to talk to another process, you use libxpc. I believe that libxpc will automatically send a "dispatch token" (? don't remember exact name, you can see it on lists of mach syscalls) which boosts the priority of the process you're calling (I believe it also generates an OS transaction so the process isn't killed for memory reasons). I believe this priority will fan out as you described. Pierre Habouzit implemented this stuff I believe, you can see a lot of it in libdispatch.

Interesting solution to the problem of app and OS developers wasting CPU power at greater rates than Moore's law can deliver it: just shunt all the stuff the user isn't looking at (and therefore doesn't care about the timeliness of) onto a slower processor.

What's impressive is Apple's first "high-end" custom silicon is about equal performance to an AMD Ryzen 7 5600X.

That's not bad!

However the M1 is only about 20-25% of the power consumption of the Ryzen 7 5600X.

That's crazy!

It'll be very interesting to see what the M3 or M4 look like (especially in X or other higher end variants) several years from now. We already have tastes of it from Marvell, Altera, Amazon and others, though it looks as if we will see ARM make huge headway in the data center (it already is) and even on desktops before 2025.

I have a 2020 Intel Macbook from work and a M1 Macbook for personal use.

Granted I put my work laptop under more load (compiling, video chats at work) but it just feels like a normal laptop. I feel it take its time loading large programs (IDEs) and the fan clicks on when I'm doing big compiles.

I use my personal laptop for occasionally coding, playing games, and also video chats. But the M1 feels amazing. It's fast, snappy, with long battery life, and I've had it for several weeks and I never hear the fan. Even playing Magic Arena AND a Parallels VM runs silent. Arena alone turns my wife's Macbook Air into a jet turbine. It makes video chats so much nicer because it's dead silent.

I've run into occasional compatibility issues with the M1. sbt not working was the latest bummer.

So while my two laptops are technically a year apart, they feel like 5 years apart. The M1 laptop lives up to the hype and I'm glad to just have a laptop that's fast, quiet, has great battery, and is reliable.

Edit: More context, I had bought a maxed-out Macbook Air last year hoping it would be my "forever-laptop" but it was just not giving me the speed I wanted, and the noise was just too much. I couldn't play any game or do any real coding in the living room without disrupting my wife enjoying her own games or shows. I'm so glad I traded up to the M1

"I never hear the fan. Even playing Magic Arena AND a Parallels VM runs silent."

That is because there is no fan.

The regular M1 MacBook does have a fan. The M1 Air doesn't, but throttles the CPU to avoid overheating

While we're being technical, there is no M1 MacBook; there is a M1 MacBook Pro and an M1 MacBook Air, as we as an M1 Mac Mini.

You're right, I meant "M1 MacBook Pro", not "M1 MacBook". I cannot seem to edit after a certain period.

In the Macbook Air there isn't. In the MBP there is.

Sorry if there was confusion.

It's an M1 Macbook Pro, so there is a fan, but I've yet to hear it.

My previous laptop was an Intel Macbook Air (2019?).

I have an M1 Macbook Pro for almost a month now as work laptop and I've only heard the fan once so far, while doing a multi-file search/replace in VSCode. For whatever reason that maxed out the performance cores for a few minutes.

Other than that it's been entirely silent and blazingly fast and I had no major issues with it.

FWIW Android (and surely iOS, although I don't know anything about that in particular) have had systems like this for a long time. Aside from all the task scheduler smarts in the kernel itself, there are all kinds of things that can be marked as low priority so they run on the LITTLE (what Apple calls "efficiency") cores, while e.g. a UI rendering thread might go straight to a "big" ("performance") core even if its historical load doesn't show it using much CPU b/w, because it's known (and marked as such by Android platform devs) to be a latency-senstive element of the workload.

Been a few years since I worked on this so I'm a bit fuzzy on the details but it's interesting stuff! Without this kind of tuning, modern flagship devices would run like absolute garbage and have terrible battery life.

While yes, the hardware had been there for a long time, Android hasn't been taking much of an advantage of it and I'm not quite sure it does now.

Google Play likes to do shit in the background. A lot of it. All the time. Even if you have <s>deliberate RCE</s> auto-update disabled in settings, it will still update itself and Google services, silently, in the background, without any way to disable that. And while it's installing anything, let alone something as clumsy as Google services, your device grinds to a halt. It sometimes literally takes 10 seconds to respond to input, it's this bad. It's especially bad when you turn on a device that you haven't used in a long time. So it definitely wasn't scheduling background tasks on low-power cores, despite knowing which tasks are background and which are not (that's what ActivityManager is for). My understanding from looking at logcat was that this was caused by way too many apps having broadcast receivers that get triggered when something gets installed.

Now, in Android 11 (on Pixel 4a), this was partly alleviated by limiting how apps see other apps, so those broadcasts don't trigger much anything, and apps install freakishly fast. That, and maybe they've finally started separating tasks between cores like this. Or maybe they started doing that long ago but only in then-current kernel versions, and my previous phone was stuck with the one it shipped with despite system updates.

These kinds of optimizations often harm benchmarks. Benchmarks are batch jobs, even the ones that try and mimic interactive sessions. Apple has made a latency/throughput optimization that often harms throughput slightly. This is the right call, but benchmarks are the reason why this low hanging fruit isn't being picked on the Intel side.

This should not harm benchmarks unless they mark their threads as background.

As for a particular strategy I presume Apple could, for example, use 6 high-performance cores instead of 4+4 hybrid. But then thermal management will be an issue. So the choice was about throughout/latency/energy efficiency. Using simple low-performance cores for tasks that can wait is very good strategy as one can put more of those cores as opposite to running the performance core under a low frequency.

I was thinking about things like the HZ setting in Linux. Lowering the setting will get you a slight throughput advantage but interactive use will be not as smooth.

"Because Macs with Intel processors can’t segregate their tasks onto different cores in the same way, when macOS starts to choke on something it affects user processes too."

Why is this? I understand that Intel chips don't use BIG/little but couldn't you assign all OS/background tasks to one core and leave the other cores for user tasks? Shouldn't the scheduler be able to do this?

Because they didn't design the OS to do that. You very well could lock a core or two at low freq/power and assign background tasks to that. It's not really a new or exotic idea.

macOS doing this is a side effect of them needing to do so, with the added benefit of it actually making things nicer all around. They could very well do this on intel/amd chips to the same effect.

The bummer is, we really don't know how good the silicon is, because nothing but macOS runs on it natively, so you can't really get an apples to apples comparison.

Probably a fight with CPU frequency ramping. You could put all the tasks on one core, but then you risk the CPU frequency spiking when it shouldn't causing more power to be drawn than necessary.

With slow light power cores, that's less of an issue.

The OS also controls the frequency so it could lock the background core(s) at low frequency.

My 16 inch pro Intel is plenty fast - for the first 45 seconds before thermal throttling kicks in. I have a feeling the M1 is faster because it can actually do work for more than just the briefest bursts

The problem I ran into the other day, had an app crash taking 50% of cpu. I was on the couch for hours on battery. Only noticed when my battery life was at 60% when normally it would be at 85%. My intel machine would have alerted me by burning my legs and trying to create lift with the fans.

Ha, speaking of burning legs, I was doing some video editing in FCPX last night, and I had to keep changing positions trying to optimize for not burning my legs too badly and not blocking the air flow through the vents on the bottom/sides causing even more throttling.

The heat and noise was what led me to sell my 16" MBP in favour of a 13" Air. I was working from home the whole time I owned it and my partner could often hear it from a different room.

No idea how anyone works in an office with one of those things without irritating the hell out of their coworkers.

Most likely because everyone already wears headphones to isolate themselves. There is outside traffic noise and aircon to compete with, as well as general drone of conversations. It's only really an issue in environments that are already quiet.

Apples intel MBP thermals are pretty abysmal wrt noise. My off brand 7th gen i7 sounds about the same as my colleagues similarly species MBP, but never throttles.

There were even people saying they deliberately sabotaged their intel thermals to make the up and coming M1 look better.

Those conspiracy theories were never confirmed. Linus thought the MacBook Air Early 2020 model’s cooling was clearly designed for an M1, but then the M1 launched without a fan at all.

I don't believe the conspiracy, but as a result, bad thermal designs works as great advertisement for M1.

So, like nice[1], except the developer sets the level of importance ahead of time? Makes sense, as long as I can reprioritize if needed.

1. https://en.wikipedia.org/wiki/Nice_(Unix)

It's nice but with additional limitations - on a normal Unix system even if you nice everything to the lowest level possible they'll still take over all cores. This limits things below a certain nice level to the efficiency cores, meaning that the performance cores are always available for foreground action.

So nice + taskset[1]?

1: https://linux.die.net/man/1/taskset

Of course the applications (programmers of the applications) need to declare their "nice" levels correctly - they can't be greedy

Nothing has ever stopped Apple from pinning indexing work to specific cores. They just didn't give a shit.

Maybe like the big.little cores of many ARM CPU in Android phone?

I'm not familiar with Android APP, maybe there are similar APIs in Android?

It's the same big.Little concept, slightly tweaked to allow this QoS work, I believe most of it was then used on Android but I doubt that Android uses the APIs well if they exist.

Finally, setting all these QoS priorities on DispatchQueue's is paying off big time.

An universally used, opinionated API with enough flexibility to let developers express their ideas about priority really helps.

Most people set way too many of those. Especially "background", where you're in for a surprise if you hit the actual background performance guarantees, since it may not run for minutes.

I wonder how much of this nice result could be achieved on a homogenous CPU if everyone used an API that expressed priorities on a fine grained task level. Process priority and CPU affinity is already a thing. But I don’t think I’ve ever set the ‘nice’ level for a single thread inside my code.

My point is, the snappiness is a result of decent system-wide adherence to a priority API more than the heterogeneous chip design. The low power consumption of course relies on both.

I'm curious if there is some architectural limit that prevents Apple from doing something similar on Intel Macs, at least ones with 8+ cores. The scheduler could arbitrarily nominate 4 cores as "efficiency" cores and keep them for background tasks, leaving the rest free for "performance".

I think the issue is that thermals, and thus overall efficiency, is optimized on the Intel chips when long-running work is split evenly across the cores.

Without knowing the inner workings of Apple's scheduler: I don't think there is any reasons this wouldn't work on x86 hardware. All you need is some API to tell the scheduler whether a task should be done "asap" or "whenever".

But you then get a huge tradeoff: If you reserve over 50% of the computational power for "asap" stuff, then all the "whenever" stuff will take twice as long as usual (assuming the tasks to be limited by compute power). On a 8C Intel that means that, for a lot of stuff, you're now essentially running on a 4C Intel. Given the price of these chips that MIGHT be a difficult sell, even for Apple. On the M1 they don't seem to care.

>All you need is some API to tell the scheduler whether a task should be done "asap" or "whenever".

We could call it ::SetThreadPriority()

For intel that would cause some serious thermal issues. The Four E cores in the M1 use about the same amount of power as one big core (5w total). In an Intel chip that would mean the four 'E' cores would use probably 10 watts each, that's 40 watts cooking a chip.

Intel does have a chip for you though, they have a version with mixed UlV cores and big cores.

Afaik, that isn't launching until 2021. https://en.wikipedia.org/wiki/Alder_Lake_(microprocessor) Or do you mean another CPU?

Would it be possible to achieve something like this in windows by pinning certain processess to specific cores? I've googled a bit and came accross this article below where it shows how to set the affinnity for a process to specific cores, and it looks like a fun experiment to do this with the system processess to see whether the performance of other applications will improve. :)

It would be a bit of a hassle to figure out which processes would all need to be changed, and whether these changes persist after rebooting and there's probably a lot more that I didn't think off though..

https://www.windowscentral.com/assign-specific-processor-cor...

Does having the actual best single thread performance available on market, has anything to with it? https://www.cpubenchmark.net/singleThread.html

Worth keeping in mind all mac users are going from underpowered Intel processors running in a terrible thermal environment for them too.

My 2018 USB-C MBP honestly feels like trash at times, just feels like every part of it is choking to hold the thing up.

  The Time Machine backup pictured above ran ridiculously slowly, taking over 15 minutes to back up less than 1 GB of files. Had I not been watching it in Activity Monitor, I would have been completely unaware of its poor performance. Because Macs with Intel processors can’t segregate their tasks onto different cores in the same way, when macOS starts to choke on something it affects user processes too.

this is really smart, and makes one wonder why intel didnt have the insight to do something like that already.... is this the result of thier "missing the boat" on smartphone processors (a.k.a giving up xscale)??

Question for the peanut gallery: In a -nix OS system, let's say single-threaded process is running on core 0. It makes a syscall. Does core 0 have to context-switch in order to handle the syscall, or could the kernel code run on core 1? This would allow a process to run longer without context switching and cache dumping, which would improve performance (as well as potentially security).

Corollary question: could one make a kernel-specific core and would there be benefit to it? Handle all the I/O, interrupts and such, all with a dedicated, cloistered root-level cache.

Cross-core interrupts and syscalls are slow. The caches for any memory to be transferred have to be flushed on the calling core and its APIC would have to interrupt the destination core to start executing the syscall, which means entering kernel mode on the calling core to get access to the APIC in the first place.

If the goal is low latency then staying on a single core is almost always better. To effectively use multiple cores requires explicit synchronization such as io_uring which uses a lock-free ring buffer to transfer opcodes and results using shared buffers visible from userspace and the kernel. io_uring has an option to dedicate a kernel thread to servicing a particular ring buffer, and this can also be limited/expanded to a set of cores. I have zero experience with io_uring in practice and so I don't know what a good tradeoff is between servicing a ring buffer from multiple or single cores. The entries are lightweight and so cache coherency probably isn't too expensive and so for a high CPU workload that also needs high throughout allowing other cores to service IO probably makes sense.

I think newer x86_64 chips also allow assigning interrupts from specific hardware to specific cores to effectively run kernel drivers mostly on a subset of cores, or to spread it to all cores under heavy I/O.

"A peanut gallery was, in the days of vaudeville, a nickname for the cheapest and ostensibly rowdiest seats in the theater, the occupants of which were often known to heckle the performers.[1] The least expensive snack served at the theatre would often be peanuts, which the patrons would sometimes throw at the performers on stage to convey their disapproval. Phrases such as "no comments from the peanut gallery" or "quiet in the peanut gallery" are extensions of the name.[1]"

https://en.wikipedia.org/wiki/Peanut_gallery

Posts like these are the gems that I come to HN for, as much as I've used the phrase, I never considered the source of it. I'd imagine I'd be in the cheap seats as well. Thanks!

If the system call is being handled by core 1, what does core 0 do? It must somehow wait for the core 1 system call to return. I'm not sure the waste created by waiting is outweighed by cache benefits.

Simple: It gets rescheduled to another process.

What about priority inversion? If a high QoS thread waits on a low QoS one? It seems like it would be a bigger issue here as the low QoS threads are only ever run on half the cores.

Grand Central Dispatch (the OS-level framework that handles these QoS classes) elevates the priority of a queue if there is high priority work waiting on low priority work to finish.

https://developer.apple.com/library/archive/documentation/Pe...

Importantly it doesn't do this for dispatch_async/dispatch_semaphore/dispatch_block_wait.

I love the fact that Apple prioritizes the human over the machine. I always felt that iPhones and iPads felt faster than desktops. I reckon the QoS strategy is the reason.

This strategy has had a strange negative effect for me a couple of times.

It used to be that I would notice rogue background tasks eating up my processor because I could feel the UI acting slow and the fans would kick on.

Now the only indication I get is my battery depleting more rapidly than expected. The UI is completely responsive still, and there are no fans. But I’m never checking my battery level anymore, so I don’t catch these processes for much longer.

I have Pluto running on a side monitor and sometimes catch the processors going insane when I don't expect it.

https://news.ycombinator.com/item?id=25624718

I wonder if shunting background processes to the slower efficiency cores has a salutary effect on other elements of system load. I’m thinking of tasks like Time Machine, which presumably are throwing out IOPS at a commensurately lower rate when effectively throttled by the efficiency cores.

The other half of the story for the efficiency cores seems to be the battery life. Most of these non-urgent background tasks are put on efficiency cores not only to separate them from my applications, but also to enable this insanely good battery life.

There is also a thermal benefit. Using the high efficiency cores puts a lower load on the cooling system. So even if the computer is plugged in and the performance cores are idle it may be best not to use them and let the cooling system gain some headroom for when the performance cores are needed.

Great point. Overall it seems like a very well designed system.

All this reminds me of when the HP PA machines were first introduced. Loads of posts about how compilation was now so fast that the screen turned red due to time dilation, etc. Of course now nobody remembers PA.

You're talking about the HP's old precision architecture, right?

https://en.wikipedia.org/wiki/PA-RISC

That's an interesting comparison because it's another case where a big player created their own chips for a competitive advantage.

There are surely some lessons in there for Apple silicon, but I don't there there's any particular reason to think it will follow the same path as HP PA. PA started in the '80s. It was aimed at high-end workstations and servers. My impression was that the value proposition was narrow: it was sold to customers who needed speed and had a pretty big budget. Until checking now, I was unaware, but it seems to have carved out a niche and was able to live there for a while, so it wasn't exactly a failure.

Time will tell how apple silicon fares. Today the M1 is a fast, power-efficient, inexpensive chip, with a reasonable (and rapidly improving) software compatibility story, and is available in some nice form factors... so basically a towering home run. But we'll just have to see how Apple sustains it over the long run. Frankly, they can drop a few balls and still have a strong story, but it's hard to project out 5, 10, 20 years and understand where this might end up.

(Personally, I'm almost surely going to get an Apple silicon Mac, as soon as they release the one for non-low-end machines. The risk looks small, the benefits look big.)

The real key for Apple is they already had a huge customer for their new chip - the iPhones and iPads have been using it for years.

This means they do not have to be dependent on Mac sales to support M1 development - they can amortize it over the largest phone manufacturer in the world.

And every time they do a successful architecture switch they make it easier to do it again in the future. If the IntAMD386 becomes the best chip of 2030 they can just start using it.

While I have my doubts whether this is the main reason for the perceived performance, it reminds me of how BeOS was able to also show incredible "apparent" performance on even m68k-level hardware.

Even windows prioritizes programs that have focus over those that don't to increase interactivity.

Yeah cool, it's fast. But why so little RAM? Virtualisation and other professional software must be already a pain to run due to the ARM architecture, so why adding a memory handicap to it?

It would be interesting to see if there are also optimisations to keep the main (UI) thread clear as much as possible. I mean if I just clicked a button then probably that is the most interesting thing for me to happen, so responding to that click should not be blocked by other high priority tasks.

I often have the feeling on my i9 machine it's almost idle but the specific core of my UI is working on something else which I don't particularly care for at the moment I'm interactive with the computer.

I would kill to pin Dropbox to efficiency cores like this. Half the time when my fans are whirring I discover it's just Dropbox frantically trying to sync things.

There are plenty of self-hosted dropbox alternatives that don't do that.

I get that not everyone is a "take matters into their own hands" kinda person, but it's worthwhile to at least look into it and see if it's something worth pursuing for you.

Maestral (https://github.com/SamSchott/maestral) is a pretty light-weight Dropbox client that works well for mac

> These [QOS levels] turn out to be integer values spread evenly between 9 and 33, respectively.

Anyone know why this is? seems fairly arbitrary...why not have 1,2,3,4,5?

They're a bit mask, with the LSB always set. The values are 100001 (33), 011001 (25), 010001 (17), and 001001 (9). And they're probably ORed with other values so multiple parameters can be set with a single word.

Best guess: either (1) it maps to internal values that macOS uses, or (2) they wanted to build in the potential to have more granular values later.

Typo in title. Doesn't parse as a result.

Thankfully my human brain is robust enough to understand by the context.

The only people who think human brains run on strict grammar rules are K-12 language teachers.

"is" should be "it's" probably.

Ok, corrected, sorry.

?! Sorry but I haven’t understood.

How it scheduled is interesting, but I wonder is the feeling really related to the core scheduling.

I'm still assuming it's faster due to unified memory architecture, latest generation lithography and less on tailored behavior for their OS.

An AMD/Intel using same soldered RAM next to CPU and same process node would give Apple a run for its money.

Still, the optimizations on OS side are interesting here.

I thought the "unified memory" meme had been debunked multiple times here.

Memory is unified its just not on die.

CPU and GPU and AI share unified memory which means zero copy transfers between them.

I laughed when they called it “unified memory.” Amazing what some marketing can do. In previous years, that was called “shared graphics memory” and it was only for low end systems.

As far as I understand, it has a lot to do with the actual design of the processor[1], and not so much to do with the on-chip memory or the software integration.

[1]: https://news.ycombinator.com/item?id=25257932

> I'm still assuming it's faster due to unified memory architecture

AMD, Intel, ARM, & Qualcomm have all been shipping unified memory for 5+ years. I'd assume all the A* SoCs have been unified memory for that matter too unless Apple made the weirdest of cost cuts.

Moreover literally none of the benchmarks out there include anything at all that involves copying/moving data between the CPU, GPU, and AI units. They are almost always strictly-CPU benchmarks (which the M1 does great in), or strictly-GPU benchmarks (where the M1 is good for integrated but that's about it)

> An AMD/Intel using same soldered RAM next to CPU and same process node would give Apple a run for its money.

AMD's memory latency is already better than the M1's. Apple's soldered RAM isn't a performance choice:

"In terms of memory latency, we’re seeing a (rather expected) reduction compared to the A14, measuring 96ns at 128MB full random test depth, compared to 102ns on the A14." source: https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...

"In the DRAM region, we’re measuring 78.8ns on the 5950X versus 86.0ns on the 3950X." https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-di...

> AMD's memory latency is already better than the M1's. Apple's soldered RAM isn't a performance choice:

Careful what you are comparing, in your examples the other CPU is also faster.

3950x is a desktop CPU and is faster then M1 -> https://gadgetversus.com/processor/apple-m1-vs-amd-ryzen-9-3...

5950x is even faster -> https://gadgetversus.com/processor/apple-m1-vs-amd-ryzen-9-5...

Lower latencies are likely due to higher clock.

For equivalent laptop specific CPU, you will get a speedup from on-package RAM vs user replaceable RAM placed further away, even desktops would benefit but it would not be a welcome change there.

> Lower latencies are likely due to higher clock.

That's not really how dram latency works. In basically all CPUs the memory controller runs at a different clock than the CPU cores do, typically at the same clock as the DRAM itself but not always.

If you meant the dram was running faster on the AMD system then also no. The M1 is using 4266mhz modules while the AMD system was running 3200mhz ram

> For equivalent laptop specific CPU, you will get a speedup from on-package RAM vs user replaceable RAM placed further away, even desktops would benefit but it would not be a welcome change there.

Huge citation needed. There's currently no real world product that matches that claim nor a theoretical one as the physical trace length is minimal latency difference and far from the major factor.

Will M1 silicon make the jump to iPhone/iPad in the future?

The latest iPad Pro does use M1.

It's more accurate to say that M1 made the jump from the A14 chips already in iPhones, as it's an enhanced variation of that design.

Zoom! Zoom! Look at my first world computation speeds!

It's much faster even if you max out all cores. This may be part of it but the chip is objectively faster.

Lots of Intel damage control these days. AMD is kicking their butt from one side and ARM from the other.

Docker doesn't feel "faster than Intel" on Mac, does it? And it certainly lags behind on features.

I was wondering how macOS scheduled the efficiency cores but was too lazy to dig into the docs. Thanks!

Launching apps takes ages on M1 mini. Reminded me of the good Windows Phone times.

Strange. With the exception of electron apps (which are slow everywhere), I've found my M1 mini to be extremely responsive. Much moreso than my 16" mpb.

Cold start of Electron, MS office, Affinity (all ARM versions) takes me north of 15".

8GB M1 Mini, so maybe that makes the situation worse.

Affinity Photo starts in 15 seconds on my M1, which IMO is not okay. It's just as slow as on my Haswell Intel Mac. Everything else launches in a second or so. Spotify (Electron) draws a window in three seconds, but takes another four to display all content.

I have the 8GB M1 as my daily driver, the only apps that take a long time for me (but NOWHERE NEARE 15 seconds - maybe close to 5, but I'm not counting) are visual studio Mac (which is probably rosetta), Unity (which IS rosetta) and blender (also rosetta).

VS Code launches instantly on my i7-4770 under Linux with XFCE. Same under Windows.

So do Slack and Spotify...

That's an 8 year old CPU! If you're having issues, the problem lies elsewhere not with Electron.

I don't know why this was downvoted. You see what you see. Maybe my experience with electron is tainted :D

I don't have any measurements, and I'm not really going to take any. It's just always felt slow. So I'll admit I should've perhaps been less prescriptive.

I think half the people in this thread are posting what they want to see and don't reflect reality.

That's a bit disingenuous to compare blazingly fast M1 to Windows Phones. What are you launching?

It's been known M1 is super fast launching apps compared to Intel macbooks - https://www.youtube.com/watch?v=vKRDlkyILNY

There's tons of video comparisons on YouTube.

Ah, Windows Phones were very responsive.

They were and they weren't. UI was pretty responsive, but starting programs was often slow. In 8.1 and above, starting the home screen was sometimes slow. So many dots crossing the screen.

Are you sure they aren't being run through Rosetta? If I remember correctly, x86 apps run through a translation process on first launch which obviously takes time. An acceptable trade off given the alternative is to not have the app at all on Apple Silicon.

Launching apps is lighting fast on M1 mini, and much faster than on Intel that it's not even funny.

Perhaps you have in mind some specific problematic app?

Or you include Intel apps that are translated to ARM on the fly on their first launch?

Weird, are they Rosetta apps? I haven't seen that on my M1.

Can it be related to this?

https://news.ycombinator.com/item?id=23273247

That was my first Mac, so maybe it is a MacOS issue not M1.

I just described my bad experience with M1 with Big Sur. Not sure who is to blame.

Ha - from another HN thread: https://fabiensanglard.net/lte/index.html

People say that Ryzen is faster - but if it has a fan, then this is a deal breaker. I have become so annoyed by fans I often just stop work when they start whirling, go make a coffee etc. It seems like M1 is now the only laptop that can let you work in silence and be productive.

usernanme checks out :)

Wow I am fluttered

I guess only the tape heads would understand that...

If fans are keeping you from working it might be time for water cooling or ear plugs.

I could appreciate this take if it wasn't for constantly getting side-eyed in a meeting room while my 16-inch MBP is blasting off because I forgot to close out a twitch.tv browser tab.

M1 will soon have a fan due to the overheating issue.

Although I imagine given how slow the response was on the butterfly keyboard issue it might be a few years out.

What overheating issue?

There isn't one in M1.

There isn't any thermal slowdowns on the M1 devices with a fan, no. The only M1 device without a fan shows thermal limitations, though.

Not an overheating issue, no, but the M1 still benefits from a fan, and obviously whatever Apple does in a Mac Pro class machine will also have a fan. They aren't going to keep at ~25W in a full size desktop, that'd be nonsense.

When was the last time Apple made anything with good thermal design?

The M1 is designed for this. Wide cores that do a lot per clock, but can't be clocked high is perfect, because Apple would rather not clock high. Intel and AMD are still fighting the MHz wars, and can't release a core design that doesn't approach 5 GHz, even if the lower power chips won't.

What overheating issue? There isn’t one.

That is all well and good. Great actually. And it makes sense. The high efficiency reduced instruction set computer has highly optimized architecture to improve efficiency. But we all knew that deep down. It's like the Ford Tempo. A mere 80 horsepower mated to a well designed and highly optimized transmission gave levels of performance that were higher than other cars in the same market.

What I can't stand are all the people saying the M1 is capable of replacing high end x86 computers. It's like owning a Tempo and mistakenly thinking your highly specialized transmission means you can walk up and challenge a 6.7L Dodge Challenger to a race. It's completely ridiculous and demonstrates a stunning lack of self awareness.

...This is partially true in that the M1 is overhyped by some...

But the M1 is also literally, by the numbers, the fastest machine in the world for some workloads. For us, my M1 Macbook Air compiles our large TypeScript Angular app in half the time of a current i9 with 64Gb ram on node v15. These are real-world, tested, and validated results. Nothing comes close..because the chip is designed to run JS as fast as physically possible. It's insanely fast at some workloads. Not all of them of course, but it's no Tempo. I would say it's more like a Tesla, faster than it should be considering the HP (a model S is much faster than cars with way more HP) but faster due to 'How' it makes the power rather than how much.

That said, I replaced a $2000 iMac 4K with a base model Macbook Air and it was a huge upgrade for my day to day work. It really is perfectly fine to replace some workstations.

> That said, I replaced a $2000 iMac 4K with a base model Macbook Air and it was a huge upgrade for my day to day work.

Essentially the same here, I just happened to replace my $2-3k Win10/Ubuntu desktop with my 8GB(!) M1 Air and it truly has been a huge upgrade for my day to day work. It feels like I'm working in the future.

That said - I primarily use this Air to ssh to all of my servers that do my heavy lifting for me. But that doesn't stop me from driving this thing hard - dozens of open tabs, multiple heavyweight apps left open (e.g. Office apps), multiple instances of VS Code, Slack, Teams, all running - zero slowdown. Zero fan sound.

It's black magic good.

What environment you compiling your large typescript app in? Windows with WSL on a 7400 rpm disk drive?

I think you have other things going on that's slowing down the compilation on the i9.

Maybe if run linux and install a fast SSD your i9 will be faster than your m1. Then by your logic you should ditch the m1.

Ironically it was a Samsung Pci-E drive in non-WSL Windows. A 16 inch Macbook Pro i9 also put out roughly alike times in MacOS. Node compile is a single-core workload with a very strong focus on small fast translated instructions, the M1 is actually that fast at that specific task.

I think you're right on this. I've also been irritated at the "eGPUs / dGPUs are no longer necessary" crowd. If an SoC GPU with the performance / size of an RTX could fit into a notebook we'd actually have them in notebooks... but we don't. The fact of the matter is that this technology doesn't exist. So the allegations that GPUs are no longer necessary because SoCs have already wholesale replaced them are comical.

>What I can't stand are all the people saying the M1 is capable of replacing high end x86 computers.

Whether or not this is possible completely depends on their unique workload. The M1 could probaly obviate any x86 chip for the average programmers. But that wouldn't be the case for gamer workloads, for example.

Is it really about workload though?

A high end gaming PC will compile typescript, play games with high quality graphics, and run your 100 browser tabs. Let's be honest, an Intel Core 2 Duo would obviate most programmer workloads just fine.

By your logic the Apple M1 is comparable to a high-end x86 chips, but you go on in the same breath with the disclaimer that it is "only certain workloads."

That is my point. A high end PC doesn't care about your workload. It is unobjectively fast. Period. You are the Tempo driver claiming that you would have beaten that Challenger if the temperature of the drag strip were just a little bit hotter....

But that Challenger doesn't care about operating conditions or workload or whatever. It will win today, tomorrow, and the next day while you're claiming that the Tempo is "comparable in the snow on Tuesdays."

I was thinking hard about getting an m1 mini but the upgrade pricing for ssd/ram is offensive and you can't upgrade them later. I will likely end up getting a newer ryzen system but it will end up costing much more for the cpu+motherboard, but will have access to dedicated graphics and I can actually just move my current 32gb of ddr4, video card, and SSDs over.

I'm curious what you think of all the benchmarks that sais otherwise. In a race between a motorized lawn mower and a racecar - if the lawn mower wins which one is ultimately the best "racecar"?

Reply on news.ycombinator.com