__restrict

Manu turkeyman at gmail.com
Thu Oct 20 23:19:03 PDT 2011


Naturally, as with all my posts, I'm not referring to x86 :)
L1 is rarely ~1 cycle access, there are even a few architectures that can't
write to L1 at all, 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.

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

On 21 October 2011 06:49, Robert Jacques <sandford at jhu.edu> wrote:

> On Thu, 20 Oct 2011 07:37:22 -0400, Manu <turkeyman at gmail.com> wrote:
>
>> Caching results manually is very tedious work, and makes a mess of your
>> code.. If you've had to do that yourself you'd understand how annoying it
>> can be.
>>
>
> I do do it all the time and I've never found it that tedious. Especially
> compared to all the loop invariant divisions, expressions, function calls,
> etc you have to excise from the loop anyways... I mean, L1 cache has a
> latency of ~ 1 cycle, division is ~50-150 cycles.
>
>
>  Placing restrict on sensible pointers is much cleaner and saves a lot of
>> time, and also results in optimisation everywhere it is used, rather than
>> just the 1-2 places that you happened to notice it was a problem...
>>
>
> Except that you should only use __restrict where you notice a problem. In
> case you didn't know, C++ compilers do (did?) all the __restrict
> optimizations for const variables. And the systematic use of const on these
> compilers is a well known source of Heisen-bugs. I haven't heard that this
> 'feature' has been disabled, but its been a while since I checked.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111021/7d593f4a/attachment.html>


More information about the Digitalmars-d mailing list