public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
@ 2003-05-02 13:26 Jan Hubicka
0 siblings, 0 replies; 6+ messages in thread
From: Jan Hubicka @ 2003-05-02 13:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10155; it has been noted by GNATS.
From: Jan Hubicka <jh@suse.cz>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: p.van-hoof@qub.ac.uk, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org,
jh@suse.de, rakdver@atrey.karlin.mff.cuni.cz
Subject: Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
Date: Fri, 2 May 2003 15:25:16 +0200
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10155
>
> How much of this can be explained with Kaveh's physmem
> patch? IIRC that patch is not in 3.2, and the increase
> in memory consumption at -O2 may be a result of that
> patch.
>
> The increase in memory at -O3 is a result of unit at a
> time compilation (which is why I CC you, Honza). You
> can check that by compiling with -O2 + all flags enabled
> at -O3 except -funit-at-a-time:
>
> ./cc1 10155.c -quiet -ftime-report -O2
> TOTAL : 24.74 0.74 26.24
>
> ./cc1 10155.c -quiet -ftime-report -O2 -funswitch-loops
> -frename-registers -finline-functions
> TOTAL : 31.49 0.59 33.87
>
> Loop unswitching is responsible for most of the compile
Zdenek, this really ought not to happen, what is going on?
> time increase.
> Now add -funit-at-a-time, and kabooooom! you lose.
>
> Apparently unit-at-a-time should still honor some size
> constraints, and it does not in its current form.
It should be more problem of inlining heuristics, than unit-at-a-time
(ie unit-at-a-time enables more inlining oppurtunities but it is
inlining heuristic mistake to take so many of them).
Or perhaps we manage to flatten functions called once into one
extraordinarily large function body and give up on it. I will try to
investigate it, but my current priority is to get unit-at-a-time working
on C++. Fixing this testcase should be easy then :)
Honza
>
> Greetz
> Steven
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
@ 2003-05-06 20:46 Peter van Hoof
0 siblings, 0 replies; 6+ messages in thread
From: Peter van Hoof @ 2003-05-06 20:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10155; it has been noted by GNATS.
From: Peter van Hoof <p.van-hoof@qub.ac.uk>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, jh@suse.de,
rakdver@atrey.karlin.mff.cuni.cz
Subject: Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive
amount of memory
Date: Tue, 06 May 2003 21:41:00 +0100
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10155
> It looks like it's related to the amount of RAM in your
> box. For me, GCC -O2 never consumes more than 40MB, and
> my machine has 192MB. If your system pulls it off to
> keep cc1 alive up to 1772MB, then I suppose you have at
> least four times as much, so your GC param settings will
> be much larger than mine --> GCC eats more memory. That
> _should_ give you a nice speedup over older GCC 3.x...
> So perhaps we can change the synopsis to reflect that his
> really only is a bug with -O3.
>
> Peter, if you compile with "gcc -v", you can see your
> garbage collector parameter settings. For me they are:
> GGC heuristics: --param ggc-min-expand=42 --param ggc-min-heapsize=23891
>
> Can you show us your settings?
Now that my computer is back in the land of the living, I can finally answer
this (in case it is still relevant)... I ran the initial test case on a Sun
Blade 100 with 2GB of RAM, these are the settings with this machine:
GNU C version 3.4 20030504 (experimental) (sparc-sun-solaris2.9)
compiled by GNU C version 3.4 20030504 (experimental).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
The compiler reaches a maximum size of 1894MB, which means that the machine has
to swap out some other processes. I also have an Ultra 5 with 640MB of RAM,
these are the settings on that machine
GGC heuristics: --param ggc-min-expand=73 --param ggc-min-heapsize=81920
I killed the compilation when the compiler grew to >1700MB because swap space
was running dangerously low, i.e. on this machine the compiler would use up all
the swap space it could get its hands on.
Hope this helps...
Peter.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
@ 2003-05-02 19:16 Zdenek Dvorak
0 siblings, 0 replies; 6+ messages in thread
From: Zdenek Dvorak @ 2003-05-02 19:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10155; it has been noted by GNATS.
From: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
To: Jan Hubicka <jh@suse.cz>
Cc: Steven Bosscher <s.bosscher@student.tudelft.nl>,
p.van-hoof@qub.ac.uk, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, jh@suse.de
Subject: Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
Date: Fri, 2 May 2003 21:08:49 +0200
Hello,
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10155
> >
> > How much of this can be explained with Kaveh's physmem
> > patch? IIRC that patch is not in 3.2, and the increase
> > in memory consumption at -O2 may be a result of that
> > patch.
> >
> > The increase in memory at -O3 is a result of unit at a
> > time compilation (which is why I CC you, Honza). You
> > can check that by compiling with -O2 + all flags enabled
> > at -O3 except -funit-at-a-time:
> >
> > ./cc1 10155.c -quiet -ftime-report -O2
> > TOTAL : 24.74 0.74 26.24
> >
> > ./cc1 10155.c -quiet -ftime-report -O2 -funswitch-loops
> > -frename-registers -finline-functions
> > TOTAL : 31.49 0.59 33.87
> >
> > Loop unswitching is responsible for most of the compile
> Zdenek, this really ought not to happen, what is going on?
it is just too many loops; the unswitching takes in fact almost no
time (there is nothing to unswitch at all) -- all the time increase
you see is in verify_loop_structure (it exhibits quadratic behavior
on this kind of tests) and verify_dominators, so I guess there is not much
to worry about.
Zdenek
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
@ 2003-05-02 17:46 Zdenek Dvorak
0 siblings, 0 replies; 6+ messages in thread
From: Zdenek Dvorak @ 2003-05-02 17:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10155; it has been noted by GNATS.
From: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
To: Jan Hubicka <jh@suse.cz>
Cc: Steven Bosscher <s.bosscher@student.tudelft.nl>,
p.van-hoof@qub.ac.uk, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, jh@suse.de
Subject: Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
Date: Fri, 2 May 2003 19:38:39 +0200
Hello,
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10155
> >
> > How much of this can be explained with Kaveh's physmem
> > patch? IIRC that patch is not in 3.2, and the increase
> > in memory consumption at -O2 may be a result of that
> > patch.
> >
> > The increase in memory at -O3 is a result of unit at a
> > time compilation (which is why I CC you, Honza). You
> > can check that by compiling with -O2 + all flags enabled
> > at -O3 except -funit-at-a-time:
> >
> > ./cc1 10155.c -quiet -ftime-report -O2
> > TOTAL : 24.74 0.74 26.24
> >
> > ./cc1 10155.c -quiet -ftime-report -O2 -funswitch-loops
> > -frename-registers -finline-functions
> > TOTAL : 31.49 0.59 33.87
> >
> > Loop unswitching is responsible for most of the compile
> Zdenek, this really ought not to happen, what is going on?
I haven't tested the loop optimizer against a program consisting
from several thousand 3-line loops, so I am not that much surprised
that something went wrong. I will check where is the problem.
Zdenek
> > time increase.
> > Now add -funit-at-a-time, and kabooooom! you lose.
> >
> > Apparently unit-at-a-time should still honor some size
> > constraints, and it does not in its current form.
>
> It should be more problem of inlining heuristics, than unit-at-a-time
> (ie unit-at-a-time enables more inlining oppurtunities but it is
> inlining heuristic mistake to take so many of them).
> Or perhaps we manage to flatten functions called once into one
> extraordinarily large function body and give up on it. I will try to
> investigate it, but my current priority is to get unit-at-a-time working
> on C++. Fixing this testcase should be easy then :)
>
> Honza
> >
> > Greetz
> > Steven
> >
> >
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
@ 2003-05-02 11:06 Steven Bosscher
0 siblings, 0 replies; 6+ messages in thread
From: Steven Bosscher @ 2003-05-02 11:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10155; it has been noted by GNATS.
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: p.van-hoof@qub.ac.uk, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org,
jh@suse.de
Cc:
Subject: Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive
amount of memory
Date: Fri, 02 May 2003 12:58:47 +0200
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10155
How much of this can be explained with Kaveh's physmem
patch? IIRC that patch is not in 3.2, and the increase
in memory consumption at -O2 may be a result of that
patch.
It looks like it's related to the amount of RAM in your
box. For me, GCC -O2 never consumes more than 40MB, and
my machine has 192MB. If your system pulls it off to
keep cc1 alive up to 1772MB, then I suppose you have at
least four times as much, so your GC param settings will
be much larger than mine --> GCC eats more memory. That
_should_ give you a nice speedup over older GCC 3.x...
So perhaps we can change the synopsis to reflect that his
really only is a bug with -O3.
Paul, if you compile with "gcc -v", you can see your
garbage collector parameter settings. For me they are:
GGC heuristics: --param ggc-min-expand=42 --param ggc-min-heapsize=23891
Can you show us your settings?
The increase in memory at -O3 is a result of unit at a
time compilation (which is why I CC you, Honza). You
can check that by compiling with -O2 + all flags enabled
at -O3 except -funit-at-a-time:
./cc1 10155.c -quiet -ftime-report -O2
TOTAL : 24.74 0.74 26.24
./cc1 10155.c -quiet -ftime-report -O2 -funswitch-loops
-frename-registers -finline-functions
TOTAL : 31.49 0.59 33.87
Loop unswitching is responsible for most of the compile
time increase.
Now add -funit-at-a-time, and kabooooom! you lose.
Apparently unit-at-a-time should still honor some size
constraints, and it does not in its current form.
Greetz
Steven
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
@ 2003-04-15 8:51 ebotcazou
0 siblings, 0 replies; 6+ messages in thread
From: ebotcazou @ 2003-04-15 8:51 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, p.van-hoof
Old Synopsis: [SPARC] gcc -O3 uses excessive amount of memory
New Synopsis: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
State-Changed-From-To: open->analyzed
State-Changed-By: ebotcazou
State-Changed-When: Tue Apr 15 08:51:49 2003
State-Changed-Why:
This is not specific to Sparc. Here are my results on x86:
options | gcc -S -O2 | gcc -S -O3
------------------------------------------
gcc 3.2.3 | 13 MB | 14 MB
gcc 3.3 | 44 MB | 48 MB
gcc 3.4 | 52 MB | > 400 MB
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10155
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-05-06 20:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-02 13:26 optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory Jan Hubicka
-- strict thread matches above, loose matches on Subject: below --
2003-05-06 20:46 Peter van Hoof
2003-05-02 19:16 Zdenek Dvorak
2003-05-02 17:46 Zdenek Dvorak
2003-05-02 11:06 Steven Bosscher
2003-04-15 8:51 ebotcazou
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).