Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD's Strix Point: Zen 5 Hits Mobile

chipsandcheese.com

Post reply on HN
Print view View original

121–130 of 241 posts

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

#121

Post by hajile »

dzaima wrote: post #99
hajile wrote: post #83

Earlier quoted context omitted.

1. Why would you WANT to hit 5+GHz when the downsides of exponential power take over? High clocks aren't a feature -- they are a cope. AMD/Intel maintain I-cache and maintain a uop cache kept in sync. Using a tiny part to pre-decode is different from a massive uop cache working as far in advance as possible in the hopes that your loops will keep you busy enough that your tiny 4-wide decoder doesn't become overwhelmed…

> My favorite absurdity of x86 (though hardly the only one) is padding. You want to align function calls at cacheline boundaries, but that means padding the previous cache line with NOPs. Those NOPs translate into uops though. I'd call that more neat than absurd. > You may want it so you can use 16 registers, but it also increases code size. RISC-V has the exact same issue, some compressed instructions having only 3…

RISC-V has a different version of this issue that is pretty straight-forward. Preferring 2-register operations is already done to save register space. The only real extra is preferring the 8 registers C uses for math. After this, it's all just compression.

x86 has a multitude of other factors than just compression. This is especially true with standard vs REX instructions because most of the original 8 instructions have specific purposes and instructions that depend on them for these (eg, Accumulator instructions with A register, Mul/div using A+D, shift uses C, etc). It's a problem a lot harder than simple compression.

Just as cracking an alphanumeric password is exponentially harder than a same-length password with numbers only, solving for all the x86 complications and exceptions is also exponentially harder.

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

#122

Post by AnthonyMouse »

hajile wrote: post #61
cyp0633 wrote: post #51

Earlier quoted context omitted.

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

I stacked the deck in AMD's favor using a 3-year-old chip on an older node. Why is AMD using 3.6x more power than M1 to get just 32% higher performance while having 17% more cores? Why are AMD's cores nearly 2x the size despite being on a better node and having 3 more years to work on them? Why are Apple's scores the same on battery while AMD's scores drop dramatically? Apple does have a reason not to run at 120w --…

> I stacked the deck in AMD's favor using a 3-year-old chip on an older node.

You could just compare the ones that are actually on the same process node:

https://www.notebookcheck.net/R9-7945HX3D-vs-M2-Max_15073_14...

But then you would see an AMD CPU with a lower TDP getting higher benchmark results.

> Why is AMD using 3.6x more power than M1 to get just 32% higher performance while having 17% more cores?

Getting 32% higher performance from 17% more cores implies higher performance per core.

The power measurements that site uses are from the plug, which is highly variable to the point of uselessness because it takes into account every other component the OEM puts into the machine and random other factors like screen brightness, thermal solution and temperature targets (which affects fan speed which affects fan power consumption) etc. If you measure the wall power of a system with a discrete GPU that by itself has a TDP >100W and the system is drawing >100W, this tells you nothing about the efficiency of the CPU.

AMD's CPUs have internal power monitors and configurable power targets. At full load there is very little light between the configured TDP and what they actually use. This is basically required because the CPU has to be able to operate in a system that can't dissipate more heat than that, or one that can't supply more power.

> Meanwhile, if AMD used the same 33w, nobody would buy their chips because performance would be so incredibly bad.

33W is approximately what their mobile CPUs actually use. Also, even lower-configured TDP models exist and they're not that much slower, e.g. the 7840U has a base TDP of 15W vs. 35W for the 7840HS and the difference is a base clock of 3.3GHz instead of 3.8GHz.

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

#123

Post by izacus »

sofixa wrote: post #94
Filligree wrote: post #18

Earlier quoted context omitted.

Ryzen mobile is consistently close, yeah. But with the sole exception of the Steam deck, I've yet to see a Ryzen mobile-bearing laptop, Windows included, which is close to the overall performance of the Macbook.

Depends on what you mean by "overall performance", but my Asus ROG Zephyrus G14 2023 is full AMD, and outperforms my work issued top of the line M1 MacBook Pro from a few months earlier in every task I've done across the two (gaming, compiling, heavy browsing). Battery life is lower under heavy load and high performance on the Zephyrus, but in power saving mode it's roughly comparable, albeit still worse.

Same here, my G14 and the M1 MBP are pretty much interchangeable for most workloads. The only time then G14 starts fans is when the 4070 turns on... and that's not an option on the M1 at all.

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

#124

Post by AnthonyMouse »

acdha wrote: post #46
cubefox wrote: post #38

Earlier quoted context omitted.

> Our benchmark database shows the Dimensity 9300 scores 2,207 and 7,408 in Geekbench 6.2's single and multi-core tests. A 30% performance improvement implies the Dimensity 9400 would score around 2,869 and and 9,630. Its single-core performance is close to that of the Snapdragon 8 Gen 4 (2,884/8,840) and it understandably takes the lead in multi-core. Both are within spitting distance from the Apple A17 Pro, which s…

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…

> for example, the M2 shipped on TSMC’s N5P first as an exclusive but when Zen 5 shipped later on the same process it didn’t close the single core performance or perf/watt gap.

That was Zen 4, but it did close the gap:

https://www.notebookcheck.net/R9-7945HX3D-vs-M2-Max_15073_14...

Single thread performance is higher (so is MT), TDP is slightly lower, Cinebench MT "points per watt" is 5% higher.

We'll get to see it again when the 3nm version of Zen5 is released (the initial ones are 4nm, which is a node Apple didn't use).

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

#125

Post by jeswin »

aurareturn wrote: post #65

