I'm very new to D (literally as of yesterday), but am very impressed with what
I'm seeing so far.

Being that I want this language to succeed and an important part of that will be performance potential over C, I'm curious - how does/will D deal with the pointer 'aliasing problem' that plagues C and C++ compiler developers?

From what little I've seen so far, it seems that this same problem has been 'forced' on D by it's backward compatability with C libraries and C/C++ -like support for pointers.

IMHO, any language that seeks to replace C/C++ should do it's best to avoid this problem, or at least discourage code that introduces it.

In article <ceis7r$23bt$1@digitaldaemon.com>,
 Dave <Dave_member@pathlink.com> wrote:

> I'm very new to D (literally as of yesterday), but am very impressed with
> what
> I'm seeing so far.
> 
> Being that I want this language to succeed and an important part of that will
> be
> performance potential over C, I'm curious - how does/will D deal with the
> pointer 'aliasing problem' that plagues C and C++ compiler developers?
> 
> From what little I've seen so far, it seems that this same problem has been 'forced' on D by it's backward compatability with C libraries and C/C++ -like support for pointers.
> 
> IMHO, any language that seeks to replace C/C++ should do it's best to avoid
> this
> problem, or at least discourage code that introduces it.

What aliasing problem would you be referring too?  ( No D does not deal with it with denial, it's an honest question :)

In article <schancel-8833C7.08301601082004@digitalmars.com>, Sha Chancellor says...
>What aliasing problem would you be referring too?  ( No D does not deal with it with denial, it's an honest question :)

I should have been more specific - sorry.

Code like this:

extern int i;

In article <ceja1n$28um$1@digitaldaemon.com>, Dave says...
>
>I should have been more specific - sorry.
>
>Code like this:
>
>extern int i;

Bah - this was cut off somehow when I posted it, I'll try again..

Code like this:

;---

extern int i;

void func( int &ri )
{
for( int j = 0; j < 10; j++ ) {
ri++;
i++;
}
}

int main()
{
i = 10;
func(i);
printf("%d\n",i);
return 0;
}

;---

where 'ri' refers to 'i' the compiler has to keep an in-memory copy instead of binding 'i' to a register for example. I guess other optimizations opportunites are lossed as well, even if the aliasing doesn't happen in the program, unless the compiler is sophisticated enough to keep track of variables like this (which of course adds compile time, complexity, bugs, etc..).

C99 has the 'restrict' keyword, but many aren't happy with that solution. More on that here: http://www.cbau.freeserve.co.uk/Compiler/RestrictPointers.html

This 'aliasing problem' is oft refered to as a reason that FORTRAN (for example) is easier to write optimizers for.

Was this that stupid of a question or what? Seriously..

Anyone want to take a crack at it? Walter??

The reason I think this may be important for D is because a) a lot of scientific computing types aren't real happy with FORTRAN 95, b) they aren't real happy with C++ for many of the same reasons we aren't, c) they aren't real happy with Java (say what you will on the Java performance issue, but when you have to write C code in an an OOP language like Java to make it perform decently, it is not suitable for HPF.) and d) so, all this leaves it wide open for D to step in and make them happy, what with it's good support for native FP and built-in complex types and all. Plus, it was designed by a compiler developer ;)

IMHO, get the HPC folks (both end-users and tool vendors) interested in an OOP language that has the potential to crunch numbers fast and you have yourself a good foothold on the language market.

Thanks..

