Walter wrote:

>> Your post just remind me that case. I'm going even further. Why to initialize anything at all? In 99.9% cases variables are initialized one
> or
>> two lines after creation and default isn't used at all.
> 
> In those cases, the optimizer will usually eliminate the initializer (since it is a "dead assignment").

'usually' is the point here. In certain cases, the compiler will not be able to determine that it actually is a dead assignment and leave it in. There should be a compiler pragma to tell the compiler about it in this case.

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:ctmtne$2car$1@digitaldaemon.com...
> I wrote about this before.
>
> There is a well known time/space-tradeoff for the preInitialization of arrays: using about three times the space one can lazy initialize an array.
>
> But this technic is useless within D, because of the automaatic preInitialization, which currently eats up about 3 cycles per byte.
>
> Please awaken to, that on a 3GHz machine the busy preInitalization of one GB then lasts one second. And the coming 64-bit-machine will have up to some TB of main memory. Current mainboards can already hold up to 4GB, which ist the current main memory limit for win32.
>
> Check again, that to preInitialize one TB you have to wait more than 15 minutes only to wait at least another 15 minutes until your videoediting can start, if no precautions are taken.
>
> We need an option to switch automatic preInitialization of arrays off.

There are several ways to create an array. If the array is statically initialized, it is initialized when it is demand paged in. There is no code generated to initialize it (in fact, there is no way to prevent this from happening!)

Next, one can allocate arrays on the stack. These are normally initialized at runtime, but this can be turned off using the idiom outlined in www.digitalmars.com/d/memory.html#uninitializedarrays.

And lastly, one can dynamically allocate arrays using new, in which case they are initialized, or using std.c.stdlib.malloc, in which case they are not, or any other allocator one wishes to use.

P.S. there's no way to allocate a TB on the stack anyway <g>

P.P.S. it's been suggested that the special initializer syntax:
    = void;
mean "I know what I'm doing, don't initialize the variable" and I've been
considering implementing it.

In article <ctr5d5$lfd$1@digitaldaemon.com>, Norbert Nemec says...
>
>Dave wrote:
>
>> In article <ctq7qb$2lmg$1@digitaldaemon.com>, =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= says...
>>>
>> <snip>
>>>
>>>But I think the *performance* of D and DMD is more than good enough. Right now I'm more concerned about the bugs and ever getting to "1.0" (and porting GDC to the new GCC 4.0, would also be very interesting)
>>>
>> 
>> I agree, with the exception of DMD floating point which I hope will be given some attention before 1.0.
>
>Have you tested the current floating point performance of gdc, compared to gcc/g++? This would give a clue about whether it is a problem of the front end or the DM backend.
>

There has been some of that for floating point posted here (on the NG) a while back -- oopack and scimark ported by Thomas Kuehn.

IIRC, generally what it showed was that GDC significantly outperformed DMD and also in the case of scimark, that GDC actually performed a bit better than GCC and was very close to Intel, so the frontend doesn't appear to be the issue.

My own experience is that DMD is very good for int. A good example of this is that the gc generally seems to run faster for DMD than GDC.

For the FP that I'm familiar with (not cache dependent heavy-duty numerics), it looks to me like DMD just needs to make as good of use of the FP registers as it does with the GP registers ;)

- Dave

"Anders F Björklund" <afb@algonet.se> wrote in message news:ctomh9$14jr$1@digitaldaemon.com...
> I see D as a nice replacement for C++ in the (very) long run,
> but I will continue to use either C or Java when they fit better...

You can write "C" code in D. Take a look at the Empire source code <g>.

> But I agree that D is a bit strange in that it's pretty easy to e.g. dereference null, but hard to e.g. allocate uninited memory ?

It isn't strange viewed from the perspective that dereferencing null always generates a seg fault, and so cannot be ignored, overlooked, etc. Allocating uninitialized memory can lead to erratic, random behavior which sometimes can *appear* to work successfully, hence the idea that this is a bad thing that must be stamped out.

Predictable, consistent behavior is what makes for robust, debuggable, error free programs.

> So far the performance has been good (just a few Mac OS X quirks still), and seems to be one of the key points of D. So it's right to address it.

I wish to point out that DMDScript in D is faster than DMDScript in C++, despite the D version doing the automatic initialization (and the other safety features in D). The magic dust at work here is the D profiler and the ease in manipulating the D source code to make it faster. (D code, I've discovered, is easier than C++ to manipulate source to try to make it run faster. I spent a lot less time tuning the D code, and got better results.)

> Maybe the auto initialization can be be replaced with an error if you try to actually use the value without setting it first ? Like in Java.

That only works well if you've got hardware support for it. The compiler cannot reliably determine this, though some compilers fake it and issue spurious and irritatingly wrong warnings when they get it wrong.

> (Java does D-style init of members, but only such errors for local vars.
>   Not sure how much work it is for the compiler to catch such errors ?)

The same techniques for catching such errors at compile time can be used instead to eliminate initializations that are not needed, which is done by DMD. I much prefer the latter approach, as when an initialization is redundant but such redundancy is not detectable, it "fails safe" by leaving the initialization in rather than issuing a nuisance error message.

> P.P.S. it's been suggested that the special initializer syntax:
>     = void;
> mean "I know what I'm doing, don't initialize the variable" and I've been
> considering implementing it.

I like it, but will it work with 'new'? When newing arrays and value types one might also not want to initialize.

Walter wrote:

>>But I agree that D is a bit strange in that it's pretty easy to
>>> e.g. dereference null, but hard to e.g. allocate uninited memory ?
> 
> It isn't strange viewed from the perspective that dereferencing null always
> generates a seg fault, and so cannot be ignored, overlooked, etc. Allocating
> uninitialized memory can lead to erratic, random behavior which sometimes
> can *appear* to work successfully, hence the idea that this is a bad thing
> that must be stamped out.

Yeah, you can hardly escape NullPointerErrors even in virtual machines.

Just meant that there are other languages that do more of hand-holding?
D has this funny mix of low and high level, that takes a time of getting used to. But I like it :-) At least most of it, save a few rants... ;-)