One of these has to be true (or both true): 1. ARM is inherently more efficient than x86 CPUs in most tasks 2. Nuvia and Apple are better CPU designers than AMD and Intel Here are results from Notebookcheck: Cinebench R24 ST perf/watt * M3: 12.7 points/watt * X Elite: 9.3 points/watt * AMD HX 370: 3.74 points/watt * AMD 8845HS: 3.1 points/watt * Intel 155H: 3.1 points/watt In ST, Apple is 3.4x more efficient than Zen…

In the same article, if you picked their R23 benchmarks the advantage vanishes in MT benchmarks; the 3nm M3 Max is actually behind 4nm Strix Point in efficiency.

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

#126

Post by AnthonyMouse »

thecompilr wrote: post #120
AnthonyMouse wrote: post #119

Earlier quoted context omitted.

"Thin and fanless" aren't that hard, just use any low power CPU. But then people also want fast. Apple does this by buying out TSMC's capacity for the latest process nodes and then taking the performance/efficiency trade off in favor of efficiency, so they get something with similar performance and lower power consumption. But then they charge you $400 for $50 worth of RAM and solder it so you can't upgrade it yourse…

The M1 was made on 5nm which have long been available to AMD and other competitors in volume.

Fast is relative. The Ryzen HX 370 has a TDP configurable down to 15W and at that power level it could be run fanless and would be faster than the M1, but it's still faster yet if you give it 54W and raise the clock speed.

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

#127

Post by janwas »

camel-cdr wrote: post #115
janwas wrote: post #100

Earlier quoted context omitted.

> it's a matter of the wrong configuration unlike x86 where it is a matter of the wrong instruction +1 to dzaima's mention of vrgather. The lack of fixed-pattern shuffle instructions in RVV is absolutely a wrong-instruction issue. I agree with your point that multiple code variants + runtime dispatch are helpful. We do this with Highway in particular for x86. Users only write code once with portable intrinsics, and t…

> +1 to dzaima's mention of vrgather. The lack of fixed-pattern shuffle instructions in RVV is absolutely a wrong-instruction issue. What others would you want? Something like vzip1/2 would make sense, but that isn't much of an permutation, since the input elements are exctly next to the output elements.

Going through Highway's set of shuffle ops:

64-bit OddEven/Reverse2/ConcatOdd/ConcatEven, OddEvenBlocks, SwapAdjacentBlocks, 8-bit Reverse, CombineShiftRightBytes, TableLookupBytesOr0 (=PSHUFB) and Broadcast especially for 8-bit, TwoTablesLookupLanes, InsertBlock, InterleaveLower/InterleaveUpper (=vzip1/2).

All of these are considerably more expensive on RVV. SVE has a nice set, despite also being VL-agnostic.

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

#128

Post by dzaima »

janwas wrote: post #108
dzaima wrote: post #106

Earlier quoted context omitted.

How does avl affect register renaming? (there's the edge-case of vl=0 that is horrifically stupid (which is by itself a mistake for which I have seen no justification but whatever) but that's probably not what you're thinking of?) Agnostic mode makes it pretty simple for hardware to do whatever it wants. Over masks it has the benefit of allowing simple hardware short-circuiting, though I'd imagine it'd be cheap enoug…

Was thinking of a shorter avl producing partial results merged into another reg. Something like a += b; a[0] += c[0]. Without avl we'd just have a write-after-write, but with it, we now have an additional input, and whether this happens depends on global state (VL). Espasa discusses this around 6:45 of https://www.youtube.com/watch?v=WzID6kk8RNs . Agree agnostic would help, but the machine also has to handle SW askin…

> Agree agnostic would help, but the machine also has to handle SW asking for mask/tail unchanged, right?

The agnosticness flags can be forwarded at decode-time (at the cost of the non-immediate-vtype vsetvl being very slow), so for most purposes it could be as fast as if it were a bit inside the vector instruction itself. Doesn't help vl=0 though.

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

#129

Post by dzaima »

camel-cdr wrote: post #114
janwas wrote: post #108

Earlier quoted context omitted.

Was thinking of a shorter avl producing partial results merged into another reg. Something like a += b; a[0] += c[0]. Without avl we'd just have a write-after-write, but with it, we now have an additional input, and whether this happens depends on global state (VL). Espasa discusses this around 6:45 of https://www.youtube.com/watch?v=WzID6kk8RNs . Agree agnostic would help, but the machine also has to handle SW askin…

> Agree agnostic would help, but the machine also has to handle SW asking for mask/tail unchanged, right? Yes, but it should rarely do so. The problem is that because of the vl=0 case you always have a dependency on avl. I think the motivavtion for the vl=0 case was that any serious ooo implementation will need to predict vl/vtype anyways, so there might as well be this nice to have feature. IMO they should've only s…

What's the "nice to have feature" of vl=0 not modifying registers? I can't see any benefit from it. If anything, it's worse, due to the problems on reduce and vmv.s.x.

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

#130

Post by aurareturn »

jeswin wrote: post #125
aurareturn wrote: post #65

One of these has to be true (or both true): 1. ARM is inherently more efficient than x86 CPUs in most tasks 2. Nuvia and Apple are better CPU designers than AMD and Intel Here are results from Notebookcheck: Cinebench R24 ST perf/watt * M3: 12.7 points/watt * X Elite: 9.3 points/watt * AMD HX 370: 3.74 points/watt * AMD 8845HS: 3.1 points/watt * Intel 155H: 3.1 points/watt In ST, Apple is 3.4x more efficient than Zen…

In the same article, if you picked their R23 benchmarks the advantage vanishes in MT benchmarks; the 3nm M3 Max is actually behind 4nm Strix Point in efficiency.

Cinebench R23 is hand optimized for X86. It uses Intel Embree engine underneath.

That's why Cinebench R23 heavily favors x86.

Post reply on HN