gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Karel Gardas]

Hello,

I've just been able to bootstrap gcc-3_3-branch with latest memory
handling patches by Kaveh R. Ghazi and give it a try on my reference MICO
source tree. The results are very good! :-)

Please look at http://gcc.gnu.org/ml/gcc/2003-02/msg00800.html for
reference. I've modified this table and results are below.

I've done just for verification one build with gcc3.2.2. The difference
between time of gcc3.2.2 build two weeks ago and now is about 0.9% so
todays build with gcc3.3 might be taken as a done in ``similar''
environment/conditions as all builds two weeks ago.

Now rough times values:

gcc3.2.2:

real    12m40.446s
user    12m25.900s
sys     0m12.330s


gcc3.3 (todays sources):

real    11m16.123s
user    10m50.030s
sys     0m21.380s


In the table, I've removed gcc3.4 and add gcc3.3 todays source tree +
deltas between gcc3.2.2 and todays gcc3.3 and gcc3.3 and todays gcc3.3. I
hope it'll be clear from the table:


File		3.2.2	3.3	3.2/3d	3.3t	3.2/3t	3.3/3td
os-unix.cc	5.67	7.19	26.81	4.3	-24.16	-40.19
dii.cc		17.84	22.14	24.1	15.23	-14.63	-31.21
typecode.cc	11.63	14.12	21.41	9.67	-16.85	-31.52
any.cc		9.02	10.76	19.29	6.89	-23.61	-35.97
codec.cc	7.48	9.57	27.94	5.87	-21.52	-38.66
buffer.cc	4.54	5.66	24.67	3.34	-26.43	-40.99
context.cc	4.84	6.16	27.27	3.66	-24.38	-40.58
except.cc	6.06	7.48	23.43	4.64	-23.43	-37.97
dispatch.cc	5.98	7.51	25.59	4.72	-21.07	-37.15
string.cc	4.65	6.06	30.32	3.61	-22.37	-40.43
object.cc	6.37	8.32	30.61	5.12	-19.62	-38.46
address.cc	6.87	8.36	21.69	5.21	-24.16	-37.68
ior.cc		16.72	21.59	29.13	14.82	-11.36	-31.36
orb.cc		22.93	28.08	22.46	19.97	-12.91	-28.88
boa.cc		11.8	14.68	24.41	9.55	-19.07	-34.95
dsi.cc		14.94	19.3	29.18	13.18	-11.78	-31.71
transport.cc	5.69	7.18	26.19	4.35	-23.55	-39.42
trans../tcp.cc	5.71	7.1	24.34	4.22	-26.09	-40.56
trans../udp.cc	5.71	7.14	25.04	4.24	-25.74	-40.62
trans../unix.cc	5.61	7.04	25.49	4.15	-26.02	-41.05
iop.cc		21.32	26.49	24.25	18.83	-11.68	-28.92
util.cc		7.62	9.6	25.98	6	-21.26	-37.5
basic_seq.cc	5	6.29	25.8	3.87	-22.6	-38.47
fast_array.cc	5.44	6.86	26.1	4.03	-25.92	-41.25
ssl.cc		13.87	17.68	27.47	12.12	-12.62	-31.45
fixed.cc	5.04	6.33	25.6	3.91	-22.42	-38.23
intercept.cc	14.7	19.23	30.82	13.17	-10.41	-31.51
codeset.cc	7.64	9.55	25	5.93	-22.38	-37.91
queue.cc	6.07	7.51	23.72	4.67	-23.06	-37.82
static.cc	25.46	32.66	28.28	22.9	-10.05	-29.88
current.cc	13.35	17.38	30.19	11.94	-10.56	-31.3
policy_impl.cc	18.19	22.82	25.45	15.45	-15.06	-32.3
service_info.cc	13.27	17.32	30.52	11.83	-10.85	-31.7
ioptypes.cc	15.66	19.77	26.25	13.57	-13.35	-31.36
ssliop.cc	13.57	17.46	28.67	11.98	-11.72	-31.39
value.cc	15.91	20.66	29.86	13.81	-13.2	-33.16
valuetype.cc	14.84	18.98	27.9	12.79	-13.81	-32.61
..etype_impl.cc	17.7	22.63	27.85	15.12	-14.58	-33.19
dynany_impl.cc	13.75	15.79	14.84	10.92	-20.58	-30.84
policy2.cc	13.6	17.51	28.75	12.06	-11.32	-31.13
tckind.cc	13.38	17.26	29	11.86	-11.36	-31.29
orb_excepts.cc	13.48	17.38	28.93	11.98	-11.13	-31.07
policy.cc	13.36	17.51	31.06	11.97	-10.4	-31.64
poa.cc		17.87	22.7	27.03	15.52	-13.15	-31.63
poa_base.cc	15.56	19.34	24.29	13.36	-14.14	-30.92
poa_impl.cc	23.06	28.39	23.11	20.36	-11.71	-28.28
dynany.cc	15.33	19.51	27.27	13.44	-12.33	-31.11
uni_base64.cc	0.1	0.1	0	0.1	0	0
uni_unicode.cc	0.16	0.19	18.75	0.17	6.25	-10.53
uni_fromuni.cc	0.33	0.38	15.15	0.38	15.15	0
uni_touni.cc	0.35	0.42	20	0.38	8.57	-9.52
except2.cc	8.4	10.58	25.95	6.82	-18.81	-35.54
pi.cc		16	20.79	29.94	14.2	-11.25	-31.7
pi_impl.cc	23.26	29.87	28.42	20.83	-10.45	-30.26
typecode_seq.cc	13.9	17.78	27.91	12.19	-12.3	-31.44
timebase.cc	13.39	17.41	30.02	11.82	-11.73	-32.11
ir.cc		59.41	73.92	24.42	55.99	-5.76	-24.26
ir_base.cc	16.13	21	30.19	14.46	-10.35	-31.14
imr.cc		20.48	25.27	23.39	17.65	-13.82	-30.15
mtdebug.cc	5.46	6.54	19.78	4.01	-26.56	-38.69

