On Fri, 21 Oct 2011 02:19:03 -0400, Manu <turkey...@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.
