> Adding to andriew's comment, x86's more strict memory model reduces the hardware's flexibility and enforces a more strict ordering than usually required. If y

> Adding to andriew's comment, x86's more strict memory model reduces the hardware's flexibility and enforces a more strict ordering than usually required. If you think you really need the x86 memory model, you're probably doing something wrong, but can get it (at significant cost) by adding lots of memory fences. I think it's perfectly sensible to be weaker than x86. But having to deal with data dependency as you have to do on alpha is just too cumbersome / hard to get right. Acquire/Release (or read/write/full) memory barriers are quite easy to understand, but data dependency barriers are damned finnicky, and missing ones are really hard to debug. I'm more than a bit doubtful that the cost of a halfway sane (even if weak) coherency model is a relevant blocker in upping the scale of both CPUs core counts and applications. At the moment the biggest issue seems to be the ability of developers to write scalable software, and to come up with patterns that make write writing scalable software more realistic. I suspect there's room for selectively reducing the coherency effects of individual instructions in some memory models - e.g. x86 atomic instructions that don't essentially imply a full memory barrier (disregarding uncached access and such) would be great. Selectively lowering the coherency makes it possible to do so in the hottest codepaths.