3 ms·

Each core needs to handle the full complexity of x86. Now, as super-scalar OoO x86 cores have evolved the percentage of die allocated to decoding the cruft has

Each core needs to handle the full complexity of x86. Now, as super-scalar OoO x86 cores have evolved the percentage of die allocated to decoding the cruft has gone down. …but when we start swarming simple cores, that cost starts to rise. Each core needs to be able to decode everything. Now when you can a 100 cores, even if the cruft is just 4%, that means you can have 4 more cores. This is for free if you are willing to recompile your code. Now, it may turn out that we need more decoding complexity than something like RISC-V currently has (Qualcomm has been working in it), but these will be deliberate, intentionally chose instead of accrued, that meet the needs of today and current trade offs, and not of the eart 80’s.

magicalhippo 2y ago
As a developer of fairly standard software, there's very little I can say I rely on from the x86/x64 ISA. One big one is probably around consistency model[1] and such which affects atomic operations and synchronizing multi-threaded code. Usually not directly though, I typically use libraries or OS primitives. Are there any non-obvious (to me anyway) ways us "typical devs" rely on x86/x64? I get the sense that a lot of software is one recompile away from running on some other ISA, but perhaps I'm overly naive. [1]: https://en.wikipedia.org/wiki/Consistency_model https://en.wikipedia.org/wiki/Consistency_model
- ajross 2y ago
  > Are there any non-obvious (to me anyway) ways us "typical devs" rely on x86/x64? Generally the answer is "we bought this product 12 years ago and it doesn't have an ARM version". Or variants like "We can't retire this set of systems which is still running the binary we blessed in this other contract". It's true that no one writing "fairly standard software" is freaking out over the inability to work on a platform without AVX-VNNI, or deals with lockless algorithms that can't be made feasibly correct with only acquire/release memory ordering semantics. But that's not really where the friction is.
  - EasyMark 2y ago
    A lot of systems are “good enough” and run flawlessly for years/decades so unless you have a good business case you won’t be able to move from x86 to ARM or the new RISC open stuff because the original system cost a couple million dollars.
    - snvzz 2y ago
      "good enough" but made a decade ago would run fine in an emulator, while much more instrumentalized and under control than if running directly on hardware.
      - ajross 2y ago
        That was true through the 90's, but not anymore. A typical datacenter unit from 2014 would have been a 4-socket Ivy Bridge-EP with 32ish ~3 GHz cores. You aren't going to emulate that feasibly with equivalent performance on anything modern, not yet.
        snvzz 2y ago
        Cycle exact? Sure. But what are the odds you need that for some x86 software made in 2014. Otherwise, via translation techniques, getting 80% of native performance isn't unheard of. Which would be very fast relative to any such Ivy Bridge server. Transitioning away from x86 definitely is feasible, as very successfully demonstrated by Apple.
  - magicalhippo 2y ago
    Yea was just trying to check for a blind spot. In these cloudy days, it seems nearly trivial for a lot of workloads, but like I said perhaps I had missed something. For us the biggest obstacle is that our compiler doesn't support anything but x86/x64. But we're moving to .Net so that'll solve itself.

magicalhippo 2y ago

As a developer of fairly standard software, there's very little I can say I rely on from the x86/x64 ISA. One big one is probably around consistency model[1] and such which affects atomic operations and synchronizing multi-threaded code. Usually not directly though, I typically use libraries or OS primitives. Are there any non-obvious (to me anyway) ways us "typical devs" rely on x86/x64? I get the sense that a lot of software is one recompile away from running on some other ISA, but perhaps I'm overly naive. [1]: https://en.wikipedia.org/wiki/Consistency_model https://en.wikipedia.org/wiki/Consistency_model

ajross 2y ago
> Are there any non-obvious (to me anyway) ways us "typical devs" rely on x86/x64? Generally the answer is "we bought this product 12 years ago and it doesn't have an ARM version". Or variants like "We can't retire this set of systems which is still running the binary we blessed in this other contract". It's true that no one writing "fairly standard software" is freaking out over the inability to work on a platform without AVX-VNNI, or deals with lockless algorithms that can't be made feasibly correct with only acquire/release memory ordering semantics. But that's not really where the friction is.
- EasyMark 2y ago
  A lot of systems are “good enough” and run flawlessly for years/decades so unless you have a good business case you won’t be able to move from x86 to ARM or the new RISC open stuff because the original system cost a couple million dollars.
  - snvzz 2y ago
    "good enough" but made a decade ago would run fine in an emulator, while much more instrumentalized and under control than if running directly on hardware.
    - ajross 2y ago
      That was true through the 90's, but not anymore. A typical datacenter unit from 2014 would have been a 4-socket Ivy Bridge-EP with 32ish ~3 GHz cores. You aren't going to emulate that feasibly with equivalent performance on anything modern, not yet.
      - snvzz 2y ago
        Cycle exact? Sure. But what are the odds you need that for some x86 software made in 2014. Otherwise, via translation techniques, getting 80% of native performance isn't unheard of. Which would be very fast relative to any such Ivy Bridge server. Transitioning away from x86 definitely is feasible, as very successfully demonstrated by Apple.
- magicalhippo 2y ago
  Yea was just trying to check for a blind spot. In these cloudy days, it seems nearly trivial for a lot of workloads, but like I said perhaps I had missed something. For us the biggest obstacle is that our compiler doesn't support anything but x86/x64. But we're moving to .Net so that'll solve itself.