3 ms·

Some call the Alpha memory model useful, some call it completely fucking insane. Dependent loads can be reordered! The mental overhead of working in that parad

by xxpor 3y ago

Some call the Alpha memory model useful, some call it completely fucking insane. Dependent loads can be reordered! The mental overhead of working in that paradigm is just not worth it.

toast0 3y ago
I'm not saying it's good for the overall system. Your choice on that. I'm just saying it's a useful memory model for making sure all your memory fences are in place. If you can run your OS/application there, it's hard to find a place it won't run. That said, Alphas were mighty fast during their prime, I don't know if that was enabled by the insane memory model or just coincidence?
- aidenn0 3y ago
  > That said, Alphas were mighty fast during their prime, I don't know if that was enabled by the insane memory model or just coincidence? There were many of the same people working on: - First 3 generations of DEC Alpha - StrongARM - SiByte MIPS (later purchased and rebranded by Broadcom) - PASemi POWER - PASemi was then aqui-hired by Apple for making ARM chips These don't have any particularly unifying memory model, but were all quite performant, so while this may be a different coincidence, I suspect that the people involved are more likely a contributing factor to the performance than the memory model.
  - meepmorp 3y ago
    Don't forget forget AMD
- xxpor 3y ago
  >I'm just saying it's a useful memory model for making sure all your memory fences are in place. Oh for sure. It's just that it's like saying a nuclear bunker will be fine if you drop a pound of dynamite on it :) >I don't know if that was enabled by the insane memory model I have to imagine it was, especially since back then the "optimization" parts of CPUs weren't nearly as advanced as they are today (branch predictors, OOO execution that still maintains the memory model guarantees, etc). Alphas were dead before my time, but I have to imagine the tradeoff was a) their expense, and b) the time it actually took to write software and track down concurrency bugs due to everything being talked about here.
zdw 3y ago
Security folks depend on this for correctness checks - OpenBSD in particular continues to supports Alpha (memory access reordering, alignment requirements) and Sparc64 (big endian, register windows), as well as the usual suspects, which frequently finds bugs that wouldn't be found on platforms without those "unusual" characteristics.
- xxpor 3y ago
  Specifically on memory ordering bugs though, philosophically speaking, are they actually bugs if the condition is impossible to hit on a given platform? From an OpenBSD perspective, I can see it being valuable to know that it means the code can be safely ported to any random arch that comes out in the future, but for more commercial software, I really can't see that being worth the time worrying about.
  - nyanpasu64 3y ago
    I think compilers are free to reorder code at compile time assuming single-threaded execution, exposing the same bugs that memory ordering exposes at runtime. I'm not sure if MSVC does this or not.
    - xxpor 3y ago
      There are a lot of details, but essentially yes. To solve that, see the compiler barriers section in https://www.kernel.org/doc/Documentation/memory-barriers.txt https://www.kernel.org/doc/Documentation/memory-barriers.txt

by xxpor 3y ago

Some call the Alpha memory model useful, some call it completely fucking insane. Dependent loads can be reordered! The mental overhead of working in that paradigm is just not worth it.

toast0 3y ago

I'm not saying it's good for the overall system. Your choice on that. I'm just saying it's a useful memory model for making sure all your memory fences are in place. If you can run your OS/application there, it's hard to find a place it won't run. That said, Alphas were mighty fast during their prime, I don't know if that was enabled by the insane memory model or just coincidence?

aidenn0 3y ago
> That said, Alphas were mighty fast during their prime, I don't know if that was enabled by the insane memory model or just coincidence? There were many of the same people working on: - First 3 generations of DEC Alpha - StrongARM - SiByte MIPS (later purchased and rebranded by Broadcom) - PASemi POWER - PASemi was then aqui-hired by Apple for making ARM chips These don't have any particularly unifying memory model, but were all quite performant, so while this may be a different coincidence, I suspect that the people involved are more likely a contributing factor to the performance than the memory model.
- meepmorp 3y ago
  Don't forget forget AMD
xxpor 3y ago
>I'm just saying it's a useful memory model for making sure all your memory fences are in place. Oh for sure. It's just that it's like saying a nuclear bunker will be fine if you drop a pound of dynamite on it :) >I don't know if that was enabled by the insane memory model I have to imagine it was, especially since back then the "optimization" parts of CPUs weren't nearly as advanced as they are today (branch predictors, OOO execution that still maintains the memory model guarantees, etc). Alphas were dead before my time, but I have to imagine the tradeoff was a) their expense, and b) the time it actually took to write software and track down concurrency bugs due to everything being talked about here.

zdw 3y ago

Security folks depend on this for correctness checks - OpenBSD in particular continues to supports Alpha (memory access reordering, alignment requirements) and Sparc64 (big endian, register windows), as well as the usual suspects, which frequently finds bugs that wouldn't be found on platforms without those "unusual" characteristics.

xxpor 3y ago
Specifically on memory ordering bugs though, philosophically speaking, are they actually bugs if the condition is impossible to hit on a given platform? From an OpenBSD perspective, I can see it being valuable to know that it means the code can be safely ported to any random arch that comes out in the future, but for more commercial software, I really can't see that being worth the time worrying about.
- nyanpasu64 3y ago
  I think compilers are free to reorder code at compile time assuming single-threaded execution, exposing the same bugs that memory ordering exposes at runtime. I'm not sure if MSVC does this or not.
  - xxpor 3y ago
    There are a lot of details, but essentially yes. To solve that, see the compiler barriers section in https://www.kernel.org/doc/Documentation/memory-barriers.txt https://www.kernel.org/doc/Documentation/memory-barriers.txt