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

231–240 of 446 posts

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

#231

Post by monocasa »

mohinder wrote: post #184
rasz wrote: post #107

Earlier quoted context omitted.

Not a lot is not how I would describe it. Take a 64bit piece of fetched data. On ARM64 you will just push that into two decoder blocks and be done with it. On x86 you got what, 1 to 15 bytes range per instruction? I dont even want to think about possible permutations, its in the 10 ^ some two digit number order.

You don't need all the permutations. If there are 32 bytes in a cache line then each instruction can only start at one of 32 possible positions. Then if you want to decode N instructions per cycle you need N 32-to-1 muxes. You can reduce the number of inputs to the later muxes since instructions can't be zero size.

It was even simpler until very recently where the decode stage would only look at a max 16 byte floating window.

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

#232

Post by monocasa »

adgjlsfhk1 wrote: post #175
newpavlov wrote: post #131

Earlier quoted context omitted.

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

> - The hardcoded page size. I'm pretty confident that this will get removed. It's an extension that made it's way into RVA23, but once anyone has a design big enough for it to be a burden, it can be dropped.

That's really hard to drop.

Fancier unix programs tend to make all kinds of assumptions about page size to do things like the double mapped ring buffer trick.

https://en.wikipedia.org/wiki/Circular_buffer#Optimization

In fact it looks like apple silicon maintains support for 4kb pages just for running Rosetta. It's one of those things like TSO that was enough of a pain to work around the assumptions that they just included hardware support for it that isn't enabled when running in regular arm software mode.

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

#233

Post by Joel_Mckay »

pezezin wrote: post #178

After playing around with some ARM hardware I have to say that I don't care whether ARM is more efficient or not as long as the boot process remains the clusterfuck that it is today. IMHO the major win of the IBM PC platform is that it standardized the boot process from the very beginning, first with the BIOS and later with UEFI, so you can grab any random ISO for any random OS and it will work. Meanwhile in the ARM…

In general, most modern ARM 8/9 64bit SoC purged a lot of the vestigial problems.

Yet most pre-compiled package builds still never enable the advanced ASIC features for compatibility and safety-concerns. AMD comparing the NERF'd ARM core features is pretty sleazy PR.

Tegra could be a budget Apple M3 Pro, but those folks chose imaginary "AI" money over awesomeness. =3

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

#234

Post by cesarb »

ack_complete wrote: post #206
newpavlov wrote: post #131

Earlier quoted context omitted.

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

> Detection of available extensions: we usually have to rely on OS to query available extensions since the `misa` register is accessible only in machine mode. Not a RISC-V programmer, but this drives me crazy on ARM. Dozens of optional features, but the FEAT_ bits are all readable only from EL1, and it's unspecified what API the OS exposes to query it and which feature bits are exposed. I don't care if it'd be slow,…

> but the FEAT_ bits are all readable only from EL1, [...] I don't care if it'd be slow, just give us the equivalent of a dedicated CPUID instruction, even if it just a reserved opcode that traps to kernel mode and is handled in software.

I like the way the Linux kernel solves this: these FEAT_ bits are also readable from EL0, since trying to read them traps to kernel mode and the read is emulated by the kernel. See https://docs.kernel.org/arch/arm64/cpu-feature-registers.htm... for details. Unfortunately, it's a Linux-only feature, and didn't exist originally (so old enough Linux kernel versions won't have the emulation).

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

#236

Post by gigatexal »

addaon wrote: post #125
Jensson wrote: post #96

Earlier quoted context omitted.

Basically yeah, if you compare CPU from same fab then its basically the same. Its just Apple buys next gen fabs while AMD and intel has to be on last gen, so the M computers people compare are always one fab gen ahead. It has very little to do with CPU architecture. They do have some cool stuff about their CPU, but the thing most laud them for has to do with fabs.

There's another difference -- willingness to actually pay for silicon. The M1 Max is a 432 mm^2 laptop chip built on a 5 nm process. Contrast that to AMD's "high end" Ryzen 7 8845HS at 178 mm^2 on a 4 nm process. Even the M1 Pro at 245 mm^2 is bigger than this. More area means not just more peak performance, but the ability to use wider paths at lower speeds to maintain performance at lower power. 432 mm^2 is friggin…

True the M1 Pro and Max chips were capable of 200GB/s and 400GB/s of bandwidth between the chip and the integrated memory. No desktop chips had such at the time I think.

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

#237

Post by [deleted] »

tester756 wrote: post #140
rafaelmn wrote: post #136

Earlier quoted context omitted.

C# syntax is faster than Java because Java has no way to define custom value types/structs (last time I checked, I know there was some experimental work on this)

and yet there's more Java in HFT than C# And don't get me wrong, I'm C# fanboi that'd never touch Java, but JVM itself is impressive as hell, so even despite not having (yet) value types/structs, Java is still very strong due to JVM (the implementation). Valhalla should push it even further.

[deleted]

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

#238

Post by achandlerwhite »

p_ing wrote: post #221
acdha wrote: post #180

Earlier quoted context omitted.

It’s all of the above. One thing Apple excels at is actually using their hardware and software together whereas the PC world has a long history of one of the companies like Intel, Microsoft, or the actual manufacturer trying to make things better but failing to get the others on-board. You can in 2025 find people who disable power management because they were burned (hopefully not literally) by some combination of ve…

Windows 10 introduced memory compression. Here's a discussion from 2015 [0]. And one on Linux by IBM from 2013 [1]. But the history goes way back [2]. I don't know why that '8GiB is great!' -- no, no it isn't. Your memory usage just spills over to swap faster. It isn't more efficient (not with those 16KiB pages). [0] https://learn.microsoft.com/en-us/shows/Seth-Juarez/Memory-C... [1] https://events.static.linuxfound.…

He didn’t say 8 gigs is great but that you can get by with about 8 gigs less than equivalent on Windows.

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

#239

Post by gigatexal »

Jensson wrote: post #123
gigatexal wrote: post #113

Earlier quoted context omitted.

Man that either hella discounts all the amazing work Apple’s CPU engineers are doing or hyping up what AMD’s have done. Idk

Isn't it you who is hyping up Apple here when you don't even compare the two using similar architecture? Compare a 5nm AMD laptop low power cpu to Apple M1 and the M1 no longer looks that much better at all.

Why are we talking about the M1 that came out eons (in computer time) ago? That the M1 is a benchmark is just sad when the M4 is running circles around competing x86 processors and the M5 is on the horizon which who knows what that has in store.

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

#240

Post by diddid »

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…

I mean the M1 is nice but pretending that it can do in 110w what the 3090 does with 320w is Apple marketing nonsense. Like if your use case is playing games like cp2077, the 3090 will do 100fps in ultra ray tracing and an M4 Max will only do 30fps. Not to mention it’s trivial to undervolt nvidia cards and get 100% performance at 80% power. So 1/3 the power for 1/3 the performance? How is that smoking anything?
Post reply on HN