Average		12.19	15.41	25.45		-15.19	-32.21
Max				31.06		15.15	0
Min				0		-26.56	-41.25

sum		731.47	924.3		629.13


definitions: 3.3t mean 3.3 version from today. 3.3/3td means delta between
time of 3.3 version and 3.3 today version. 3.3 version reference is about
2 weeks old. All other definitions are in reference table (url above)


JFYI: Before two weeks, I thought that I'll skip 3.3 release, because it's
slower than 3.2.2 and doesn't bring anything new (much usefull for us).
Now I'm looking forward to seeing it, since it's faster. (at least for our
purposes)


Thanks to all and especially to Kaveh R. Ghazi!

Karel
PS: Seeing these results, I think that it might be interesting to see
gcc3.4 times with Kaveh R. Ghazi's patches (I hope they are already
applied). I'll test it on Monday...
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Kaveh R. Ghazi]

 > From: Karel Gardas <kgardas@objectsecurity.com>
 > 
 > Hello,
 > 
 > I've just been able to bootstrap gcc-3_3-branch with latest memory
 > handling patches by Kaveh R. Ghazi and give it a try on my reference MICO
 > source tree. The results are very good! :-)
 > 
 > JFYI: Before two weeks, I thought that I'll skip 3.3 release, because it's
 > slower than 3.2.2 and doesn't bring anything new (much usefull for us).
 > Now I'm looking forward to seeing it, since it's faster. (at least for our
 > purposes)
 > 
 > Thanks to all and especially to Kaveh R. Ghazi!
 > 
 > Karel
 > PS: Seeing these results, I think that it might be interesting to see
 > gcc3.4 times with Kaveh R. Ghazi's patches (I hope they are already
 > applied). I'll test it on Monday...

<blush> Thanks, it's very gratifying to know the patch had a positive
impact.  You're seeing even more of an improvement that I did on
Gerald's testcase.  That's great.  I'm interested to see reports from
other very large (c++) packages.

The same code is also in 3.4, so you should see similar improvements
there.

BTW, (I may have missed it) what's your OS, how much memory does your
system have and does physmem.c report it accurately?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Gerard Beekmans]

On February 23, 2003 09:21 am, Kaveh R. Ghazi wrote:
> Gerald's testcase.  That's great.  I'm interested to see reports from
> other very large (c++) packages.

Any suggestions to make that you'd like to see tested? I got more than enough 
CPU cyles and a decently fast machine (p4-2.2ghz, 512 ram) so I'd be happy to 
help out where I can.

-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Karel Gardas]

On Sun, 23 Feb 2003, Kaveh R. Ghazi wrote:

>  > PS: Seeing these results, I think that it might be interesting to see
>  > gcc3.4 times with Kaveh R. Ghazi's patches (I hope they are already
>  > applied). I'll test it on Monday...
>
> <blush> Thanks, it's very gratifying to know the patch had a positive
> impact.  You're seeing even more of an improvement that I did on
> Gerald's testcase.  That's great.  I'm interested to see reports from
> other very large (c++) packages.
>
> The same code is also in 3.4, so you should see similar improvements
> there.

ACK. Good, anyway, since 3.4 was even faster for MICO compilation than
3.3. I guess it'll be the fastest gcc > 3.2. - that's even w/o using PCH.

> BTW, (I may have missed it) what's your OS, how much memory does your
> system have and does physmem.c report it accurately?

I've already posted it. It's Debian GNU/Linux 3.0 on PIII 256kb L2 cache,
i440BX chipset, 512MB 100MHz SDRAM. pmem reports:

