By: rwessel (robertwessel.delete@this.yahoo.com), August 17, 2014 10:40 am
Room: Moderated Discussions
Ronald Maas (rmaas.delete@this.wiwo.nl) on August 17, 2014 9:57 am wrote:
> Aaron Spink (aaronspink.delete@this.notearthlink.net) on August 17, 2014 12:42 am wrote:
> > That's because barriers are generally slow and annoying to use and weakly ordered
> > architectures need more of them. Strongly ordered architectures need less barriers
> > and because its effectively a common case, handle it much better.
> >
>
> In reality x86 will likely see the same amount of barriers compared
> to other architectures. This because of the following scenario:
> 1) Someone works on a project X that requires 5 memory barriers
> to function. On x86 everything works flawlessly
> 2) Got some critical bug reports because his software fails on other architectures. E.g. ARM
> 3) Spend time to track down the root cause of the problem and after adding 10 extra memory
> barriers in various places, finally the software start working properly on cores with weak
> memory ordering. Actually only 1 or 2 extra barriers where needed, but developer did not
> remove the unneeded ones because it is late already and need to catch some sleep
> 4) Next day developer gets paranoid as he/she does not want to spend other nights / week-ends burning the midnight
> oil, reviews the code, and for good measure puts in another extra 10 barriers in different sections of the
> code where he / she suspect it may be needed for e.g. PowerPC. Does not hurt to be careful. Right?
> 5) Now at the end of the day, all architectures see 25 memory barriers regardless
>
> It is not that developers are generally incompetent, but there are always corner cases that
> are not trivial to understand. As people in software developers usually work on a lot of pressure
> to deliver, they they do not have the luxury to spend reading through a whole bunch of PDFs
> in order to get a proper level of understanding. Especially when his / her manager is looking
> over his shoulder to make sure that persons actually works on solving the problem.
So the argument is now that x86 is so bad that even the screwups in other ISAs slow it down? ;-)
> Aaron Spink (aaronspink.delete@this.notearthlink.net) on August 17, 2014 12:42 am wrote:
> > That's because barriers are generally slow and annoying to use and weakly ordered
> > architectures need more of them. Strongly ordered architectures need less barriers
> > and because its effectively a common case, handle it much better.
> >
>
> In reality x86 will likely see the same amount of barriers compared
> to other architectures. This because of the following scenario:
> 1) Someone works on a project X that requires 5 memory barriers
> to function. On x86 everything works flawlessly
> 2) Got some critical bug reports because his software fails on other architectures. E.g. ARM
> 3) Spend time to track down the root cause of the problem and after adding 10 extra memory
> barriers in various places, finally the software start working properly on cores with weak
> memory ordering. Actually only 1 or 2 extra barriers where needed, but developer did not
> remove the unneeded ones because it is late already and need to catch some sleep
> 4) Next day developer gets paranoid as he/she does not want to spend other nights / week-ends burning the midnight
> oil, reviews the code, and for good measure puts in another extra 10 barriers in different sections of the
> code where he / she suspect it may be needed for e.g. PowerPC. Does not hurt to be careful. Right?
> 5) Now at the end of the day, all architectures see 25 memory barriers regardless
>
> It is not that developers are generally incompetent, but there are always corner cases that
> are not trivial to understand. As people in software developers usually work on a lot of pressure
> to deliver, they they do not have the luxury to spend reading through a whole bunch of PDFs
> in order to get a proper level of understanding. Especially when his / her manager is looking
> over his shoulder to make sure that persons actually works on solving the problem.
So the argument is now that x86 is so bad that even the screwups in other ISAs slow it down? ;-)