3 ms·
Yes, that's precisely the tradeoff the parent is talking about — relaxed ordering enables faster clocks, but you end up paying for that clock speed when you nee
by pdpi 7y ago
Yes, that's precisely the tradeoff the parent is talking about — relaxed ordering enables faster clocks, but you end up paying for that clock speed when you need more, more expensive, barriers.
- gpderetta 7y agoYes and I'm saying that in practice as an architecture matures, especially in the multicore era, expensive barriers are no longer acceptable and even relaxed mode architectures have to introduce the same optimisations that stronger architectures had to introduce earlier on, negating a lot of the advantages of having a relaxed memory model in the first place.
- notacoward 7y agoHave you considered alternatives besides always-on total ordering and weak ordering with full barriers? Various forms of partial barriers already exist. In theory, they can preserve the performance wins from weak ordering. In practice, programmers seem to have even more trouble reasoning about them than they do with full barriers. That's why I expressed ambivalence above. I don't have the certainty that comes with mere speculation.
- gpderetta 7y agoWell x86 itself requires barriers for store/loads; the cost of such a barrier had been going down for a few generations but improvements have stalled recently. Recent ARMs apparently have cheap explicit load acquire and store release which are great and map very well to the c11 memory model. If this means they need to use less transistors or save some power, that's even better. The issue is with some RISCs were even implemeting acquire/release semantic requires expensive barriers (and seq cst requires even more expensive barriers), the only alternative being address or flow control dependent loads which are hard to reason about in higher level languages. And then there was alpha were even load consume required a barrier.