total=503.476562Mb avail=8.234375Mb

Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Kaveh R. Ghazi]

 > Any suggestions to make that you'd like to see tested? I got more than
 > enough CPU cyles and a decently fast machine (p4-2.2ghz, 512 ram) so
 > I'd be happy to help out where I can.
 > Gerard Beekmans

Thanks for volunteering.

If you don't have any large projects or code in mind yourself, perhaps
trying the C++ packages listed in the release criteria application
"integration tests" would be a good start.  See:
http://gcc.gnu.org/gcc-3.1/criteria.html

Ideally, I'd like to see before and after tests for compile times
using 3.3.  (The 3.4 tree is often broken these days IMHO.)

You can simulate the "before" compiler by disabling the heuristics.
Commenting out the init_ggc_heuristics() in toplev.c should do it.  To
validate it was disabled properly, expect to see the old values of 30%
and 4096K for the GC parameters when compiling code with -v in the
"before" compiler.  With 512Mb, the "after" compiler should show
roughly 65% and 65536K but I've seen it vary depending on how
"accurately" the OS responds to physmem's queries.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Zack Weinberg]

Gerard Beekmans <gerard@linuxfromscratch.org> writes:

> What I have in mind are some project that take an hour or more to compile on 
> my system. Examples are qt-3.1.1 (about an hour), kdebase-3.1 (about 80 
> mins), openoffice (about 4.5 hours), java sdk (can't remember how long it 
> used to take but it's a large-ish package for sure).

These are all good.  We're interested in compile speed across all
supported languages, so it's fine to do stuff that isn't C++.

If you can use oprofile to produce summaries for entire package
builds, I'd be very interested to see the results.  In addition
to the obvious user-space CPU cycle counting, it would be good
to see if there's any part of the kernel that gets hammered,
and get cache and TLB miss statistics.

zw

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Gerard Beekmans]

On February 23, 2003 04:00 pm, Kaveh R. Ghazi wrote:
> Thanks for volunteering.

Glad to help.

> If you don't have any large projects or code in mind yourself, perhaps

What I have in mind are some project that take an hour or more to compile on 
my system. Examples are qt-3.1.1 (about an hour), kdebase-3.1 (about 80 
mins), openoffice (about 4.5 hours), java sdk (can't remember how long it 
used to take but it's a large-ish package for sure).

Some of this isn't C++ I know but I'll see what happens anyway.

> trying the C++ packages listed in the release criteria application
> "integration tests" would be a good start.  See:
> http://gcc.gnu.org/gcc-3.1/criteria.html

I can add those too no problem.

> Ideally, I'd like to see before and after tests for compile times
> using 3.3.  (The 3.4 tree is often broken these days IMHO.)

<cut before/after procecure>

Sounds good. It'll be about a week before I can send any feedback, I'm moving 
tomorrow and I won't have Internet hooked up in my new place until coming 
Saturday if the cable company keeps their promise.

I'll pull a CVS copy of gcc-3.3 tonight so I'll have the most recent version I 
can get before I disconnect the computers here.

-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Gerard Beekmans]

On February 23, 2003 04:44 pm, Zack Weinberg wrote:
> If you can use oprofile to produce summaries for entire package
> builds, I'd be very interested to see the results.  In addition
> to the obvious user-space CPU cycle counting, it would be good
> to see if there's any part of the kernel that gets hammered,
> and get cache and TLB miss statistics.

oprofile is a new beast to me. Are you talking about 
http://oprofile.sourceforge.net ?

Got a quick cheat sheet with commands that'll produce output you guys like to 
see (I guess I should just download the package and read the docs that come 
with it).


-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Zack Weinberg]

Gerard Beekmans <gerard@linuxfromscratch.org> writes:

> On February 23, 2003 04:44 pm, Zack Weinberg wrote:
>> If you can use oprofile to produce summaries for entire package
>> builds, I'd be very interested to see the results.  In addition to
>> the obvious user-space CPU cycle counting, it would be good to see
>> if there's any part of the kernel that gets hammered, and get cache
>> and TLB miss statistics.
>
> oprofile is a new beast to me. Are you talking about 
> http://oprofile.sourceforge.net ?

Yes.

> Got a quick cheat sheet with commands that'll produce output you
> guys like to see (I guess I should just download the package and
> read the docs that come with it).

Sorry, the only reason I haven't done this myself is that I haven't
been able to figure out how to get it working on my own systems.

zw

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Mike Stump]

On Sunday, February 23, 2003, at 08:52 AM, Gerard Beekmans wrote:
> On February 23, 2003 09:21 am, Kaveh R. Ghazi wrote:
>> Gerald's testcase.  That's great.  I'm interested to see reports from
>> other very large (c++) packages.
>
> Any suggestions to make that you'd like to see tested?

qt please

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Gerard Beekmans]

