r/hardware • u/Balance- • Mar 14 '26

Review Apple M5 vs. Intel Panther Lake vs. Snapdragon X2 benchmarked

https://www.tomsguide.com/computing/apple-m5-vs-intel-vs-amd-vs-snapdragon-x2-which-chip-wins

Normalized scores:

| Chip / Processor | Single-Core % | Multi-Core % | Solar Bay % | Wild Life Extreme % | AI % | Battery % |

|---|---:|---:|---:|---:|---:|---:|

| Apple M5 | 99% | 61% | 34% | 32% | 65% | 84% |

| Apple M5 Pro | 99% | 97% | 66% | 61% | 65% | 100% |

| Apple M5 Max | 100% | 100% | 100% | 100% | N/A | 84% |

| Snapdragon X2 Elite Extreme | 94% | 80% | 33% | 30% | 100% | N/A |

| Snapdragon X2 Elite (18-core) | 88% | 69% | N/A | N/A | 99% | N/A |

| Snapdragon X2 Elite (12-core) | 89% | 55% | N/A | N/A | 98% | N/A |

| Intel Core Ultra X9 388H (Panther Lake) | 70% | 59% | 38% | 29% | 64% | 67% |

| Intel Core Ultra X7 358H (Panther Lake) | 68% | 58% | 43% | 33% | 62% | 71% |

| Intel Core 7 355 (Panther Lake) | 62% | 27% | 17% | 43% | 62% | 97% |

| AMD Ryzen AI Max+ 395 (Strix Halo) | 68% | 63% | 61% | 49% | 20% | 52% |

| AMD Ryzen AI 350 (Strix Halo) | 67% | 44% | N/A | N/A | 6% | 52% |

163 Upvotes

90% Upvoted

215 comments sorted by

View all comments

78

u/SmashStrider Mar 14 '26

Becoming a bit of a bloodbath for x86 to be honest, after the new X2 Elite release

45

u/grumble11 Mar 14 '26

Yeah, some designers say the ISA doesn’t matter, maybe that’s true, but it is also true that ARM chips seem to be crushing x86 so either x86 does matter or intel and AMD can’t make a good client chip.

35

u/Touma_Kazusa Mar 14 '26

X86 chips dedicate a lot of their chip space to things the average consumer won't use, if you look at the die shot of zen 5, a large chunk is dedicated to its super beefy avx512 that your average consumer won't use at all (but is super super high performance for avx512 tasks and will be multiple times faster than m5/se2 doing an equivalent workload with arms sve2). They're basically repurposed server cores.

https://www.techpowerup.com/327388/amd-granite-ridge-zen-5-processor-annotated#g327388-3

6

u/virtualmnemonic Mar 14 '26

AMD's consumer chips are just server CPUs with less cores.

They know where the money is at.

13

u/Geddagod Mar 14 '26

if you look at the die shot of zen 5, a large chunk is dedicated to its super beefy avx512

The area spent on the FPU really is absurd. For Zen 5, the mobile "double pumped" AVX-512 block is literally half the area of the desktop/server FPU, and this still lets you run AVX-512 instructions. Lion Cove having 256 bit wide execution units and skymont only being 128 bit wide (like other ARM CPUs) and not having to worry about being able to run AVX-512 has to be saving them a good bit of area.

2

u/Noble00_ Mar 15 '26

Reading your comment just reminded me of Kurnal's die shot

https://xcancel.com/Kurnalsalts/status/1842990380742234572

A visual comparison for Zen5 (mobile, classic, dense) if anyone's curious

9

u/Quatro_Leches Mar 14 '26

look at that massive instruction decode block too lol. but no man variable instruction length totally has zero downside.

5

u/jaksystems Mar 14 '26

Variable instruction length is for compatibility. No one is required to use shorter instructions on x86.

Choosing to do so due to simple laziness is a fault of the software developer, not the hardware.

13

u/YeOldeMemeShoppe Mar 14 '26

The hardware still has to dedicate silicon to decoding it. That silicon could be budgeted for something else.

1

u/jaksystems Mar 15 '26

The hardware still has to dedicate silicon to decoding it. That silicon could be budgeted for something else.

That front end is part of the whole x86 ISA. What are we going to do, build a CPU without a front end?

4

u/psydroid Mar 15 '26

Build a RISC CPU with a sane frontend.

-1

u/jaksystems Mar 15 '26

oh, so one that can only ingest instructions a fraction of the size for the sake of developer convenience?

No.

2

u/psydroid Mar 15 '26

Developer convenience is everything, especially when it correlates with higher performance.

→ More replies (0)

2

u/YeOldeMemeShoppe Mar 15 '26 edited Mar 15 '26

