If ARM starts dominating in desktop and laptop spaces with a quite different set of applications, might we start seeing more software bugs around race conditions? Caused by developers writing software with X86 in mind, with its differing constraints on memory ordering.

▲ vardump 4 hours ago | parent | next [-]

That's a possibility. Some code still assumes (without realizing!) x86 style ordered loads and stores. This is called a strong memory model, specifically TSO, Total Store Order. If you tell x86 to execute "a=1; b=2;", it will always store value to 'a' first. Of course compilers might reorder stores and loads, but that's another matter.

ARM is free to reorder stores and loads. This is called a weak memory model. So unless it's explicitly told to the compiler, like C++ memory_order::acquire and memory_order::release, you might get invalid behavior. Heisenbugs in the worst case.

▲ cmrdporcupine 2 hours ago | parent | prev | next [-]

This is actually one reason I feel like developing my systems level stuff on ARM64 instead of x86 (I have a DGX Spark box) is not a bad idea. Building lower level concurrent data structures, etc. it just seems wiser to have to deal with this more immanently.

That said, I've never actually run into one of these issues.

▲ dd_xplore 5 hours ago | parent | prev | next [-]

The major issue is these days most software is electron based or a webapp. I miss the days of 98/XP, where you'd find tons of desktop software. A PC actually felt something that had a purpose. Even if you spin up a XP/98(especially 98/2000 VM) now, you'd see the entire OS feels something that you can spend some time on. Nowadays most PCs feel like a random terminal where I open the browser and do some basic work(except for gaming ofcourse). I really hate the UX of win 11 , even 10 isn't much better compared to XP. I really hope we go back to that old era.

▲ ivolimmen 5 hours ago | parent | prev | next [-]

If you go around your OS yes that could be the case but you can already have issues using the application from machine to machine with the same OS having different amounts of RAM and different CPU's. But I am not an expert in these matters.

▲ runeks 4 hours ago | parent | prev | next [-]

Wouldn't the compiler take care of producing the correct machine code?

▲ octachron 4 hours ago | parent | next [-]

The issue is that the C memory model allows more behaviours than the memory model of x86-64 processors. You can thus write code which is incorrect according to the C language specification but will happen to work on x86-64 processors. Moving to arm64 (with its weaker memory model than x86-64) will then reveal the latent bug in your program.

	▲	Someone 3 hours ago \| parent [-]
		And “happen to work on x86-64 processors” also will depend on the compiler. If you write `a = 1; b = 'p';` both the compiler and the CPU can freely pick the order in which those two happen (or even execute them in parallel, or do half of one first, then the other, then the other half of the first, but I think those are hypothetical cases) x86-64 will never do such a swap, but x86-64 compilers might. If you write `a = 1; b = 2;` , things might be different for the C compiler because a and b can alias. The hardware still is free to change that order, though.

▲ mrweasel 3 hours ago | parent | prev | next [-]

OpenBSD famously keeps a lot of esoteric platforms around, because running the same code on multiple architectures reveal a lot of bugs. At least that was one of the arguments previously.

▲ mhh__ 4 hours ago | parent | prev [-]

The compiler relies on the language and programmer to enforce and follow a memory consistency model

▲ Zardoz84 3 hours ago | parent | prev | next [-]

If it is programmed in assembly. This kind of nasty detail should be handled by the compilers.

	▲	askl 2 hours ago \| parent [-]
		If it's programmed in assembly, it just wont compile for a different architecture.

▲ jordiburgos 4 hours ago | parent | prev [-]

Only for the hand-written assemply parts of the source code. The rest will be handled by the compilers.

▲

bpye 4 hours ago | parent | next [-]

You don't need to be writing assembly. Anything sharing memory between multiple threads could have bugs with ARM's memory model, even if written in C, C++, etc.

▲

silon42 4 hours ago | parent | prev [-]

Not even close. Except maybe in Rust /s

	▲	galangalalgol 3 hours ago \| parent [-]
		For rustaceans missing that /s, if you just use Relaxed ordering everywhere and you aren't sure why, but hey tests pass on x86, then yeah on arm it may have a problem. On x86 it effectively is SeqCst even if you specify Relaxed.