You are mixing up too many things. Code compilation and browsing are tasks with very different profiles. What would be interesting for the kind of argument you are making is to compare battery runtime compiling code between M4 and M4 max generations. But since we are talking about browsing, this is not the kind of conclusion you can make. Browsing does not utilize all 18 cores and it’s not a throughput task. In fact, it’s a task almost entirely dominated by waiting for user input or timer interrupts. As mentioned previously, uncore and other system changes will usually play a much bigger role in reducing the power consumption, unless we find evidence that the main core consumes less power. Replacing low-power E-cores by higher-powered throughput cores certainly wont improve battery life. Another option is of course what @dada_dave has said, and that’s that these workloads don’t run on main cores anymore. But that would be very unlike Apple.
M5 Pro and Max unveiled
- Thread starter leman
- Start date
You are mixing up too many things. Code compilation and browsing are tasks with very different profiles. What would be interesting for the kind of argument you are making is to compare battery runtime compiling code between M4 and M4 max generations. But since we are talking about browsing, this is not the kind of conclusion you can make. Browsing does not utilize all 18 cores and it’s not a throughput task. In fact, it’s a task almost entirely dominated by waiting for user input or timer interrupts. As mentioned previously, uncore and other system changes will usually play a much bigger role in reducing the power consumption, unless we find evidence that the main core consumes less power. Replacing low-power E-cores by higher-powered throughput cores certainly wont improve battery life. Another option is of course what @dada_dave has said, and that’s that these workloads don’t run on main cores anymore. But that would be very unlike Apple.
I don't think anyone is disputing that this new core type will change how Apple designs SOCs ... it already has ... or that this isn't a big deal ... it is very much so. Having said that, the name change is producing confusion (which will dissipate over time as people get used to the new naming convention). (I see @casperes1996 already beat me to this point while I was slowly typing)
Again I see I am extremely slow and @casperes1996 has already said all the points I was going to make. I think the misapprehension you are under is that the battery life tests are multi-core? They aren't - they are ST or lightly threaded at most, but pretty sure ST. Only one core is on typically. Which I think for Apple means only one cluster is on, every other cluster is powered down and drawing effectively near 0W of power. So for these battery life tests the presence or absence of other cores and their type that aren't on don't really matter that much. If this was comparing battery life under code compilation that would be great, but it isn't. We have to wait for 3rd party tests and I suspect power efficiency of these new cores in heavily MT tasks will indeed be excellent and demonstrate why Apple did this. It's just that the battery life tests itself don't do that. We need a different kind of test to really show these off - battery life or wall power under code compilation/Cinebench.
Last edited:
casperes1996
Site Champ
- Joined
- Nov 29, 2021
- Posts
- 521
That's the point though. The whole discussion here has been names. What this does to the product line is technically interesting and I think we're all on board with the idea that it's a fascinating evolution to follow along with and see what kinds of designs it allows and what performance characteristics it'll lead to. But the only thing that we've really discussed here is the name. That's what's been called confusing, that's what's been central to the discussion. And whether "balanced" sounds too weak for what the core offers; That's a marketting problem. The engineering speaks for itself in benchmarks and real world usage.
It doesn't upset me. It perplexes me. I'm so confused that this thread is more upset about names than hyped about the performance lol. I mean I understand talking about it, but that's like the narrative of the whole thread
Yes I'm not unaware you don't like the names they picked lol
Yes, but the marketing is meant to communicate what the tech is, and dare I say that Apple's marketing has always been more direct about the tech than most. They don't label their efficiency core , E core, as "High Performance Efficiency," like something Intel would do, even though the engineering behind their E core would support superlatives more than just "efficiency." That's what I'm saying: the fact that they chose performance as the name indicates to me it's more performant than people expect.
I could be wrong, always. This is just a discussion, but I am confused why it's dominated by MARKETING and not engineering. There's plenty of performance claims to think about, engineering descriptions, etc. We can discuss that.
@Cmaier @leman @dada_dave @casperes1996 guys, enough. I have FOUR people simultaneously discussing this with me and you're all ganging up on me. I can't even properly respond to all of you at the same time. This is a circular discussion. You guys are great but chill out.
On which kind of workload? Heavy multiprocessing stuff that uses all cores, sure. Office or web browsing - no, since these only utilize one or two cores max, usually on the main core cluster.
Again, you are appear to be confusing the computational demands of different workloads. The battery life improvement has been quoted for workloads where over 95% of the CPU time is spent waiting in a low-power mode, and where most cores are powered down. The power consumption of such workloads is dominated by the baseline power and other involved IP blocks - memory, caches, data busses, networking components etc. That’s what “uncore” refers to.
- Joined
- Sep 26, 2021
- Posts
- 8,092
- Main Camera
- Sony
It’s not ganging up just because we disagree. I promise you none of us are coordinating our responses in any way. In fact, us four don’t even seem to be addressing the same points (though there appears to be some overlap).
I don’t think we are ganging up on you at all, in fact I think it’s a very civil and constructive conversation. You can take as much time as you need to respond too, this is not a synchronous medium. Just something to think about, if you have multiple people (all experts in their own right) challenging your argument, maybe it’s a good time to reanalyze your premises?
I didn't say it was because you *disagreed* lmfao, it's the latter part of 4 people simultaneously discussing this with me and asking me for details. I cannot do it all at once, synchronously or asynchronously
- Joined
- Sep 26, 2021
- Posts
- 8,092
- Main Camera
- Sony
Good news is that caches, at least, can be powered down if not needed (or partially powered down). I’m sure they use SRAM for those. So if not all cores need to access the cache, it can shut down read hardware as needed. Of course it can’t shut down the entire cache unless there are no memory accesses, but you’ll only be burning static power, which is going to be 10-15% of overall power, probably. Turning off the whole thing would reduce it to effectively zero.
- Joined
- Sep 26, 2021
- Posts
- 8,092
- Main Camera
- Sony
Nice thing about this medium is there is no reason to respond immediately. Or at all!
This is flawed logic, and you're smart enough to know that it's flawed.
Aye though a 3d core type is already a paradigm shift so it's possible Apple is changing up how they are doing things wrt to thread priorities. But then they'll definitely need to be publishing an update to their Optimization Guide!
I didn’t say “if many people disagree, this must be that you are wrong”. I said “if many people disagree, it’s time to reexamine your argument”. Your argument might be flawed, or it might be hitting too many friction points that render it difficult to understand and accept. It is also entirely possible that I misunderstood what you are saying.
casperes1996
Site Champ
- Joined
- Nov 29, 2021
- Posts
- 521
As long as there's only 2 core types per product I think the scheduler is unchanged and just treats them as P and E from a scheduling perspective. We can run a diff on the scheduler when the next XNU source code release is dumped and see if we learn anything
Right but they may be changing what kind of threads get assigned where - my impression, you would know better than I, was that there were a bunch of thread levels but only the very bottom were guaranteed to go to the E-cores by default by the scheduler and otherwise Apple would assign threads to an available S-core if possible. Under the hypothesis that the battery life test threads are actually running on the P-core, it's possible that higher priority (though presumably not the highest) threads may be going to the P-core by default, especially on battery but maybe plugged-in too!, instead of the S-core. Basically Apple is starting to shunt threads to the P-cores (even when S-cores are available) to avoid turning on S-core clusters that under the old system would've gone to the S-cores.
Last edited:
- Joined
- Sep 26, 2021
- Posts
- 8,092
- Main Camera
- Sony
I’m wondering if the new-P’s are stickier than the E’s.
Yup that's what I'm wondering as well.
My "argument" was literally posting the battery life increase and then the wonderful @Cmaier asking if that was instead due to the networking chip, to which I explained why I thought not, instead using the engineering change of the chip to explain why I thought the battery life increased for the M5 Max chip.
I'm not technically apt enough, nor do I have the resources, nor do I honestly want to at this point spend the effort and energy delving into the nitty gritty of individual performance claims and cross comparing using a chip that isn't even out. To be clear, I was speaking about general performance benchmarks when using M3 Pro situation as context like Geekbench.
My official "position" is this:
1. the new P core is more performant than E, and more efficient than S.
2. This allowed them to change the core configuration from 12 HP/4 HE set up to 6HP/12HE, which combined with the new fusion tech allowed them to 1) boost overall performance (I was using code compilation as one example), 2) boost battery life, and 3) maintain thermal efficiency.
3. N1 chip helps
It is a fact that the M5 Max chip has increased its battery life and performance and core count across both models.
MacBook Pro 14":
20 hours of streaming, and 13 hours of wireless web for M5 Max
18 hours/13 hours for M4 Max
22 hours/14 hours for M5 Pro
22 hours/14 hours for M4 Pro
MacBook Pro 16":
22 hours of streaming, and 16 hours of web for M5 Max
21 hours/14 hours for M4 Max
24 hours/17 hours for M5 Pro
24 hours/17 hours for M4 Pro
13" MacBook Air:
18 hours streaming, 15 hours wireless web for M5
18 hours/15 hours for M4
15" macbook Air:
18 hours streaming, and 15 hours of wireless web for M5
18 hours streaming, and 15 hours of wireless web for M4
Explain to me why you think it's the N1 chip contributing most of the battery life increase and not the new chip, despite the fact that the MBA has the N1 chip and doesn't have any battery increase at all. I'm not the expert.
casperes1996
Site Champ
- Joined
- Nov 29, 2021
- Posts
- 521
Yeah, I have no real idea right now, but my hypothesis is that the system will behave as it currently does, treating S as P and P as E in the old system. In Grand Central Dispatch, there are 6 different "Quality of Service" tiers (although one of the 6 is "unspecified") - There are a lot more thread priority levels than that though. The QoS tiers are more like buckets and within each bucket there are tiers too, and this is for threads within a single process but the process itself can be prioritised too and so on and so on. The top two QoS tiers are "User interactive" and "User Initiated". The lowest two are "Background (lowest)" and "Utility". Then there's default in the middle. Your actual priority in the scheduler can vary a lot every single pass through the scheduler. This can be based on whether you voluntarily gave up the CPU or you were pre-empted, how much of the CPU you utilised in your timeslice, your associated process' priority, whether you have a window visible on screen, whether Game Mode is on or not, whether Low Power Mode/High Power Mode is on or not, thermal state and potentially more I forgot or don't know about. There's plenty of room for Apple to adjust things with the information available by running processes using Grand Central Dispatch - But ideally they can also do well scheduling tasks that are un-prioritised POSIX threads.
It's also worth remembering that there are other ways to prioritise high-QoS jobs than associating them with a super core. For example, you can time slice it longer before you pre-empt it, especially if you have a high enough core count that you can always keep pre-empting something frequently enough to keep the overall system responsive.
Possibly. I'm just not really sure the desired characteristics of changing the scheduling behaviour.
If something is explicitly labelled to be background work that isn't time sensitive, put it on the most efficient core we have, no-brainer. If all we have is background-tier jobs, clock-gate that cluster too.
Any work that may affect the responsiveness of the system or how quickly a task the user may be waiting on finishes, schedule on S cores first, and if there's so many parallel threads not yielding the CPU that we can spill the task Into the P cores, do that.
Unless we wind up with a single chip with all three tiers of core on it, I don't see the benefit or desired outcome of changing the thread scheduling. With three core types it'd need to be considered how they interact, but as long as there's just two types, a strong and a weaker, regardless of what the difference is between them almost, I feel like the same pattern as before is relevant. Only reason I could see for that changing is if the Super core was *a lot* more power hungry, but it's the same as what we used to call P in the base M5, so we know for a fact it's not an unreasonably power hungry core that would make it infeasible to rely on it for most tasks