"Norbert Nemec" <Norbert@Nemec-online.de> wrote in message news:ctq0t2$2e32$1@digitaldaemon.com...
> J C Calvarese wrote:
>
> > The majority of programmers would never touch this
> > setting. Those that have to clear 1 TB of memory have the option.
>
> You don't really have to go for one 1TB to see the use of that option.
Write
> a routine that has a 1KB array locally on the stack and call that routine repeatedly...
>

I had a situation like this (but more than 1KB) and it didn't seem to work
that
slow, but i am sure it would work faster if it wasn't initialized every
time.
Why not try to persuade Walter of some syntax that would allow to create
uninitialized
arrays?

noinit int[100000] array;

or any other form that could be used.

This would ofcourse be an option and used only when you need it and are sure that you will initialize the data  later.

>

pragma wrote:

> In article <ctoitr$11pk$1@digitaldaemon.com>, Norbert Nemec says...
>>Any ideas for a possible syntax
>>specifying "This variable should not be initialized"? It should be
>>possible both for variables as well as for dynamically allocated memory or
>>class members.
> 
> This sounds like a job for a compiler pragma.
> 
>> pragma(noinit) int a; // a gets a random value now (just like C!).
>> int[] b;
>> pragma(noinit){
>>     b = new int[1024*1024*1024]  // b gets an uninitalized 1GB block.
>> }
> 
> The nice thing about this is that pragmas in D are not be ignored if not understood.  So while compiler dependent, the code won't compile on D compilers that don't support 'noinit'.
> 
> - EricAnderton at yahoo

And you could always use "else" to initialize memory old way. I like it.
-- 
Dawid Ciężarkiewicz | arael
jid: arael@fov.pl

In article <ctq2di$2gbd$1@digitaldaemon.com>, Norbert Nemec says...
>
<snip>
>
>The result was still pure C and therefore completely portable. The performance was, of course, tuned to one specific architecture, but there were basically constants to adjust for tuning it for about any modern processor.
>
>Doing the same thing in assembler would probably not be much faster. (After you went from 8% to 80%, the remaining factor of 1.25 probably isn't worth the effort. 80% peak performance is already well beyond what people usually go for.)
>

If you still have that code handy, would it be possible to run it through DMD and GDC and post the results vs., say, GCC (and Intel C/++ if it's available)?

Just out of curiousity..

Thanks,

- Dave

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.

It's important to me and I think will actually turn out to be important to the overall acceptance of the language (and certainly DMD) come 1.0.

I'm not talking about new array semantics, vectorizing, expression templates or anything like what Norbert has been speaking of lately; just plain old for(...) { PI * 2.0 * radius[i]; ...; } type of stuff.

BTW - How close are they getting with GCC 4? I have not been following that lately.

- Dave

>
>--anders

Dave wrote:

> BTW - How close are they getting with GCC 4? I have not been following that
> lately.

See http://gcc.gnu.org/develop.html#stage3, they're at the final stage.

Apple is going to use it as the main system compiler in next Mac OS X.

--anders

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.

Are there any general comparisons of the code produced by the different compilers? (Not only "What *does* work?", like in the stress test, but also "How well does is work?")

Dave wrote:

> In article <ctq2di$2gbd$1@digitaldaemon.com>, Norbert Nemec says...
>>
> <snip>
>>
>>The result was still pure C and therefore completely portable. The performance was, of course, tuned to one specific architecture, but there were basically constants to adjust for tuning it for about any modern processor.
>>
>>Doing the same thing in assembler would probably not be much faster. (After you went from 8% to 80%, the remaining factor of 1.25 probably isn't worth the effort. 80% peak performance is already well beyond what people usually go for.)
>>
> 
> If you still have that code handy, would it be possible to run it through DMD and GDC and post the results vs., say, GCC (and Intel C/++ if it's available)?

Already found out to my disappointment that I don't have it on my local harddisk any more. Have to dig up some old backups...

In any case, I would not expect very conclusive results. The code was plain ANSI C and did not depend on any compiler optimizations. Furthermore, it was tuned to a specific Alpha processor (which had a comparatively simple cache structure) The techniques were rather general, but the specifics were tuned exactly to that one machine which I don't have any access to any more.

Anyhow: I'll try to dig up the code and see in which state it is.

Norbert Nemec wrote:
| Are there any general comparisons of the code produced by the
| different compilers? (Not only "What *does* work?", like in the
| stress test, but also "How well does is work?")

Most of the comparisons are on the benchmark level

http://www.prowiki.org/wiki4d/wiki.cgi?Benchmarks
http://gcc.gnu.org/benchmarks/
http://shootout.alioth.debian.org/

I'm not aware of any current public compiler dissections.

Thomas

Norbert Nemec wrote:

> Are there any general comparisons of the code produced by the different
> compilers? (Not only "What *does* work?", like in the stress test, but also
> "How well does is work?")

On Mac OS X,
most of it is like "hooray, it compiles" :-)

Benchmarks hasn't been too bad, but currently
GCC is quicker for most tasks (and then again
gcc code generated on PPC is not all that good)

When Mango compiles, and some of the more annoying D
bugs like "void main()" are out, we can do some more
testing. For now, DStress is a pretty good start...

--anders

"Dawid Ciê¿arkiewicz" <arael@fov.pl> wrote in message news:ctnv58$c53$1@digitaldaemon.com...
> I was reading documentation of D and found paragraph about initialization
of
> variables. Can somebody tell me what is the point in doing so and if it's done just by setting them after creation (and IMHO wasting cpu cycles) or is it cost free (I don't know how would be that possible, but that is why I'm asking).

The point of it is to eliminate a common, and difficult to find, source of bugs.

> 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").