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

141–150 of 241 posts

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

#141

Post by hajile »

dzaima wrote: post #105
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.…

Expanding on 3: I think it ends up at O(n^2 * log n) transistors, O(log n) critical path (not sure on routing or what fan-out issues might there be). Basically: determine end of instruction at each byte (trivial but expensive). Determine end of two instructions at each byte via end2[i]=end[end[i]]. Then end4[i]=end2[end2[i]], etc, log times. That's essentially log(n) shuffles. With 32-byte/cycle decode that's roughy…

Determining the end of a RISC-V instruction requires checking two bits and you have the knowledge that no instruction exceeds 4 bytes or uses less than 2 bytes.

x86 requires checking for a REX, REX2, VEX, EVEX, etc prefix. Then you must check for either 1 or 2 instruction bytes. Then you must check for the existence of a register byte, how many immediate byte(s), and if you use a scaled index byte. Then if a register byte exists, you must check it for any displacement bytes to get your final instruction length total.

RISC-V starts with a small complexity then multiplies it by a small amount. x86 starts with a high complexity then multiplies it by a big amount. The real world difference here is large.

As I pointed out elsewhere ARM's A715 dropped support for aarch32 (which is still far easier to decode than x86) and cut decoder size by 75% while increasing raw decoder count by 20%. The decoder penalties of bad ISA design extend beyond finding instruction boundaries.

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

#142

Post by nightski »

jml7c5 wrote: post #56

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 d…

I don't mind fans at all, in fact I find fan noises a little soothing (a childhood thing, we didn't have AC). Everyone has different priorities, personally I'd prefer to not have throttled performance.

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

#143

Post by sandreas »

jml7c5 wrote: post #56

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 d…

Did you know NBFC (Notebook Fan Control)? It's old, but still works on some devices and you can create custom profiles via XML.

https://github.com/hirschmann/nbfc

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

#144

Post by dzaima »

hajile wrote: post #141
dzaima wrote: post #105

Earlier quoted context omitted.

Expanding on 3: I think it ends up at O(n^2 * log n) transistors, O(log n) critical path (not sure on routing or what fan-out issues might there be). Basically: determine end of instruction at each byte (trivial but expensive). Determine end of two instructions at each byte via end2[i]=end[end[i]]. Then end4[i]=end2[end2[i]], etc, log times. That's essentially log(n) shuffles. With 32-byte/cycle decode that's roughy…

Determining the end of a RISC-V instruction requires checking two bits and you have the knowledge that no instruction exceeds 4 bytes or uses less than 2 bytes. x86 requires checking for a REX, REX2, VEX, EVEX, etc prefix. Then you must check for either 1 or 2 instruction bytes. Then you must check for the existence of a register byte, how many immediate byte(s), and if you use a scaled index byte. Then if a register…

I don't disagree that the real-world difference is massive; that much is pretty clear. I'm just pointing out that, as far as I can tell, it's all just a question of a constant factor, it's just massive. I've written half of a basic x86 decoder in regular imperative code, handling just the baseline general-purpose legacy encoding instructions (determines length correctly, and determines opcode & operand values to some extent), and that was already much.

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

#145

Post by Const-me »

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 --…

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

I’m writing this comment on HP ProBook 445 G8 laptop. I believe I bought it in early 2022, so it's a relatively old model. The laptop has a Ryzen 5 5600U processor which uses ≤ 25W. I’m quite happy with both the performance and battery life.

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

#146

Post by [deleted] »

hajile wrote: post #75
pickledish wrote: post #69

Earlier quoted context omitted.

You should try not to talk so confidently about things you don't know about -- this statement > if AMD used the same 33w, nobody would buy their chips because performance would be so incredibly bad Is completely incorrect, as another commenter (and I think the notebookcheck article?) point out -- 30w is about the sweet spot for these processors, and the reason that 110w laptop seems so inefficient is because it's giv…

Halo products with high scores sell chips. This isn’t a new idea. So you lower the wattage down. Now you’re at M1 Pro levels of performance with 17% more cores and nearly double the die area and barely competing with a chip 3 years older while on a newer, more expensive node too. That’s not selling me on your product (and that’s without mentioning the worst core latency I’ve seen in years when going between P and C c…

[deleted]

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

#147

Post by hajile »

dzaima wrote: post #131
hajile wrote: post #121

Earlier quoted context omitted.

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 h…

If anything, I'd say x86's fixed operands make register allocation easier! Don't have to register-allocate that which you can't. (ok, it might end up worse if you need some additional 'mov's. And in my experience more 'mov's is exactly what compilers often do.) And, right, RISC-V even has the problem of being two-operand for some compressed instructions. So the same register allocation code that's gone towards x86 ca…

With 16 registers, you can't just avoid a register because it has a special use. Instead, you must work to efficiently schedule around that special use.

Lack of special GPRs means you can rename with impunity (this will change slightly with the load/store pair extension). Having 31 truly GPR rather than 8 GPR+8 special GPR also gives a lot of freedom to compilers.

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

#148

Post by rafaelmn »

hajile wrote: post #136
rafaelmn wrote: post #91

Earlier quoted context omitted.

That's what I'm thinking - they make trade-offs to reach peak performance in desktop designs that don't translate optimally to laptops and when you start from mobile designs you probably made the opposite trade-offs - that would be my guess for the discrepancy.

Laptops vastly outsell desktops, so this tradeoff means hurting the majority of your customers to please a small minority. Servers also care about perf/watt a LOT and they are the highest profit margin segment. Why would AMD choose a target that hurts the majority of their market unless there wasn't another good option available?

The architecture started in desktop space and data center/mobile was an afterthought up until Intel shitting the bed repeatedly. If they redesigned from ground up they could probably get better instructions/watt but that would look terrible if it wasn't accompanied by a perf boost over previous generation. Just like Apple doesn't seem to scale well with more power.

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

#149

Post by dzaima »

hajile wrote: post #147
dzaima wrote: post #131

Earlier quoted context omitted.

If anything, I'd say x86's fixed operands make register allocation easier! Don't have to register-allocate that which you can't. (ok, it might end up worse if you need some additional 'mov's. And in my experience more 'mov's is exactly what compilers often do.) And, right, RISC-V even has the problem of being two-operand for some compressed instructions. So the same register allocation code that's gone towards x86 ca…

With 16 registers, you can't just avoid a register because it has a special use. Instead, you must work to efficiently schedule around that special use. Lack of special GPRs means you can rename with impunity (this will change slightly with the load/store pair extension). Having 31 truly GPR rather than 8 GPR+8 special GPR also gives a lot of freedom to compilers.

Function arguments and return values already are effectively special use, and should frequently be on par if not much more frequent than the couple x86 instructions with fixed registers.

Both clang and gcc support calls having differing used calling conventions within one function, which ends up effectively exactly identical to fixed-register instructions (i.e. an x86 'imul r64' can be done via a pseudo-function where the return values are in rdx & rax, an input is in rax, and everything else is non-volatile; and the dynamically-choosable input can be allocated separately). And '__asm__()' can do mixed fixed and non-fixed registers anyway.

Post reply on HN