__restrict

[Robert Jacques]

On Fri, 21 Oct 2011 02:19:03 -0400, Manu <turkeyman at gmail.com> wrote:
> Naturally, as with all my posts, I'm not referring to x86 :)

Naturally, stating that upfront would drastically improve our understanding and weighting of your arguments. :)

> L1 is rarely ~1 cycle access, there are even a few architectures that can't
> write to L1 at all,

And I work on GPU, so I can understand that pain. Then again, I'm so much more conscious of my code in those situations. For example, the following are not all created equal:

for(uint i = 0;        i <  length; i++)
for( int i = 0;        i <  length; i++)
for(uint i = length-1; i >= 0;      i--)
for( int i = length-1; i >= 0;      i--)

> and I've never come in contact with a compiler that can
> do anything useful with the const keyword in C. That said __restrict is
> fundamentally different than const, const suggests I can't change the
> memory pointed at, when that is often exactly what I intend to do.

My point, was that there are C++ compilers that do do things (not) useful with const, that are in principal the exact same things that would happen to a __restrict object. And it caused lots of hard to find bugs. So I feel safe in saying that usage of __restrict should never be wide spread. It should only be used in well understood and controlled code hot spots.

> It seems to be very hard to convince people who have never had to work on
> these platforms that it's really important :/

One of the best ways to do that it to prove it with numbers, with real code that a consciousness embedded developer could be expected to write.