5 ms·

I appreciate learning more about what, exactly, ARM's "weaker memory model" constitutes. It's clearer to me after reading this article. I wonder how much the g

by runeks 6y ago

I appreciate learning more about what, exactly, ARM's "weaker memory model" constitutes. It's clearer to me after reading this article. I wonder how much the gain in performance of e.g. Apple's M1 chip, compared to an x86 CPU, can be attributed to this weaker constraint. Given that the M1 can outperform an x86 CPU even when emulating x86 code, perhaps it's not much. Also, I suspect programming languages that are immutable by default will gain a larger advantage using ARM's weaker memory model, as the compiler can more often safely let the CPU perform reordering (due to not having to wait for a mutable variable being updated until it can execute a subsequent line of code which depends on this updated variable).

saagarjha 6y ago
The M1 chip can do uncontended atomics almost "for free", and offers a mode where it firms up its memory ordering without much performance loss, so I am not actually sure how much this gets them.
- KMag 6y ago
  Well, it gets them enough that they bothered implementing all of the circuitry for both memory models and an extra bit of thread state to switch between them. I'm sure they did a bunch of simulation before going with that decision. I'm sure they did some simulations before going down that road and found that it was worth it vs. just going with a more strict x86-like memory model all the time.
  - cma 6y ago
    > I'm sure they did some simulations before going down that road and found that it was worth it vs. just going with a more strict x86-like memory model all the time. Or they didn't want developers to rely on it so they can remove it in the future when they deprecate x64 (they deprecated x86 so it is only a matter of time).
    - KMag 6y ago
      > Or they didn't want developers to rely on it If simulations show that it's not currently worth the effort, but they want to keep the option open, that implies that they believe some technological change in the future may make the relaxed memory model bear fruit. Actually, now that I think about it, another option is that the weaker memory model is more advantageous in lower power implementations, like iWatch, and preventing developers from relying on the stronger memory model available in M1 reduces the number of bugs in iWatch applications that share code with iPhone apps or OSX apps.
Tuna-Fish 6y ago
The reason it doesn't help them that much in performance is that the difference in the way x86/ARM manage memory is not that ARM reorders more and x86 reorders less, but that ARM reorders openly and x86 reorders things behind your back but makes sure everything is where you think they should be if/when you look. This is the reason that the relatively primitive memory model of x86 has turned out to be so successful despite the consensus in the field being that it's way to restrictive for performance way back in the 90's. It turns out that the x86 memory model is an easy target for a complex reordering backend to provide as a "facade", between what is actually happening the in CPU's own L1 and buffers and what everything else thinks it's doing. The only way weaker memory orderings benefit is that they don't need as large buffers and queues on the backend, as they can retire memory operations earlier. Except that if you just implement the ARM memory model as specified and without a similar facade, it will actually lose to modern x86, because the x86 chip can make use of the freedom provided by it's machinery to reorder even more without any of it ever being visible to the software. So you end up implementing a similar system as the x86, with only very minor gains from the fact that you can sometimes properly retire accesses earlier and thus get a little more use out of your buffers. ARM, especially 64-bit ARM, has genuine advantages over x86. (Notably, decode.) The weak memory model is not one of them, outside the very weakest and tiniest cores (where it allows some reordering with a tiny load-store backend).
- my123 6y ago
  And on Arm cores, you aren't obligated to provide a weak memory model. Some Arm vendors provide cores with stronger memory models, mainly TSO in Arm server land and sequential consistency for NVIDIA in-house CPUs.
- deadmutex 6y ago
  Thank you for your insightful comment. Do you mind going a bit more into the decode advantage?
  - my123 6y ago
    32-bit fixed size instructions, that are aligned. That allows you to have 8-wide decoders for example. On x86, you can't really do this/didn't happen because the instructions are 1 to 15 bytes long, and you'll need to decode the prior instruction at least in part to determine where your current instr starts. (currently 4-wide decoders are available for x86 uArches)
CalChris 6y ago
The M1 is outperforming an x86 CPU when emulating x86 code by translating that code into ARMv8 instructions. So if the x86 code was designed using x86's strong memory model and is then dynamically translated into ARMv8 and run with a weak memory model, there will be problems, no? Maybe Rosetta 2 handles this; that would be impressive.
- floatboth 6y ago
  No, Apple doesn't run the translated code with a weak memory model, Rosetta 2 toggles the total store ordering (which the M1 supports) on when running its code. Microsoft's translator (and QEMU?) does insert extra barriers to make it run on a weak memory model, because they are designed to run on HW without TSO.
  - CalChris 6y ago
    Yes, Apple added a CPU mode bit. From the article: Note: writing an x86 emulator on ARM forces you to deal with this in a particularly messy way because you never know when reordering will be a problem so you typically have to insert a lot of memory barriers. Or you can follow Apple’s strategy and add a CPU mode that enforces x86/x64 memory ordering, turning that on when emulating. I'm a little surprised+happy the ARM architectural license allowed this.
    - floatboth 6y ago
      Why wouldn't it? A stronger memory model doesn't break anything in the ISA. You can always go stronger, it's not a problem even for native applications, it would just make them slightly slower. What is surprising with Apple is that they were allowed to add extra instructions for machine learning related math (yeah, CPU instructions in addition to a dedicated separate "neural engine" on the chip: https://news.ycombinator.com/item?id=24471699 https://news.ycombinator.com/item?id=24471699)
      - CalChris 6y ago
        After doing a little web research, I'll conclude that it's impossible to know from the outside what the restrictions are on ARM architectural licensees other than they have to pass the ARM compatibility test suite. New instructions (probably not), new modes (looks like), dunno (definitely). However, Apple is one of the founding ARM partners and it is rumored they have a special license (not all licenses are created equal). Clearly they are doing this mode thing. Whether Samsung could get away with the exact same thing is a good question. I'm going to guess that NVidia can.
