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 <sandf...@jhu.edu> wrote: > On Wed, 19 Oct 2011 17:10:55 -0400, Peter Alexander < > peter.alexander...@gmail.com> wrote: > > On 19/10/11 3:08 PM, Robert Jacques wrote: >> >>> On Wed, 19 Oct 2011 07:58:15 -0400, Manu <turkey...@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. >