3 ms·
To be pedantic, x86 does have opt-in weaker memory models. When you're setting up the TLB entries, you can configure how strong the cache behavior is for the me
by jcranmer 2y ago
To be pedantic, x86 does have opt-in weaker memory models. When you're setting up the TLB entries, you can configure how strong the cache behavior is for the memory... which means in practice, you can't really access these memory models unless you're doing firmware, or you're using nontemporal stores [1].
On a more practical level, however, it's actually disruptive to make the hardware have optional less-restrictive semantic operations, because the other instructions might need more fences to guarantee the necessary properties. For example, on x86, compilers drop all explicit store fences because they're "unnecessary" on the hardware, and adding in operations that would make them necessary, even for existing code that doesn't know about the instructions that don't exist yet.
[1] Incidentally, this means trying to read the manual to figure out what a nontemporal store actually does can feel like turning your brain to mush.
- kmeisthax 2y ago> For example, on x86, compilers drop all explicit store fences because they're "unnecessary" on the hardware I mean specifically for new programs that are written with weaker memory models in mind. So you'd have to enable an -fNOTSO flag on your compiler that emits all the fences that would otherwise be skipped. Looking at what I can find about nontemporal stores, they sound like they already have a weird kind of release semantics on x86, even though their intent was to avoid cache thrashing, not so much to allow greater memory reordering. Are these actually used in compilers?
- jcranmer 2y agoCompilers will generally expose a nontemporal store intrinsic, but don't expect them to actually try to use it automatically.
- anonymousDan 2y agoI think they were particularly beneficial in some workloads for optane persistent memory
- dzaima 2y agoCompilers can generate non-temporal ops if you ask for it explicitly in some form. And they are problematic: https://github.com/llvm/llvm-project/issues/64521 https://github.com/llvm/llvm-project/issues/64521
- adrian_b 2y agoThe cache behavior regarding the ordering of memory accesses cannot be configured. What you can select when mapping memory is to make some regions uncached (with several variants, e.g. write-combining). Some of the kinds of uncached memory regions, especially those whose names include "write-combining", implement weaker orderings of the memory accesses in comparison with how cacheable memory works on x86, where 3 of the 4 kinds of memory access reorderings are prohibited (i.e. all except that subsequent loads can be performed before prior stores). However choosing a memory type with weakly-ordered accesses cannot increase the performance on x86, because the loss of performance by not using the cache is much greater. The weakly-ordered accesses only recover a small part of the performance loss caused by uncached memory.
- jcranmer 2y agoIs the mapping memory stuff separate from what's being set up by the OS as part of the TLB? I'm generally willfully ignorant of the privileged side of ISAs since I'm firmly a compilers guy, so I mostly only got this level of stuff by having to look at it thanks to it being incorporated into the definition of nontemporal store on x86 (which still ends up being confusing as heck).
- NobodyNada 2y agoYes, the "mapping memory stuff" is the page tables. (The TLB is an internal cache the processor keeps of recently used page table entries, which is mostly internal to the processor and transparent to the OS, except that the OS needs to remember to issue a special instruction to invalidate the TLB after modifying page tables.)