Hacker News Reader

Comment by tyingq | Hacker News Reader

It says the split for performance versus efficiency cores will be:

- 20 total, 16 high performance, 4 efficiency

- 40 total, 32 high performance, 8 efficiency

Which is kind of interesting given that the 8 core M1 is split half/half at 4 high performance, 4 efficiency.

Sounds like perhaps MacOS doesn't typically have more than 4 cores worth of low-priority work, regardless of the system size/workload?

View on HN

This is what I would have expected - I suggested when the M1 was first mentioned that it might make more sense for the Mac Pro to just have a side wall of separate independent SOC stacks with independent on-thread memory that GCD could manage behind the scenes. This seems like a much more straight-forward way to throw more performance into the higher-end machines without making long-tail disruptions to the architecture.

The efficiency cores are essentially for when the system is idling or for the 95% case (browsing the web, watching YouTube and checking e-mails). If a task is performance-bottlenecked then it makes sense to go straight to maximum performance rather than any in-between combination as you're essentially either waiting for the computer or not (i.e. it probably doesn't make much sense to try to strike an efficiency balance for tasks that are stressing a minimal set of low-power cores when they need to be completed either way - and in a machine where there's no battery life to worry about).

> browsing the web, watching YouTube

I know people say this all the time, but the reality is modern web browsers are incredibly expensive processors.

Yes, and it's also because a 2 KB text today comes inside of megabytes of code that has to be executed, and some code is additionally very expensive to execute, as it's doing shady stuff in trying to fulfill all the promises of all ad companies involved, sometimes really hundreds for a single page.

There was a moment in web history when the same happened due to the flash-based ads which easily spent huge amounts of CPU for... nothing meaningful to the reader. Now the flash is gone, but the pattern repeated.

And even not counting all the ads, today's "hot" web development conventions are often making the CPU even hotter.

This right here.

It's like there's this assumption that the web's simple serving of HTML was a compromise of the time rather than it's killer feature.

I don't want to sift through hundreds of images and outbound links from the ads you're trying to trick me into clicking, I just want the information I came for or I'm gone forever.

Generally speaking, Apple's systems throw work like web browsing to the performance cores. Browsing the web is actually super intensive for very short periods of time, increasing performance of rendering makes the system feel snappier. They mastered this art in the iPhone as they had to learn how to make snappy feeling devices that also sipped power, the easiest way to do this is to be done with processing as fast as possible so you can get back to idling on just the E-cores.

The E-core magic trick is that they are always running and also exist to prevent thread stoppers, tasks that force you to pause high-priority work such as network requests, push notifications, or memory management. This enables a machine where the performance cores can pound away at tasks uninterrupted and your cache can stay dedicated to the task at hand, preventing situations where you may have to dump branches mid-process, increasing performance consistency. Mathematically, it works out to where the P cores are ~5.2W each and then the E-cores are less than that combined, allowing the system to idle on just e-Cores and spin up and dedicate P-Cores to the UI and UX intensive tasks, keeping the thermals low and performance high. In a situation like the Mac Pro, I would expect much, much hotter P-Cores too as the thermals will allow.

A nitpick but arguably an important one for your point - this article argues that the efficiency cores aren’t for “browsing the web / watching YouTube / checking emails” but for non-interactive tasks like Spotlight indexing (based on GCD scheduling priority).

https://eclecticlight.co/2021/05/17/how-m1-macs-feel-faster-...

> tasks like Spotlight indexing

I'd swear that Spotlight indexing would prefer a freaking supercomputer when it runs.

My whole system just starts to feel sluggish, especially if I just moved a bunch (say 1-5GB) of files onto my system and not it wants to index them.

</rant>

Consider the use cases. The Mac Pro is a desktop, always plugged in and used for the power. The M1 is on a laptop running on a battery where efficiency is more important to improve the battery life.

So why put efficiency cores in the desktop processor at all?

It still nice to reduce power consumption and heat production when running idle.

A desktop runs a lot of low priority processes. The efficiency cores can be given all those processes. This means some low priority thread will get scheduled on a performance core and bust the cache.

There's also plenty of time where the system has low intensity use or is idle. The efficiency cores let things like receiving notifications or checking e-mail happen for very little power draw. Fans only need to run during intense use and the system can be quiet the rest of the time.

The guys have split the traditional UI thread and the background thread down to the silicon.

