Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

eclecticlight.co

Post reply on HN
Print view View original

381–390 of 427 posts

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

#381

Post by why_only_15 »

Arcuru wrote: post #377

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 c…

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.

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

#382

Post by why_only_15 »

comex wrote: post #380
Arcuru wrote: post #377

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 c…

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 k…

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.

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

#383

Post by jfrunyon »

coder543 wrote: post #235
cptskippy wrote: post #219

Earlier quoted context omitted.

You're assuming that the scaling is linear though. What if there's a fixed 10 second ding on x86? That 39 minute compile on the m1 would only be 39:10 on the x86.

> What if there's a fixed 10 second ding on x86? There isn't.

And yet it is extremely unlikely that it's linear or anywhere near it.

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

#384

Post by coder543 »

jfrunyon wrote: post #383
coder543 wrote: post #235

Earlier quoted context omitted.

> What if there's a fixed 10 second ding on x86? There isn't.

And yet it is extremely unlikely that it's linear or anywhere near it.

What is "linear" in this context? If the Y-axis is performance, what is the X-axis? That statement doesn't seem to make much sense without any additional explanation.

If I run a benchmark for a program on the M1, that's a single data point. It's hard to call a single data point "linear", "quadratic", or anything else... and you can't really put multiple benchmarks on the X-axis, because they're measuring different things.

What would even make it (whatever "it" is) "extremely unlikely"? People have had over 6 months to run benchmarks on the M1. Surely you can find a concrete answer to your question that doesn't involve random speculation on internet forums?

Based on my own experiences, I have no reason to believe that the M1's performance starts tanking if you run it for longer than a few seconds, in case you're implying that the other processors will "catch up" if they have longer to get up to speed... why would they? That makes no sense either. Longer compilations are faster on M1 too, relative to my Intel hexacore MBP, from what I've seen in the past. I mean, obviously, right? Why wouldn't they be? Intel's processors change frequencies in milliseconds... it doesn't take them minutes to warm up.

The M1 isn't a silver bullet. AMD makes laptop processors that are more powerful. But the M1 is still really good for what it is, and those AMD processors consume notably more power than the M1 to achieve their performance.

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

#385

Post by SigmundA »

kllrnohj wrote: post #305
SigmundA wrote: post #300

Earlier quoted context omitted.

I believe most of the benchmarks where Metal based in the Anand article, also PBO have been around for quiet a while in OpenGL: https://developer.apple.com/library/archive/documentation/Gr... Any back and forth between CPU and GPU will be faster with unified memory especially with a coherent on die cache. This is the same model from iOS so just about anyone doing metal will already be optimizing for it same with any…

> I believe most of the benchmarks where Metal based in the Anand article But that doesn't tell you anything. Being Metal-based doesn't mean they were designed nor benefit from UMA. Especially since, again, Apple's own recommendation on big data (read: textures) is to copy it. > Any back and forth between CPU and GPU will be faster with unified memory especially with a coherent on die cache. Yes, but games & gfxbench…

First API's don't support it, can't pin memory (which is what a PBO does). Then oh well they are not taking advantage of it. Move the goal post much?

TBDR came to prominence in UMA mobile architectures, it's a big part of what allows it to perform so well with limited memory bandwidth. The M1 is just an evolution of Apples mobile designs and PowerVR before that.

Mali GPU's are UMA and alway have been AFAIK

https://community.arm.com/developer/tools-software/graphics/...

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

#386

Post by sgerenser »

RankingMember wrote: post #312
thefourthchime wrote: post #310

Earlier quoted context omitted.

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

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

#387

Post by ajkblue »

lars512 wrote: post #318

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.

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

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

#388

Post by lukeh »

cbsmith wrote: post #367
kemayo wrote: post #236

Earlier quoted context omitted.

If it's Intel-compiled apps, it's also that Rosetta is translating them to run on M1 when they're first run, as I understand it. Both of these are first-time launch issues, so comparing launch times on the second launch is probably more reasonable.

Good point. I'm really surprised they don't translate during installation (ahead of time).

I believe they do.

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

#389

Post by coder543 »

jrockway wrote: post #359
omegabravo wrote: post #327

Earlier quoted context omitted.

update: time GOARCH=amd GOOS=linux go build -a 6s for the M1 too!

Do keep in mind that go heavily caches for "go build": https://golang.org/cmd/go/#hdr-Build_and_test_caching

the "-a" directive in "go build -a" should cause a clean rebuild, which is what they were using

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

#390

Post by 1123581321 »

Eric_WVGG wrote: post #141
coldtea wrote: post #9

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.

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?

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