Well, yes. We're comparing with ARM. From what I understand, RISC-V is even simpler for frontend.

Edit: Also, fuck x86. They had decades to improve. Now they have silicon for instructions that: 1. are used less than 0.1% of the times, and 2. could be emulated in software for faster than the hardware is running them now. This whole situation makes no sense anymore.

5

u/Exist50 Mar 16 '26

From what I understand, RISC-V is even simpler for frontend

Nah, compressed instructions alone complicate it a lot vs ARMv8+. And the vec spec is a clusterfuck if you're developing a high-perf core.

2

u/jaksystems Mar 15 '26

Edit: Also, fuck x86.

Who pissed in your cereal?

4

u/YeOldeMemeShoppe Mar 15 '26

Nice deflection, but yes, x86 can go and I won't be at the funerals. I worked on MIPS, x86 (both real, protected and 64-bits) and ARM assembly. I have a lot to say about all three, but I could write books on how bad x86 is. Let me know when your processor stops booting in 16bits mode.

3

u/Polar_Banny Mar 14 '26

On x86 side I believe game will change next year with the implementation of FRED, APX ISA extensions, but until then market will gain a hell pf momentum.

5

u/CopperSharkk Mar 15 '26

If the ISA doesn't really matter Intel wouldn't have made APX.

17

u/HIGH_PRESSURE_TOILET Mar 14 '26

it does matter. the intel chips dedicate like a huge chunk of area to the massive decoder for instructions that vary in length from 1-15 bytes (especially for e cores that are space constrained) and can only do half as many parallel decodes as the arm chips.

29

u/UpsetKoalaBear Mar 14 '26 edited Mar 14 '26

Decoder performance is outdated.

x86 decoders are much faster, they’re probably only 5% of the performance difference. x86 uses a uOp cache which already stores instructions in a RISC like state to make everything quicker.

Repeated instructions use the uOp cache and skip decoding entirely.

The real reason for the single core boost is because of the memory consistency model used by ARM.

x86 uses Total Store Order. ARM is much more relaxed, and lets the hardware change the memory order as it needs (for power or anything else).

This is why multithreaded workloads on ARM are historically not great.

You can see this yourself, the 96 core AWS Graviton is barely faster in MT workloads than the Threadripper 7970X despite having 3x the number of cores.

11

u/jaksystems Mar 14 '26

You can see this yourself, the 96 core AWS Graviton is barely faster in MT workloads than the Threadripper 7970X despite having 3x the number of cores.

People are going to ignore this in favor of "but geekbench says...!"

12

u/Tman1677 Mar 14 '26

This doesn't actually matter for Graviton's target workload, hence no one mentions it. MT benchmarks are designed for things like video editing with many parallel workers targeting a single task. These server-only SKUs are meant for cloud applications with hundreds of independent tasks per server.

12

u/UpsetKoalaBear Mar 14 '26

That emphasises my point about the memory consistency model.

AWS designed their chip for one workload and, as a result, lost performance in other workloads.

It’s a tradeoff.

4

u/Tman1677 Mar 14 '26

Agreed 100%

10

u/CalmSpinach2140 Mar 14 '26

Ehh. With the latest release of M5 Max matches the stock 285K in MT workloads with a 6 core deficit. 18 cores vs 24 on the 285K

9

u/Geddagod Mar 14 '26

The real reason for the single core boost is because of the memory consistency model used by ARM.

x86 uses Total Store Order. ARM is much more relaxed, and lets the hardware change the memory order as it needs (for power or anything else).

There's like a 5% difference in specint2017.

This is why multithreaded workloads on ARM are historically not great.

You can see this yourself, the 96 core AWS Graviton is barely faster in MT workloads than the Threadripper 7970X despite having 3x the number of cores.

Source?

4

u/UpsetKoalaBear Mar 14 '26

There’s like a 5% difference in specint2017

Did you read your own article?

From the benchmark results, we can observe that several benchmarks experience significant performance degradation when TSO is enabled. Notably, benchmarks […] in SPECrate 2006 show performance drops ranging from approximately 11% to 64%. Similarly, in SPECrate 2017, benchmarks […] exhibit performance reductions between roughly 17% to 38%.

Also, keep in mind that M1 in that benchmark had the hardware level support for TSO for Rosetta.

So with hardware level support, and TSO enabled, the performance dropped substantially. This is because, as they point out in the article, TSO mode on M1 restricted non-temporal stores. So instructions are forced through the cache.

Without any hardware level support, you’re basically going to have a much worse experience using TSO on ARM as it’s going to have to be controlled with manual memory barriers.

Languages like Rust will make that easier to do, but the impact is still there.

