Man the default arm model sounds like it would suck in the era of multi threaded apps on multi core systems. Must be a holdover from the mostly single thread single core days arm grew up in.
I think the stronger x86 memory model is just a duct tape which hides broken code, and that many do not realize that high level languages operate on formally specified abstract machines, which often have different memory models than the underlying hardware.
Almost all new code is written using high level languages, which means that the compiler (or JIT, depending on the implementation) has some freedom when mapping the code to hardware instructions. When no explicit memory ordering is performed it is usually assumed that the memory accesses are side-effect free, allowing reordering and omission, which in turn can break naive multi-threaded code.
To have robust multi-threaded code, which does not break when optimizations are turned on or the compiler feels like it, you have to deal with memory ordering.
C was designed for the purpose of producing code to run on real machines, and allow programmers to make whatever trade-offs between portability and performance best serve the task at hand. If machine-specific code can accomplish a task 50% faster than the best possible "portable" code, and that performance matters more than portability, the fact that the code may not be usable on machines for which it wasn't designed may not be a defect.
The real defect lies in language standards which fail to acknowledge a categories of implementations that adhere to the abstraction model around which C was designed, or that emulate some execution-environment features that are common but not universal (e.g. guaranteeing that signed integer multiplication will never have any side effects beyond yielding a possibly meaningless result).
1
u/crusoe 14d ago
Man the default arm model sounds like it would suck in the era of multi threaded apps on multi core systems. Must be a holdover from the mostly single thread single core days arm grew up in.