Who knows, maybe the UI thread only needs access to the graphics card, and the background thread only access to network. It would save a lot of interrupt loops.

> Fans only need to run during intense use and the system can be quiet the rest of the time.

This is a bigger deal than it might seem. Fans running means that dust is accumulating in the machine at an accelerated rate, even if you have filters in place. The less the fans have to run, the less dust accumulates, and the longer cooling functions near-peak. A tower that sees sporadic heavy usage especially stand to benefit from fan minimization.

As has been mentioned elsewhere, devoting some cores to background tasks and reserving the others for higher-priority stuff also makes the system feel more responsive.

See, for example, this article from yesterday: https://eclecticlight.co/2021/05/17/how-m1-macs-feel-faster-...

Long story short, segregating background work from foreground work means that Spotlight indexing won't cause the UI to become sluggish. I'm guessing it also tends to be more cache-friendly.

But separating the background work doesn't actually require efficiency cores. With 40 performance cores, you could still dedicate 4 or 8 of them to "background" processes only. As that article you linked shows, the background processes would simply complete more quickly without affecting interactive work on the machine.

performance cores are physically larger than the efficiency ones, by about 3-4x. I'm sure there are other tradeoffs cache size like too. So would you rather have 32 performance cores and 8 efficiency or 34 performance?

Consuming 1/10 as much power would also have thermal advantages for the die overall, and segregating them onto a separate L2 cache from the performance cores would help with that cache friendliness situation, different allocations of logic units means you can tailor them toward different kinds of workloads. . . I'm no CPU designer, so I really can't speak with authority here, but I can at least see several possible reasons why it would make sense even when you aren't worried about battery life.

In upper end extreme case, using 8 HE Core instead of 8 HP Core saves you 24 to 32W. Those 32W could allow more GPU usage or some other part of system such as ISP or NPU.

At the end of the day you will still need HE Core, they just aren't as important comparing to a Battery devices.

Not to mention Marketing, Die Size cost consideration.

To reduce the need for noisy cooling.

Heat.

To expand on that:

The design challenge of high-performance CPUs today is heat. Too much heat induces throttling. Putting low-priority stuff onto efficiency cores reserves the power budget of the SoC for high-priority tasks.

https://arstechnica.com/gadgets/2021/05/apples-m1-is-a-fast-...

I'm not sure I get your point, but isn't the M1 used in the Mac Mini and iMac, both of which are always plugged in and have no batteries?

Because the M1 is used in laptops and desktops and this chip likely would only be used in the Mac Pro

I wonder what % of high end users actually work on battery only. For me it's mostly a desktop that I move between home and office. And like maybe 2% of time batteries.

In an office all the time going to meetings. I usually have long-running processes that I’m not going to turn off just for the meeting.

It seems obvious once you look at it - the "efficiency" mode is almost a quasi-sleep and so it makes sense to only dedicate a certain number of processors to it (as every efficiency core could in theory have been a performance core).

The OS appears to partition the processors, like linux cpuset stuff, with low priority threads getting given to the efficiency cores, so you basically keep the low priority background stuff off the performant cores.

How many is optimum is an interesting question, I would assume the apple peeps have a good idea and are on the money with this design.

it's not clear to me why the optimal number of efficiency cores wouldn't be zero on a desktop. why not just use the die area for additional performance cores? one or two full cores shouldn't have much effect on the thermal/power budget if they're just working on background tasks.

I suspect heat is a bigger problem than you're assuming, but also, you would want a similar architecture to simplify the os code.

Perhaps. It wasn't obvious to me. I thought things like non-active browser tabs and various background daemons would easily occupy more than 4 efficiency cores. Though I suppose that has a lot to do with how they are implemented.

I assume they optimize Safari for this, and I'd think they'd be much more likely to quiesce a background tab (and let it swap out) than to keep it running at a slower speed.

At some point it's more efficient to have a single performance core going than a number of efficiency ones.

They do up to 8 on the big CPU according to rumor, so there's obviously some room there.

A performance-focused workstation would have more performance cores because it’s being used for more CPU-intensive work. If you don’t actually need that many performance cores, you’d buy a Mac Mini instead.

That seems a bit weird to me. Many programs are hard to multithread but I'd expect that if any given program can make effective use of 8 threads it can probably keep scaling to 16 and 32. The hard part is getting from 1 to 2 and 2 to 4. So I'd expect that in most cases having more than 8 high performance cores doesn't make that much sense.

