4 ms·

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 condition

by dinglo 8mo ago

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.

ivolimmen 8mo ago
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.
dd_xplore 8mo ago
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.
- rbanffy 8mo ago
  > Nowadays most PCs feel like a random terminal It's a fun perception. For the longest time, all the "serious" computers were used through networks and terminals and didn't even come with any ability to connect a monitor or a keyboard (although a serial terminal would work as the system console). I used to joke (usually looking at Unisys Windows-based big servers), if the computer had VGA and PS/2 ports, it wasn't a computer, but a toy. Those Unisys servers weren't toys, but you could run Pinball and Minesweeper directly on them, which kind of said otherwise. I think we got used to such levels of platform bloat that we don't care if the UI toolkit these days is bigger than the entire operating system that runs 95% of the world's payment transactions.
- pjmlp 8mo ago
  Those of us that keep using Windows or macOS, can still find native applications for many cases, especially because the culture of accepting to pay for small utilities. It is the Year of Desktop Linux that keeps being inundated with Electron crap, to detriment of Gtk, Qt, KDE, and whatever else is out there.
  - dd_xplore 8mo ago
    Linux apps today dont have that feel of apps that we had in 98/2000 era or even XP era. Windows platform had really good apps.
runeks 8mo ago
Wouldn't the compiler take care of producing the correct machine code?
- mhh__ 8mo ago
  The compiler relies on the language and programmer to enforce and follow a memory consistency model
