* Just a reminder of serious open 3.3 PRs
@ 2003-04-06 16:54 Steven Bosscher
2003-04-06 18:33 ` Jan Hubicka
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Steven Bosscher @ 2003-04-06 16:54 UTC (permalink / raw)
To: gcc
Hi,
These are unassigned, poorly analyzed regressions. All PRs I
mention here are still present on the mainline, so even if you don't
care much about 3.3, you still may want to have a look at these PRs ;-)
The two three are serious compile time regressions from 3.2 that should
be show stoppers for 3.3 according to the GCC release criteria. .
opt/8361 [3.3/3.4 regression] C++ compile-time performance regression
This is a 70% slowdown wrt. 3.0.4, and 30% wrt. 3.2.1. It was blamed
on garbage collection and other things, but no real analysis was done
for this problem. The "official" rule from the release criteria
states that "A release candidate's compile-time should not exceed
GCC 2.95.3 by more than 15% ..." Here we have two times the maximum
slowdown with respect to the latest official release.
BTW This is Gerald's PR that tracks g++ slowdown, ref.
http://gcc.gnu.org/ml/gcc/2002-04/msg01168.html (but read "3.3" for "3.2"
in the table, and keep in mind that 3.3 only slowed down *more* since
these timings were done).
opt/10196 [3.3/3.4 regression] Compile time regression with inlining
This is a >1000% slowdown (i.e. more than 10 times the compile time!)
wrt. 3.2.3. The slowdown is in expand, jump, and cfg cleanup, and was
reported for POOMA. Quote from the release criteria says it all:
"POOMA is a complex expression-template library that will tax the ability
of G++ to deal with templates, an area that has historically been buggy.
In addition, templates have historically taken inordinately much time and
memory at compile-time. With the widespread prevalence of templates in C++
programs, including the standard library, testing this area heavily is
vitally important."
Two other PRs I'd like to bring to your attention are these two wrong-code
bugs:
java/8866 [3.3/3.4 regression] Bug in switch statement code generation -- missing label
Here a complete jump table for a switch statement is being blown away.
Graham Scott said he was working on a fix, but two months have passed
and the bug is still there. The result of problem is clear, but the
cause has not been analysed yet.
opt/8634 [3.2/3.3/3.4 regression] incorrect code for inlining of memcpy under -O2
memcpy a char* buffer, then compare the original to the copy: Not the same?!
Not much analysis, and a rejected workaround patch.
Most other 35 open high-priority PRs are target specific regressions
(probably still present on the mainline as well) or less serious issues
such as ICEs on illegal code or legal but really arcane code (stuff like
inline-asm). 3.3 is IMHO really looking good now, except for these PRs
I mentioned.
Greetz
Steven
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Just a reminder of serious open 3.3 PRs
2003-04-06 16:54 Just a reminder of serious open 3.3 PRs Steven Bosscher
@ 2003-04-06 18:33 ` Jan Hubicka
2003-04-07 6:54 ` Kaveh R. Ghazi
2003-04-14 22:17 ` Gerald Pfeifer
2 siblings, 0 replies; 9+ messages in thread
From: Jan Hubicka @ 2003-04-06 18:33 UTC (permalink / raw)
To: Steven Bosscher; +Cc: gcc
> Hi,
>
> These are unassigned, poorly analyzed regressions. All PRs I
> mention here are still present on the mainline, so even if you don't
> care much about 3.3, you still may want to have a look at these PRs ;-)
>
>
> The two three are serious compile time regressions from 3.2 that should
> be show stoppers for 3.3 according to the GCC release criteria. .
>
> opt/8361 [3.3/3.4 regression] C++ compile-time performance regression
> This is a 70% slowdown wrt. 3.0.4, and 30% wrt. 3.2.1. It was blamed
> on garbage collection and other things, but no real analysis was done
> for this problem. The "official" rule from the release criteria
> states that "A release candidate's compile-time should not exceed
> GCC 2.95.3 by more than 15% ..." Here we have two times the maximum
> slowdown with respect to the latest official release.
> BTW This is Gerald's PR that tracks g++ slowdown, ref.
> http://gcc.gnu.org/ml/gcc/2002-04/msg01168.html (but read "3.3" for "3.2"
> in the table, and keep in mind that 3.3 only slowed down *more* since
> these timings were done).
>
> opt/10196 [3.3/3.4 regression] Compile time regression with inlining
> This is a >1000% slowdown (i.e. more than 10 times the compile time!)
> wrt. 3.2.3. The slowdown is in expand, jump, and cfg cleanup, and was
> reported for POOMA. Quote from the release criteria says it all:
> "POOMA is a complex expression-template library that will tax the ability
> of G++ to deal with templates, an area that has historically been buggy.
> In addition, templates have historically taken inordinately much time and
> memory at compile-time. With the widespread prevalence of templates in C++
> programs, including the standard library, testing this area heavily is
> vitally important."
>
>
> Two other PRs I'd like to bring to your attention are these two wrong-code
> bugs:
>
> java/8866 [3.3/3.4 regression] Bug in switch statement code generation -- missing label
> Here a complete jump table for a switch statement is being blown away.
> Graham Scott said he was working on a fix, but two months have passed
> and the bug is still there. The result of problem is clear, but the
> cause has not been analysed yet.
>
> opt/8634 [3.2/3.3/3.4 regression] incorrect code for inlining of memcpy under -O2
> memcpy a char* buffer, then compare the original to the copy: Not the same?!
> Not much analysis, and a rejected workaround patch.
Zdenek needs to choose better subject next time...
http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01655.html
There is also target/9929 that is quite serious. Hope we will converge
to something soon.
Honza
>
>
> Most other 35 open high-priority PRs are target specific regressions
> (probably still present on the mainline as well) or less serious issues
> such as ICEs on illegal code or legal but really arcane code (stuff like
> inline-asm). 3.3 is IMHO really looking good now, except for these PRs
> I mentioned.
>
> Greetz
> Steven
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Just a reminder of serious open 3.3 PRs
2003-04-06 16:54 Just a reminder of serious open 3.3 PRs Steven Bosscher
2003-04-06 18:33 ` Jan Hubicka
@ 2003-04-07 6:54 ` Kaveh R. Ghazi
2003-04-07 8:41 ` Kaveh R. Ghazi
2003-04-07 15:23 ` Steven Bosscher
2003-04-14 22:17 ` Gerald Pfeifer
2 siblings, 2 replies; 9+ messages in thread
From: Kaveh R. Ghazi @ 2003-04-07 6:54 UTC (permalink / raw)
To: s.bosscher; +Cc: gcc
> opt/8361 [3.3/3.4 regression] C++ compile-time performance regression
> This is a 70% slowdown wrt. 3.0.4, and 30% wrt. 3.2.1. It was blamed
> on garbage collection and other things, but no real analysis was done
> for this problem. The "official" rule from the release criteria
> states that "A release candidate's compile-time should not exceed GCC
> 2.95.3 by more than 15% ..." Here we have two times the maximum
> slowdown with respect to the latest official release. BTW This is
> Gerald's PR that tracks g++ slowdown, ref.
> http://gcc.gnu.org/ml/gcc/2002-04/msg01168.html (but read "3.3" for
> "3.2" in the table, and keep in mind that 3.3 only slowed down *more*
> since these timings were done).
I've analyzed PR8361 generate.ii via --time-report with last night's
3.2 and 3.3 CVS. Looking at the numbers now, I don't think the
problem really is "garbage collection". Even if it is partially to
blame for the time spent compiling, that segment is now much less of a
factor since the physmem patches went in. With this addition, the
"garbage collection" times approach zero for large memory systems
(512Mb to 1Gb,) and when I run the testcase at -O0 on a large memory
solaris2.7 system, I get *faster* overall results for 3.3 than I do
for 3.2. (The same can't be said for -O3 though.)
Even with the memory size crippled down to a simulated 32Mb or 64Mb
the isolated GC times are roughly comparable in 3.2 and 3.3. I.e. the
majority of the actual slowdown came from somewhere else.
At -O0, the hot spots for --time-report were "garbage collection",
"parser" and "name lookup". For -O3 compiles, again "name lookup" is
a big factor, given that it didn't exist in 3.2. I also see that
"global CSE" is much worse. But "expand" is a bit better.
One interesting thing is that in 3.3 both "parser" and especially
"name lookup" use a lot of system time, regardless of the RAM size.
So IMHO analyzing why "name lookup" is so bad and perhaps why "global
CSE" got worse would help with this PR.
--Kaveh
I've included the top entries in timing runs for 3.2, and for 3.3 with
various simulated memory sizes at -O0 and -O3 with CVS from 20030406.
----------------------------------------------------------------------------
These are at -O0:
3.2 (Effectively RAM 32Mb)
garbage collection : 22.57 (26%) usr 0.04 ( 1%) sys 22.00 (24%) wall
parser : 33.95 (40%) usr 1.76 (33%) sys 37.00 (41%) wall
global alloc : 8.51 (10%) usr 0.12 ( 2%) sys 9.25 (10%) wall
TOTAL : 85.75 5.26 91.00
3.3 (RAM 32Mb --param ggc-min-expand=30 --param ggc-min-heapsize=4096)
garbage collection : 24.94 (28%) usr 0.00 ( 0%) sys 25.50 (24%) wall
parser : 27.62 (31%) usr 5.95 (29%) sys 30.25 (28%) wall
name lookup : 10.05 (11%) usr 10.92 (53%) sys 20.50 (19%) wall
global alloc : 8.51 (10%) usr 0.09 ( 0%) sys 9.50 ( 9%) wall
TOTAL : 87.77 20.61 108.50
3.3 (RAM 64Mb --param ggc-min-expand=34 --param ggc-min-heapsize=8192)
garbage collection : 21.93 (26%) usr 0.03 ( 0%) sys 22.25 (21%) wall
parser : 26.94 (32%) usr 5.82 (27%) sys 33.25 (31%) wall
name lookup : 10.02 (12%) usr 11.71 (54%) sys 22.00 (21%) wall
global alloc : 8.44 (10%) usr 0.10 ( 0%) sys 7.50 ( 7%) wall
TOTAL : 84.20 21.63 106.00
3.3 (RAM 256Mb --param ggc-min-expand=47 --param ggc-min-heapsize=32768)
garbage collection : 10.78 (15%) usr 0.01 ( 0%) sys 10.50 (11%) wall
parser : 28.45 (39%) usr 5.64 (27%) sys 32.25 (34%) wall
name lookup : 9.53 (13%) usr 11.16 (54%) sys 23.00 (24%) wall
global alloc : 8.66 (12%) usr 0.07 ( 0%) sys 10.50 (11%) wall
TOTAL : 73.86 20.82 95.00
3.3 (RAM 512Mb --param ggc-min-expand=65 --param ggc-min-heapsize=65536)
garbage collection : 1.97 ( 3%) usr 0.01 ( 0%) sys 2.00 ( 2%) wall
parser : 27.50 (42%) usr 6.60 (30%) sys 32.25 (37%) wall
name lookup : 10.60 (16%) usr 11.04 (51%) sys 21.00 (24%) wall
global alloc : 8.91 (14%) usr 0.17 ( 1%) sys 9.25 (11%) wall
TOTAL : 65.04 21.81 86.75
3.3 (RAM 1Gb --param ggc-min-expand=100 --param ggc-min-heapsize=131072)
garbage collection <doesn't appear!>
parser : 28.73 (45%) usr 7.22 (30%) sys 35.25 (40%) wall
name lookup : 9.56 (15%) usr 11.27 (47%) sys 19.75 (23%) wall
global alloc : 8.65 (14%) usr 0.32 ( 1%) sys 8.25 ( 9%) wall
TOTAL : 63.77 23.89 87.75
----------------------------------------------------------------------------
These are at -O3:
3.2 (Effectively RAM 32Mb)
garbage collection : 41.60 (19%) usr 0.04 ( 1%) sys 41.75 (18%) wall
parser : 33.38 (15%) usr 2.78 (42%) sys 36.25 (16%) wall
expand : 20.57 ( 9%) usr 0.08 ( 1%) sys 21.25 ( 9%) wall
CSE : 28.62 (13%) usr 0.00 ( 0%) sys 30.25 (13%) wall
global CSE : 4.51 ( 2%) usr 0.04 ( 1%) sys 4.00 ( 2%) wall
rename registers : 14.22 ( 6%) usr 0.03 ( 0%) sys 16.50 ( 7%) wall
TOTAL : 222.02 6.61 229.25
3.3 (RAM 32Mb --param ggc-min-expand=30 --param ggc-min-heapsize=4096)
garbage collection : 47.49 (17%) usr 0.02 ( 0%) sys 47.25 (16%) wall
parser : 28.40 (10%) usr 6.54 (31%) sys 37.50 (13%) wall
name lookup : 9.80 ( 4%) usr 11.16 (53%) sys 18.25 ( 6%) wall
expand : 14.84 ( 5%) usr 0.02 ( 0%) sys 12.25 ( 4%) wall
CSE : 37.00 (14%) usr 0.01 ( 0%) sys 35.75 (12%) wall
global CSE : 12.81 ( 5%) usr 0.00 ( 0%) sys 14.00 ( 5%) wall
rename registers : 16.90 ( 6%) usr 0.02 ( 0%) sys 16.00 ( 5%) wall
TOTAL : 271.62 20.95 292.50
3.3 (RAM 64Mb --param ggc-min-expand=34 --param ggc-min-heapsize=8192)
garbage collection : 42.19 (16%) usr 0.00 ( 0%) sys 42.50 (15%) wall
parser : 28.37 (11%) usr 6.13 (29%) sys 33.25 (12%) wall
name lookup : 9.82 ( 4%) usr 11.80 (56%) sys 22.50 ( 8%) wall
expand : 14.66 ( 6%) usr 0.01 ( 0%) sys 18.75 ( 7%) wall
CSE : 37.28 (14%) usr 0.02 ( 0%) sys 34.00 (12%) wall
global CSE : 12.74 ( 5%) usr 0.00 ( 0%) sys 12.50 ( 4%) wall
rename registers : 16.92 ( 6%) usr 0.03 ( 0%) sys 16.25 ( 6%) wall
TOTAL : 265.88 21.07 287.00
3.3 (RAM 256Mb --param ggc-min-expand=47 --param ggc-min-heapsize=32768)
garbage collection : 26.71 (11%) usr 0.00 ( 0%) sys 27.25 (10%) wall
parser : 27.90 (11%) usr 6.86 (31%) sys 33.75 (12%) wall
name lookup : 9.77 ( 4%) usr 11.85 (53%) sys 22.75 ( 8%) wall
expand : 14.64 ( 6%) usr 0.05 ( 0%) sys 15.50 ( 6%) wall
CSE : 36.53 (15%) usr 0.03 ( 0%) sys 37.25 (14%) wall
global CSE : 12.77 ( 5%) usr 0.02 ( 0%) sys 12.75 ( 5%) wall
rename registers : 16.81 ( 7%) usr 0.05 ( 0%) sys 16.75 ( 6%) wall
TOTAL : 248.13 22.17 270.25
3.3 (RAM 512Mb --param ggc-min-expand=65 --param ggc-min-heapsize=65536)
garbage collection : 14.58 ( 6%) usr 0.00 ( 0%) sys 14.50 ( 6%) wall
parser : 28.81 (12%) usr 7.18 (33%) sys 35.00 (13%) wall
name lookup : 9.63 ( 4%) usr 11.23 (51%) sys 21.25 ( 8%) wall
expand : 14.53 ( 6%) usr 0.02 ( 0%) sys 12.25 ( 5%) wall
CSE : 36.47 (15%) usr 0.02 ( 0%) sys 38.50 (15%) wall
global CSE : 12.87 ( 5%) usr 0.01 ( 0%) sys 13.50 ( 5%) wall
rename registers : 16.82 ( 7%) usr 0.05 ( 0%) sys 17.50 ( 7%) wall
TOTAL : 238.27 22.04 260.75
3.3 (RAM 1Gb --param ggc-min-expand=100 --param ggc-min-heapsize=131072)
garbage collection : 4.38 ( 2%) usr 0.00 ( 0%) sys 4.50 ( 2%) wall
parser : 28.58 (13%) usr 7.14 (30%) sys 33.50 (13%) wall
name lookup : 10.47 ( 5%) usr 11.11 (46%) sys 23.00 ( 9%) wall
expand : 14.45 ( 6%) usr 0.89 ( 4%) sys 14.00 ( 6%) wall
CSE : 35.26 (16%) usr 0.16 ( 1%) sys 31.25 (12%) wall
global CSE : 12.60 ( 6%) usr 0.14 ( 1%) sys 14.25 ( 6%) wall
rename registers : 16.74 ( 7%) usr 0.09 ( 0%) sys 16.50 ( 7%) wall
TOTAL : 225.97 24.19 251.00
----------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Just a reminder of serious open 3.3 PRs
2003-04-07 6:54 ` Kaveh R. Ghazi
@ 2003-04-07 8:41 ` Kaveh R. Ghazi
2003-04-07 15:23 ` Steven Bosscher
1 sibling, 0 replies; 9+ messages in thread
From: Kaveh R. Ghazi @ 2003-04-07 8:41 UTC (permalink / raw)
To: s.bosscher; +Cc: gcc
To see what happened between 3.3 and 3.4-mainline, I compiled the
PR8361 generate-3.4.ii test simulating the middle RAM amount of 256Mb.
Results for -O0 and -O3 are below. The -O0 results are almost
identical, however there is some improvement in the -O3 results,
around 6% overall.
The major diffs at -O3 are: "parser"+"name lookup" got worse, "expand"
is much better, "CSE"+"CSE2" got worse and "global CSE" is better.
It might be worthwhile to see if we can identify the speedups for
"expand" and "global CSE" and backport them from mainline to 3.3.
Likewise we should figure out why some of these things got worse.
--Kaveh
----------------------------------------------------------------------------
These are at -O0:
3.3 (RAM 256Mb --param ggc-min-expand=47 --param ggc-min-heapsize=32768)
garbage collection : 9.68 (14%) usr 0.01 ( 0%) sys 9.75 (11%) wall
parser : 27.38 (39%) usr 5.47 (28%) sys 32.75 (37%) wall
name lookup : 9.49 (14%) usr 10.52 (55%) sys 19.00 (21%) wall
global alloc : 7.96 (11%) usr 0.09 ( 0%) sys 10.50 (12%) wall
TOTAL : 70.03 19.29 89.25
3.4 (RAM 256Mb --param ggc-min-expand=47 --param ggc-min-heapsize=32768)
garbage collection : 9.16 (13%) usr 0.01 ( 0%) sys 9.17 (10%) wall
parser : 25.06 (35%) usr 6.07 (32%) sys 31.59 (35%) wall
name lookup : 14.40 (20%) usr 10.79 (57%) sys 24.60 (27%) wall
global alloc : 7.89 (11%) usr 0.08 ( 0%) sys 8.01 ( 9%) wall
TOTAL : 71.61 18.95 90.57
----------------------------------------------------------------------------
These are at -O3:
3.3 (RAM 256Mb --param ggc-min-expand=47 --param ggc-min-heapsize=32768)
garbage collection : 32.99 (12%) usr 0.01 ( 0%) sys 33.00 (11%) wall
parser : 25.62 (10%) usr 7.51 (36%) sys 32.80 (11%) wall
name lookup : 13.79 ( 5%) usr 10.91 (52%) sys 24.89 ( 9%) wall
expand : 27.33 (10%) usr 0.38 ( 2%) sys 27.71 (10%) wall
integration : 9.99 ( 4%) usr 0.05 ( 0%) sys 10.04 ( 3%) wall
CSE : 24.54 ( 9%) usr 0.00 ( 0%) sys 24.54 ( 9%) wall
global CSE : 21.87 ( 8%) usr 0.02 ( 0%) sys 21.88 ( 8%) wall
CSE 2 : 8.29 ( 3%) usr 0.01 ( 0%) sys 8.31 ( 3%) wall
global alloc : 7.96 ( 3%) usr 0.03 ( 0%) sys 8.00 ( 3%) wall
rename registers : 16.56 ( 6%) usr 0.03 ( 0%) sys 16.59 ( 6%) wall
TOTAL : 266.17 20.86 287.04
3.4 (RAM 256Mb --param ggc-min-expand=47 --param ggc-min-heapsize=32768)
garbage collection : 28.59 (11%) usr 0.01 ( 0%) sys 28.75 (11%) wall
parser : 26.85 (11%) usr 6.94 (31%) sys 35.25 (13%) wall
name lookup : 8.95 ( 4%) usr 11.55 (52%) sys 20.25 ( 7%) wall
expand : 15.55 ( 6%) usr 0.06 ( 0%) sys 16.50 ( 6%) wall
integration : 9.09 ( 4%) usr 0.00 ( 0%) sys 9.25 ( 3%) wall
CSE : 36.49 (15%) usr 0.01 ( 0%) sys 36.50 (13%) wall
global CSE : 12.44 ( 5%) usr 0.03 ( 0%) sys 11.75 ( 4%) wall
CSE 2 : 10.30 ( 4%) usr 0.00 ( 0%) sys 11.75 ( 4%) wall
global alloc : 7.61 ( 3%) usr 0.01 ( 0%) sys 10.00 ( 4%) wall
rename registers : 16.64 ( 7%) usr 0.02 ( 0%) sys 16.00 ( 6%) wall
TOTAL : 248.67 22.09 271.00
----------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Just a reminder of serious open 3.3 PRs
2003-04-07 6:54 ` Kaveh R. Ghazi
2003-04-07 8:41 ` Kaveh R. Ghazi
@ 2003-04-07 15:23 ` Steven Bosscher
2003-04-07 17:13 ` Kaveh R. Ghazi
1 sibling, 1 reply; 9+ messages in thread
From: Steven Bosscher @ 2003-04-07 15:23 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc
Op ma 07-04-2003, om 02:21 schreef Kaveh R. Ghazi:
> I've included the top entries in timing runs for 3.2, and for 3.3 with
> various simulated memory sizes at -O0 and -O3 with CVS from 20030406.
> 3.3 (RAM 1Gb --param ggc-min-expand=100 --param ggc-min-heapsize=131072)
> garbage collection <doesn't appear!>
It had better not appear. You have a heap as big as the total memory
many people have in their computer. It probably never collects at all :-)
---- 8< ----
> These are at -O3:
>
> 3.2 (Effectively RAM 32Mb)
> garbage collection : 41.60 (19%) usr 0.04 ( 1%) sys 41.75 (18%) wall
> parser : 33.38 (15%) usr 2.78 (42%) sys 36.25 (16%) wall
> expand : 20.57 ( 9%) usr 0.08 ( 1%) sys 21.25 ( 9%) wall
> CSE : 28.62 (13%) usr 0.00 ( 0%) sys 30.25 (13%) wall
> global CSE : 4.51 ( 2%) usr 0.04 ( 1%) sys 4.00 ( 2%) wall
> rename registers : 14.22 ( 6%) usr 0.03 ( 0%) sys 16.50 ( 7%) wall
> TOTAL : 222.02 6.61 229.25
>
---- 8< ----
> 3.3 (RAM 1Gb --param ggc-min-expand=100 --param ggc-min-heapsize=131072)
> garbage collection : 4.38 ( 2%) usr 0.00 ( 0%) sys 4.50 ( 2%) wall
> parser : 28.58 (13%) usr 7.14 (30%) sys 33.50 (13%) wall
> name lookup : 10.47 ( 5%) usr 11.11 (46%) sys 23.00 ( 9%) wall
> expand : 14.45 ( 6%) usr 0.89 ( 4%) sys 14.00 ( 6%) wall
> CSE : 35.26 (16%) usr 0.16 ( 1%) sys 31.25 (12%) wall
> global CSE : 12.60 ( 6%) usr 0.14 ( 1%) sys 14.25 ( 6%) wall
> rename registers : 16.74 ( 7%) usr 0.09 ( 0%) sys 16.50 ( 7%) wall
> TOTAL : 225.97 24.19 251.00
So with the GC params set to the defaults, 3.3 needs 1 friggin' GB to be
close to but still slower than 3.2 with only 32MB!? That looks really
sad...
Were these timings you did avarages or did you do one run for each?
Greetz
Steven
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Just a reminder of serious open 3.3 PRs
2003-04-07 15:23 ` Steven Bosscher
@ 2003-04-07 17:13 ` Kaveh R. Ghazi
0 siblings, 0 replies; 9+ messages in thread
From: Kaveh R. Ghazi @ 2003-04-07 17:13 UTC (permalink / raw)
To: s.bosscher; +Cc: gcc
> From: Steven Bosscher <s.bosscher@student.tudelft.nl>
>
> Op ma 07-04-2003, om 02:21 schreef Kaveh R. Ghazi:
> > I've included the top entries in timing runs for 3.2, and for 3.3 with
> > various simulated memory sizes at -O0 and -O3 with CVS from 20030406.
>
> > 3.3 (RAM 1Gb --param ggc-min-expand=100 --param ggc-min-heapsize=131072)
> > garbage collection <doesn't appear!>
>
> It had better not appear. You have a heap as big as the total memory
> many people have in their computer. It probably never collects at all :-)
>
> ---- 8< ----
> > These are at -O3:
> >
> > 3.2 (Effectively RAM 32Mb)
> > garbage collection : 41.60 (19%) usr 0.04 ( 1%) sys 41.75 (18%) wall
> > parser : 33.38 (15%) usr 2.78 (42%) sys 36.25 (16%) wall
> > expand : 20.57 ( 9%) usr 0.08 ( 1%) sys 21.25 ( 9%) wall
> > CSE : 28.62 (13%) usr 0.00 ( 0%) sys 30.25 (13%) wall
> > global CSE : 4.51 ( 2%) usr 0.04 ( 1%) sys 4.00 ( 2%) wall
> > rename registers : 14.22 ( 6%) usr 0.03 ( 0%) sys 16.50 ( 7%) wall
> > TOTAL : 222.02 6.61 229.25
> >
> ---- 8< ----
> > 3.3 (RAM 1Gb --param ggc-min-expand=100 --param ggc-min-heapsize=131072)
> > garbage collection : 4.38 ( 2%) usr 0.00 ( 0%) sys 4.50 ( 2%) wall
> > parser : 28.58 (13%) usr 7.14 (30%) sys 33.50 (13%) wall
> > name lookup : 10.47 ( 5%) usr 11.11 (46%) sys 23.00 ( 9%) wall
> > expand : 14.45 ( 6%) usr 0.89 ( 4%) sys 14.00 ( 6%) wall
> > CSE : 35.26 (16%) usr 0.16 ( 1%) sys 31.25 (12%) wall
> > global CSE : 12.60 ( 6%) usr 0.14 ( 1%) sys 14.25 ( 6%) wall
> > rename registers : 16.74 ( 7%) usr 0.09 ( 0%) sys 16.50 ( 7%) wall
> > TOTAL : 225.97 24.19 251.00
>
> So with the GC params set to the defaults, 3.3 needs 1 friggin' GB to be
> close to but still slower than 3.2 with only 32MB!? That looks really
> sad...
Agreed, my point was to illustrate that blaming GC was not looking in
the right spot. We certainly have room for improvement in other areas.
>
> Were these timings you did avarages or did you do one run for each?
One each, it would have been too hard to do averages given the number
of fields and columns. However I did run some of the tests multiple
times and they didn't vary by more than 1-3 seconds in the "TOTAL"
column so I belive the numbers are fairly consistent.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Just a reminder of serious open 3.3 PRs
2003-04-06 16:54 Just a reminder of serious open 3.3 PRs Steven Bosscher
2003-04-06 18:33 ` Jan Hubicka
2003-04-07 6:54 ` Kaveh R. Ghazi
@ 2003-04-14 22:17 ` Gerald Pfeifer
2003-04-14 22:56 ` Steven Bosscher
2 siblings, 1 reply; 9+ messages in thread
From: Gerald Pfeifer @ 2003-04-14 22:17 UTC (permalink / raw)
To: Steven Bosscher; +Cc: gcc, Kaveh R. Ghazi
On Sun, 6 Apr 2003, Steven Bosscher wrote:
> The two three are serious compile time regressions from 3.2 that should
> be show stoppers for 3.3 according to the GCC release criteria. .
>
> opt/8361 [3.3/3.4 regression] C++ compile-time performance regression
> This is a 70% slowdown wrt. 3.0.4, and 30% wrt. 3.2.1. It was blamed
> on garbage collection and other things, but no real analysis was done
> for this problem. The "official" rule from the release criteria
> states that "A release candidate's compile-time should not exceed
> GCC 2.95.3 by more than 15% ..." Here we have two times the maximum
> slowdown with respect to the latest official release.
Here is a comparison of how GCC evolved (snapshots around mid of last
week):
-O0 -O1 -O2 -O3
GCC 3.0.4 27.95 44.52 56.57 56.48
3.2-branch 29.87 +7% 54.28 +22% 70.95 +25% 75.29 +33%
3.3-branch 29.09 +4% 57.11 +30% 78.99 +40% 81.61 +44%
mainline 27.06 56.09 77.77 82.02
Here we have +30% when comparing against 3.0.4 for -O1, and +40% for -O2!
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.pfeifer.com/gerald/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Just a reminder of serious open 3.3 PRs
2003-04-14 22:17 ` Gerald Pfeifer
@ 2003-04-14 22:56 ` Steven Bosscher
2003-04-15 14:31 ` Gerald Pfeifer
0 siblings, 1 reply; 9+ messages in thread
From: Steven Bosscher @ 2003-04-14 22:56 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: gcc, Kaveh R. Ghazi
Op ma 14-04-2003, om 22:45 schreef Gerald Pfeifer:
> On Sun, 6 Apr 2003, Steven Bosscher wrote:
> > The two three are serious compile time regressions from 3.2 that should
> > be show stoppers for 3.3 according to the GCC release criteria. .
> >
> > opt/8361 [3.3/3.4 regression] C++ compile-time performance regression
> > This is a 70% slowdown wrt. 3.0.4, and 30% wrt. 3.2.1. It was blamed
> > on garbage collection and other things, but no real analysis was done
> > for this problem. The "official" rule from the release criteria
> > states that "A release candidate's compile-time should not exceed
> > GCC 2.95.3 by more than 15% ..." Here we have two times the maximum
> > slowdown with respect to the latest official release.
>
> Here is a comparison of how GCC evolved (snapshots around mid of last
> week):
>
> -O0 -O1 -O2 -O3
> GCC 3.0.4 27.95 44.52 56.57 56.48
> 3.2-branch 29.87 +7% 54.28 +22% 70.95 +25% 75.29 +33%
> 3.3-branch 29.09 +4% 57.11 +30% 78.99 +40% 81.61 +44%
> mainline 27.06 56.09 77.77 82.02
>
> Here we have +30% when comparing against 3.0.4 for -O1, and +40% for -O2!
Yes -- but what is a bit surprising (at least, to me) is that most of
the slowdown is already introduced at -O1.
What do the time reports tell you, which parts are the biggest losers?
I assume you left the default GC params in for 3.3 and mainline?
Greetz
Steven
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Just a reminder of serious open 3.3 PRs
2003-04-14 22:56 ` Steven Bosscher
@ 2003-04-15 14:31 ` Gerald Pfeifer
0 siblings, 0 replies; 9+ messages in thread
From: Gerald Pfeifer @ 2003-04-15 14:31 UTC (permalink / raw)
To: Steven Bosscher; +Cc: gcc, Kaveh R. Ghazi
On Tue, 15 Apr 2003, Steven Bosscher wrote:
>> -O0 -O1 -O2 -O3
>> GCC 3.0.4 27.95 44.52 56.57 56.48
>> 3.2-branch 29.87 +7% 54.28 +22% 70.95 +25% 75.29 +33%
>> 3.3-branch 29.09 +4% 57.11 +30% 78.99 +40% 81.61 +44%
>> mainline 27.06 56.09 77.77 82.02
>>
>> Here we have +30% when comparing against 3.0.4 for -O1, and +40% for -O2!
> Yes -- but what is a bit surprising (at least, to me) is that most of
> the slowdown is already introduced at -O1.
>
> What do the time reports tell you, which parts are the biggest losers?
> I assume you left the default GC params in for 3.3 and mainline?
Yes, so in a sense if was unfair towards _older_ releases, and the
current CVS sources are even worse. :-(
Dan Nicolaescu and Kaveh Ghazi did some further analyses
http://gcc.gnu.org/ml/gcc/2002-12/msg00516.html
http://gcc.gnu.org/ml/gcc/2003-04/msg00251.html
http://gcc.gnu.org/ml/gcc/2003-04/msg00252.html
and I know also updated PR/8361 with this new information.
Gerald
PS: Note that I first filed this problem as PR 3083 close to two years
ago. :-(
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-04-15 12:32 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-06 16:54 Just a reminder of serious open 3.3 PRs Steven Bosscher
2003-04-06 18:33 ` Jan Hubicka
2003-04-07 6:54 ` Kaveh R. Ghazi
2003-04-07 8:41 ` Kaveh R. Ghazi
2003-04-07 15:23 ` Steven Bosscher
2003-04-07 17:13 ` Kaveh R. Ghazi
2003-04-14 22:17 ` Gerald Pfeifer
2003-04-14 22:56 ` Steven Bosscher
2003-04-15 14:31 ` Gerald Pfeifer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).