16 ms·
AMD claims Arm ISA doesn't offer efficiency advantage over x86
- exmadscientist 1y agoThis is an entirely uncontroversial take among experts in the space. x86 is an old CISC-y hot mess. RISC-V is a new-school hyper-academic hot mess. Recent ARM is actually pretty good. And none of it matters, because the uncore and the fabrication details (in particular, whether things have been tuned to run full speed demon or full power sipper) completely dominate the ISA. In the past x86 didn't dominate in low power because Intel had the resources to care but never did, and AMD never had the resources to try. Other companies stepped in to full that niche, and had to use other ISAs. (If they could have used x86 legally, they might well have done so. Oops?) That may well be changing. Or perhaps AMD will let x86 fade away.
- mananaysiempre 1y ago> x86 didn't dominate in low power because Intel had the resources to care but never did Remember Atom tablets (and how they sucked)?
- YetAnotherNick 1y ago> how they sucked Care to elaborate. I had the 9" mini laptop kind of device based on Atom and don't remember Atom to be the issue.
- mananaysiempre 1y agoI had a Atom-based netbook (in the early days when they were 32-bit-only and couldn’t run up-to-date Windows). It didn’t suck, as such, but it was definitely resource-starved. However, what I meant is Atom-based Android tablets. At about the same time as the netbook craze (late 2000s to early 2010s) there was a non-negligible number of Android tablets, and a noticeable fraction of them was not ARM- but Atom-based. (The x86 target in the Android SDK wasn’t only there to support emulators, originally.) Yet that stopped pretty quickly, and my impression is that that happened because, while Intel would certainly have liked to hitch itself to the Android train, they just couldn’t get Atoms fast enough at equivalent power levels (either at all or quickly enough). Could have been something else, e.g. perhaps they didn’t have the expertise to build SoCs with radios? Either way, it’s not that Intel didn’t want to get into consumer mobile devices, it’s that they tried and did not succeed.
- toast0 1y agoAndroid x86 devices suffer when developers include binary libraries and don't add x86. At the time of Intel's x86 for Android push, Google didn't have good apk thinning options, so app developers had to decide if they wanted to add x86 libraries for everyone so that a handful of tablets/phones would work properly... for the most part, many developers said no; even though many/most apps are tested on the android emulator that runs on x86 and probably have binary libraries available to work in that case. IMHO, If Intel had done another year or two of trying, it probably would have worked, but they gave up. They also canceled x86 for phone like the day before the Windows Mobile Continuum demo, which would have been a potentially much more compelling product with x86, especially if Microsoft allowed running win32 apps (which they probably wouldn't, but the potential would be interesting)
- cptskippy 1y agoAtom used an in-order execution model so it's performance was always going to be lacking. Because it was in-order it had a much simpler decoder and much smaller die size, which meant you could crap the chipset and CPU on a single die. Atom wasn't about power efficiency or performance, it was about cost optimization.
- Synaesthesia 1y agoIt got a lot better. First few generations were dog-slow, although they did work.
- Findecanor 1y agoYou mean Atom tablets running Android ? I have a ten-year old Lenovo Yoga Tab 2 8" Windows tablet, which I still use at least once every week. It is still useful. Who can say that they are still using a ten-year old Android tablet?
- deleted 1y ago[deleted]
- masfuerte 1y agoI still use my 2015 Kindle Fire (which runs Android) for ebooks and light web browsing.
- peterfirefly 1y agoMy iPad Mini 4 turns 10 in a month.
- vt240 1y agoYeah, I got to say in our sound company inventory I still use a dozen 6-10 year old iPads with all the mixers. They run the apps at 30fps and still hold a charge all day.
- criticalfault 1y agoWere they running windows or android?
- wmf 1y agoThat's the point. Early Atom wasn't designed with care but the newer E-cores are quite efficient because they put more effort in.
- Voultapher 1y agoThe PMICs were also bad, plus the whole Windows software stack - to this day - is nowhere nearly as well optimized for low background and sleep power usage as MacOS and iOS are.
- saltcured 1y agoI had an Atom-based Android phone (Razr-i) and it was fine.
- kccqzy 1y agoThey sucked because Intel didn't care.
- mmis1000 1y agoI have tried one before. And surprisingly, It did not suck as most people claimed to be. I can even do light gaming (warframe) on it with reasonable frame rate. (It's about 2015 ~ 2020 era). So it probably depends on manufacturer (or use case though) (Also probably due to it is a tablet, so it have a reasonable fast storage instead of hdds like notebooks in that era)
- jojobas 1y agoEeepc was was a hit. Its successors still make excellent cheap long-life laptops, if not as performant as Apple.
- josefx 1y agoWhat year? I remember Linux gaining some traction in the low end mobile device market early on because Micrsoft just released Vista and that wouldn't even run well on most Vista Ready desktop systems.
- jonbiggums22 1y agoIIRC Intel hobbled early Atom with an ancient process node for the chipsets which actually made up most of the idle power usage. It was pretty clear that both Microsoft and Intel wanted this product category to go away or at least be totally relegated to bottom tier lest it cannibalize their higher margin businesses. And then of course Apple and Android came along and did just that anyway.
- wlesieutre 1y agoVIA used to make low power x86 processors
- yndoendo 1y agoFun fact. The idea of strong national security is the reason why there are three companies with access to the x86 ISA. DoD originally required all products to be sourced by at least three companies to prevent supply chain issues. This required Intel to allow AMD and VIA to produce products based on ISA. For me this is good indicator if someone that talks about good national security knows what they are talking about or are just spewing bullshit and playing national security theatre.
- rasz 1y agoIntel didnt "allow" VIA anything :). Via acquired x86 tech from IDT (WinChip Centaur garbage) in a fire sale. IDT didnt ask anyone about any licenses, neither did Cyrix, NextGen, Transmeta, Rise nor NEC. Afaik DoD wasnt the reason behind original AMD second source license, it was IBM forcing Intel on chips that went into first PC.
- cheema33 1y agoThis.
- pavlov 1y agoAnd Transmeta…
- DeepYogurt 1y agoTransmeta wasn't x86 internally but decoded x86 instructions. Retrobytes did a history of transmeta not too long ago and the idea was essentially to be able to be compatible with any cpu uarch. Alas by the time it shipped only x86 was relevant. https://www.youtube.com/watch?v=U2aQTJDJwd8 https://www.youtube.com/watch?v=U2aQTJDJwd8
- torginus 1y agoI remember reading this Jim Keller interview: https://web.archive.org/web/20210622080634/https://www.anandtech.com/show/16762/an-anandtech-interview-with-jim-keller-laziest-person-at-tesla 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 much been figured out on x86 that it's no longer a bottleneck Also my personal addendum is that today's Intel efficiency cores are have more transistors and better perf than the big Intel cores of a decade ago
- fanf2 1y agoApple’s ARM cores have wider decode than x86 M1 - 8 wide M4 - 10 wide Zen 4 - 4 wide Zen 5 - 8 wide
- wmf 1y agoSkymont - 9 wide
- adgjlsfhk1 1y agopure decoder width isn't enough to tell you everything. X86 has some commonly used ridiculously compact instructions (e.g. lea) that would turn into 2-3 instructions on most other architectures.
- kimixa 1y agoAlso the op cache - if it hits that the decoder is completely skipped.
- ajross 1y agoThe whole ModRM addressing encoding (to which LEA is basically a front end) is actually really compact, and compilers have gotten frightently good at exploiting it. Just look at the disassembly for some non-trivial code sometime and see what it's doing.
- mort96 1y agoThis matches my understanding as well, as someone who has a great deal of interest in the field but never worked in it professionally. CPUs all have a microarchitecture that doesn't look like the ISA at all, and they have an instruction decoder that translates ISA one or more ISA instructions into zero or more microarchitectural instructions. There are some advantages to having a more regular ISA, such as the ability to more easily decode multiple instructions in parallel if they're all the same size or having to spend fewer transistors on the instruction decoder, but for the big superscalar chips we all have in our desktops and laptops and phones, the drawbacks are tiny. I imagine that the difference is much greater for the tiny in-order CPUs we find in MCUs though, just because an amd64 decoder would be a comparatively much larger fraction of the transistor budget
- themafia 1y agoThen there's mainframes. Where you want code compiled in 1960 to run unmodified today. There was quite of original advantage as well as IBM was able to implement the same ISA with three different types and costs of computers.
- astrange 1y agouOps are kind of oversold in the CPU design mythos. They are not that different from the original ISA, and some x86 instructions (like lea) are both complex and natural fits for hardware so don't get microcoded.
- whynotminot 1y agoAn annoying thing people have done since Apple Silicon is claim that its advantages were due to Arm. No, not really. The advantage is Apple prioritizing efficiency, something Intel never cared enough about.
- wvenable 1y agoBy prioritizing efficiency, Apple also prioritizes integration. The PC ecosystem prefers less integration (separate RAM, GPU, OS, etc) even at the cost of efficiency.
- Panzer04 1y agoEh, probably the biggest difference is in the OS. The amount of time Linux or Windows will spend using a processor while completely idle can be a bit offensive.
- acdha 1y agoIt’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 vendors slacking on QA! One good example of this is RAM. Apple Silicon got some huge wins from lower latency and massive bandwidth, but that came at the cost of making RAM fixed and more expensive. A lot of PC users scoffed at the default RAM sizes until they actually used one and realized it was great at ~8GB less than the equivalent PC. That’s not magic or because Apple has some super elite programmers, it’s because they all work at the same company and nobody wants to go into Tim Cook’s office and say they blew the RAM budget and the new Macs need to cost $100 more. The hardware has compression support and the OS and app teams worked together to actually use it well, whereas it’s very easy to imagine Intel adding the feature but skimping on speed / driver stability, or Microsoft trying to implement it but delaying release for a couple years, or not working with third-party developers to optimize usage, etc. – nobody acting in bad faith but just what inevitably happens when everyone has different incentives.
- tliltocatl 1y agoNitpick: uncore and the fabrication details dominate the ISA on high end/superscalar architectures (because modern superscalar basically abstract the ISA away at the frontend). On smaller (i. e. MCU) cores x86 will never stand any chance.
- bpye 1y agoNot that it stopped Intel trying - https://en.m.wikipedia.org/wiki/Intel_Quark https://en.m.wikipedia.org/wiki/Intel_Quark
- epolanski 1y agoI have a hard time believing this fully: more custom instructions, more custom hardware, more heat. How can you avoid it?
- tapoxi 1y agoSince the Pentium Pro the hardware hasn't implemented the ISA, it's converted into micro ops.
- epolanski 1y agoCome on, you know what I meant :) If you want to support AVX e.g. you need 512bit (or 256) wide registers, you need dedicated ALUs, dedicated mask registers etc. Ice Lake has implemented SHA-specific hardware units in 2019.
- adgjlsfhk1 1y agosure, but Arm has Neon/sve which impose basically the same requirements for vector instructions, and most high performance arm implimentations have a wide suite of crypto instructions (e.g. Apple's M series chips have AES, SHA1 and Sha256 instructions)
- camel-cdr 1y agoNeon has it worse, because it's harder to scale issue width then vector length. Zen5 has four issue 512-bit ALUs, current Arm processors have been stuck at four issue 128-bit for years. Issue width scales quadratically, while vector length mostly scales linearly. Intel decided it is easier to rewrite all performance critical applications thrice then to go wider than four issue SIMD. It will have to be seen if Arm is in a position to push software ro adopt SVE, but currently it looks very bleak, with much of the little SVE code thats out there just assuming 128-bit SVE, because thats what all of the hardware is.
- toast0 1y agoARM has instructions for SHA, AES, vectors, etc too. Pretty much have to pay the cost if you want the perf.
- somanyphotons 1y agoI'd love to see what would happen if AMD put out a chip with the instruction decoders swapped out for risc-v instruction decoders
- guerrilla 1y agoIndeed. We don't need it, but I want it for perfectionist aesthetic completion.
- AnotherGoodName 1y agoFwiw the https://en.wikipedia.org/wiki/AMD_Am29000 https://en.wikipedia.org/wiki/AMD_Am29000 RISC CPU and the https://en.wikipedia.org/wiki/AMD_K5 https://en.wikipedia.org/wiki/AMD_K5 are a good example of this. As in AMD took their existing RISC CPU to make the K5 x86 CPU. Almost the same in die shots except the K5 had more transistors for the x86 decoding. The AM29000's instruction set is actually very close to RISC-V too! Very hard to find benchmarks comparing the two directly though.
- throwawaymaths 1y agoTIL the k5 was RISC. thank you
- TheAmazingRace 1y agoIt was a valiant effort by AMD when they made their first attempt at an in-house x86 chip design. Prior to this, AMD effectively cloned Intel designs under license. Sadly, the K5 was pretty underwhelming upon release, and it wasn’t until AMD acquired NexGen and integrated their special sauce into their next version core, the K6, that things started getting interesting. I was quite fond of my old AMD K6 II+ based PC back in the day. It had good value for the money. Then you see the K7/Athlon core, complete with inspiration from the DEC Alpha thanks to none other than Jim Keller, and AMD was on a serious tear for a good while after that, beating Intel to 1 GHz.
- newpavlov 1y ago>RISC-V is a new-school hyper-academic hot mess. Yeah... Previously I was a big fan of RISC-V, but after I had to dig slightly deeper into it as a software developer my enthusiasm for it has cooled down significantly. It's still great that we got a mainstream open ISA, but now I view it as a Linux of the hardware world, i.e. a great achievement, with a big number of questionable choices baked in, which unfortunately stifles other open alternatives by the virtue of being "good enough".
- codedokode 1y agoWhat choices? The main thing that comes to mind is lack of exceptions on integer overflow but you are unlikely meaning this.
- newpavlov 1y ago- 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 https://github.com/llvm/llvm-project/issues/110454). Other platforms either guarantee "reasonable" performance for such operations, or forbid misaligned access with "aligned" loads/stores and provide separate misaligned instructions. Arguably, RISC-V should've done the latter (with misaligned instructions defined in a separate higher-end extension), since passing unaligned pointer into an aligned instruction signals correctness problems in software. - The hardcoded page size. 4 KiB is a good default for RV32, but arguably a huge missed opportunity for RV64. - The weird restriction in the forward progress guarantees for LR/SC sequences, which forces compilers to compile `compare_exchange` and `compare_exchange_weak` in the absolutely same way. See this issue for more information: https://github.com/riscv/riscv-isa-manual/issues/2047 https://github.com/riscv/riscv-isa-manual/issues/2047 - The `seed` CSR: it does not provide a good quality entropy (i.e. after you accumulated 256 bits of output, it may contain only 128 bits of randomness). You have to use a CSPRNG on top of it for any sensitive applications. Doing so may be inefficient and will bloat binary size (remember, the relaxed requirement was introduced for "low-powered" devices). Also, software developers may make mistake in this area (not everyone is a security expert). Similar alternatives like RDRAND (x86) and RNDR (ARM) guarantee proper randomness and we can use their output directly for cryptographic keys with very small code footprint. - Extensions do not form hierarchies: it looks like the AVX-512 situation once again, but worse. Profiles help, but it's not a hierarchy, but a "packet". Also, there are annoyances like Zbkb not being a proper subset of Zbb. - 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. This makes detection quite annoying for "universal" libraries which intend to support various OSes and embedded targets. The CPUID instruction (x86) is ideal in this regard. I totally disagree with the virtualization argument against it, nothing prevents VM from intercepting the read, no one excepts huge performance from such reads. And this list is compiled after a pretty surface-level dive into the RISC-V spec. I heard about other issues (e.g. being unable to port tricky SIMD code to the V extension or underspecification around memory coherence important for writing drivers), but I can not confidently talk about those, so it's not part of my list. P.S.: I would be interested to hear about other people gripes with RISC-V.
- Ianjit 1y agoThis paper is great: "Our methodical investigation demonstrates the role of ISA in modern microprocessors’ performance and energy efficiency. We find that ARM, MIPS, and x86 processors are simply engineering design points optimized for different levels of performance, and there is nothing fundamentally more energy efficient in one ISA class or the other. The ISA being RISC or CISC seems irrelevant." https://dl.acm.org/doi/10.1145/2699682 https://dl.acm.org/doi/10.1145/2699682 https://abdullahyildiz.github.io/files/isa_wars.pdf https://abdullahyildiz.github.io/files/isa_wars.pdf
- jabl 1y ago> Or perhaps AMD will let x86 fade away. I agree with what you write otherwise, but not this. Why would AMD "let x86 fade away"? They are one of the two oligolistic CPU providers of the x86 ecosystem which is worth zillions. Why should they throw that away in order to become yet another provider of ARM (or RISC-V or whatnot) CPUs? I think that as long as the x86 market remains healthy, and AMD is in a position to compete in that market, they will continue doing so.
- jabl 1y ago> oligolistic I meant to write "oligopolistic", of course.
- w4rh4wk5 1y agoOk. When will we get the laptop with AMD CPU that is on par with a Macbook regarding battery life?
- azornathogron 1y agoHow much of the Mac's impressive battery life is due purely to CPU efficiency, and how much is due to great vertical integration and the OS being tuned for power efficiency? It's a genuine question; I'm sure both factors make a difference but I don't know their relative importance.
- SushiHippie 1y agoI just searched for the asahi linux (Linux for M Series Macs) battery life, and found this blog post [0]. > During active development with virtual machines running, a few calls, and an external keyboard and mouse attached, my laptop running Asahi Linux lasts about 5 hours before the battery drops to 10%. Under the same usage, macOS lasts a little more than 6.5 hours. Asahi Linux reports my battery health at 94%. [0] https://blog.thecurlybraces.com/2024/10/running-fedora-asahi-linux-on-an-m1-macbook-pro-16/#Battery_life https://blog.thecurlybraces.com/2024/10/running-fedora-asahi...
- pablok2 1y agoHow much instruction perf analysis do they do to save 1% (compounded) on the most common instructions
- adgjlsfhk1 1y agoit's less that and more all the peripheral things. USB, wifi, bluetooth, ram, random capacitors in the VRM etc.
- ux266478 1y agoThe overwhelming majority is due to the power management software, yes. Other ARM laptops do not get anywhere close to the same battery life. The MNT Reform with 8x 18650s (24000mAh, 3x what you get an MBP) gets about 5h of battery life with light usage.
- SOTGO 1y agoI'd be interested to hear someone with more experience talk about this or if there's more recent research, but in school I read this paper: <https://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-power-struggles.pdf https://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa...> that seems to agree that x86 and ARM as instruction sets do not differ greatly in power consumption. They also found that GCC picks RISC-like instructions when compiling for x86 which meant the number of micro-ops was similar between ARM and x86, and that the x86 chips were optimized well for those RISC-like instructions and so were similarly efficient to ARM chips. They have a quote that "The microarchitecture, not the ISA, is responsible for performance differences."
- astrange 1y ago`lea` is a very common x86 instruction that isn't RISC-like. (Actually I don't think any x86 operations are RISC-like since they're variable length and overwrite their inputs.) It's just that the most complicated of all x86 instructions are so specific that they're too irrelevant to use. Or were straight up removed in x86-64.
- bfrog 1y agoAnd yet... the world keeps proving Intel and AMD wrong on this premise with highly efficient Arm parts. While sure, there's bound to be improvements to make on x86 ultimately its a variable length opcode encoding with a complex decoder path. If nothing else, this is likely a significant issue in comparison to the nicely word aligned op code encoding arm has and surely given apples to apples core designs, the opcode decoding would be a deciding factor.
- tinktank 1y agoPPA results comparing x86 to ARM say otherwise; take a look at Ryzen's embedded series and Intel's latest embedded cores.
- bfrog 1y agoHave they reached apple m level of performance/watt after half a decade of the apple m parts being out yet? Do either AMD or Intel beat Apple in any metric in mobile?
- deleted 1y ago[deleted]
- tinktank 1y agoYes and yes - again, go look at the published results.
- bfrog 1y agoI have, the m4 is significantly ahead by any measure I’ve seen, with snapdragon just behind. https://www.xda-developers.com/tested-apple-m4-vs-intel-lunar-lake-snapdragon-x-elite/ https://www.xda-developers.com/tested-apple-m4-vs-intel-luna...
- Jensson 1y agoThe m4 is not the same fab technology so not comparable. If you want to discuss the validity of some CPU architecture it needs to be between comparable fab technology, M4 being a generation ahead there makes the comparison unfair. If you compare like to like the difference almost completely disappears.
- slimginz 1y agoIIRC There was a Jim Keller interview a few years ago where he said basically the same thing (I think it was from right around when he joined Tenstorrent?). The ISA itself doesn't matter, it's just instructions. The way the chip interprets those instructions is what makes the difference. ARM was designed from the beginning for low powered devices whereas x86 wasn't. If x86 is gonna compete with ARM (and RISC-V) then the chips are gonna need to also be optimized for low powered devices, but that can break decades of compatibility with older software.
- sapiogram 1y agoIt's probably from the Lex Friendman podcast he did. And to be fair, he didn't say "it doesn't matter", he said "it's not that important".
- tester756 1y agohttps://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter https://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter
- BirAdam 1y agoJim Keller did say essentially that, and I think this is proven in two different facts. First, x86 hasn't directly executed x86 instructions in a very long time. Second, Rosetta 2. ISA doesn't matter. Logic matters. Cache matters. Branch prediction and speculative execution matter. Buffers matter. Instruction reordering matters. Node size and packaging matter. SIMD matters for some workloads. Etc.
- deleted 1y ago[deleted]
- WithinReason 1y agoSince newer CPUs have heterogeneous cores (high performance + low power), I'm wondering if it makes sense to drop legacy instructions from the low power cores, since legacy code can still be run on the other cores. Then e.g. an OS compiled the right way can take advantage of extra efficiency without the CPU losing backwards compatibility
- o11c 1y agoWe've seen CPU-capability differences by accident a few times, and it's always a chaotic mess leading to SIGILL. The kernel would need to have a scheduler that knows it can't use those cores for certain tasks. Think about how hard you would have to work to even identify such a task ...
- mmis1000 1y agoCurrent windows or linux executable format don't even list the used instruction though. And even it is listed, how about dynamic linkables? The program may decide to load library at any time it wishes, and the OS is not going to know what instruction may be used this time.
- MBCook 1y agoYou couldn’t even scan the executable if you wanted to. Because lots of code will check what the CPU is capable of doing and choose the most efficient path based on what instructions it’s allowed to use. So until you’ve run it (halting problem) you may find instructions that you’d never even run.
- devnullbrain 1y agoInteresting but it would be pretty rough to implement. If you take a binary now and run it on a core without the correct instructions, it will SIGILL and probably crash. So you have these options: Create a new compilation target - You'll probably just end up running a lot of current x86 code exclusively on performance cores to a net loss. This is how RISC-V deals with optional extensions. Emulate - This already happens for some instructions but, like above, could quickly negate the benefits Ask for permission - This is what AVX code does now, the onus is on the programmer to check if the optional instructions can be used. But you can't have many dropped instructions and expect anybody to use it. Ask for forgiveness - Run the code anyway and catch illegal instruction exceptions/signals, then move to a performance core. This would take some deep kernel surgery for support. If this happens remotely often it will stall everything and make your system hate you. The last one raises the question: which instructions are we considering 'legacy'? You won't get far in an x86 binary before running into an instruction operating on memory that, in a RISC ISA, would mean first a load instruction, then the operation, then a store. Surely we can't drop those.
- gigatexal 1y agoYou’ll pry the ARM M series chips of my Mac from my cold dead hands. They’re a game changer in the space and one of the best reasons to use a Mac. I am not a chip expert it’s just so night and day different using a Mac with an arm chip compared to an Intel one from thermals to performance and battery life and everything in between. Intel isn’t even in the same ballpark imo. But competition is good and let’s hope they both do —- Intel and AMD because the consumer wins.
- mort96 1y agoI 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.
- KingOfCoders 1y agoWhat you have to understand, these are all the same people.
- cylemons 1y agoDont high profile designers have strong anticompetes?
- KingOfCoders 1y agoe.g. Jim Keller. CPU engineer 1982 - 1998, DEC Alpha processors (loved them) 1998 - 1999, AMD Athlon 1999 - 2004, MIPS 2008 - 2012, Apple A4/A5 2012 - 2015, AMD Ryzen/Zen 2016 - 2018, Tesla 2018 - 2020, Intel https://en.wikipedia.org/wiki/Jim_Keller_%28engineer%29 https://en.wikipedia.org/wiki/Jim_Keller_%28engineer%29
- astrange 1y agoCalifornia doesn't allow noncompete clauses. It's why Silicon Valley exists in the first place.
- kccqzy 1y ago
- Avi-D-coder 1y agoFrom what I have heard it's not the RISCy ISA per se, it's largely arm's weaker memory model. I'd be happy to be corrected, but the empirical core counts seem to agree.
- hydroreadsstuff 1y agoIndeed, the memory model has a decent impact. Unfortunately it's difficult to isolate in measurement. Only Apple has support for weak memory order and TSO in the same hardware.
- MBCook 1y agoOh there’s an interesting idea. Given that Linux runs on the M1 and M2 Macs, would it be possible to do some kind of benchmark there where you could turn it on and off at will for your test program?
- gok 1y agoThis has been done in fact: https://doi.org/10.1016/j.sysarc.2024.103102 https://doi.org/10.1016/j.sysarc.2024.103102
- nottorp 1y agoIrrelevant. There are two entities allowed to make x86_64 chips (and that only because AMD won the 64 bit ISA competition, otherwise there'd be only Intel). They get to choose. The rest will use arm because that's all they have access to. Oh, and x86_64 will be as power efficient as arm when one of the two entities will stop competing on having larger numbers and actually worry about power management. Maybe provide a ?linux? optimized for power consumption.
- shmerl 1y agoAMD do handle power consumption well, at least if you run in eco mode instead of pushing CPU to the limits. I always set eco mode on on modern Ryzens.
- nottorp 1y agoI have a Ryzen box that I temperature limited to 65 C indeed. That was about 100 W in my office with just the graphics integrated into the Ryzen. However, next to it there's a M2 mac mini that uses all of 37 W when I'm playing Cyberpunk 2077 so... > Both Intel and AMD provide runtime power control so this is tunable. The last ~10% of performance requires far more than 10% of the power. Yes but the defaults are insane.
- shmerl 1y agoCyberpunk 2077 is very GPU bound, so it's not really about CPU there. I'm playing it using 7900 XTX on Linux :) But yeah, defaults are set to look better in benchmarks and they are not worth it. Eco mode should be the default.
- dotnet00 1y agoIf you're measuring the draw at the wall, AFAIK desktop Ryzen keeps the chipset running at full power all the time and so even if the CPU is idle, it's hard to drop below, say, ~70W at the wall (including peripherals, fans, PSU efficiency etc). Apparently desktop Intel is able to drop all the way down to under 10W on idle.
- ZuLuuuuuu 1y agoThere are a lot of theoretical articles which claim similar things but on the other hand we have a lot of empirical evidence that ARM CPUs are significantly more power efficient. I used laptops with both Intel and AMD CPUs, and I read/watch a lot of reviews in thin and light laptop space. Although AMD became more power efficient compared to Intel in the last few years, AMD alternative is only marginally more efficient (like 5-10%). And AMD is using TSMC fabs. On the other hand Qualcomm's recent Snapdragon X series CPUs are significantly more efficient then both Intel and AMD in most tests while providing the same performance or sometimes even better performance. Some people mention the efficiency gains on Intel Lunar Lake as evidence that x86 is just as efficient, but Lunar Lake was still slightly behind in battery life and performance, while using a newer TSMC process node compared to Snapdragon X series. So, even though I see theoretical articles like this, the empirical evidence says otherwise. Qualcomm will release their second generation Snapdragon X series CPUs this month. My guess is that the performance/efficiency gap with Intel and AMD will get even bigger.
- ryukoposting 1y agoI think both can be true. A client CPU spends most of its life idling. Thus, the key to good battery life in client computing is, generally, idle power consumption. That means low core power draw at idle, but it also means shutting off peripherals that aren't in use, turning off clock sources for said peripherals, etc. ARM was built for low-power embedded applications from the start, and thus low-power idle states are integrated into the architecture quite elegantly. x86, on the other hand, has the SMM, which was an afterthought. AFAICT case for x86 ~ ARM perf equivalence is based on the argument that instruction decode, while empirically less efficient on x86, is such a small portion of a modern, high-performance pipeline that it doesn't matter. This reasoning checks out IMO. But, this effect would only be visible while the CPU is under load.
- flembat 1y agoThat is quite a confession from AMD. It's not X86 at all, just every implementation. It is not like the ARM processors in Macs are simple any more, thats for sure.
- variadix 1y agoInstruction decode for variable length ISAs is inherently going to be more complex, and thus require more transistors = more power, than fixed length instruction decode, especially parallel decode. AFAIK modern x86 cores have to speculatively decode instructions to achieve this, compared to RISC ISAs where you know where all the instruction boundaries are and decoding N in parallel is a matter of instantiating N decoders that work in parallel. How much this determines the x86 vs ARM power gap, I don’t know, what’s much more likely is x86 designs have not been hyper optimized for power as much ARM designs have been over the last two decades. Memory order is another non-negligible factor, but again the difference is probably more attributable to the difference in goals between the two architectures for the vast majority of their lifespan, and the expertise and knowledge of the engineers working at each company.
- cptskippy 1y agoThe ISA is the contract or boundary between software and hardware. While there is a hardware cost to decode instructions, the question is how much? As all the fanbois in the thread have have pointed out, Apple's M series is fast and efficient compared to x86 for desktop/server workloads. What no one seems to acknowledge is that Apple's A series is also fast and efficient compared to other ARM implementations in mobile workloads. Apple sees the need to maintain M and A series CPUs for different workloads, which indicates there's a benefit to both. This tells me the ISA decode hardware isn't or isn't the only bottleneck.
- MBCook 1y agoWhatever the hardware cost is it must pale in comparison to trying to implement the instructions set directly. Wasn’t that the huge benefit of the Pentium Pro? The main reason to have both A and M series chips, I think, is related to which custom processors are available as well as how many of each. There’s no point in putting the full GPU from an M4 into a cell phone, it’s just gonna waste a ton of power.
- hereme888 1y agoI was just window-shopping laptops this morning, and realized ARM-based doesn't necessarily hold battery life advantages.
- pacetherace 1y agoPlus they are not cheap either.
- mrheosuper 1y agoI Blame that on Qualcomm. Right now they are the only vendor with ARM CPU on Windows. And using QC CPU means you must buy their whole "solution".
- gtirloni 1y agoYou mean Windows-based ARM laptops or Macbooks?
- deleted 1y ago[deleted]
- hereme888 1y agoWindows. Never owned a Mac.
- aurareturn 1y agoThey actually do. Qualcomm matches Intel's best battery life but gives you more performance. Apple exceeds the best x86 performance and battery life by a large margin.
- tester756 1y agoOf course, because saying that X ISA is faster than Y ISA is like saying that Java syntax is faster than C# syntax Everything is about the implementation: compiler, JIT, runtime/VM, stdlib, etc. https://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter https://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter
- rafaelmn 1y agoC# 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)
- tester756 1y agoand 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.
- cjbgkagh 1y agoHFT code is unusual in the way it is used. A lot of work goes into avoiding the Garbage Collection and other JVM overheads.
- deleted 1y ago[deleted]
- mrsmrtss 1y agoIt may also be related to the fact that .NET until now does not have any GC with super low latency pauses, but there are interesting development going on recently regarding this - https://github.com/dotnet/runtime/discussions/115627 https://github.com/dotnet/runtime/discussions/115627.
- gt0 1y agoI'm glad an authoritative source has stated this. It's been ongoing BS for years. I first got into ARM machines with the Acorn Archimedes and even back then, people were spouting some kind of intrinsic efficiency benefit to ARM that just didn't make any sense.
- astrange 1y agoIt is true for small cores, it's just not important for big cores compared to all the other things you have to solve.
- MBCook 1y agoMakes sense. A 386 had 275,000 transistors. You can see how instruction decode stuff for a more complex x86 instruction could be a reasonable fraction of that. ArrowLake is 17.8 billion. Even if you divide by the core count instruction decode obviously isn’t much of that.
- wetpaws 1y ago[dead]
- pezezin 1y agoAfter 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 world it seems that every single CPU board requires its own drivers, device tree, and custom OS build. RISC-V seems to suffer from the same problem, and until this problem is solved, I will avoid them like toxic waste.
- Teknoman117 1y agoARM systems that support UEFI are pretty fun to work with. Then there's everything else. Anytime I hear the phrase "vendor kernel" I know I'm in for an experience...
- nicman23 1y agonah when i hear vendor kernel i just do not go for that experience. it is not 2006 get your shit mainline or at least packaged correctly.
- mrheosuper 1y agoFun Fact: Your Qualcomm based Phone may already use UEFI.
- markfeathers 1y agoCheck out ARM SBSA / SBBR which seems aimed at solving most of these issues. https://en.wikipedia.org/wiki/Server_Base_System_Architecture https://en.wikipedia.org/wiki/Server_Base_System_Architectur... I'm hopeful RISCV comes up with something similar.
- camel-cdr 1y agohttps://github.com/riscv-non-isa/riscv-server-platform/blob/main/server_platform_intro.adoc https://github.com/riscv-non-isa/riscv-server-platform/blob/...
- pjdesno 1y agoRelated to this, I remember seeing a research talk that fairly convincingly demonstrated that almost all performance differences between several ARM amd x86 CPUs were explained by microarchitectural features (branch predictor type and size, etc) rather than ISA. There was one benchmark affected by a deficiency in the ARM ISA, but that’s probably fixed by now.
- txrx0000 1y agoIt'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=Z0tNtMwYrGA https://www.youtube.com/watch?v=b3FTtvPcc2s https://www.youtube.com/watch?v=b3FTtvPcc2s https://www.youtube.com/watch?v=ymoiWv9BF7Q https://www.youtube.com/watch?v=ymoiWv9BF7Q 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. edit: Correction. I looked at the die image of Strix Halo and thought it looked like it had on-package RAM. It does not. It doesn't use PMIC either. Lunar Lake is the only Apple M-series competitor on x86 at the moment.
- mrheosuper 1y agoBy PMIC, did you mean VRM ?, if not, can you tell me the difference between them ?
- txrx0000 1y agoI'm not an expert on the topic and don't really know the difference. But in the video they say it can finetune power delivery to individual parts of the SoC and reduce idle power.
- mrheosuper 1y agoWell, Every single CPU need some kind of voltage regulation module to work. About "fine tune" part, this does not relate to PMIC(or VRM) at all, more like CPU design: How many power domain does this CPU have ?
- audunw 1y agoI don’t know how it is for Apple-M, but for chips I’ve worked on, this can definitely relate to PMIC/VRMs. You can tune the voltage you feed to the various power domains based on the clock speed required for those domains at any given time. We do it with on-chip power regulators, but I suppose for Apple M it would perhaps be off-chip PMICs feeding power into the chip.
- userbinator 1y agoInteresting to see this show up literally the day after I post a comment with this 11-year-old article on the same topic: https://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient https://www.extremetech.com/extreme/188396-the-final-isa-sho... It is a little ironic to see AMD making the backwards-compatibility argument, when they were the ones who made the very inelegant AMD64, had some known differences to Intel's CPUs in some edge-cases, and then much later, https://www.os2museum.com/wp/vme-broken-on-amd-ryzen/ https://www.os2museum.com/wp/vme-broken-on-amd-ryzen/ There are some very-low-power x86 SoCs which are largely found in embedded systems; the most famous of these may be https://en.wikipedia.org/wiki/Vortex86 https://en.wikipedia.org/wiki/Vortex86
- deleted 1y ago[deleted]
- pmarreck 1y ago> However, these are insignificant compared to the number of PCs running x86 today, as well as the volume of notebooks being shipped with an x86 CPU Which is insignificant compared to the number of smartphones and pad devices running ARM quite powerfully (and without much heat) for hours and hours. Their point? Everything I've read about x86 is that it is hideously complex, which is almost certainly impeding progress. Why would you want to prolong the life of an architecture like that?
- pulkittt 1y agoThis interview with AMD Zen chief architect Mike Clark validated that the efficiency gains are not due to ISA https://www.computerenhance.com/p/an-interview-with-zen-chief-architect https://www.computerenhance.com/p/an-interview-with-zen-chie...
- KingOfCoders 1y ago"When RISC first came out, x86 was half microcode. So if you look at the die, half the chip is a ROM, or maybe a third or something. And the RISC guys could say that there is no ROM on a RISC chip, so we get more performance. But now the ROM is so small, you can’t find it. Actually, the adder is so small, you can hardly find it? What limits computer performance today is predictability, and the two big ones are instruction/branch predictability, and data locality." Jim Keller
- rickdeckard 1y agoI agree, but I also don't think that the ISA is the differentiation factor for real-life efficiency between those two architectures. ARMs advantage is that every user-facing OS built for ARM was designed to be power-efficient, with frameworks governing applications. x86, not so much...
- waterTanuki 1y agoThen why does AWS charge less for the same compute workloads on ARM?
- viktorcode 1y agoThat statement contradicts the significant growth of ARM in server space in recent years.
- high_na_euv 1y agoIt does not
- zuhsetaqi 1y agoDon't claim it just show/proof it by offering a chip for consumers that matches or better beats the metrics of Apples offerings.
- perryizgr8 1y agoApple offers no chip though. It builds laptops with the best battery life and near top end performance. No other laptop manufacturer has been able to match that.
- sylware 1y agoRISC-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'.
- thecosmicfrog 1y agoWhat is "PI lock"? A cursory web search didn't reveal much.
- sylware 1y agoIP lock, my bad (in my native language it is the other way around). Intellectual Property lock. ARM, x86(intel), x86_64(amd) have such extremely strong locks in countries where those are legal to be enforced. It is said they literaly deny anybody else to use their ISAs unless there is a super strong power struggle and/or a giga-enormous amount of $$$ in the bargain.
- sylware 1y agoOh, regarding GPUs, AMD started to experiment on userland _hardware_ ring buffers... I don't know how they will handle their scarse VM id resources... the kernel may end up "only" mmaping event/command ring buffers and data dma/doorbells buffers with an "IRQ" event file descriptor. We are talking a "near 0-driver"... but they will have to be very confident in their GPU robustness to do that, not to mention 3D pipeline programming from those userland _hardware_ buffers will have to be really simple and directly "ready" to work.
- bob1029 1y agoTheoretically 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.
- Symmetry 1y agoThere are two separate issues here. Can an x86 be made nearly as efficient as an ARM chip with unbounded effort? Sure. But it's a lot easier to make a competent ARM design than a competent x86 design because there's so much more to the later and the front end has to be a lot more complicated to deal with the unsynchronized encoding.
- josemanuel 1y agoDoesn't the Arm 'weak' memory model (versus the x86 'strong' memory model) not have a significant impact to power consumption?