>In article <ceja1n$28um$1@digitaldaemon.com>, Dave says...
>>
>>I should have been more specific - sorry.
>>
>>Code like this:
>>
>>extern int i;
>
>Bah - this was cut off somehow when I posted it, I'll try again..
>
>Code like this:
>
>;---
>
>extern int i;
>
>void func( int &ri )
>{
>for( int j = 0; j < 10; j++ ) {
>ri++;
>i++;
>}
>}
>
>int main()
>{
>i = 10;
>func(i);
>printf("%d\n",i);
>return 0;
>}
>
>;---
>
>where 'ri' refers to 'i' the compiler has to keep an in-memory copy instead of binding 'i' to a register for example. I guess other optimizations opportunites are lossed as well, even if the aliasing doesn't happen in the program, unless the compiler is sophisticated enough to keep track of variables like this (which of course adds compile time, complexity, bugs, etc..).
>
>C99 has the 'restrict' keyword, but many aren't happy with that solution. More on that here: http://www.cbau.freeserve.co.uk/Compiler/RestrictPointers.html
>
>This 'aliasing problem' is oft refered to as a reason that FORTRAN (for example) is easier to write optimizers for.
>

In article <ceobns$1akh$1@digitaldaemon.com>, Dave says...
>
>Was this that stupid of a question or what? Seriously..

If I understand your question, the D version would be this:

int i;

void func( inout int ri )
{
for( int j = 0; j < 10; j++ ) {
ri++;
i++;
}
}

int main()
{
i = 10;
func(i);
printf("%d\n",i);
return 0;
}

Not a stupid question at all. See previous threads, for example
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5274
Norbet and Walter (and probably others) had a nice discussion about future
possibilities. Walter doesn't like "restrict" much either.

Dave wrote:

> 
> Was this that stupid of a question or what? Seriously..
> 
> Anyone want to take a crack at it? Walter??
> 
> The reason I think this may be important for D is because a) a lot of scientific computing types aren't real happy with FORTRAN 95, b) they aren't real happy with C++ for many of the same reasons we aren't, c) they aren't real happy with Java (say what you will on the Java performance issue, but when you have to write C code in an an OOP language like Java to make it perform decently, it is not suitable for HPF.) and d) so, all this leaves it wide open for D to step in and make them happy, what with it's good support for native FP and built-in complex types and all. Plus, it was designed by a compiler developer ;)
> 
> IMHO, get the HPC folks (both end-users and tool vendors) interested in an OOP language that has the potential to crunch numbers fast and you have yourself a good foothold on the language market.
> 
> Thanks..
> 
>>In article <ceja1n$28um$1@digitaldaemon.com>, Dave says...
>>>
>>>I should have been more specific - sorry.
>>>
>>>Code like this:
>>>
>>>extern int i;
>>
>>Bah - this was cut off somehow when I posted it, I'll try again..
>>
>>Code like this:
>>
>>;---
>>
>>extern int i;
>>
>>void func( int &ri )
>>{
>>for( int j = 0; j < 10; j++ ) {
>>ri++;
>>i++;
>>}
>>}
>>
>>int main()
>>{
>>i = 10;
>>func(i);
>>printf("%d\n",i);
>>return 0;
>>}
>>
>>;---
>>
>>where 'ri' refers to 'i' the compiler has to keep an in-memory copy instead of binding 'i' to a register for example. I guess other optimizations opportunites are lossed as well, even if the aliasing doesn't happen in the program, unless the compiler is sophisticated enough to keep track of variables like this (which of course adds compile time, complexity, bugs, etc..).
>>
>>C99 has the 'restrict' keyword, but many aren't happy with that solution. More on that here: http://www.cbau.freeserve.co.uk/Compiler/RestrictPointers.html
>>
>>This 'aliasing problem' is oft refered to as a reason that FORTRAN (for example) is easier to write optimizers for.
>>

In article <ceoed5$1btb$1@digitaldaemon.com>, Ben Hinkle says...
>
>Not a stupid question at all. See previous threads, for example
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5274
>Norbet and Walter (and probably others) had a nice discussion about future possibilities. Walter doesn't like "restrict" much either.

Also, I found some ever older threads using "aliasing problem" at http://www.digitalmars.com/advancedsearch.html:

http://www.digitalmars.com/d/archives/1913.html http://www.digitalmars.com/d/archives/333.html

