4 ms·

How do you mean? On x86 even if you have the assembly, you don’t know what order loads and stores will execute in. Depending on the architecture there will be s

How do you mean? On x86 even if you have the assembly, you don’t know what order loads and stores will execute in. Depending on the architecture there will be some constraints, but usually not enough to guarantee a particular order. That is why barriers exist.

saagarjha 7y ago
On x86_64 this is the only kind of reordering that is allowed; there are other things that presented in a way that guarantees apparent order.
ajross 7y ago
Memory barriers (also cache control mechanisms) are documented by the architecture, and are exposed as instructions or similar hardware interfaces. Obviously OO execution exists, but it's not a magical insurmountable fence (see what I did there?) that blocks all optimization. It has well-specified rules on every architecture. If it didn't, concurrent code couldn't be written correctly at all. And on x86, the rules amount to "the processor will expend herculean effort to make sure that all memory orderings look identical to all readers in the system" (with a few oddball exceptions, read the SDM, yada yada). Really, on x86 you pretty much don't have to worry about this. If two memory operations happen in a given sequence in the disassembly, literally everyone who reads those locations will agree they happened in the order presented, no matter what optimizations the hardware might have done internally.
- Skunkleton 7y ago
  Sure, as long as DMA or SMP isn’t involved. And I’m not sure why you are bringing up optimizations here? Out of order memory access is itself a fairly important optimization, why would it preclude optimization?
  - bluGill 7y ago
    On x86 the architecture guarantees memory read/write order. They are not allowed to make some important optimizations because it would change observed memory read/write. DMA or SMP makes no difference to this. On most other architectures the CPU can and will change memory read/write order. As a result there is a lot of multi-threaded code that works correctly on x86 that fails when run elsewhere.
    - Skunkleton 7y ago
      X86 absolutely can make observable reorderings. Here’s a link with citations to Intel docs if anyone wants to read more. https://bartoszmilewski.com/2008/11/05/who-ordered-memory-fences-on-an-x86/ https://bartoszmilewski.com/2008/11/05/who-ordered-memory-fe...
      - ajross 7y ago
        FWIW: this gets argued about occasionally, but consensus seems to be that the cited line in the SDM is documenting a misfeature on an older CPU (though the details escape me about which it is). That effect is, IIRC, not observable on current hardware.
        Skunkleton 7y ago
        Maybe. I’ve implemented a ring buffer that is used between two virtual machine domains. There were a few places where barriers were needed. If they were removed the ring buffer would start corrupting data. These barriers are in addition to the many obviously needed compiler barriers.

saagarjha 7y ago

On x86_64 this is the only kind of reordering that is allowed; there are other things that presented in a way that guarantees apparent order.

ajross 7y ago

Memory barriers (also cache control mechanisms) are documented by the architecture, and are exposed as instructions or similar hardware interfaces. Obviously OO execution exists, but it's not a magical insurmountable fence (see what I did there?) that blocks all optimization. It has well-specified rules on every architecture. If it didn't, concurrent code couldn't be written correctly at all. And on x86, the rules amount to "the processor will expend herculean effort to make sure that all memory orderings look identical to all readers in the system" (with a few oddball exceptions, read the SDM, yada yada). Really, on x86 you pretty much don't have to worry about this. If two memory operations happen in a given sequence in the disassembly, literally everyone who reads those locations will agree they happened in the order presented, no matter what optimizations the hardware might have done internally.

Skunkleton 7y ago
Sure, as long as DMA or SMP isn’t involved. And I’m not sure why you are bringing up optimizations here? Out of order memory access is itself a fairly important optimization, why would it preclude optimization?
- bluGill 7y ago
  On x86 the architecture guarantees memory read/write order. They are not allowed to make some important optimizations because it would change observed memory read/write. DMA or SMP makes no difference to this. On most other architectures the CPU can and will change memory read/write order. As a result there is a lot of multi-threaded code that works correctly on x86 that fails when run elsewhere.
  - Skunkleton 7y ago
    X86 absolutely can make observable reorderings. Here’s a link with citations to Intel docs if anyone wants to read more. https://bartoszmilewski.com/2008/11/05/who-ordered-memory-fences-on-an-x86/ https://bartoszmilewski.com/2008/11/05/who-ordered-memory-fe...
    - ajross 7y ago
      FWIW: this gets argued about occasionally, but consensus seems to be that the cited line in the SDM is documenting a misfeature on an older CPU (though the details escape me about which it is). That effect is, IIRC, not observable on current hardware.
      - Skunkleton 7y ago
        Maybe. I’ve implemented a ring buffer that is used between two virtual machine domains. There were a few places where barriers were needed. If they were removed the ring buffer would start corrupting data. These barriers are in addition to the many obviously needed compiler barriers.