13 ms·
This 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 i
by exmadscientist 1y ago
This 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.