__restrict

[Robert Jacques]

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.

> I'm curious to know what you mean by "maybe also because in D where possible
> we prefer things that the compiler is able to verify/enforce". I'm not sure
> how that really applies to __restrict. It's effectively an optimisation hint
> to the compiler, giving it explicit instructions... what would there be to
> verify or enforce in this case?

That's the point, the compiler can't verify or enforce the assumptions of __restrict. Think of array indexing in C. The compiler has no way of verifying or enforcing that ptr[10_000] is a valid memory location. And this has lead to undefined behavior and a large number of security exploits. In D, the arrays always carry around their lengths, so indexes can be checked. No more undefined behavior and less exploits. Similarly, C's const provides no actual guarantees. But compilers used it to optimize code anyways, which has lead many a programmer to long hours debugging.

> Is it that it would be preferred if
> __restrict-ability could be implied by carefully crafted language rules?

Yes, and it is for array operations.

> I
> just don't think that's possible.. But it's still an important keyword.
>
> How difficult is it to contribute to D in these areas? Is that something
> that is encouraged, or is D still too embryonic to have random people coming
> along and adding things here and there?

It's very easy to contribute. The source code for DMD, LDC, GDC is all available and patches are regularly submitted and accepted. Check out D's github repositories and the mailing lists for more.

> On 19 October 2011 12:36, bearophile <bearophileHUGS at lycos.com> wrote:
>
>> Manu:
>>
>> > I sent an email about this once before... but there was no real
>> > response/discussion on the topic.
>>
>> It was discussed a bit in past, and restrict was not appreciated a lot,
>> maybe also because in D where possible we prefer things that the compiler is
>> able to verify/enforce.
>> And I think D/DMD is not yet in a development stage where it cares for max
>> performance details. I think there are plenty of more important things to
>> work on before that. The recently almost-fixed "inout" was more urgent than
>> "__restrict".
>>
>> Bye,
>> bearophile
>>