(I think they relate to your topic, but I'm not 100% sure.)

jcc7

Doh! CTFA (Check the fargin' Archives). Sorry, and thanks for the responses and pointers to the archives.

Here are some from back a while.. Can anyone tell me if the non-overlapping array prohibition is still part of the spec.?

http://www.digitalmars.com/drn-bin/wwwnews?D/348 http://www.digitalmars.com/drn-bin/wwwnews?D/1926 http://www.digitalmars.com/drn-bin/wwwnews?D/18534 http://www.digitalmars.com/drn-bin/wwwnews?D/18543 http://www.digitalmars.com/drn-bin/wwwnews?D/17971

The following deal with exactly what my original post had in mind:

http://www.digitalmars.com/drn-bin/wwwnews?D/28260, to qoute Walter:

"Historically, adding in special keywords for such optimizations has not worked out well. That's why I was thinking of making it implicit for D function parameters."

I AGREE - let's do that (make it implicit, but warn in debug mode), or is it too
late?

http://www.digitalmars.com/drn-bin/wwwnews?D/28377, to qoute Walter again:

"I think it would be better to have the compiler assume they are not aliased (since that is by far the usual case) and have to say when they are not aliased. Also, a runtime check that they really are not aliased might be appropriate in debug mode."

I, again, wholeheartedly AGREE.

I'm with Drew here: http://www.digitalmars.com/drn-bin/wwwnews?D/28904

What is the state of this as far as D goes?

God Bless you Walter, I can see you put a lot of thought into memory layout for and vectorizing of arrays and such, and also the aliasing issue.

Hopefully these ideas (non-overlapping arrays and implicit no-alias with debug warning) have stood the test of time and v1 implementation so far. Because if they do, I think it covers a lot of the issue for not only HPC code, but also many other things now-a-days, like writing high-throughput socket code, database engines, AI engines, speech synthesis, etc., etc., etc...

It seems like Walter wants to give both us and compiler implementors a great high-performance base to work with..

Not only that, but consider this: In these days of cool, productive and decent performance interpreted languages like Perl, Python, etc. not to mention Java, many people are just not going to switch just because of excellent new features (most people think "their" language has enough features - after all, they've been able to "get by with it so-far").

Now, if you give them:

- High-performance on the order Fortran,
- Intuitive (implicit aliasing like C is NOT intuitive to most people using
Perl, VB, Java, etc. and therefore is the source of a lot of bugs to them),
- True OOP language with all the features of D,

THAT in total is a great reason to switch.

How about the compiler developers?? Many of them would quit en-masse if you told them they had to implement C++ all over again, except with MORE features ;)

Thanks for all of the pointers to the archived messages.

- Dave

In article <ceoed5$1btb$1@digitaldaemon.com>, Ben Hinkle says...
>
>Not a stupid question at all. See previous threads, for example
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5274
>Norbet and Walter (and probably others) had a nice discussion about future possibilities. Walter doesn't like "restrict" much either.
>
>Dave wrote:
>
>> 
>> Was this that stupid of a question or what? Seriously..

In article <ceoc3l$1apl$1@digitaldaemon.com>, Sean Kelly says...
>int i;
>
>void func( inout int ri )
>{
>for( int j = 0; j < 10; j++ ) {
>ri++;
>i++;
>}
>}
>
>int main()
>{
>i = 10;
>func(i);
>printf("%d\n",i);
>return 0;
>}
>

Yes and it runs as the C version nominally would.

Walter, back here: http://www.digitalmars.com/drn-bin/wwwnews?D/28904 you mention

> What Fortran has over C is the 'noalias' on function parameters which allows for aggressive optimization. What I'm thinking of is writing the spec for D functions so that parameters are always 'noalias' (for extern (C) functions this would not apply).

Is that or some other resolution to aliasing still under consideration??

Others - how much current code would that break?? Would it have a big effect on the DTL implementation for example?

Thanks..