4 ms·

> it also gives us better density overall by having smaller instructions. x86 can put more work into each instruction byte, so we can have denser binaries and i

> it also gives us better density overall by having smaller instructions. x86 can put more work into each instruction byte, so we can have denser binaries and increase performance that way. Is that really true? I was under the impression that ARM core density was better than x86. The first Google result I found agrees: https://www.bitsnbites.eu/cisc-vs-risc-code-density/ https://www.bitsnbites.eu/cisc-vs-risc-code-density/ > It may take a little bit more microarchitectural work for us to account for stronger memory order on the x86 side, but of course the software has to account for the weaker memory ordering on the ARM side. So there are tradeoffs. I don't think this makes sense either since software has to have synchronisation anyway. I don't think much software relies on x86 TSO (intentionally anyway; I'm sure many bugs are covered up by it). Anyway fantastic interview! Very refreshing when they're actually technical with interesting questions and answers.

dundarious 2y ago
Relying on TSO is not a bug if your target platform is just amd64.
- IshKebab 2y ago
  I was thinking about code that relies on TSO but doesn't insert synchronisation primitives for the compiler, and it just happens to violate the expected ordering. E.g. maybe the code would break if you increased the optimisation level or switched compiler.
  - dundarious 2y ago
    You can write data race free code with just compiler reorder fences and extremely limited sync primitives on x86/64, but cannot with most other ISAs.
  - adgjlsfhk1 2y ago
    Generally the way this works is that when you write atomic algorithms, you are doing 2 things. The first is telling the compiler what it's allowed to optimize, and the 2nd is controlling the processor. What this means is that the code that relies on TSO (which is pretty close to the C++ memory model), you add a bunch of information to the code that prevents the compiler from doing some optimizations, and then when the compiler is generating native code, on X86 it will turn into regular loads/stores, but on arm it will have additional fence instructions.
    - IshKebab 2y ago
      Yes indeed. But it will only add the fences where needed whereas on x86 it basically has implicit fences everywhere which is clearly worse.
      - adgjlsfhk1 2y ago
        it's not actually that clear. hardware can do some pretty neat tricks to make the fences basically free when there aren't multiple cores writing to the same memory. as a result, most of those explicit fences are just extra front end pressure.
jamessinghal 2y ago
I'd assume the synchronization primitives in OSes are written with the memory ordering in mind at the least.
- IshKebab 2y ago
  Yeah I think this is true - they can be nops on x86. But it's still going to be better to have explicit sync instructions only where needed than implicit sync everywhere.
adgjlsfhk1 2y ago
> The first Google result I found agrees: https://www.bitsnbites.eu/cisc-vs-risc-code-density/ https://www.bitsnbites.eu/cisc-vs-risc-code-density/ This isn't a great metric for 2 reasons. Firstly, it's looking at static rather than dynamic instruction counts, and 2nd x86 tends to get bigger vectorized implimentations, but these are often on bigger vectors so the "instructions per data" which is the more important metric in many cases is lower. https://news.ycombinator.com/item?id=19329128 https://news.ycombinator.com/item?id=19329128 has a pretty interesting discussion on this from a few years ago, but 2 places where x86 shines are the lea and mov instructions. They are both incredibly compact for representing potentially very complicated operations.

dundarious 2y ago

Relying on TSO is not a bug if your target platform is just amd64.

IshKebab 2y ago
I was thinking about code that relies on TSO but doesn't insert synchronisation primitives for the compiler, and it just happens to violate the expected ordering. E.g. maybe the code would break if you increased the optimisation level or switched compiler.
- dundarious 2y ago
  You can write data race free code with just compiler reorder fences and extremely limited sync primitives on x86/64, but cannot with most other ISAs.
- adgjlsfhk1 2y ago
  Generally the way this works is that when you write atomic algorithms, you are doing 2 things. The first is telling the compiler what it's allowed to optimize, and the 2nd is controlling the processor. What this means is that the code that relies on TSO (which is pretty close to the C++ memory model), you add a bunch of information to the code that prevents the compiler from doing some optimizations, and then when the compiler is generating native code, on X86 it will turn into regular loads/stores, but on arm it will have additional fence instructions.
  - IshKebab 2y ago
    Yes indeed. But it will only add the fences where needed whereas on x86 it basically has implicit fences everywhere which is clearly worse.
    - adgjlsfhk1 2y ago
      it's not actually that clear. hardware can do some pretty neat tricks to make the fences basically free when there aren't multiple cores writing to the same memory. as a result, most of those explicit fences are just extra front end pressure.

jamessinghal 2y ago

I'd assume the synchronization primitives in OSes are written with the memory ordering in mind at the least.

IshKebab 2y ago
Yeah I think this is true - they can be nops on x86. But it's still going to be better to have explicit sync instructions only where needed than implicit sync everywhere.

adgjlsfhk1 2y ago

> The first Google result I found agrees: https://www.bitsnbites.eu/cisc-vs-risc-code-density/ https://www.bitsnbites.eu/cisc-vs-risc-code-density/ This isn't a great metric for 2 reasons. Firstly, it's looking at static rather than dynamic instruction counts, and 2nd x86 tends to get bigger vectorized implimentations, but these are often on bigger vectors so the "instructions per data" which is the more important metric in many cases is lower. https://news.ycombinator.com/item?id=19329128 https://news.ycombinator.com/item?id=19329128 has a pretty interesting discussion on this from a few years ago, but 2 places where x86 shines are the lea and mov instructions. They are both incredibly compact for representing potentially very complicated operations.