5 ms·

Only if you have racy accesses which you should not.

by wbl 3y ago

jeffbee 3y ago
If you think it's that simple you are exactly the kind of developer who would never have succeeded in programming the DEC Alpha. On the Alpha, even dependent loads and stores can be reordered by the hardware and observed in any non-program order on other CPUs. So if CPU 1 sets X to 42 and takes the address of X, and CPU 2 dereferences X, it can observe any value of X, 42 or whatever, even if both CPUs used explicit memory fences with regards to the address of X. This was so hard to grok that the Linux kernel was broken on Alpha during the entire lifetime of the CPU, not fixed until January 2018. The Alpha is so weak and hard to use that half the C++11 explicit memory ordering stuff is only relevant to that CPU.
- mhh__ 3y ago
  How many people independently need to work it out? I doubt most python programmers know what atomics are and yet they persist.
  - jeffbee 3y ago
    In this context it is relevant. Nobody was programming anything in Python in 1992. The question is, how much of Alpha's apparent performance was real, and how much was due to the missing memory barriers causing programs to go faster and produce surprising (incorrect) results, interspersed with the odd mysterious crash?
    - mhh__ 3y ago
      How many threaded programs in general were there? The only SPEC (or SPEC-like) benchmarks I tend to pay attention to are single-threaded, multi-process (i.e. compile times) - Unless these bugs were in te kernel I'd imagine most unix-y workflows would be unaffected.
    - notacoward 3y ago
      I don't think you're giving much credit to people who were programming multi-processor systems at that time. As @mhh_ points out, the vast majority weren't writing code that was multi-threaded at all. Of those who were, fewer still were writing the kind of code that was so tightly synchronized that these issues would even surface. OS engineers (such as myself) and others who did so were typically much closer to the hardware and aware that it was a rapidly evolving field, so they knew to watch out for these kinds of land mines. If you want to cite "surprising results" and "odd mysterious crashes" try making it more than conjecture by providing some data. I was there and such things didn't seem particularly more common on Alpha than elsewhere. Years later, as I said somewhere in this thread, I worked with another (MIPS-based) chip designed by some of the Alpha engineers, with the same predilection for weak memory ordering. In about two years, I found three bugs related to missing memory barriers - one in NFS, one in NBD, and one in Lustre (which isn't even part of the kernel). Yes, they were a pain to debug. Part of the reason is that they would occur so damn rarely. Damn near 100% of the time the "vulnerable" code would run just fine anyway. Writing reproducers was a serious challenge. More importantly, these bugs were dwarfed by bugs of many other more familiar types - use after free, deadlock, protocol errors, etc. Any bugginess attributable to the weak memory model was noise. So yeah, Alpha's performance was very real. Using hypotheticals to bash it in pseudo-retrospect seems uncharitable, to say the least.
- mhh__ 3y ago
  Also given that Apple (and SPARC) chips have a means to vary the memory model at runtime, I think the way things would go if memory consistency was genuinely blocking Alpha's progress then they'd change it. It wouldn't be an easy thing to stomach but we have about ten billion flavours of X86 and Arm sub-ISAs floating around today

Only if you have racy accesses which you should not.

by wbl 3y ago

Only if you have racy accesses which you should not.

If you think it's that simple you are exactly the kind of developer who would never have succeeded in programming the DEC Alpha. On the Alpha, even dependent loads and stores can be reordered by the hardware and observed in any non-program order on other CPUs. So if CPU 1 sets X to 42 and takes the address of X, and CPU 2 dereferences X, it can observe any value of X, 42 or whatever, even if both CPUs used explicit memory fences with regards to the address of X. This was so hard to grok that the Linux kernel was broken on Alpha during the entire lifetime of the CPU, not fixed until January 2018. The Alpha is so weak and hard to use that half the C++11 explicit memory ordering stuff is only relevant to that CPU.

mhh__ 3y ago
How many people independently need to work it out? I doubt most python programmers know what atomics are and yet they persist.
- jeffbee 3y ago
  In this context it is relevant. Nobody was programming anything in Python in 1992. The question is, how much of Alpha's apparent performance was real, and how much was due to the missing memory barriers causing programs to go faster and produce surprising (incorrect) results, interspersed with the odd mysterious crash?
  - mhh__ 3y ago
    How many threaded programs in general were there? The only SPEC (or SPEC-like) benchmarks I tend to pay attention to are single-threaded, multi-process (i.e. compile times) - Unless these bugs were in te kernel I'd imagine most unix-y workflows would be unaffected.
  - notacoward 3y ago
    I don't think you're giving much credit to people who were programming multi-processor systems at that time. As @mhh_ points out, the vast majority weren't writing code that was multi-threaded at all. Of those who were, fewer still were writing the kind of code that was so tightly synchronized that these issues would even surface. OS engineers (such as myself) and others who did so were typically much closer to the hardware and aware that it was a rapidly evolving field, so they knew to watch out for these kinds of land mines. If you want to cite "surprising results" and "odd mysterious crashes" try making it more than conjecture by providing some data. I was there and such things didn't seem particularly more common on Alpha than elsewhere. Years later, as I said somewhere in this thread, I worked with another (MIPS-based) chip designed by some of the Alpha engineers, with the same predilection for weak memory ordering. In about two years, I found three bugs related to missing memory barriers - one in NFS, one in NBD, and one in Lustre (which isn't even part of the kernel). Yes, they were a pain to debug. Part of the reason is that they would occur so damn rarely. Damn near 100% of the time the "vulnerable" code would run just fine anyway. Writing reproducers was a serious challenge. More importantly, these bugs were dwarfed by bugs of many other more familiar types - use after free, deadlock, protocol errors, etc. Any bugginess attributable to the weak memory model was noise. So yeah, Alpha's performance was very real. Using hypotheticals to bash it in pseudo-retrospect seems uncharitable, to say the least.
mhh__ 3y ago
Also given that Apple (and SPARC) chips have a means to vary the memory model at runtime, I think the way things would go if memory consistency was genuinely blocking Alpha's progress then they'd change it. It wouldn't be an easy thing to stomach but we have about ten billion flavours of X86 and Arm sub-ISAs floating around today