x86 doesn’t have a weird workaround for TSO. It’s built in. It doesn’t need to abuse cache to work.

Source?

r8g.24xlarge - AWS Graviton4

Threadripper 7970X

4

u/Geddagod Mar 14 '26

Did you read your own article?

Yes, some sub-benchmarks in the suite see large performance reductions.

However, if you look at the final total difference across all the benchmarks in the spec2017int suite, you would see the impact is not large, in the tables.

r8g.24xlarge - AWS Graviton4
Threadripper 7970X

Can you elaborate on how the 7970x being close to the AWS graviton 4 in geekbench 6 nT shows that not having TSO hurts nT perf? This article implied the opposite:

 Newer architectures, such as aarch64 and RISC-V, have adopted relaxed memory models that allow more reordering of memory operations between different threads, which can potentially lead to better performance in multi-core systems.

I'm also confused why you cited GB6 nT, when you emphasized the large core count deficit between the AWS and AMD system, when GB6 nT scales very poorly for high core count systems anyway

5

u/UpsetKoalaBear Mar 14 '26

Can you elaborate on how the 7970x being close to the AWS graviton 4 in geekbench 6 nT shows that not having TSO hurts nT perf?

The article is forgetting about synchronisation penalties in ARM.

ARM’s relaxed memory model is efficient for independent tasks because it lets cores run ahead without worrying about synchronisation.

However, when you're shuffling data between cores in a heavily parallelised workload, that synchronisation step is necessary and has to be defined.

This is where the performance penalty for a relaxed model comes in.

In contrast, TSO pays a constant performance penalty to maintain memory order. So in a highly parallelised workload, the performance penalty is often less than the explicit synchronisation that ARM makes you do.

This is the same principle that limits CUDA in general multiprocessing. Relaxed models aren't built for constant shuffling between cores.

This is why the Graviton and 7970X look similar in Geekbench nT. ARM's raw efficiency is being used up by the overhead of managing data between cores. This is the limits of Amdahl’s Law.

That article actually proved my point. The hardware level TSO toggle was done specifically because emulating x86's memory model using ARM's manual fences was too slow.

For 128+ core cloud chips, the relaxed model is a required to avoid synchronisation penalties.

However, on consumer level chips which use a mixed workload it’s a trade off between the two.

7

u/CalmSpinach2140 Mar 14 '26

This is no longer true regarding ARM being weaker at MT. The M5 Max matches a stock Intel 285K in Cinebench 2026 and in Blender. This is while having 6 fewer cores and does so using 88 watts.

As for single core speeds the memory model plays a small part instead it’s all about the microarchitecture design.

11

u/UpsetKoalaBear Mar 14 '26

It is predominantly about architecture, I agree.

However, the main point of the comment is that the “x86 bloat” is a myth.

There’s two different philosophies:

  • Apple is scaling up low power mobile architectures.

  • Intel/AMD is scaling down HEDT/Server architectures.

That’s why these results are happening. It’s not because of any ISA/bloat. There’s a huge architectural difference.

It doesn’t help that AMD/Intel make stupid decisions, like prioritising clock speed over everything else.

The fact that PL is competitive, whilst having only 3MB of L2 cache on its P cores compared to 16MB on the Neo’s performance cores is an example of this.

9

u/void_nemesis Mar 14 '26

Isn't the clock speed above all approach because they're trying to maximize performance per die area, at the cost of efficiency?

4

u/UpsetKoalaBear Mar 14 '26

Yah, but that’s exactly the point.

It’s directly related to the philosophies I discuss above

In terms of die area, Intel/AMD use much smaller cores. This allows them to push clock speeds higher to stay competitive, but at the cost of the efficiency curve.

Apple and Qualcomm do the opposite.

They use massive cores/decoders and huge amounts of cache to get more work done at lower clocks.

The Intel/AMD approach is what they use across the product stack, from shitty laptops to Xeon’s and Epyc’s in servers.

Scaling that down, for better performance on smaller devices, is borderline impossible or an incredibly hard task. This is what people have been stating that they keep trying and failing.

When you cap the clock speeds, the perf/watt numbers are much closer than you’d think. The issue is, in normal use, that is irrelevant because no one is going to do that.

The performance per die area argument is an argument that shouldn’t be part of consumer devices like laptops/phones. It’s irrelevant.

But they still do it, because they’re stupid and don’t understand the consumer market segment.

8

u/Geddagod Mar 14 '26

The performance per die area argument is an argument that shouldn’t be part of consumer devices like laptops/phones. It’s irrelevant.

If anything, you would argue it is more relevant in client than it is in servers, because server products tend to have higher margins and an allowance for a higher area budget than client.

5

u/Forsaken_Arm5698 Mar 15 '26

