The following takes nearly three minutes to compile.
The culprit is the line bar ~= B();
What is wrong with this?

Thanks,
Dan
----------------
struct B {
  const size_t SIZE = 1024*64;
  int[SIZE] x;
}

void main() {
  B[] barr;
  barr ~= B();
}
-----------------

On Tue, 23 Oct 2012 22:50:46 -0500, Dan <dbdavidson@yahoo.com> wrote:

> The following takes nearly three minutes to compile.
> The culprit is the line bar ~= B();
> What is wrong with this?
>
> Thanks,
> Dan
> ----------------
> struct B {
>    const size_t SIZE = 1024*64;
>    int[SIZE] x;
> }
>
> void main() {
>    B[] barr;
>    barr ~= B();
> }
> -----------------
I have the same issue on linux x64 2.060

So appending to a dynamic array isn't really that efficient.
But this goes WAY over that line.  I'm timing your test now.

It's still going...


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wednesday, 24 October 2012 at 04:49:19 UTC, 1100110 wrote:
>> The following takes nearly three minutes to compile.
>> The culprit is the line bar ~= B();
>> What is wrong with this?

> I have the same issue on linux x64 2.060
>
> So appending to a dynamic array isn't really that efficient. But this goes WAY over that line.  I'm timing your test now.
>
> It's still going...

 It appears it's all happening during copying init, why I am not sure.

[code]
struct B {
  enum SIZE = 1024 * 64;
  int[SIZE] x;
}

//same timing issue, no array involved
void test(B b) {}

void main() {
  test(B());
}
[/code]

 I've changed the *64 to various numbers and gotten curious results. The mb is the noted (estimated) memory footprint it used during compiling.

1:   0m0.725s   mb:??
2:   0m1.414s   mb:??
4:   0m2.620s   mb:28
8:   0m8.937s   mb:30
16:  0m35.869s  mb:34
32:  2m36.922s  mb:42
64:  9m27.353s  mb:56

On Wednesday, 24 October 2012 at 03:50:47 UTC, Dan wrote:
> The following takes nearly three minutes to compile.
> The culprit is the line bar ~= B();
> What is wrong with this?
>
> Thanks,
> Dan
> ----------------
> struct B {
>   const size_t SIZE = 1024*64;
>   int[SIZE] x;
> }
>
> void main() {
>   B[] barr;
>   barr ~= B();
> }
> -----------------

The code DMD generates for initializing the struct does not use loops, so it's
xor     ecx, ecx
mov     [eax], ecx
mov     [eax+4], ecx
mov     [eax+8], ecx
mov     [eax+0Ch], ecx
mov     [eax+10h], ecx
mov     [eax+14h], ecx
mov     [eax+18h], ecx
mov     [eax+1Ch], ecx
mov     [eax+20h], ecx
mov     [eax+24h], ecx
mov     [eax+28h], ecx
mov     [eax+2Ch], ecx
mov     [eax+30h], ecx
mov     [eax+34h], ecx
mov     [eax+38h], ecx
...

So your code creates a lot of work for the compiler.

On Wednesday, 24 October 2012 at 09:50:38 UTC, Era Scarecrow wrote:
> On Wednesday, 24 October 2012 at 04:49:19 UTC, 1100110 wrote:
>>> The following takes nearly three minutes to compile.
>>> The culprit is the line bar ~= B();
>>> What is wrong with this?
>
>> I have the same issue on linux x64 2.060
>>
>> So appending to a dynamic array isn't really that efficient. But this goes WAY over that line.  I'm timing your test now.
>>
>> It's still going...
>
>  It appears it's all happening during copying init, why I am not sure.
>
> [code]
> struct B {
>   enum SIZE = 1024 * 64;
>   int[SIZE] x;
> }
>
> //same timing issue, no array involved
> void test(B b) {}
>
> void main() {
>   test(B());
> }
> [/code]
>
>  I've changed the *64 to various numbers and gotten curious results. The mb is the noted (estimated) memory footprint it used during compiling.
>
> 1:   0m0.725s   mb:??
> 2:   0m1.414s   mb:??
> 4:   0m2.620s   mb:28
> 8:   0m8.937s   mb:30
> 16:  0m35.869s  mb:34
> 32:  2m36.922s  mb:42
> 64:  9m27.353s  mb:56

According to assembly dmd just generates repetitive instructions to zero memory instead of making it in a loop. A workaround is to initialize array to void and then zero it in a loop.

