7 ms·

I agreed with you up until the x86 comment. Legacy x86 support is largely a red herring. The constraints are architectural (as you noted, per-core memory bandwi

I agreed with you up until the x86 comment. Legacy x86 support is largely a red herring. The constraints are architectural (as you noted, per-core memory bandwidth, plus other things) more than they are due to being tied down to legacy instruction sets.

mlyle 2y ago
If the goal ends up being many-many-core, x86's complexity tax may start to matter. The cost of x86 compatibility relative to all the complexities required for performance has been small, but if we end up deciding that memory latency is going to kill us and we can't keep complex cores fed, then that is a vote for simpler architectures. I suspect the future will be something between these extremes (tons of dumb cores or ever-more-complicated cores to try and squeeze out IPC), though.
- hajile 2y ago
  The x86 tax ALREADY matters. Intel was only able to increase the number of decoders by adding entirely independent decoder complexes while reducing the number of decoders per branch. In practice, this means that decode increases for branchy code, but non-branchy code will be limited to just 3 decoders. In contrast, an ARM X4 or Apple M4 can decode 10 instructions under all conditions. This also play into ideas like Larabee/Knights processors where you basically want the tiniest core possible attached to a massive SIMD engine. x86 decode eats up a lot of real estate. Even worse, x86 decode adds a bunch of extra stages which in turn increase the size of the branch predictor. That's not the biggest issue though. Dealing with all of this and all the x86 footguns threaded throughout the pipeline slows down development. It takes more designers and more QAs more time to make and test everything. ARM can develop a similar CPU design for a fraction of the cost compared to AMD/Intel and in less time too because there's simply fewer edge cases they have to work with. This ultimately means the ARM chips can be sold for significantly less money or higher margins.
  - TinkersW 2y ago
    In the talk given by lead architect for skymont they implied it could decode 9 under all conditions, not just when there are heavy branches.
  - jart 2y ago
    Then show me the low-cost ARM version of AMD's 96-core Threadripper.
    - wmf 2y ago
      Ampere One was supposed to be out by now.
  - nuudlman 2y ago
    The fun thing with branch predictors is that they tell you where the next branch is (among other things like the direction of the branch). Since hardware is built out of finite wires, the prediction will saturate to some maximum distance (something in the next few cache lines). How this affects decode clusters is left as an exercise to the reader.
  - atq2119 2y ago
    > In contrast, an ARM X4 or Apple M4 can decode 10 instructions under all conditions. Not if there are fewer than 10 instructions between branches...
Pet_Ant 2y ago
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.
hulitu 2y ago
> Legacy x86 support ... is slowly dissapearing. Even on Windows 10 is very hard to run Win32 programs from Win95, Win98 era.

mlyle 2y ago

If the goal ends up being many-many-core, x86's complexity tax may start to matter. The cost of x86 compatibility relative to all the complexities required for performance has been small, but if we end up deciding that memory latency is going to kill us and we can't keep complex cores fed, then that is a vote for simpler architectures. I suspect the future will be something between these extremes (tons of dumb cores or ever-more-complicated cores to try and squeeze out IPC), though.

hajile 2y ago
The x86 tax ALREADY matters. Intel was only able to increase the number of decoders by adding entirely independent decoder complexes while reducing the number of decoders per branch. In practice, this means that decode increases for branchy code, but non-branchy code will be limited to just 3 decoders. In contrast, an ARM X4 or Apple M4 can decode 10 instructions under all conditions. This also play into ideas like Larabee/Knights processors where you basically want the tiniest core possible attached to a massive SIMD engine. x86 decode eats up a lot of real estate. Even worse, x86 decode adds a bunch of extra stages which in turn increase the size of the branch predictor. That's not the biggest issue though. Dealing with all of this and all the x86 footguns threaded throughout the pipeline slows down development. It takes more designers and more QAs more time to make and test everything. ARM can develop a similar CPU design for a fraction of the cost compared to AMD/Intel and in less time too because there's simply fewer edge cases they have to work with. This ultimately means the ARM chips can be sold for significantly less money or higher margins.
- TinkersW 2y ago
  In the talk given by lead architect for skymont they implied it could decode 9 under all conditions, not just when there are heavy branches.
- jart 2y ago
  Then show me the low-cost ARM version of AMD's 96-core Threadripper.
  - wmf 2y ago
    Ampere One was supposed to be out by now.
- nuudlman 2y ago
  The fun thing with branch predictors is that they tell you where the next branch is (among other things like the direction of the branch). Since hardware is built out of finite wires, the prediction will saturate to some maximum distance (something in the next few cache lines). How this affects decode clusters is left as an exercise to the reader.
- atq2119 2y ago
  > In contrast, an ARM X4 or Apple M4 can decode 10 instructions under all conditions. Not if there are fewer than 10 instructions between branches...

Pet_Ant 2y ago

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.

hulitu 2y ago

> Legacy x86 support ... is slowly dissapearing. Even on Windows 10 is very hard to run Win32 programs from Win95, Win98 era.