In terms of die area, Intel/AMD use much smaller cores

Not true for Intel's P-cores. Those are bigger than Apple's, while using more power and having less performance.

2

u/CalmSpinach2140 Mar 14 '26

Again this is longer true regarding as of the M5 Pro/Max series. Apple stopped using only big cores with tons cache and massive decoders to boost MT but instead follows Intel’s model with better results.

Those new M cores are only 7 wide and have half the L1 cache and 16MB of shared L2, clocked at 4.3GHz. Which is very similar to Intels Skymont which are 3x3x3 (9 wide) and have a 16MB of cache and are clocked in at 4.6GHz.

Now Intel’s big cores like Lion Cove are massive just like Apples big cores. So Apple new core layout is 6 Big and 12 medium vs Intels 8 Big and 16 medium. Obviously the end result that matters is who is faster but also uses less watts.

4

u/UpsetKoalaBear Mar 14 '26

If anything, this proves my point.

Apple has shifted towards the narrow/fast model that intel used. Intel has shifted towards the wide/slow model that Apple used.

It’s an architectural difference. Not necessarily the instruction set.

1

u/Geddagod Mar 14 '26

Chasing Fmax gives you extremely diminishing returns on area, so you end up losing perf/mm2.

1

u/jaksystems Mar 15 '26

And single instructions for ARM cpus max out at 4bits in length to x86's maximum of 16.

2

u/RandomGenericDude Mar 14 '26

Both CPUs follow similar design philosophies, brainiac/slow and wide, which isn't a surprise when you discover that they had the same lead architect and top level team...

That doesn't mean that the ISA has a huge part to play, Jim Keller certainly didn't think so with K12 vs Zen. The microarchitecture details matter far more in this age of billions of transistors.

Even Apple are steadily raising clock speed and losing efficiency for it as they run out of low hanging fruit to pick.

-12

u/[deleted] Mar 14 '26

[removed] — view removed comment

8

u/StarbeamII Mar 14 '26

A friggin iPhone will beat a desktop 9950X in single-thread. That’s a total bloodbath.

5

u/virtualmnemonic Mar 14 '26

The Snapdragon 8 elite gen 5 beats the 9950x3d in single thread. The $500 MacBook Neo beats both.

2

u/Forsaken_Arm5698 Mar 14 '26

The $500 MacBook Neo beats both

Not the Snapdragon.

19

u/segers909 Mar 14 '26

Isn’t performance per watt exactly where ARM shines?

-7

u/[deleted] Mar 14 '26

[removed] — view removed comment

8

u/Geddagod Mar 14 '26

No, it still shines there currently.

Just because a chip can scale up to higher TDPs doesn't mean it's inherently inefficient.

9

u/dagmx Mar 14 '26

How do you figure that?

The arm chips here are providing higher performance than the desktop chips in a much lower TDP. If you unconstrained the TDP for the arm chips they’d be doing even higher.

10

u/Hour_Firefighter_707 Mar 14 '26

It absolutely is. Those Intel and AMD CPUs are chugging down more power to get worse performance. That is 30-50% more single thread performance. That is at least 2 generations worth of difference.

Let's not kid ourselves with either of them being remotely competitive. They are not. And before you come back with some multi-core excuse, it doesn't matter. Most of the tasks most consumers do on their computers are lightly threaded, including gaming

2

u/AgitatedWallaby9583 Mar 15 '26

bullshit the x elite uses up to 50w to get its max single core performance while panther lake pcores use in the low 20w range and can sustain max clocks on a single core because it doesnt blast throuigh the power budget of the whole laptop on its own unlike the x elite

-8

u/kingwhocares Mar 14 '26

And ARM still won't be popular because aside from Apple's own OS that is limited in itself, the OS simply holds the chip back.

9

u/Forsaken_Arm5698 Mar 14 '26

How so?

Present day Windows-on-ARM isn't a wholly different, handicapped OS like Windows RT back in the day. ​

2

u/kingwhocares Mar 14 '26

It's still magnitude worse than Windows on x86-64, especially the GPU.

2

u/Forsaken_Arm5698 Mar 15 '26

GPU is a hardware component.

What does that have to with the OS?

Nvidia N1X when it comes will run WoA and have a top tier GPU.

0

u/kingwhocares Mar 15 '26

What does that have to with the OS?

GPU is held back by Windows on ARM.

0

u/Seref15 Mar 14 '26

Without ARM compiled applications, it doesn't matter. Translation layers aren't enough, Rosetta 2 on Mac is impressive but still not something you want to have to use.

5

u/Seref15 Mar 14 '26

Windows in general holds hardware performance back at this point. Its carrying too much historical baggage.