l1k 6y ago
I've you want to learn even more, take a look at Documentation/memory-barriers.txt in the Linux kernel source tree: https://www.kernel.org/doc/html/latest/staging/index.html#memory-barriers https://www.kernel.org/doc/html/latest/staging/index.html#me...

by runeks 6y ago

saagarjha 6y ago

The M1 chip can do uncontended atomics almost "for free", and offers a mode where it firms up its memory ordering without much performance loss, so I am not actually sure how much this gets them.

KMag 6y ago
Well, it gets them enough that they bothered implementing all of the circuitry for both memory models and an extra bit of thread state to switch between them. I'm sure they did a bunch of simulation before going with that decision. I'm sure they did some simulations before going down that road and found that it was worth it vs. just going with a more strict x86-like memory model all the time.
- cma 6y ago
  > I'm sure they did some simulations before going down that road and found that it was worth it vs. just going with a more strict x86-like memory model all the time. Or they didn't want developers to rely on it so they can remove it in the future when they deprecate x64 (they deprecated x86 so it is only a matter of time).
  - KMag 6y ago
    > Or they didn't want developers to rely on it If simulations show that it's not currently worth the effort, but they want to keep the option open, that implies that they believe some technological change in the future may make the relaxed memory model bear fruit. Actually, now that I think about it, another option is that the weaker memory model is more advantageous in lower power implementations, like iWatch, and preventing developers from relying on the stronger memory model available in M1 reduces the number of bugs in iWatch applications that share code with iPhone apps or OSX apps.

Tuna-Fish 6y ago

The reason it doesn't help them that much in performance is that the difference in the way x86/ARM manage memory is not that ARM reorders more and x86 reorders less, but that ARM reorders openly and x86 reorders things behind your back but makes sure everything is where you think they should be if/when you look. This is the reason that the relatively primitive memory model of x86 has turned out to be so successful despite the consensus in the field being that it's way to restrictive for performance way back in the 90's. It turns out that the x86 memory model is an easy target for a complex reordering backend to provide as a "facade", between what is actually happening the in CPU's own L1 and buffers and what everything else thinks it's doing. The only way weaker memory orderings benefit is that they don't need as large buffers and queues on the backend, as they can retire memory operations earlier. Except that if you just implement the ARM memory model as specified and without a similar facade, it will actually lose to modern x86, because the x86 chip can make use of the freedom provided by it's machinery to reorder even more without any of it ever being visible to the software. So you end up implementing a similar system as the x86, with only very minor gains from the fact that you can sometimes properly retire accesses earlier and thus get a little more use out of your buffers. ARM, especially 64-bit ARM, has genuine advantages over x86. (Notably, decode.) The weak memory model is not one of them, outside the very weakest and tiniest cores (where it allows some reordering with a tiny load-store backend).

my123 6y ago
And on Arm cores, you aren't obligated to provide a weak memory model. Some Arm vendors provide cores with stronger memory models, mainly TSO in Arm server land and sequential consistency for NVIDIA in-house CPUs.
deadmutex 6y ago
Thank you for your insightful comment. Do you mind going a bit more into the decode advantage?
- my123 6y ago
  32-bit fixed size instructions, that are aligned. That allows you to have 8-wide decoders for example. On x86, you can't really do this/didn't happen because the instructions are 1 to 15 bytes long, and you'll need to decode the prior instruction at least in part to determine where your current instr starts. (currently 4-wide decoders are available for x86 uArches)

CalChris 6y ago

The M1 is outperforming an x86 CPU when emulating x86 code by translating that code into ARMv8 instructions. So if the x86 code was designed using x86's strong memory model and is then dynamically translated into ARMv8 and run with a weak memory model, there will be problems, no? Maybe Rosetta 2 handles this; that would be impressive.

floatboth 6y ago
No, Apple doesn't run the translated code with a weak memory model, Rosetta 2 toggles the total store ordering (which the M1 supports) on when running its code. Microsoft's translator (and QEMU?) does insert extra barriers to make it run on a weak memory model, because they are designed to run on HW without TSO.
- CalChris 6y ago
  Yes, Apple added a CPU mode bit. From the article: Note: writing an x86 emulator on ARM forces you to deal with this in a particularly messy way because you never know when reordering will be a problem so you typically have to insert a lot of memory barriers. Or you can follow Apple’s strategy and add a CPU mode that enforces x86/x64 memory ordering, turning that on when emulating. I'm a little surprised+happy the ARM architectural license allowed this.
  - floatboth 6y ago
    Why wouldn't it? A stronger memory model doesn't break anything in the ISA. You can always go stronger, it's not a problem even for native applications, it would just make them slightly slower. What is surprising with Apple is that they were allowed to add extra instructions for machine learning related math (yeah, CPU instructions in addition to a dedicated separate "neural engine" on the chip: https://news.ycombinator.com/item?id=24471699 https://news.ycombinator.com/item?id=24471699)
    - CalChris 6y ago
      After doing a little web research, I'll conclude that it's impossible to know from the outside what the restrictions are on ARM architectural licensees other than they have to pass the ARM compatibility test suite. New instructions (probably not), new modes (looks like), dunno (definitely). However, Apple is one of the founding ARM partners and it is rumored they have a special license (not all licenses are created equal). Clearly they are doing this mode thing. Whether Samsung could get away with the exact same thing is a good question. I'm going to guess that NVidia can.

l1k 6y ago

I've you want to learn even more, take a look at Documentation/memory-barriers.txt in the Linux kernel source tree: https://www.kernel.org/doc/html/latest/staging/index.html#memory-barriers https://www.kernel.org/doc/html/latest/staging/index.html#me...