On 24/10/12 17:39, thedeemon wrote:
> On Wednesday, 24 October 2012 at 03:50:47 UTC, Dan wrote:
>> The following takes nearly three minutes to compile.
>> The culprit is the line bar ~= B();
>> What is wrong with this?
>>
>> Thanks,
>> Dan
>> ----------------
>> struct B {
>>   const size_t SIZE = 1024*64;
>>   int[SIZE] x;
>> }
>>
>> void main() {
>>   B[] barr;
>>   barr ~= B();
>> }
>> -----------------
>
> The code DMD generates for initializing the struct does not use loops,
> so it's
> xor     ecx, ecx
> mov     [eax], ecx
> mov     [eax+4], ecx
> mov     [eax+8], ecx
> mov     [eax+0Ch], ecx
> mov     [eax+10h], ecx
> mov     [eax+14h], ecx
> mov     [eax+18h], ecx
> mov     [eax+1Ch], ecx
> mov     [eax+20h], ecx
> mov     [eax+24h], ecx
> mov     [eax+28h], ecx
> mov     [eax+2Ch], ecx
> mov     [eax+30h], ecx
> mov     [eax+34h], ecx
> mov     [eax+38h], ecx
> ...
>
> So your code creates a lot of work for the compiler.

That's incredibly horrible, please add to bugzilla.

On Wed, Oct 24, 2012 at 06:04:10PM +0200, Don Clugston wrote:
> On 24/10/12 17:39, thedeemon wrote:
> >On Wednesday, 24 October 2012 at 03:50:47 UTC, Dan wrote:
> >>The following takes nearly three minutes to compile.
> >>The culprit is the line bar ~= B();
> >>What is wrong with this?
> >>
> >>Thanks,
> >>Dan
> >>----------------
> >>struct B {
> >>  const size_t SIZE = 1024*64;
> >>  int[SIZE] x;
> >>}
> >>
> >>void main() {
> >>  B[] barr;
> >>  barr ~= B();
> >>}
> >>-----------------
> >
> >The code DMD generates for initializing the struct does not use loops,
> >so it's
> >xor     ecx, ecx
> >mov     [eax], ecx
> >mov     [eax+4], ecx
> >mov     [eax+8], ecx
> >mov     [eax+0Ch], ecx
> >mov     [eax+10h], ecx
> >mov     [eax+14h], ecx
> >mov     [eax+18h], ecx
> >mov     [eax+1Ch], ecx
[...]

Yikes!! Why aren't we using memset (or equivalent) here?!


> That's incredibly horrible, please add to bugzilla.
[...]

Yeah, no kidding! For comparison, GDC does a way better job in this department:

	$ time dmd test.d

	real    0m7.564s
	user    0m7.529s
	sys     0m0.029s
	$ time gdc test.d

	real    0m0.107s
	user    0m0.069s
	sys     0m0.036s
	$

This is with SIZE = 1024*16 (I didn't dare try it with 1024*64).  That's a 75:1 ratio between dmd and gdc, which is pretty horrible, since dmd is usually significantly faster than gdc.

Surprisingly, though, dmd still produces a smaller executable than gdc for this code! I'm guessing the optimizer cleans up that code afterwards? (Or maybe there are other factors at play here that I'm not aware of.)


T

-- 
EMACS = Extremely Massive And Cumbersome System

On Wednesday, 24 October 2012 at 17:43:11 UTC, H. S. Teoh wrote:

> Surprisingly, though, dmd still produces a smaller executable than gdc
> for this code! I'm guessing the optimizer cleans up that code
> afterwards? (Or maybe there are other factors at play here that I'm not aware of.)

Must be other factors. "Optimized" code (generated by dmd with -release -O) looks like
mov DWORD PTR [edx], 0
mov DWORD PTR [edx+4], 0
mov DWORD PTR [edx+8], 0
...
so it should be even bigger and probably slower.

On Wednesday, October 24, 2012 18:04:10 Don Clugston wrote:
> That's incredibly horrible, please add to bugzilla.

There are at least a couple of potentially related bugs already:

http://d.puremagic.com/issues/show_bug.cgi?id=8828 http://d.puremagic.com/issues/show_bug.cgi?id=8449

though this may still merit a new report.

- Jonathan M Davis

Dan wrote:

> The following takes nearly three minutes to compile.

... and this returns immediately:

--------------------------------
struct B {
   const size_t SIZE = 1024*64;
   int[SIZE] x= void; // !!!
}

void main() {
   B[] barr;
   barr ~= B();
}
-------------------------------
- manfred