__restrict

[Don]

On 19.10.2011 10:41, Manu wrote:
> I sent an email about this once before... but there was no real
> response/discussion on the topic.
>
> I just want to emphasise the importance of __restrict in optimising hot
> code, and I'm curious to know if there has already been discussion on
> the matter? Plans for implementation? Workarounds?
> I'd have thought that surely guys like Don would have considered and
> care about these details intimately?
>
> - Manu

In addition to what others have said, __restrict is not very low-hanging 
fruit for D.

The main reason for this is that D's arrays always know their length.
(Somebody mentioned array operations, but I don't think they are 
terribly important for __restrict; rather, it's the fact that arrays 
retain their length information).
Many operations which would be done with pointers in C, are done with 
arrays in D, and it's very easy to check for aliasing of arrays. 
Pointers aren't even allowed in @safe code.

A secondary reason is that D has immutable. Unlike C++'s const, this 
*can* be used for optimisation. And we also have the guarantee that 
memory is not shared between threads.

In view of this, it's not at all clear to me that the C __restrict 
concept is immediately applicable to D without modification.

Thus:
(1) __restrict is more important (has wider applicability) in C than in D;
(2) some very important array and immutable optimisations haven't been 
done yet; it is believed that they will have a far bigger impact than 
__restrict.

So __restrict is a low priority at this stage.