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

AMD claims Arm ISA doesn't offer efficiency advantage over x86

techpowerup.com

Post reply on HN
Print view View original

321–330 of 446 posts

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#321

Post by sylware »

RISC-V has no PI lock like ARM or x86 and x86_64.

RISC-V has to start to seriously defend itself, because it is a death sentence for ARM ISA and and could start to cast shadows on x86_64 in some areas slowly but surely. Some people will try to bring it down, hard.

If you stick to core rva22+ (core RISC-V ISA), RISC-V is good enough to replace all of them, without PI lock, and with a global standard ISA, software may have a chance to get out of the horrible mess it is currently in (a lot of critical software code path may end up assembly written... no compiler lock-in, extremely hard to do planned obsolescence, etc).

RISC-V is basically ARM ISA without PI lock.

I have been writting RISC-V assembly running on x86_64 with an interpreter for much of my software projects. It is very pleasant to code using it (basic assembler: no pseudo-instructions, I don't even use the compressed instructions).

I hope to get my hands on RISC-V performant implementations on near state-of-the-art silicon process some day (probably a mini-server, for all the self hosted stuff).

The 'silicon market' is saturated then it is amazing what the RISC-V supporters have been able to achieve. There will be mistakes (some probably big), before implementations do stabilize in the various domains (desktop/server/embedded/mobile/etc), and expect the others to press hard on them.

The next step for RISC-V would be a GPU ISA, and for RVAX, a standard hardware GPU programming interface... but it may be still too early for that since we kind of still don't know if we reach 'the sweet spot'.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#322

Post by bob1029 »

Theoretically x86 could be more efficient in terms of instruction caches and memory bandwidth, but it doesn't seem like this would be very substantial in most use cases. I'm not aware of many hot path instruction streams that are so complex that caches and interconnects are getting saturated.

Moving instructions to the decoder is way more expensive than actually decoding them. The factor is insane once you get to DRAM. But, it doesn't seem all that relevant in practice.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#323

Post by whatagreatboy »

jorvi wrote: post #224
torginus wrote: post #18

Earlier quoted context omitted.

I remember reading this Jim Keller interview: https://web.archive.org/web/20210622080634/https://www.anand... Basically the gist of it is that the difference between ARM/x86 mostly boils down to instruction decode, and: - Most instructions end up being simple load/store/conditional branch etc. on both architectures, where there's literally no difference in encoding efficiency - Variable length instruction has pretty…

Nice followup to your link: https://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter . Personally I do not entirely buy it. Intel and AMD have had plenty of years to catch up to Apple's M-architecture and they still aren't able to touch it in efficiency. The PC Snapdragon chips AFAIK also offer better performance-per-watt than AMD or Intel, with laptops offering them often having 10-30% longer battery life at simila…

Even Jim Keller says that instruction decode is the difference, and that saves a lot of battery for ARM even if it doesn't change the core efficiency at full lot.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#324

Post by whizzter »

exmadscientist wrote: post #247
jorvi wrote: post #224

Earlier quoted context omitted.

Nice followup to your link: https://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter . Personally I do not entirely buy it. Intel and AMD have had plenty of years to catch up to Apple's M-architecture and they still aren't able to touch it in efficiency. The PC Snapdragon chips AFAIK also offer better performance-per-watt than AMD or Intel, with laptops offering them often having 10-30% longer battery life at simila…

Yes, Intel/AMD cannot match Apple in efficiency. But Apple cannot beat Intel/AMD in single-thread performance. (Apple marketing works very hard to convince people otherwise, but don't fall for it.) Apple gets very, very close, but they just don't get there. (As well, you might say they get close enough for practical matters; that might be true, but it's not the question here.) That gap, however small it might be for…

It's the gaming/HPC focus, sure you can achieve some stunning benchmark numbers with nice vectorized straightforward code.

In the real world we have our computers running JIT'ed JS, Java or similar code taking up our cpu time, tons of small branches (mostly taken the same way and easily remembered by the branch predictor) and scattering reads/writes all over memory.

Transistors not spent on larger branch prediction caches or L1 caches are badly spent, doesn't matter if the CPU can issue a few less instructions per clock to ace an benchmark if it's waiting for branch mispredictions or cache misses most of the time.

There's no coincidence that the Apple teams iirc are partly the same people that built Pentium-M (that begun the Core era by delivering very good perf on mobile chips when P4 was supposed to be the flagship).

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#325

Post by dwattttt »

boxed wrote: post #309
ben-schaaf wrote: post #263

Earlier quoted context omitted.

> Personally I do not entirely buy it. Intel and AMD have had plenty of years to catch up to Apple's M-architecture and they still aren't able to touch it in efficiency. The PC Snapdragon chips AFAIK also offer better performance-per-watt than AMD or Intel, with laptops offering them often having 10-30% longer battery life at similar performance. Do not conflate battery life with core efficiency. If you want to measu…

He said "per watt", that's still true. You just talked about max throughput, which no one is discussing.

> The latest AMD under full load uses the same power as M1 and is faster, thus it has better performance per watt.

He also said per watt. An AMD CPU running at full power and then stopping will use less battery than an M1 with the same task; that's comparing power efficiency.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#326

Post by cylemons »

KingOfCoders wrote: post #271
mort96 wrote: post #26

Earlier quoted context omitted.

I have absolutely no doubt in my mind that if Apple's CPU engineers got half a decade and a mandate from the higher ups, they could make an amazing amd64 chip too.

What you have to understand, these are all the same people.

Dont high profile designers have strong anticompetes?

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#327

Post by mrheosuper »

MBCook wrote: post #212
kragen wrote: post #88

Earlier quoted context omitted.

What if the kernel handled unimplemented instruction faults by migrating the process to a core that does implement the instruction and restarting the faulting instruction?

What if that core isn’t free? What if it’s not going to be free for a long time? That could be a recipe for random long stalls for some processes.

> What if that core isn’t free

Just context switch it, like how you run 2 programs with single core cpu

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#328

Post by txrx0000 »

jlei523 wrote: post #288
txrx0000 wrote: post #198

It's not the ISA. Modern Macbooks are power-efficient because they have: - RAM on package - PMIC power delivery - Better power management by OS Geekerwan investigated this a while ago, see: https://www.youtube.com/watch?v=Z0tNtMwYrGA https://www.youtube.com/watch?v=b3FTtvPcc2s https://www.youtube.com/watch?v=ymoiWv9BF7Q Intel and AMD have implemented these improvements with Lunar Lake and Strix Halo. You can buy an x…

Intel and AMD have implemented these improvements with Lunar Lake and Strix Halo. You can buy an x86 laptop with Macbook-like efficiency right now if you know which SoCs to pick. This just isn't true. Yes, Lunar Lake has great idle performance. But if you need to actually use the CPU, it's drastically slower than M4 while consuming more power. Strix Halo battery life and efficiency is not even in the same ball park.

If you look the battery life benchmarks they did at around the 5:00 mark in the third video, you can see that it achieves similar battery life compared to the an M3 Macbook in typical day-to-day use. This reflects the experience most users will have with the device.

It's true that the perf/watt is still a lot worse than the latest gen M4 under heavy load, but it's close enough to the M1 and significantly better than prior laptops chips on x86.

It is a first gen product like the M1. But it does show the ISA is not as big of a limiting factor as popularly believed.

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#329

Post by petrichorko »

ben-schaaf wrote: post #263
jorvi wrote: post #224

Earlier quoted context omitted.

Nice followup to your link: https://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter . Personally I do not entirely buy it. Intel and AMD have had plenty of years to catch up to Apple's M-architecture and they still aren't able to touch it in efficiency. The PC Snapdragon chips AFAIK also offer better performance-per-watt than AMD or Intel, with laptops offering them often having 10-30% longer battery life at simila…

> Personally I do not entirely buy it. Intel and AMD have had plenty of years to catch up to Apple's M-architecture and they still aren't able to touch it in efficiency. The PC Snapdragon chips AFAIK also offer better performance-per-watt than AMD or Intel, with laptops offering them often having 10-30% longer battery life at similar performance. Do not conflate battery life with core efficiency. If you want to measu…

To me it's not as simple as comparing the efficiency under full load. I imagine the efficiency on x86 as some kind of log curve, which translates to higher power consumption even on lighter loads. Apple's ARM implementation tends to eat a lot less power on tasks that happen most of the time, hence greatly improving the battery life.

I've tried a Ryzen 7 that had a similar efficiency to an M1 according to some tests, and that thing ran hot like crazy. Its just marketing bullshit to me now..

Re: AMD claims Arm ISA doesn't offer efficiency advantage over x86

#330

Post by dzaima »

newpavlov wrote: post #131
codedokode wrote: post #126

Earlier quoted context omitted.

What choices? The main thing that comes to mind is lack of exceptions on integer overflow but you are unlikely meaning this.

- Handling of misaligned loads/stores: RISC-V got itself into a weird middle ground, ops on misaligned pointers may work fine, may work "extremely slow", or cause fatal exceptions (yes, I know about Zicclsm, it's extremely new and only helps with the latter, also see https://github.com/llvm/llvm-project/issues/110454 ). Other platforms either guarantee "reasonable" performance for such operations, or forbid misaligne…

Another bad choice (perhaps more accurately called a bug, but they chose to not do anything about it): vmv1.r & co (aka whole-vector-register move instructions) depend on valid vtype being set, despite not using any part of it (outside of the extreme edge-case of an interrupt happening in the middle of it, and the hardware wanting to chop the operation in half instead of finishing it (entirely pointless for application-class CPUs where VLEN isn't massive enough for that to in any way be useful; never mind moves being O(1) with register renaming))

So to move one vector register to another, you need to have a preceding vsetvl; worse, with the standard calling convention you may get illegal vtype after a function call! Even worse, the behavior is actually left reserved for for move with illegal vtype, so hardware can (and some does) just allow it, thereby making it impossible to even test for on some hardware.

Oh, and that thing about being able to stop a vector instruction midway through? You might think that's to allow guaranteeing fast interrupts while keeping easy forwards progress; but no, vector reductions cannot be restarted.. And there's the extremely horrific vfredosum[1], which is an ordered float sum reduction, i.e. a linear chain of N float adds, i.e. a (fp add latency) * (element count in vector) -cycle op that must be started completely over again if interrupted.

[1]: https://dzaima.github.io/intrinsics-viewer/#0q1YqVbJSKsosTtY...

Post reply on HN