On Mon, Dec 15, 2008 at 7:07 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Are you using a lot of templates and recursive imports?

A lot of templates, yes.  A lot of recursive imports, I don't think so.  Is there an easy way to see if I have recursive imports?  I usually try to make my imports tree-like, but it's possible I may have some unintentional import cycles.

--bb

> Bill Baxter wrote:
>>
>> For me, V1.038 compiles my code but takes a really really really long time to do so.
>>
>> It now takes  1 min 20 secs for a full build, when it used to compile
>> in 13 seconds.
>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>
>> (building with DSSS and tango)
>

Bill Baxter schrieb:
 Is there an easy way to see if I have recursive imports?  I
> usually try to make my imports tree-like, but it's possible I may have
> some unintentional import cycles.
> 
> --bb

Yep, you can use DIL to analyse your code and draw dependency graphs.
http://code.google.com/p/dil/

quote
Produce module dependency graphs using the graphviz dot format.
.....Cyclic edges (import statements) and nodes (modules) are highlighted in red. The edges of public imports are bold.
end quote

bls

Walter Bright:
> Are you using a lot of templates and recursive imports?

Note: the mysterious new bug I have found in V.1.038 may have some relation with recursive imports (removing them that bug more or less vanishes).

Bye,
bearophile

Bill Baxter:
> For me, V1.038 compiles my code but takes a really really really long
> time to do so.
> It now takes  1 min 20 secs for a full build, when it used to compile
> in 13 seconds.
> Forget the 60% slowdown from LDC -- this is 515% slower!
> (building with DSSS and tango)

I have tested the compilation timings of my dlibs (using 'bud'), they contain lot of templates.
Compilation timings (with unittest), no run:
  V1.037: 11.33 s
  V1.038: 11.52 s
The size of the resulting exe is the same (1.887 MB).

(Without unittests the compilation is much faster, about 0.47 seconds for 1.038). So it seems my compilation timings are grown, but not much.

I have just found out that 'bud' isn't using both cores of my CPU. Why??

Bye,
bearophile

On Mon, 15 Dec 2008 17:37:27 +0300, bearophile <bearophileHUGS@lycos.com> wrote:

> Bill Baxter:
>> For me, V1.038 compiles my code but takes a really really really long
>> time to do so.
>> It now takes  1 min 20 secs for a full build, when it used to compile
>> in 13 seconds.
>> Forget the 60% slowdown from LDC -- this is 515% slower!
>> (building with DSSS and tango)
>
> I have tested the compilation timings of my dlibs (using 'bud'), they contain lot of templates.
> Compilation timings (with unittest), no run:
>   V1.037: 11.33 s
>   V1.038: 11.52 s
> The size of the resulting exe is the same (1.887 MB).
>
> (Without unittests the compilation is much faster, about 0.47 seconds for 1.038).
> So it seems my compilation timings are grown, but not much.
>
> I have just found out that 'bud' isn't using both cores of my CPU. Why??
>

Neither does DMD (bud is just a thin wrapper around DMD).
I use CodeBlocks and it has "number of parallel builds" option which is very helpful.
DSSS on Linux can do that, too, IIRC.

> Bye,
> bearophile

Hello Andrei,

> Bill Baxter wrote:
> 
>> On Sun, Dec 14, 2008 at 8:40 PM, Daniel de Kok
>> <daniel@nowhere.nospam> wrote:
>> 
>>> On Sun, 14 Dec 2008 20:10:26 +0900, Bill Baxter wrote:
>>> 
>>>>> Version D 1.038   Dec 11, 2008
>>>>> New/Changed Features
>>>>> * Added Partial IFTI Bugzilla 493
>>>> Hooray!  Now I can finish porting std.algorithm and friends to D1!
>>>> 
>>> So, we'll see a new std2? :^) (I for one would be very happy)
>>> 
>> Not a new std2, just updates to the old one.  But yeh.
>> 
> Apologies for the delay in updating std2. I've had a good reason (in
> addition to having a dissertation to complete), see www.erdani.org.
> :o)
> 
> Andrei
> 


Aha! A baby! Congrats!  Looks like Andrew is going to have a big head start with computers. :-)

-JJR

Bill Baxter wrote:
> On Mon, Dec 15, 2008 at 7:07 PM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> Are you using a lot of templates and recursive imports?
> 
> A lot of templates, yes.  A lot of recursive imports, I don't think
> so.  Is there an easy way to see if I have recursive imports?  I
> usually try to make my imports tree-like, but it's possible I may have
> some unintentional import cycles.

I don't know of an easy way to tell. The reason I ask is because modules that recursively import themselves will wind up doing a lot more template instantiations because the compiler can't tell which module will instantiate an external template reference. (Change in this behavior fixes a bug.)

Extrawurst wrote:
> Even if so, why has it become so much slower ?

See my answer to Bill.

Bill Baxter schrieb:
> For me, V1.038 compiles my code but takes a really really really long
> time to do so.
> 
> It now takes  1 min 20 secs for a full build, when it used to compile
> in 13 seconds.
> Forget the 60% slowdown from LDC -- this is 515% slower!
> 
> (building with DSSS and tango)
> 
> --bb
> 

In my project compilation takes now several minutes for some files which compiled in about a second with 2.021. I stopped the compilation of the whole project after about 2 hours (took 2 min at most on 2.021).

I'll try to track this down when I get the time, but i doubt that those times get anywhere near those of the original.

Hi,

first of all, thank you Walter and all the D community for making the great "pure"
feature become reality.
I have 2 questions concerning the behaviour of this feature.

The first one concerns the existence -or not- of "pure delegates".
It makes sense to use a delegate if its closure is not empty -otherwise it is no
more than a function-. This is the reason why we can think delegates cannot be
pure. Let's take an example:

void foo(){
    int x=0;
    //bar is not pure at all in this context
    int bar(){
        return x;
    }
    writefln(bar()); // prints '0'
    ++x;
    writefln(bar()); // prints '1'
}

But the fact is that when returning a delegate, its closure freezes forever and so behaves like a local variable and not like a global variable by respect to the delegate :

int delegate() getPureFunction(int x){
    int bar(){
        return x;
    }
    return &bar;
}

void main(){
    int delegate() myPureFunction;
    myPureFunction = getPureFunction(5);
}

In this example, myPureFunction looks like a pure function, does it?
So how does dmd 2.022 behave for such kind of "pure delegates" ? Do you think
there is a futur for pure delegates in the D language ? If not this would mean
that we cannot use the power of delegates (to do real functionnal programming) and
the power of purity in the same time, which will be very disapointing for
programmers, don't you think ?

This was my first question. The second one concerns purity and parallel programming. Is dmd 2.022 implementing some kind of parallelism thanks to pure function? In fact I have been argued that "pure" keyword is not enough for the compiler to make an efficient parallel program. The problem would be that the compiler has no mean to know the granularity of the tasks. What are your feelings about that?

Thanks a lot