- octachron 8mo ago
  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 8mo ago
    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.
  - rbanffy 8mo ago
    This architecture trick was often used for precisely this - finding bugs in the program that would work in one architecture and fail in another. A very common class of issues like these was about endianness, and PowerPC was very handy because it could boot as both high and low-endian modes (I think I remember different versions of Linux for each mode, but I'm no longer sure).
    - jasomill 8mo ago
      Starting with POWER8, the Linux kernel and some of the BSDs support 64-bit PowerPC in both big- and little-endian modes. Older PowerPC chips had more limited support for little-endian, and all the commercial desktop/server PowerPC OSes that come immediately to mind (classic Mac OS, Mac OS X, NEXTSTEP / OpenStep, OS/400 / IBM i, AIX, BeOS) are big-endian only. As you'd expect, Linux distribution support for big- and little-endian varies.
jordiburgos 8mo ago
Only for the hand-written assemply parts of the source code. The rest will be handled by the compilers.
- silon42 8mo ago
  Not even close. Except maybe in Rust /s
  - galangalalgol 8mo ago
    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.
- bpye 8mo ago
  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.
vardump 8mo ago
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.
- Fire-Dragon-DoL 8mo ago
  Is this only for constants or even for instructions? Like: a=fooMethod(); b=otherMethod() Will this be reordered?
  - vardump 8mo ago
    Depends on the processor's store queue. It might be. Of course if otherMethod() is anything more complicated, 'a' will almost certainly be assigned first. Of course you should still do the order dependent assignment correctly, like by using C++ std::memory_order or atomics.
Zardoz84 8mo ago
If it is programmed in assembly. This kind of nasty detail should be handled by the compilers.
- askl 8mo ago
  If it's programmed in assembly, it just wont compile for a different architecture.
cmrdporcupine 8mo ago
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.
IshKebab 8mo ago
I think that's less likely than you'd expect because the memory ordering model used by C++ and others essentially requires you to write code that works even without x86's total storage order. If you don't then you can get bugs even on x86, because the compiler will violate the ordering you thought you had in your program, even if the CPU doesn't. Also most software runs on ARM now and I don't think that has actually happened in practice.
- rbanffy 8mo ago
  > Also most software runs on ARM now and I don't think that has actually happened in practice. At least in my house, ARM cores outnumber x86 cores by at least four to one. And I'm not even counting the 32-bit ARM cores in embedded devices. There is a lot of space for memory ordering bugs to manifest in all those devices.
  - IshKebab 8mo ago
    The number of cores is fairly similar actually. X86 has been commonly 2 or 4 core for decades, and ARM is only recently more than that.
- wat10000 8mo ago
  It's definitely a real issue in real code, since the CPU isn't bound by things like function boundaries or alias analysis or pointer validity. For example: x = *a; if (x) y = *b; The compiler cannot reorder the load of b before the load of a, because it may not be a valid pointer if x is false. But the CPU is free to speculate long ahead, and if the pointer in b isn't valid, that's fine, the CPU can attempt a speculative load and fail. It's not particularly common and code that has this issue will probably crash only rarely, but it's not too hard to do.
  - IshKebab 8mo ago
    I don't understand your example. That code is correct on both architectures.
martin1975 7mo ago
Curious, what type of code and in what language do you write that the compiler wouldn't take care of this without you even trying?

by dinglo 8mo ago

ivolimmen 8mo ago

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.

dd_xplore 8mo ago

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.

rbanffy 8mo ago
> Nowadays most PCs feel like a random terminal It's a fun perception. For the longest time, all the "serious" computers were used through networks and terminals and didn't even come with any ability to connect a monitor or a keyboard (although a serial terminal would work as the system console). I used to joke (usually looking at Unisys Windows-based big servers), if the computer had VGA and PS/2 ports, it wasn't a computer, but a toy. Those Unisys servers weren't toys, but you could run Pinball and Minesweeper directly on them, which kind of said otherwise. I think we got used to such levels of platform bloat that we don't care if the UI toolkit these days is bigger than the entire operating system that runs 95% of the world's payment transactions.
pjmlp 8mo ago
Those of us that keep using Windows or macOS, can still find native applications for many cases, especially because the culture of accepting to pay for small utilities. It is the Year of Desktop Linux that keeps being inundated with Electron crap, to detriment of Gtk, Qt, KDE, and whatever else is out there.
- dd_xplore 8mo ago
  Linux apps today dont have that feel of apps that we had in 98/2000 era or even XP era. Windows platform had really good apps.

runeks 8mo ago

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

mhh__ 8mo ago
The compiler relies on the language and programmer to enforce and follow a memory consistency model
octachron 8mo ago
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 8mo ago
  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.
- rbanffy 8mo ago
  This architecture trick was often used for precisely this - finding bugs in the program that would work in one architecture and fail in another. A very common class of issues like these was about endianness, and PowerPC was very handy because it could boot as both high and low-endian modes (I think I remember different versions of Linux for each mode, but I'm no longer sure).
  - jasomill 8mo ago
    Starting with POWER8, the Linux kernel and some of the BSDs support 64-bit PowerPC in both big- and little-endian modes. Older PowerPC chips had more limited support for little-endian, and all the commercial desktop/server PowerPC OSes that come immediately to mind (classic Mac OS, Mac OS X, NEXTSTEP / OpenStep, OS/400 / IBM i, AIX, BeOS) are big-endian only. As you'd expect, Linux distribution support for big- and little-endian varies.

jordiburgos 8mo ago

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

silon42 8mo ago
Not even close. Except maybe in Rust /s
- galangalalgol 8mo ago
  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.
bpye 8mo ago
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.

vardump 8mo ago

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.

Fire-Dragon-DoL 8mo ago
Is this only for constants or even for instructions? Like: a=fooMethod(); b=otherMethod() Will this be reordered?
- vardump 8mo ago
  Depends on the processor's store queue. It might be. Of course if otherMethod() is anything more complicated, 'a' will almost certainly be assigned first. Of course you should still do the order dependent assignment correctly, like by using C++ std::memory_order or atomics.

Zardoz84 8mo ago

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

askl 8mo ago
If it's programmed in assembly, it just wont compile for a different architecture.

cmrdporcupine 8mo ago

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.

IshKebab 8mo ago

I think that's less likely than you'd expect because the memory ordering model used by C++ and others essentially requires you to write code that works even without x86's total storage order. If you don't then you can get bugs even on x86, because the compiler will violate the ordering you thought you had in your program, even if the CPU doesn't. Also most software runs on ARM now and I don't think that has actually happened in practice.

rbanffy 8mo ago
> Also most software runs on ARM now and I don't think that has actually happened in practice. At least in my house, ARM cores outnumber x86 cores by at least four to one. And I'm not even counting the 32-bit ARM cores in embedded devices. There is a lot of space for memory ordering bugs to manifest in all those devices.
- IshKebab 8mo ago
  The number of cores is fairly similar actually. X86 has been commonly 2 or 4 core for decades, and ARM is only recently more than that.
wat10000 8mo ago
It's definitely a real issue in real code, since the CPU isn't bound by things like function boundaries or alias analysis or pointer validity. For example: x = *a; if (x) y = *b; The compiler cannot reorder the load of b before the load of a, because it may not be a valid pointer if x is false. But the CPU is free to speculate long ahead, and if the pointer in b isn't valid, that's fine, the CPU can attempt a speculative load and fail. It's not particularly common and code that has this issue will probably crash only rarely, but it's not too hard to do.
- IshKebab 8mo ago
  I don't understand your example. That code is correct on both architectures.

martin1975 7mo ago

Curious, what type of code and in what language do you write that the compiler wouldn't take care of this without you even trying?