By: dmcq (dmcq.delete@this.fano.co.uk), July 8, 2015 10:11 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 8, 2015 8:23 am wrote:
> dmcq (dmcq.delete@this.fano.co.uk) on July 7, 2015 2:38 pm wrote:
> >
> > I think ARM would have been better off without those rules
> > at all and just depended on memory barrier instructions.
> > I guess they were left in because of having to cope with systems like Linux which were written for x86 and
> > don't properly describe for the hardware what is really required.
>
> Bzzt, wrong.
>
> Linux actually copes with weak memory ordering fine. Even the lack of data dependencies.
> We support alpha, after all, which has exactly that "only memory barriers" model.
>
> And that model is pure and utter garbage. All it results in is software having to add insane memory barriers
> that don't actually matter 99% of the time (because it's actually hard for hardware to screw up a dependency
> ordering), which in turn just makes normal code go slower - because the piece of crap hardware that doesn't
> normally do memory orderings usually goes much slower when you say "uhhuh, now you need to be careful".
>
> Plus it results in bugs, because code that works on one microarchutecture may not work on another.
>
> Now, the weak memory ordering people go "but that code was buggy to begin with", which just shows that
> they don't understand software. Show me a piece of bugfree software, and I will show you a piece of useless
> software. Seriously. Bugs happen. Even when you're careful. The way those bugs get noticed is by testing.
> If you cannot accept that, then you should take up another vocation. Maybe farming.
>
> If your architecture model is designed so that testing is basically meaningless because your architecture
> under-defines behavior, then your architecture is objectively inferior. Really. It's that simple. It's
> not a "balance between software and hardware" or a matter of opinion. It's a cold hard fact.
>
> The whole objectively inferior thing has some really nasty interaction at a high level too. The
> broken ARM and Power memory model causes pain right now for the C standards committee that is trying
> to come up with ways to do efficient threading. Those people are sadly bending over backwards to
> make things architecture-neutral, resulting in an objectively worse standard. Oh well.
>
> Anyway, one big reason why the whole "data dependency is an implicit ordering" happens
> is that (a) it's fairly hard for hardware to screw that up (although it's been done, see
> alpha), and (b) it turns out that languages like Java actually required some memory ordering.
> You screw up too badly, and you screw Java (object construction in particular).
>
> But there are other reasons, and debugging is a major one.
>
> Weak memory ordering really is bad.
>
> Linus
If Linux copes with weak memory ordering and just using barriers then that is good. If a person wants to use shared data they should signal to the hardware that they are doing that - it should not be a general overhead. At the implementation level an architecture could implement the x86 way if that is more efficient overall but there is no particular evidence of that - only evidence that Intel have been able to spend huge amounts on trying to get round problems and that nobody has a clear idea now what their architecture is supposed to do except new processors should try and work around putting bugs into old code.
The design of the hardware is becoming more automated and straightforward rules are what are needed. You're probably well aware of the problems that crop up because the compilers are getting more intelligent and follow the specs so they can produce better optimised code. That is happening to processors. As they get more intelligent in following the specs we need proper markers on access to shared data. As well as straightforward testing we want to check the logic using test tools that can test all possible paths logically rather than just one path followed by one out of order processor. And that sort of thing would only be where performance is critical - elsewhere simplicity is the key to avoiding bugs.
> dmcq (dmcq.delete@this.fano.co.uk) on July 7, 2015 2:38 pm wrote:
> >
> > I think ARM would have been better off without those rules
> > at all and just depended on memory barrier instructions.
> > I guess they were left in because of having to cope with systems like Linux which were written for x86 and
> > don't properly describe for the hardware what is really required.
>
> Bzzt, wrong.
>
> Linux actually copes with weak memory ordering fine. Even the lack of data dependencies.
> We support alpha, after all, which has exactly that "only memory barriers" model.
>
> And that model is pure and utter garbage. All it results in is software having to add insane memory barriers
> that don't actually matter 99% of the time (because it's actually hard for hardware to screw up a dependency
> ordering), which in turn just makes normal code go slower - because the piece of crap hardware that doesn't
> normally do memory orderings usually goes much slower when you say "uhhuh, now you need to be careful".
>
> Plus it results in bugs, because code that works on one microarchutecture may not work on another.
>
> Now, the weak memory ordering people go "but that code was buggy to begin with", which just shows that
> they don't understand software. Show me a piece of bugfree software, and I will show you a piece of useless
> software. Seriously. Bugs happen. Even when you're careful. The way those bugs get noticed is by testing.
> If you cannot accept that, then you should take up another vocation. Maybe farming.
>
> If your architecture model is designed so that testing is basically meaningless because your architecture
> under-defines behavior, then your architecture is objectively inferior. Really. It's that simple. It's
> not a "balance between software and hardware" or a matter of opinion. It's a cold hard fact.
>
> The whole objectively inferior thing has some really nasty interaction at a high level too. The
> broken ARM and Power memory model causes pain right now for the C standards committee that is trying
> to come up with ways to do efficient threading. Those people are sadly bending over backwards to
> make things architecture-neutral, resulting in an objectively worse standard. Oh well.
>
> Anyway, one big reason why the whole "data dependency is an implicit ordering" happens
> is that (a) it's fairly hard for hardware to screw that up (although it's been done, see
> alpha), and (b) it turns out that languages like Java actually required some memory ordering.
> You screw up too badly, and you screw Java (object construction in particular).
>
> But there are other reasons, and debugging is a major one.
>
> Weak memory ordering really is bad.
>
> Linus
If Linux copes with weak memory ordering and just using barriers then that is good. If a person wants to use shared data they should signal to the hardware that they are doing that - it should not be a general overhead. At the implementation level an architecture could implement the x86 way if that is more efficient overall but there is no particular evidence of that - only evidence that Intel have been able to spend huge amounts on trying to get round problems and that nobody has a clear idea now what their architecture is supposed to do except new processors should try and work around putting bugs into old code.
The design of the hardware is becoming more automated and straightforward rules are what are needed. You're probably well aware of the problems that crop up because the compilers are getting more intelligent and follow the specs so they can produce better optimised code. That is happening to processors. As they get more intelligent in following the specs we need proper markers on access to shared data. As well as straightforward testing we want to check the logic using test tools that can test all possible paths logically rather than just one path followed by one out of order processor. And that sort of thing would only be where performance is critical - elsewhere simplicity is the key to avoiding bugs.