On February 23, 2003 04:00 pm, Kaveh R. Ghazi wrote:
> "before" compiler.  With 512Mb, the "after" compiler should show
> roughly 65% and 65536K but I've seen it vary depending on how
> "accurately" the OS responds to physmem's queries.

Pretty much. I have 64% and 64221K

I'll send these emails on a per-package basis as it makes more sense. Work is 
tying me up so instead of waiting a long time for everything in on email I'll 
send the test results as I get them.

I completed tests on QT-3.2.1.
With the "before" compiler it takes 48 minutes
With the "after" compiler it takes 42 minutes
(With gcc-3.2.1 it takes about 60 minutes)

I tried linux-2.4.18 and 2.4.20 but both fail to compiled with the 3.3-CVS 
version so I tried the 2.5.63 version. They are pretty much the same, the 
"before" compiler is 30 seconds faster (5.5 minutes as opposed to 6 minutes) 
on a default config (make defconfig && time make bzImage).

kdebase is due next and I'll start on the packages from the release criteria 
application "integration tests" page.

-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Gerard Beekmans]

On March 3, 2003 02:06 pm, Gerard Beekmans wrote:
> criteria application "integration tests" page.

Emacs-21.2 (all compiles repeated three times to make sure the numbers are 
accurate)
        "Before"        289 seconds (4:54 min)
        "After" 291 seconds (4:51 min)
        gcc-3.2.1       299 seconds (4:49min)



I tried Pooma but I can't get it to configure. I run "./tester.pl <compiler 
prefix>" and it fails. It needs to read the file lib/LINUXgcc but it doens't 
exist. All that's in the 'lib' subdirectory is an empty file called "empty". 
It wasn't clear to me whether I need the 'real' pooma package too or just the 
pooma-gcc package.

I just happened upon the "GCC 3.3 release criteria" thread (still catching up, 
been without Internet for a week while moving there are still almost 700 
unread messages in this list. Going to take me a little while to sift 
through). I'll start with that page and test the packages listed.


-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Gerard Beekmans]

On March 4, 2003 09:29 am, Gerard Beekmans wrote:

And a few more from the gcc-3.3/criteria.html page

ACE-5.3.1 and only ran "make -C ace"; not the entire package (just to save 
some time)
	"Before" compiler:	409 sec (8:16 min)
	"After" compiler:	377 sec (6:17 min)

Blitz-20001213: ran 'make check'
	"Before" compiler:	443 sec (7:23 min)
	"After" compiler:	240 sec (5:40 min)

Boost-1.22.0:
	"Before" compiler:	450 sec (7:30 min)
	"After" compiler:	343 sec (5:43 min)

PS: For those lost in the thread; 'before' compiler refers to gcc-3.3-cvs with 
init_gcc_heuristics(); disabled, the 'after' compiler has this enabled (in 
the gcc/toplev.c file).

PS2: Are more test results desired/required? I'd hate wasting time on these 
particular tests if there are other things that are more useful to be tested.



-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Gerard Beekmans]

On March 4, 2003 01:08 pm, Gerard Beekmans wrote:
> Blitz-20001213: ran 'make check'
> 	"Before" compiler:	443 sec (7:23 min)
> 	"After" compiler:	240 sec (5:40 min)

That would be 340 seconds for the 'after' test (5:40 mins still correct).

-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Karel Gardas]

 Gerard,

I'm sorry but I'm a bit confused by your timings. I guess there are some
typos...

On Tue, 4 Mar 2003, Gerard Beekmans wrote:

> On March 4, 2003 09:29 am, Gerard Beekmans wrote:
>
> And a few more from the gcc-3.3/criteria.html page
>
> ACE-5.3.1 and only ran "make -C ace"; not the entire package (just to save
> some time)
> 	"Before" compiler:	409 sec (8:16 min)

8*60+16 = 496 sec

> 	"After" compiler:	377 sec (6:17 min)
>
> Blitz-20001213: ran 'make check'
> 	"Before" compiler:	443 sec (7:23 min)
> 	"After" compiler:	240 sec (5:40 min)

5*60+40 = 340 sec

Is it right?

Thanks,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: gcc3.3 30% speedup in the past 2 weeks (MICO compilation)

[Gerard Beekmans]

On March 4, 2003 01:49 pm, Karel Gardas wrote:
> I'm sorry but I'm a bit confused by your timings. I guess there are some
> typos...

There are. The 240 vs 340 seconds was spotted earlier.

> > ACE-5.3.1 and only ran "make -C ace"; not the entire package (just to
> > save some time)
> > 	"Before" compiler:	409 sec (8:16 min)
>
> 8*60+16 = 496 sec

You're right, my fault again. I should stick with what I wrote on paper and 
not try to add the seconds as an afterthought. Or I should just use a 
calculator next time.

-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-