On Saturday, 27 October 2012 at 23:07:19 UTC, BLM768 wrote:
In any case, though, separately initializing every member of
an array is
silly. That's what a loop is for. That, or a memcpy from an
immutable
copy of .init.
I think that the reasoning behind DMD's implementation is that
for sma
In any case, though, separately initializing every member of an
array is
silly. That's what a loop is for. That, or a memcpy from an
immutable
copy of .init.
I think that the reasoning behind DMD's implementation is that
for small structs, writing out the instructions is more efficient
t
On Thu, Oct 25, 2012 at 12:05:25AM +0200, Era Scarecrow wrote:
> On Wednesday, 24 October 2012 at 15:39:19 UTC, thedeemon wrote:
> >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],
On Wednesday, 24 October 2012 at 15:39:19 UTC, thedeemon wrote:
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
...
So your code creates a lot of work for the compiler.
That seems sil
On Wednesday, October 24, 2012 21:35:22 Manfred Nowak wrote:
> 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(
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
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
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 oth
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?
> >>
> >>Tha
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;
}
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 appe
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 ~=
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
On Tue, 23 Oct 2012 22:50:46 -0500, 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();
14 matches
Mail list logo
