kai:

> I was scared off by the warning that D 2.0 support is experimental.

LDC is D1 still, mostly :-(
And at the moment it uses LLVM 2.6.
LLVM 2.7 contains a new optimization that can improve that code some more.


> Good to know, thanks (thats actually a great feature for scientists!).

In theory D is a bit fit for numerical computations too, but there is lot of work to do still. And some parts of D design will need to be improved to help numerical code performance.

From my extensive tests, if you use it correctly, D1 code compiled with LDC can be about as efficient as C code compiled with GCC or sometimes a little more efficient.

-------------

Steven Schveighoffer:
> In C/C++, the default value for doubles is 0.

I think in C and C++ the default value for doubles is "uninitialized" (that is anything).

Bye,
bearophile

bearophile wrote:
> kai:
> 
>> I was scared off by the warning that D 2.0 support is experimental.
> 
> LDC is D1 still, mostly :-(
> And at the moment it uses LLVM 2.6.
> LLVM 2.7 contains a new optimization that can improve that code some more.
> 
> 
>> Good to know, thanks (thats actually a great feature for scientists!).
> 
> In theory D is a bit fit for numerical computations too, but there is lot of work to do still. And some parts of D design will need to be improved to help numerical code performance.
> 
> From my extensive tests, if you use it correctly, D1 code compiled with LDC can be about as efficient as C code compiled with GCC or sometimes a little more efficient.
> 
> -------------
> 
> Steven Schveighoffer:
>> In C/C++, the default value for doubles is 0.
> 
> I think in C and C++ the default value for doubles is "uninitialized" (that is anything).
> 
	That depends. In C/C++, the default value for any global variable
is to have all bits set to 0 whatever that means for the actual data
type. The default value for local variables and malloc/new memory is
"whatever was in this place in memory before" which can be anything.
The default value for calloc is to have all bits to 0 as for global
variables.

	In the OP code, the malloc will probably return memory that has
never been used before, therefore probably initialized to 0 too (OS
dependent).

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

bearophile wrote:
> kai:
>> Any ideas? Am I somehow not hitting a vital compiler optimization?
> 
> DMD compiler doesn't perform many optimizations, especially on floating point computations.

More precisely:
In terms of optimizations performed, DMD isn't too far behind gcc. But it performs almost no optimization on floating point. Also, the inliner doesn't yet support the newer D features (this won't be hard to fix) and the scheduler is based on Pentium1.

Jérôme M. Berger wrote:
>
> 	That depends. In C/C++, the default value for any global variable
> is to have all bits set to 0 whatever that means for the actual data
> type.

No it's not, it's always uninitialized.

Visual studio will initialise memory & a functions stack segment with 0xcd, but only in debug builds. In release mode you get what was already there. That used to be the case with gcc (which used 0xdeadbeef) as well unless they've changed it.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

div0 wrote:
> Jérôme M. Berger wrote:
>> 	That depends. In C/C++, the default value for any global variable
>> is to have all bits set to 0 whatever that means for the actual data
>> type.
> 
> No it's not, it's always uninitialized.
> 
	According to the C89 standard and onwards it *must* be initialized
to 0. If it isn't then your implementation isn't standard compliant
(needless to say, gcc, Visual, llvm, icc and dmc are all standard
compliant, so you won't have any difficulty checking).

> Visual studio will initialise memory & a functions stack segment with 0xcd, but only in debug builds. In release mode you get what was already there. That used to be the case with gcc (which used 0xdeadbeef) as well unless they've changed it.
> 
	This does not concern global variables. Therefore the second part
of my message applies, the part you didn't quote:
> The default value for local variables and malloc/new memory is "whatever was in this place in memory before" which can be anything. The default value for calloc is to have all bits to 0 as for global variables.

	I should have added that some compiler / standard libraries allow
you to have a default initialization value for debugging purpose.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

strtr wrote:
> == Quote from bearophile (bearophileHUGS@lycos.com)'s article
>> But the bigger problem in your code is that you are performing operations on
> NaNs (that's the default initalization of FP values in D), and operations on NaNs
> are usually quite slower.
> 
> I didn't know that. Is it the same for inf?

Yes, nan and inf are usually the same speed. However, it's very CPU dependent, and even *within* a CPU! On Pentium 4, for example, for x87, nan is 200 times slower than a normal value (!), but on Pentium 4 SSE there's no speed difference at all between nan and normal. I think there's no speed difference on AMD, but I'm not sure.
There's almost no documentation on it at all.


> I used it as a null for structs.
> 

== Quote from Don (nospam@nospam.com)'s article
> strtr wrote:
> > == Quote from bearophile (bearophileHUGS@lycos.com)'s article
> >> But the bigger problem in your code is that you are performing operations on
> > NaNs (that's the default initalization of FP values in D), and operations on NaNs are usually quite slower.
> >
> > I didn't know that. Is it the same for inf?
> Yes, nan and inf are usually the same speed. However, it's very CPU
> dependent, and even *within* a CPU! On Pentium 4, for example, for x87,
> nan is 200 times slower than a normal value (!), but on Pentium 4 SSE
> there's no speed difference at all between nan and normal. I think
> there's no speed difference on AMD, but I'm not sure.
> There's almost no documentation on it at all.

Thanks!
NaNs being slower I can understand but inf might well be a value you want to use.

> > I used it as a null for structs.
> >

Steven Schveighoffer wrote:

>     double [] foo = new double [cast(int)1e6];
>     foo[] = 0;

I've discovered that this is the equivalent of the last line above:

  foo = 0;

I don't see it in the spec. Is that an old or an unintended feature?

Ali

Ali Çehreli <acehreli@yahoo.com> wrote:

> Steven Schveighoffer wrote:
>
>  >     double [] foo = new double [cast(int)1e6];
>  >     foo[] = 0;
>
> I've discovered that this is the equivalent of the last line above:
>
>    foo = 0;
>
> I don't see it in the spec. Is that an old or an unintended feature?

Looks unintended to me.  In fact (though that might be the
C programmer in me doing the thinking), it looks to me like
foo = null;. It might be related to the discussion in
digitalmars.D "Is [] mandatory for array operations?".

-- 
Simen

Simen kjaeraas wrote:
> Ali Çehreli <acehreli@yahoo.com> wrote:
>
>> Steven Schveighoffer wrote:
>>
>>  >     double [] foo = new double [cast(int)1e6];
>>  >     foo[] = 0;
>>
>> I've discovered that this is the equivalent of the last line above:
>>
>>    foo = 0;
>>
>> I don't see it in the spec. Is that an old or an unintended feature?

I have to make a correction: It works with fixed-sized arrays. It does not work with the dynamic array initialization above.

> Looks unintended to me.  In fact (though that might be the
> C programmer in me doing the thinking), it looks to me like
> foo = null;. It might be related to the discussion in
> digitalmars.D "Is [] mandatory for array operations?".

Thanks,
Ali