This fact however makes "performance per watt" comparisons misleading between different processors designed for different environments (e.g. M1 vs AMD Desktop). It takes a more power to get that much extra perf, conversely and the more under-appreciate part IMO reducing the speed a little can save a ton of power/heat if the chip is currently running at the higher power portion of the curve.
On a desktop machine most people would want them to tune for performance at quite a substantial power efficiency cost so of course a desktop chip most probably is less power efficient per unit of compute. You don't need to power it with a battery after all and there's heaps more cooling capacity in a bigger form factor so why optimise for that?
For comparison, the 3090 has almost 1TB of memory bandwidth.
Per chiplet.
I wonder if future perf gains will come, game console-style, from areas besides general purpose computation -- specialized instructions / cores for specialized tasks.
Imagine an entire core optimized for Safari and its Javascript engine. Their next chip is called the "M1 Marathon Edition" and you get 36 hours of real-world battery life with Safari. And/or the iWork suite. And maybe they have a behind the scenes collab with Slack and select other app makers so that they can be a part of the "Marathon" program too.
I dunno, just spitballing. Not saying that's likely or even what I'm pining for, just one possible avenue once they've plucked all the low-hanging general purpose computing fruit.
What if somebody on the Intel/AMD side of things includes some optimizations for SSE, AVX, etc? Are they punishing everybody else?
At any rate, my idea was less than half baked and again, not exactly something I'm pining for. Was just thinking about things Apple might conceivably be able to try with their unique vertical integration.
Hyper-optimizing for a particular application means the way that particular application works gets accelerated, but not things in general. Sure, if a browser behaved identically to Safari, it too would potentially experience the speed up barring any weird microcode/firmware that only allows those extensions to be used by Apple-signed binaries which is a whole 'nother level of nightmare. Stepping outside of that highly optimized path is essentially a penalty though as it by definition wouldn't be so highly optimized. And once that optimized path has been etched into the silicon, there's no real updating it unless we move to CPUs being more like FPGAs which isn't likely to happen.
Intel doesn't forbid compilers from generating code for SSE or AVX.
Apple _does_ forbid Chrome from using energy management and other APIs for no other reason than to keep it less efficient than Safari.
That is unfair and I would not support that behavior whether talking about private software APIs or private hardware instructions. What I was half-assedly imagining wouldn't be anything like that.
(Although, FWIW, Chrome has private APIs too: https://blog.chromium.org/2021/01/limiting-private-api-avail... Different use case, but still.)
I've been having trouble figuring out exactly which private bits and bobs Webkit might be taking advantage of on MacOS.
Other commenters are suggesting that Apple's intent is to keep Chrome and other third-party apps from matching Safari's energy efficiency.
But as you say, I'm not sure that makes strategic sense. If that is true, Apple is essentially crippling most Mac use cases just to benefit Safari. That really would not seem to be in Apple's best interests.
I am a developer, but not a iOS/MacOS developer. So I have followed this sort of thing only very loosely over the years.
But whenever I have heard about grumblings about private Apple-only APIs being used by blessed first-party Apple apps on iOS, it seems to me that the explanation was always that the private APIs either:
1. posed some sort of security issue
2. were simply not yet stable enough to expose to third-party apps
As every developer knows, publicly exposing any API represents a maintenance burden: you're committing to support that API and keep it stable for X number of years. In general you see this kind of pattern a lot: a platform developer dogfoods APIs internally for some period of time before they're stable enough to expose publicly.
E.g even on the M1 Pro/Max, you're going to get much better performance and battery if you're using a video editor that supports prores decoding.
It's already possible to target GPUs in-browser directly; and most older HTML primitives were recast in terms of GPU operations around the time of the original iPhone. The only thing I can think of that's still been left on the table is rendering vector geometry on-GPU; but most sites don't redraw so much as to make this a huge performance win.
Video decode has been offloaded to hardware for decades as well. The only reason to decode video on-CPU is if you're decoding crazy-old formats[0] that don't have hardware decoder blocks present for them.
The other huge problem is networking - which is also heavily hardware-optimized and has been for a while. Large assets mean keeping your Wi-Fi or LTE baseband on for longer. You could mitigate this with compression; which can be hardware optimized... though I'm not sure how much of a benefit that provides outside of game consoles[1].
[0] In my personal experience: I wrote a Sorenson H.263 decoder for Ruffle. Right now it not only executes on-CPU, but blocks the event loop main thread. However, the video files in question are so low-quality that this isn't a significant problem for most Flash movies and everything works fine (though I do want to try on-GPU video decoding at some point).
[1] Current-gen game consoles (PS5/XSeries) have hardware decompression blocks. However, the intent is to quickly decompress gigabytes worth of data quickly; most websites aren't nearly that bloated.
I'm not. Let them all scramble and pull out the big guns to try to compete. That's capitalism at it's finest, which isn't exactly what we've been seeing in the CPU space for the prior decades. We got lucky that AMD caught Intel with their pants down recently (if only because it strengthens AMD and makes them a better competitor), but a duopoly isn't necessarily what I would consider a good market condition for progress (as we've seen with iOS vs Android). Lots of different experiments with feedback from people on what they find good would be much preferable, and while a constrained CPU such as Apple's isn't perfect, it does represent more choice and pressure on other players to evolve in ways they may have been resistant to previously.
> And maybe they have a behind the scenes collab with Slack and select other app makers so that they can be a part of the "Marathon" program too.
RIP the general purpose computer. :(
> And maybe they have a behind the scenes collab with
> Slack and select other app makers so that they can
> be a part of the "Marathon" program too.
RIP the general purpose computer. :(
Since heterogenuous cores are now a mainstream thing, with a mixture of full-throttle and performance-minded cores on a single die, and the performance cores may be hitting a wall until we get to smaller processes, perhaps the next frontier could be efficiency.
Remember how some software proudly displayed those "optimized for MMX" or "optimized for 3DNow!" badges back in the day? What if there was something like that for apps that optimized for those efficiency cores, and what if the efficiency cores met them halfway by implementing some app-friendly stuff in hardware? Sort of like how some common Javascript string ops have dedicated CPU hardware dedicated to them now.
Anyway, yeah. I'm probably just re-inventing CISC all over again, badly.
I don't think that would be worth it. What's the point of 36 hours of battery life? How often do you need more than 12 hours of life on battery? Increasing the maximum battery life only makes sense when it also increases battery life for the more power-hungry workload (which is where you're likely to reach the limit), why bother building dedicated hardware for a specific workload that's already beyond what you need?
> reducing electricity usage reduces costs and overall emissions in to the planet
You're going to need a looooooooooooooooong time for the electricity usage reduction to compensate for the enormous energy cost of manufacturing a new laptop. If you care about the climate, don't buy a new laptop if your previous one is still running fine, there's just no way energy efficiency is going to be worth it.
Considering that some of the magic in these things is the shared, local memory with a very wide bus it would seem obvious that trying to go multi chip would indeed be a massive headache in this regard
[0]: https://architosh.com/2021/10/apples-new-m1-pro-is-chop-vers...
All of the M1 devices have been monolithic dies so far.
Zen 2 was a must-have upgrade over Zen+ and it was a 10% IPC increase.