• bearophile (19/20) Oct 15 2009 I have discussed this topic a little in the past, but I didn't receive a...

bearophile <bearophileHUGS lycos.com> writes:

I have discussed this topic a little in the past, but I didn't receive a good
answer. So I try again explaining the situation better for Walter too.

I don't need a full specs for the D1/D2 languages, but now and then a little
more language specification helps.
In C there are several undefined/unspecified things, that sometime allow for
better optimizations on very different CPUs. But D tries to be less bug-prone,
so it has to define more its behaviour. This may lead to a bit less performance
(and in certain cases a lot less performance).
When possible it's very good for D to have a syntax that allows the programmer
to choose between a more predictable behaviour and a more aggressive
optimization for performance (like in the case of uninitialized variables set
to void. Generally it's better for the safer behaviour to be the default one).

As Wikipedia says:
http://en.wikipedia.org/wiki/Pointer_alias
<<
In C, any function pointer argument may alias any other function pointer
argument. The compiler must assume that any accesses through these pointers can
alias. This dramatically restricts the potential for optimization.

In C++, pointer arguments are assumed not to alias if they point to
fundamentally different types ("strict aliasing" rules). This allows more
optimizations to be done than in C.

In C99, the "restrict" keyword specifies that a pointer argument does not alias
any other pointer argument. This saves a little the situation for the C
language, allowing more optimizations.
 [I think the LLVM backend of LDC is able to use such information in a good
way, if such information is available (currently it's not available, because I
think D unfortunately doesn't offer such semantics yet).]


See also:
http://www.lysator.liu.se/c/restrict.html
http://stackoverflow.com/questions/98340/what-are-the-common-undefinedunspecified-behavior-for-c-that-you-run-into

In GCC there is also the "may_alias":
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Type-Attributes.html

For performance you have to assume pointer not alias each other, this allows
for better optimizations in several situations. But I use D to handle memory
manually, for example using a pointer to point to different kinds of tagged
structs, etc. (Sometimes for me the freedom to use memory in such low level way
is the whole point of using D instead of Python/Java). Such operations are
unsafe in C++ (well, in GCC you may use an union to stop the compiler to
optimize things in the wrong way, or you can use the blunt tool of the
"-fno-strict-aliasing" flag.

So this is a very good situation where D can grow a standard and portable way
(and syntax) to offer the programmer both performance and safety according to
the different situations, something that you can do in C99 on GCC only in a
nonportable way. D is in the position to improve this situation compared to C
and C++. Even if the back-end of DMD isn't able to use such information, the
backend of LDC is already able to use it, and future D compilers will have such
information. So I think it has to be added.

Bye,
bearophile