Amdahl's law can be formulated in the following way:

<math>S_\text{latency}(s) = \frac 1 {(1 - p) + \frac p s}</math>

That's tautologically true but the question is what the distribution of p is over the 0-1 interval for real world programs.

A Mac Pro is likely to be dedicated to those workloads which ARE easy to thread - video editing and processing - or simply have multiple applications running simultaneously.

Someone who doesn't need more performance cores is unlikely to invest in a Mac Pro.

Macs are primarily well designed consumer devices, status symbols and objects of brand loyalty. These factors will push sales beyond a basic functional need.

I'm confused at this response. My thought is that instead of 32 high performance cores and 8 efficiency cores it might be better to have 8 high performance cores and ~100 efficiency ones which ought to be about the same area and power but provide a lot more throughput if software can utilize that level of parallelism.

There's a lot of software that won't scale to 108 cores, of course, but again I expect the amount of software that could usefully scale to 40 parallel threads but can't scale to 108 to be fairly small.

The performance cores seem to take maybe twice as much space as the efficiency cores, so I'm not sure the tradeoff would be worth it - the efficiency cores would need to be more than half as fast taking into account the parallelism to make the tradeoff worth it.

In a world where power and heat budgets don't matter at all you'd not have any efficiency cores, after all.

The general rule of thumb for reasonably sized cores, which both Apple's performance and efficiency cores are, is that performance tends to scale with the square of the transistor and energy budget due to N^2 structures like the bypass network, ROB, etc being the long poles. Now, for any given transistor budget there's going to be a non-linear tradeoff between performance and power governed by supply voltage versus process threshold voltage. And if you're testing a chip and using only one or the other of the two sorts of cores you're paying for the uncore and memory subsystem regardless of which cores you're testing which complicates things. But it would be really weird if power consumption wasn't super linear with performance, that's why "efficiency cores" have "efficiency" in their name.

> it can probably keep scaling to 16 and 32

Bad assumption. It's pretty difficult to write a multithreaded program that scales up to 32 cores. You have to carefully avoid all sources of process-wide contention. The only cases where it is easy to just keep adding cores are where the units of independent work are overwhelmingly large compared to everything else, like video compression.

No, it's certainly hard to write a multithreaded program that scales up to 32 cores. But it's also hard to write a multithreaded program that scales up to 8 cores. I'm saying that if we exclude the multithreaded programs that don't scale to 8 cores, most of them can be made to scale to 32 cores with reasonable effort.

I don’t really agree. You can get cpus where eight cores share an l2 cache and you can pretty much obliviously program those and get totally reasonable scaling because the contention penalty is the L2 access latency. There are no 32-core parts with that property, so you’re paying for at best L3 access latency and maybe main memory, possibly even NUMA node-crossing latency.

Are there CPU architectures where 8 cores share a L2 cache? I'm not aware of any though I can think of several where 4 cores share a L2 cache, though those tend to be pretty lightweight cores. More often you see issues with the L3 cache being shared between 8 cores or no as with Zen 2 versus Zen 3. And since only lightweight cores tend to share L2s this isn't really an issue in terms of replacing heavyweight cores with lightweight ones. Mostly, though when I think about sharing data between 8 cores I tend to be concentrating on making sure it ends up as S in MESI, MOESI, MESIF or whatever cache coherency protocol the chip is using.

Sure, POWER9 offers pairs of SMT8 cores sharing L2 caches, that's 16 thread contexts presented to software that are all sharing an L2 cache domain. Intel "Tremont" Atom has a shared L2 cache for a module of up to 4 cores. Maybe that is the one you allude to as lightweight.

Yes, there are clearly architectures where 8 threads share a L2$. L1$ too in both recent POWER SMT8 cores and SPARC Niagras. Yes, Intel Atoms were one of the examples I was thinking of regarding 4 cores sharing an L2$. One can quibble about what counts as a "core" when you're talking about POWER9 or Bulldozers but even being generous I don't think there's ever been a design where 8 cores all share the same L2$.

Even then, there’s the contention on memory access. If one of those easily paralleled tasks uses x% of your memory bandwidth, having more than 100/x CPUs won’t help.

Reply on news.ycombinator.com