__restrict

[Manu]

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.
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...

On 20 October 2011 05:25, Robert Jacques <sandford at jhu.edu> wrote:

> On Wed, 19 Oct 2011 17:10:55 -0400, Peter Alexander <
> peter.alexander.au at gmail.com> wrote:
>
>  On 19/10/11 3:08 PM, Robert Jacques wrote:
>>
>>> On Wed, 19 Oct 2011 07:58:15 -0400, Manu <turkeyman at gmail.com> wrote:
>>>
>>>> I agree, that is certainly more important :)
>>>>
>>>> I'm mainly just curious to know about how the main contributors feel
>>>> about
>>>> these things, and whether these things will be implemented/planned, or
>>>> if
>>>> they violate some fundamental language principles...
>>>> Basically, I really want to start some major work in D, but before
>>>> investing
>>>> into the language, I want to know that important features are
>>>> recognised and
>>>> have a long term plan...
>>>>
>>>
>>> Well, __restrict was mainly added to C (IIRC), to allow loop
>>> vectorization. In D, we have explicit array operations, which carry a
>>> lot of the same caveats as __restrict, except are checkable.
>>>
>>
>> It's for far more than vectorization. Any place that has redundant loads
>> can benefit from __restrict.
>>
>> I recommend this presentation on the subject:
>> http://www.slideshare.net/**guest3eed30/memory-**optimization<http://www.slideshare.net/guest3eed30/memory-optimization>
>>
>> It's about memory optimizations. Aliasing issues start at slide 35.
>>
>>
> Thanks. I've seen most of that before. And even in those slide, the major
> (though not only) use-case for __restrict is with array and matrix
> processing. Most other use-cases can be cached manually or are really,
> really unsafe.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111020/746dbf2b/attachment.html>