A user question (was: Re: Faster compilation speed)

A user question (was: Re: Faster compilation speed)

[Marco Morandini]

I'm a simple user, so
please forgive me if
I'm asking something obvious.

With Version 1 of the code below the compile time at -O2
is approx a quadratic function of the number of call to pippo(a);
With Version 2 of the code the compile time is approx a linear
function of N.
Is this reasonable? On a 650MHz PIII with 512 Mb of memory
I get the following timings for Version 1:

N     seconds
1000  1.1
10000 16
20000 49
30000 92
40000 186

After that, with 50000 lines of code,
g++ eats all the memory, and goes to swap.

gcc -v
Reading specs from 
/home2/marco/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../configure --enable-threads 
--enable-languages=c,c++,f77 --prefix=/home2/marco/local
Thread model: posix
gcc version 3.1

Thanks, and apologize again if this is only noise.

Marco


Version 1
-------------------
class A{
private:
	double c;
public:
	virtual ~A();
};
void dummy(const A&a);
int main(void) {
	A a;
	pippo(a);
           .
           .
    //repeat this line N times
           .
           .
        pippo(a);
        return 0;
}

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

Version 2
-------------------
void dummy(const double&a);
int main(void) {
	double a;
	pippo(a);
           .
           .
    //repeat this line N times
           .
           .
        pippo(a);
        return 0;
}

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

Re: A user question (was: Re: Faster compilation speed)

[Marco Morandini]

Marco Morandini wrote:
> wrong code....

bleah!
Here is the right code
(pippo (dummy in italian) <-> dummy)


Marco


Version 1
-------------------
class A{
private:
    double c;
public:
    virtual ~A();
};
void dummy(const A&a);
int main(void) {
    A a;
    dummy(a);
           .
           .
    //repeat this line N times
           .
           .
    dummy(a);
    return 0;
}

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

Version 2
-------------------
void dummy(const double&a);
int main(void) {
    double a;
    dummy(a);
           .
           .
    //repeat this line N times
           .
           .
    dummy(a);
    return 0;
}

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

Re: A user question (was: Re: Faster compilation speed)

[Mike Stump]

On Tuesday, August 13, 2002, at 10:37 AM, Marco Morandini wrote:

PATCH: Re: A user question (was: Re: Faster compilation speed)

[Mike Stump]

On Tuesday, August 13, 2002, at 02:29 PM, Mike Stump wrote:

Re: PATCH: Re: A user question (was: Re: Faster compilation speed)

[Richard Henderson]

On Tue, Aug 13, 2002 at 05:06:42PM -0700, Mike Stump wrote:
>       * sched-rgn.c (CHECK_DEAD_NOTES): Limit how much checking
>	we do to avoid n^2 behavior.

I don't like it.

Instead, arrange to make a single pass across the rtl removing
and counting death notes and storing the counts into an array
indexed by basic block.  The add up the counts for each block
in the region as is sort of done currently.



r~

Re: PATCH: Re: A user question (was: Re: Faster compilation speed)

[Michael Matz]

Hi,

On Tue, 13 Aug 2002, Mike Stump wrote:

> :-(  The biggest single culprit count wise is some aggressive checking
> code.  The below change save 1.5 minutes of compile time out of 5
> minutes on an n=20,000 case.  The top of the tree is much worse than a
> gcc 3.1 compiler, 5 minutes compared to 56 seconds.

This is a typical case why I strongly dislike such arbitrary cutoff means
to avoid slow behaviour instead of redesigning how it works.  From the
code you posted it seems, that the blocks bitmap is extremely sparse (in
the second loop only one bit is set in evry case, the second loop only
seems to set one bit each time by pure luck), but still it's completely
traversed, through pointer chasing even (the bb double linked list).
This suggests to change the interface of count_or_remove_death_notes() to
take a bitmap (not sbitmap), and rearrange the outer loop of it, to use
EXECUTE_IF_SET_IN_BITMAP().


Ciao,
Michael.

Re: PATCH: Re: A user question (was: Re: Faster compilation speed)

[Michael Matz]

On Wed, 14 Aug 2002, Michael Matz wrote:

> code you posted it seems, that the blocks bitmap is extremely sparse (in
> the second loop only one bit is set in evry case, the second loop only
                                                        ^^^^^^
                                                        first of course

> seems to set one bit each time by pure luck), but still it's completely


Ciao,
Michael.