> I wish to point out that DMDScript in D is faster than DMDScript in C++,
> despite the D version doing the automatic initialization (and the other
> safety features in D). The magic dust at work here is the D profiler and the
> ease in manipulating the D source code to make it faster. (D code, I've
> discovered, is easier than C++ to manipulate source to try to make it run
> faster. I spent a lot less time tuning the D code, and got better results.)

The differences I'm seeing are mostly due to the fact that Apple has spent a lot of time tuning their compiler for C, Objective-C and C++
(and even the bastard child Objective-C++) but for D, I need to use
the regular GCC which only has a few of those PowerPC tunings done...

This gets even larger when using vector operations, on the PPC G4/G5.

For DMD platforms, such as Win32 or Linux X86, this is not an issue.
(or maybe less of an issue, as I don't how the SSE/MMX support is?)

> The same techniques for catching such errors at compile time can be used
> instead to eliminate initializations that are not needed, which is done by
> DMD. I much prefer the latter approach, as when an initialization is
> redundant but such redundancy is not detectable, it "fails safe" by leaving
> the initialization in rather than issuing a nuisance error message.

It's also simpler to code with variables that start with a known value,
rather than getting warnings later (even if they could be done reliable)

I actually like that member fields are inited with known initializers,
usally zeroes, and the locals will be optimized out anyway... Leaving
large arrays and such, which is something that still can be addressed.

--anders

In article <ctraod$rm5$1@digitaldaemon.com>, Walter says...
>
>
>"Anders F Björklund" <afb@algonet.se> wrote in message news:ctomh9$14jr$1@digitaldaemon.com...
>> I see D as a nice replacement for C++ in the (very) long run,
>> but I will continue to use either C or Java when they fit better...
>
>You can write "C" code in D. Take a look at the Empire source code <g>.
>

FWIW, that's where I see D making it's biggest inroads initially with the general programming community, especially now that Linux is surging and has a large number of fluent C programmers who are generally not forced into "vendor (or language or tool) tie-in". They'll use it a lot like C except maybe actually start to use OOP because D makes that very straight-forward ;)

That's also why I personally tend to put a lot of stock in run-time performance; an easier/safer/gc'd "C" that generally performs as well at v1.0 (and potentially better in the future) sounds like a pretty darn good reason to risk a switch for me <g>.

I mean the reason a systems programmer 'drops to C' and doesn't do everything in Perl or Python or whatever is because of performance. That's usually the most compelling reason anyway. Less than equal performance (or even perceived performance via common benchmark results) will also be an equally compelling reason for many C programmers to not try D ;)

- Dave

"Norbert Nemec" <Norbert@Nemec-online.de> wrote in message news:ctq038$2de3$1@digitaldaemon.com...
> For C on the other hand, D should try to surpass it in every respect, so that there are no cases left, where C "fits better". This certainly is an ambitious goal that may never be reached completely, but nevertheless, it is a goal.

Currently, the only cases where C fits better are:

1) you need to work with existing C code
2) there isn't a D compiler for the target
3) you're working with a tool that generates C code
4) your staff is content using C and will not try anything else

These are all environmental considerations, not language issues. It's faster to write code in D, faster to compile it and faster to debug it. If I'm missing something, if there is something that the C language is a better fit for, I'd like to know what it is!

Walter wrote:
> There are several ways to create an array. If the array is statically
> initialized, it is initialized when it is demand paged in. There is no code
> generated to initialize it (in fact, there is no way to prevent this from
> happening!)
> 
> Next, one can allocate arrays on the stack. These are normally initialized
> at runtime, but this can be turned off using the idiom outlined in
> www.digitalmars.com/d/memory.html#uninitializedarrays.
> 
> And lastly, one can dynamically allocate arrays using new, in which case
> they are initialized, or using std.c.stdlib.malloc, in which case they are
> not, or any other allocator one wishes to use.
> 
> P.S. there's no way to allocate a TB on the stack anyway <g>
> 
> P.P.S. it's been suggested that the special initializer syntax:
>     = void;
> mean "I know what I'm doing, don't initialize the variable" and I've been
> considering implementing it.

All this makes me think that the only thing that really needs to be done is for this to be added to the FAQ.

D's current behaviour is more or less ideal as it stands: uninitialized memory can be acquired without fuss, but it won't ever be done by accident.

 -- andy

"Norbert Nemec" <Norbert@Nemec-online.de> wrote in message news:ctr980$pr9$1@digitaldaemon.com...
> >> Your post just remind me that case. I'm going even further. Why to initialize anything at all? In 99.9% cases variables are initialized
one
> > or
> >> two lines after creation and default isn't used at all.
> >
> > In those cases, the optimizer will usually eliminate the initializer (since it is a "dead assignment").
>
> 'usually' is the point here. In certain cases, the compiler will not be
able
> to determine that it actually is a dead assignment and leave it in. There should be a compiler pragma to tell the compiler about it in this case.

I honestly think that in a non-trivial program, you'd be very, very hard pressed to see a measurable difference in program performance from this.