Good question, some CPUs have better perf/watt and are cheaper, notably Ryzen 5800U from the same year : https://www.cpubenchmark.net/power_performance.html

That's a bullshit chart: only one of the two axes is actually measured data, and the other axis is made up.

You mean the standard TDP is made up ?

Yes. "TDP" from Intel and AMD have completely different definitions and are only loosely correlated with actual power consumption (especially for mobile parts); they're pretty much made up by the marketing departments for the purpose of product segmentation. The "TDP" they list for Apple is made up by PassMark; Apple doesn't publish a TDP number.

Good point! Here are some numbers at peak load, check Cinebench R15 multicore wattage and score : https://www.notebookcheck.net/M1-vs-R7-5800U_12937_12976.247...

No mention of methodology there. In the review of the M1, it looks like they reported some numbers from software estimates (never particularly accurate, especially for cross-platform comparisons), and some measurements of wall power (ignoring the battery, which actually matters for peak power consumption). The one AMD 5800U review I checked seemed to be mostly using wall power measurements. Their methodology article does not really provide any further detail ( https://www.notebookcheck.net/Our-Test-Criteria.15394.0.html ). Every plausible way of producing the numbers in the comparison chart from the data they collect and present in their individual laptop reviews leaves them at risk of systematic errors on the order of several Watts.

I disagree. I don't mean that Ryzen 5800U lied about its stats or something, but the totality of the systems based on Ryzen 5800U is at best competitve with Intel systems and at worst Intel would look better. Unfortunately, the tuning that Apple have done is significant (more power-efficient screen, speakers and other assorted hardware that you would usually ignore).

Also, even ignoring all of that, Apple M series are basically the only option for a resonably functional ARM device. I acknowledge Chromebook can be effectively transformed into Linux, but their focus on price shows.

"being an arm device" is not an advantage though.

Being on a less used architecture, in the PC context, has its downsides though.

Intel is rapidly losing the server market to Arm. So, if you are targeting phones or the cloud, having an Arm laptop is an advantage. (MacOS includes a hypervisor that runs Arm Linux better than any native Arm Linux device I can purchase for myself.)

Most phones barely run anything but bytecode anyway.

Iphones do, but the biggest advantage of an M1 in that case the advantage by far ought to be "runs macos" and not, "is arm".

x86 rapidly losing in serverspace? No. If you work on servers you are still mostly working on x86. And in most cases it wouldn't matter anyway.

Lot of hypotheticals to try and justify it.

> Most phones barely run anything but bytecode anyway

Since when? If you mean Android’s Java, it is mostly AOT compiled/cached machine code.

Which runs just fine on x86 as well...

My point was that the intersection between the low level programming where you do care about which architecture you are running on and phones is very very slim.

Not saying that shouldn't be the case, but that is unfortunately where we are.

That's normal thing. Emulated hardware is normally chosen so that is simplest to implement and the drivers are most common. (Before you go up to the specialised solutions) Hypervisor runs X better than native is true for almost any X for non-critical solutions.

ARM (64-bit) is a much more secure architecture than Intel; it would be simply because it doesn't have variable-length instructions, but it also has PAC/BTI and more coming in ARMv9.

Much more secure? Really?

And you think it is relevant for a laptop?

You clearly don’t think it is. Elucidate.

> Much more secure? Really?

Really.

> And you think it is relevant for a laptop?

Yes, it's got your personal info and you run a web browser on it.

There are so many more low hanging fruits that makes the architecture (in relation to arm vs. x86) completely irrelevant to the equation.

When we get to those kind of details, maybe you shouldn't rely on drivers that were written without proper information about the hardware?

No, in the web browser case this is literally the most important thing. Second most important would be hardware image/video codecs but that's an optional power optimization. Third would be setting up IOMMUs so the wifi chip can't read all your memory.

Writing hardware drivers through reverse engineering is actually fairly common, not too difficult, and the people doing it for Asahi aren't running into problems - it's more like everyone else just assumes they will.

I would have thought the browser was the most important thing. Do you have any examples to share?

Particularly and genuinely curious about how variable length instructions have affected browser security.

"not too difficult", I guess everything is relative. But I'd have to disagree and say that the work they do is quite difficult.

"aren't running into problems". How would we know? (obviously talking about security problems here)

> I would have thought the browser was the most important thing. Do you have any examples to share?

No, you're right. The architectural differences like pointer signing sometimes need the code to adopt them but mostly you get them for free after the compiler adopts them.

A browser is special though because it runs JavaScript so it's got a compiler (JIT) in it. So exploiting the JIT lets you attack the rest of the system after you find something like a use-after-free or type confusion bug. The ARM security techniques MTE and PAC protect against this.

> Particularly and genuinely curious about how variable length instructions have affected browser security.

Basically the issue is that you can jump into the middle of an instruction and it can be another valid instruction. This lets you find something called a "ROP gadget" and construct a new evil program out of little bits of browser code. Harder but not impossible with fixed length instructions. BTI is meant to protect against this too.

It also makes it easier to hide evil code inside an innocent looking binary, but that's more of a problem for like an antivirus and there's other ways to do it anyway.

> "aren't running into problems". How would we know? (obviously talking about security problems here)

We wouldn't, that is possible. I just meant that they're making good progress getting everything to run at all, and most of the image of it being super hard is coming from commenters. (Of course it is pretty hard.)

Performance and power is pretty easy to observe just by watching your battery life though.

Yes Apple shines especially on idle TDP, their battery life is impressive.

Do you have benchmarks of Intel 11 gen beating Zen 3 ?

This is the difference right there. My daily driver is an 6800U (a slightly more efficient 5800U), the whole system idles on Linux at around 6W which is way too much to target whole day battery life. The performance is amazing though.

That page has the 5800U at 18735 / 25w, around 750/w.

M2 8-core is 15356, and the tdp figure isn’t listed because it’s got the ram on the same package, but IIRC the entire package has a 15w tdp. If that recollection is correct, that’s over 1000/w; add 6w power use for ram to the ryzen and it’s really no contest.

I agree it misses context. We should compare peak load and peak TDP.

Check the Cinebench R15 multicore here, Zen3 wins on perf/watt again

https://www.notebookcheck.net/M1-vs-R7-5800U_12937_12976.247...

Looking at the Cinebench R15 results it seems like the M1 x86 actually had better perf/Watt than the 5800U despite the oversite the M1 is running this 2013 benchmark via emulation.

Note: If you hit the expandos you'll see nearly every 5800U result is coming from a 30W/25W TDP 5800U. Even if you take the most favorable R15 test (multicore), the 25W value for the 5800U, and a 15W value for the M1 (despite the page saying 10W) that still comes out with perf/watt in favor of the M1 emulating the benchmark. If you look at the first native release of Cinebench (R23 in 2020) you'll see the reality that the M1 runs at about the exact same speed (slightly ahead in single core, slightly behind in multicore) at 1/2 the Wattage.

For comparison an entire Mac Mini system pulls 30W from the wall when running a compute benchmark workload https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste... including conversion loss, peripherals, memory, and anything else.

Interesting thank you! Also the primary/secondary core of the M1 is pretty clever. Intel 13th gen uses a similar strategy now, but not AMD yet, which is surprising considering their chiplet approach.

I think the new 7950x3d is primary/secondary also.

Not exactly. One chiplet has more L3 cache, but the other one can run at higher clock speeds, so which one to prefer depends on the application. Which makes it a horrible mess from a software/OS perspective.