AMD's Strix Point: Zen 5 Hits Mobile • Hacker News Board

Re: AMD's Strix Point: Zen 5 Hits Mobile

#51

Post by cyp0633 » Sun, Aug 11, 2024, 2:08 AM UTC

hajile wrote: post #48

jsheard wrote: post #10

Earlier quoted context omitted.

Any efficiency comparison involving Apples chips also has to factor in that Tim Cook keeps showing up at TSMCs door with a freight container full of cash to buy out exclusive access to their bleeding edge silicon processes. ARM may be a factor but don't underestimate the power of having more money than God. Case in point, Strix Point is built on TSMC 4nm while Apple is already using TSMCs second generation 3nm proces…

Let's do the math on M1 Pro (10-core, N5, 2021) vs HX370 (12-core, N4P, 2024). Firestorm without L3 is 2.281mm2. Icestorm is 0.59mm2. M1 Pro has 8P+2E for a total of 19.428mm2 of cores included. Zen4 without L3 is 3.84mm2. Zen4c reduces that down to 2.48mm2. Zen5 CCD is pretty much the same size as Zen4 (though with 27% more transistors), so core size should be similar. AMD has also stated that Zen5c has a similar sh…

Power efficiency is a curve, and Apple may have its own reason not to make M1 Pro run at 110W as well

Re: AMD's Strix Point: Zen 5 Hits Mobile

#52

Post by anvuong » Sun, Aug 11, 2024, 2:12 AM UTC

sm_1024 wrote: post #11

wtallis wrote: post #8

Earlier quoted context omitted.

The CPU core's instruction set has no influence on how well the chip as a whole manages power when not executing instructions.

That is fair, I was taught that decoders for x86 are less efficient and more power hungry than RISC ISAs because of their variable length instructions. I remember being told (and it might be wrong) that ARM can decode multiple instructions in parallel because the CPU knows where the next instruction starts, but for x86, you'd have to decode the instructions in order.

That was true when ARM was first released, but over the years the decoder for ARM has gotten more and more complicated. Who would have guessed adding more specialized instructions would result in more complicated decoders? ARM now uses multi-stage decoders, just the same as x86.

Re: AMD's Strix Point: Zen 5 Hits Mobile

#53

Post by acdha » Sun, Aug 11, 2024, 2:17 AM UTC

cubefox wrote: post #49

acdha wrote: post #46

Earlier quoted context omitted.

That appears to be an unconfirmed rumor and it’s exciting if true (and there aren’t major caveats on power), but did you notice how they mentioned extra work by ARM? The argument isn’t that Apple is unique, it’s that the performance gaps they’ve shown are more than simply buying premium fab capacity. That doesn’t mean other designers can’t also do that work, but simply that it’s more than just the process - for examp…

Since it's unclear whether Apple has a significant architectural advantage over Qualcomm and MediaTek, I would rather attribute this to relatively poor AMD architectures. Provisionally. At least their GPUs have been behind Nvidia for years. (AMD holding its own against Intel is not surprising given Intel's chip fab problems.)

Yes, to be clear I’d be very happy if MediaTek jumps in with a strong contender since consumers win. It doesn’t look like the Qualcomm chips are performing as well as hoped but I’d wait a bit to see how much tuning helps since Windows ARM was not a major target until now.

Re: AMD's Strix Point: Zen 5 Hits Mobile

#54

Post by hajile » Sun, Aug 11, 2024, 2:17 AM UTC

dzaima wrote: post #45

hajile wrote: post #36

Earlier quoted context omitted.

Clam makes some serious technical mistakes in that article and some info is outdated. 1. His claim that "ARM decoder is complex too" was wrong at the time (M1 being an obvious example) and has been proven more wrong since publication. ARM dropped the uop cache as soon as they dropped support for their very CISC-y 32-bit catastrophe. They bragged that this coincided with a whopping 75% reduction in decoder size for th…

Some notes: 3: I don't think more decoders should be exponentially more complex, or even polynomial; I think O(n log n) should suffice. It just has a hilarious constant factor due to the lookup tables and logic needed, and that log factor also impacts the critical path length, i.e. pipeline length, i.e. mispredict penalty. Of note is that x86's variable-length instructions aren't even particularly good at code size.…

3. You can look up the papers released in the late 90s on the topic. If it was O(n log n), going bigger than 4 full decoders would be pretty easy.

6. Not all of those SIMD sets are compatible with each other. Some (eg, SSE4a) wound up casualties of the Intel v AMD war. It's so bad that the Intel AVX10 proposal is mostly about trying to unify their latest stuff into something more cohesive. If you try to code this stuff by hand, it's an absolute mess.

