5 ms·

Why should the hardware do something software can take care of just as well was the design philosophy here.

by wbl 7y ago

ajross 7y ago
Because when it doesn't, it leads to "insane" results like the one upthread. Reasoning about memory barriers is outrageously hard, and asymptotic software quality is outrageously expensive. At the end of the day an x86 kernel is going to have fewer race conditions than one for a traditional architecture, and that's worth something. This is a lesson that software folks have been pushing with tools like static typing and memory lifetime analysis. The same applies at the hardware level.
- zozbot234 7y ago
  You "just" need a memory barrier on every ptr indirection (including array indexing, etc.) that might go through something that's being shared among multiple threads. The more interesting question is whether requiring that additional barrier buys more performance in the typical case where you're not touching shared data.
  - BeeOnRope 7y ago
    > The more interesting question is whether requiring that additional barrier buys more performance in the typical case where you're not touching shared data. Probably yes, i.e., there was some hardware reason for it. You can find one explanation [1] floating about that explains the effect was due to the cache banking design, with separate invalidation queues for each bank. Presumably that was better in some respect than the alternative designs available to implementors. That said, the difference is probably fairly small and if Alpha were around today they would almost certain want to abandon that particular reordering since they are the only one doing it and there would be a lot of pressure on them to make it fast (this comes up in all sorts of non-trivial scenarios like double checked locking, reads of final fields in Java, etc). That's generally the pattern, I think: if you are the odd man out with the weakest model, and you aren't the dominant player, you will have a lot of pressure to at least offer fast ways of lining up with the stronger models. So even if a weak model is a better design point in a vacuum, it might not be true when real-world implementation pressures are considered. --- [1] http://lse.sourceforge.net/locking/wmbdd.html http://lse.sourceforge.net/locking/wmbdd.html

Why should the hardware do something software can take care of just as well was the design philosophy here.

by wbl 7y ago

Why should the hardware do something software can take care of just as well was the design philosophy here.

Because when it doesn't, it leads to "insane" results like the one upthread. Reasoning about memory barriers is outrageously hard, and asymptotic software quality is outrageously expensive. At the end of the day an x86 kernel is going to have fewer race conditions than one for a traditional architecture, and that's worth something. This is a lesson that software folks have been pushing with tools like static typing and memory lifetime analysis. The same applies at the hardware level.

zozbot234 7y ago
You "just" need a memory barrier on every ptr indirection (including array indexing, etc.) that might go through something that's being shared among multiple threads. The more interesting question is whether requiring that additional barrier buys more performance in the typical case where you're not touching shared data.
- BeeOnRope 7y ago
  > The more interesting question is whether requiring that additional barrier buys more performance in the typical case where you're not touching shared data. Probably yes, i.e., there was some hardware reason for it. You can find one explanation [1] floating about that explains the effect was due to the cache banking design, with separate invalidation queues for each bank. Presumably that was better in some respect than the alternative designs available to implementors. That said, the difference is probably fairly small and if Alpha were around today they would almost certain want to abandon that particular reordering since they are the only one doing it and there would be a lot of pressure on them to make it fast (this comes up in all sorts of non-trivial scenarios like double checked locking, reads of final fields in Java, etc). That's generally the pattern, I think: if you are the odd man out with the weakest model, and you aren't the dominant player, you will have a lot of pressure to at least offer fast ways of lining up with the stronger models. So even if a weak model is a better design point in a vacuum, it might not be true when real-world implementation pressures are considered. --- [1] http://lse.sourceforge.net/locking/wmbdd.html http://lse.sourceforge.net/locking/wmbdd.html