The P proposal is basically DOA. It could happen, but nobody's interested at this point. Just like the B proposal subsumed a bunch of ridiculously small extensions, I expect a new V proposal to simply unify these. As you point out, there isn't really any conflict between these tiny instruction releases.

There is discussion around the 48-bit format (the bits have been reserved for years now), but there are a couple different proposals (personally, I think 64-bit only with the ability to put multiple instructions inside is better, but that's another topic). Most likely, a 48-bit format does NOT do multiple encoding, but instead does a superset of encodings (just like how every 16-bit instruction expands into a 32-bit instruction). They need/want 48-bits to allow 4-address instructions too, so I'd imagine it's coming sooner or later.

Either way, the length encoding is easy to work with compared to x86 where you must check half the bits in half the bytes before you can be sure about how long your instruction really is.

8. There could be some variance, but x86 has this issue too and SO many more besides.

Re: AMD's Strix Point: Zen 5 Hits Mobile

#55

Post by sliken » Sun, Aug 11, 2024, 2:20 AM UTC

apatheticonion wrote: post #29

Are there any mini PCs with Zen 5?

"AMD Strix Point expected to debut in October, claims AOOSTAR" was a new headline I've seen. Seems about right that laptops (higher margin parts) land a few months before the SFFs.

I'm excited about the strix halo that has more cores, double the GPU, and double the memory badwidth (to keep the GPU fed).

Re: AMD's Strix Point: Zen 5 Hits Mobile

#56

Post by jml7c5 » Sun, Aug 11, 2024, 2:21 AM UTC

I sit firm in my belief that the best thing Microsoft could do for their laptop ecosystem is to add support for a "max fan speed" slider somewhere prominent in the Windows UI.

People want the option to make their laptop silent or nearly silent. And when users do need the power, they generally prefer a slightly slower laptop at a reasonable volume rather than the roar of a jet engine.

Laptop manufacturers want their devices to score high on benchmarks. The best way to do that is to add a fan that can become very loud.

The incentives are not aligned.

All laptops should be designed to operate passively 100% of the time, if the owner so chooses. I doubt manufacturers will go that route unless Microsoft nudges them towards it. It would have downstream effects on how review sites benchmark laptops (i.e., at various power draws/noise levels producing a curve rather than a single number), which would have downstream effects on what CPU designers optimize for. It'd be great for consumers.

Re: AMD's Strix Point: Zen 5 Hits Mobile

#57

Post by sm_1024 » Sun, Aug 11, 2024, 2:21 AM UTC

hajile wrote: post #48

jsheard wrote: post #10

Earlier quoted context omitted.

Any efficiency comparison involving Apples chips also has to factor in that Tim Cook keeps showing up at TSMCs door with a freight container full of cash to buy out exclusive access to their bleeding edge silicon processes. ARM may be a factor but don't underestimate the power of having more money than God. Case in point, Strix Point is built on TSMC 4nm while Apple is already using TSMCs second generation 3nm proces…

Let's do the math on M1 Pro (10-core, N5, 2021) vs HX370 (12-core, N4P, 2024). Firestorm without L3 is 2.281mm2. Icestorm is 0.59mm2. M1 Pro has 8P+2E for a total of 19.428mm2 of cores included. Zen4 without L3 is 3.84mm2. Zen4c reduces that down to 2.48mm2. Zen5 CCD is pretty much the same size as Zen4 (though with 27% more transistors), so core size should be similar. AMD has also stated that Zen5c has a similar sh…

119W for hx370 looks extremely sus, seems to me more like the system level power consumption and not CPU-only.

According to phoronix [1,2], in their blender CPU test, they measured a peak of 33W.

Here max power numbers from some other tests that I know are multi-threaded:

--

Linux 6.8 Compilation: 33.13 W

LLVM Compilation: 33.25 W

--

If I plug in 33W into your equation, that would give us score of HX 370: 104 PPA

This supports the HX 370 being pretty power efficient, although still not as power efficient as M3.

[1] https://www.phoronix.com/review/amd-ryzen-ai-9-hx-370/3

[2] https://www.phoronix.com/review/amd-ryzen-ai-9-hx-370/4

Re: AMD's Strix Point: Zen 5 Hits Mobile

#58

Post by sm_1024 » Sun, Aug 11, 2024, 2:29 AM UTC

cyp0633 wrote: post #51

hajile wrote: post #48

Earlier quoted context omitted.

Let's do the math on M1 Pro (10-core, N5, 2021) vs HX370 (12-core, N4P, 2024). Firestorm without L3 is 2.281mm2. Icestorm is 0.59mm2. M1 Pro has 8P+2E for a total of 19.428mm2 of cores included. Zen4 without L3 is 3.84mm2. Zen4c reduces that down to 2.48mm2. Zen5 CCD is pretty much the same size as Zen4 (though with 27% more transistors), so core size should be similar. AMD has also stated that Zen5c has a similar sh…

Power efficiency is a curve, and Apple may have its own reason not to make M1 Pro run at 110W as well

I think the OC might have mis-read the power numbers, 110 W is well into desktop CPU power range. Here is a excerpt from Anand Tech:

> In our peak power test, the Ryzen AI 9 HX 370 ramped up and peaked at 33 W.

https://www.anandtech.com/show/21485/the-amd-ryzen-ai-hx-370...

Re: AMD's Strix Point: Zen 5 Hits Mobile

#59

Post by dzaima » Sun, Aug 11, 2024, 2:30 AM UTC

hajile wrote: post #54

dzaima wrote: post #45

Earlier quoted context omitted.

Some notes: 3: I don't think more decoders should be exponentially more complex, or even polynomial; I think O(n log n) should suffice. It just has a hilarious constant factor due to the lookup tables and logic needed, and that log factor also impacts the critical path length, i.e. pipeline length, i.e. mispredict penalty. Of note is that x86's variable-length instructions aren't even particularly good at code size.…

3. You can look up the papers released in the late 90s on the topic. If it was O(n log n), going bigger than 4 full decoders would be pretty easy. 6. Not all of those SIMD sets are compatible with each other. Some (eg, SSE4a) wound up casualties of the Intel v AMD war. It's so bad that the Intel AVX10 proposal is mostly about trying to unify their latest stuff into something more cohesive. If you try to code this stu…

I know the E-cores (gracemont, crestmont, skymont) have the multi-decoder setup; the first couple search results don't show Golden Cove being the same. Do you have some reference for that?

6. Ah yeah the funky SSE4a thing. RISC-V has its own similar but worse thing with RVV0.7.1 / xtheadvector already though, and it can be basically guaranteed that there will be tons of one-off vendor extensions, including vector ones, given that anyone can make such.

8. RVV's vrgather is extremely bad at this, but is very important for a bunch of non-trivial things; existing RVV1.0 hardware has it at O(LMUL^2), e.g. BPI-F3 takes 256 cycles for LMUL=8[1]. But some hypothetical future hardware could do it at O(LMUL) for non-worst-case indices, thus massively changing tradeoffs. So far the compiler approaches are to just not do high LMUL when vrgather is needed (potentially leaving free perf on the table), or using indexed loads (potentially significantly worse).

Whereas x86 and ARM SIMD perf variance is very tiny; basically everything is pretty proportional everywhere, with maybe the exception of very old atom cores. There'll be some differences of 2x up or down of throughput of instruction classes, but it's generally not so bad as to make way for alternative approaches to be better.

[1]: https://camel-cdr.github.io/rvv-bench-results/bpi_f3/index.h...

Re: AMD's Strix Point: Zen 5 Hits Mobile

#60

Post by moonfern » Sun, Aug 11, 2024, 2:31 AM UTC

carstenhag wrote: post #17

arnaudsm wrote: post #7

Earlier quoted context omitted.

ARM got a lot of hype since the release of the M1, but most users only compared it to the terrible Intel MBPs. Ryzen mobile has been consistently close to Apple silicon perf/watt for 5 years. But got little press coverage. Hype can be really decorrelated from real world performance.

But how is this the case? I never saw a single article mentioning that a non-Mac laptop was better. (Random article saying M3 pro is better than a Dell laptop https://www.tomsguide.com/news/macbook-pro-m3-and-m3-max-bat... )

You're right, but... The idea comes from the desktop world. AMD's zen 4 desktop cpu's especially the gaming variants like the Ryzen 7 7800X3D almost matches the performance per watt of Apple's M3.

Their laptop cpu's as some companies did release same model different cpu were less efficient than intel.

But the Asus ProArt P16 (used in the article) did manage an extreme endurance score in the video test called Big Buck Bunny H.264 1080p which runs at 150 cd/m² with 21 hours. With it's higher resolution, oled and 10% less battery capacity that's better 40 minutes better than the macbook pro 16 m3 max. In the wifi test also run at 150 cd/m² the m3 run for 16 hours, the asus 8. ( https://www.notebookcheck.net/Asus-ProArt-P16-laptop-review-... )

For me noise matters, that Asus has a whisper mode which produces 42db as much as an M3 max under full load. Please be aware that if you're susceptible of PWM, that ASUS laptop has issues.