Re: compiler memory use optimization

Re: compiler memory use optimization

[Dan Kegel]

Joe Buck wrote:

> Giovanni Bajo wrote:
>> The good news is that 3.4 is much better [than 3.3] on many testcases.
>> (Un)luckily, it is also much more ISO/ANSI C++ standard compliant, so
>> upgrading from 3.3 to 3.4 for a large C++ applications could be non-trivial.
> 
> This is mainly the case for those who have never used compilers other than
> g++, and who learn the language by throwing code at the compiler and
> seeing what works.

The scars on my back say large C++ applications by even very
good programmers can be a lot of work to port from gcc-3.3 to gcc-3.4.
Or from gcc-2.95.3 to gcc-3.3.  Or from 32 bit to 64 bit.  Or from
gcc-3.4 to icc-8.1.  Any big change brings its own set of problems...
- Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

compiler memory use optimization

[naje]

Hi,
my program use C++ templates vary hard, so i've got much memory spent for
compilation, and sometimes i've got "virtual memory exhaust" error.
Is there any way to find out which part of my program is hard to
compile to optimize it, and is there any methods to optimize memory use in gcc?
And that kinds of optimizations of my code can i use to optimize
compilation?

I use gcc3.3 on freebsd 5.2.
Thank you.

Re: compiler memory use optimization

[Giovanni Bajo]

naje <najeiv@ukr.net> wrote:

> my program use C++ templates vary hard, so i've got much memory spent for
> compilation, and sometimes i've got "virtual memory exhaust" error.
> Is there any way to find out which part of my program is hard to
> compile to optimize it, and is there any methods to optimize memory use in
> gcc? And that kinds of optimizations of my code can i use to optimize
> compilation?

It's not easy to tell because they are mostly ineffeciencies spread across
the whole compiler. Surely we can do nothing without a preprocessed source
code to start with (and we can do nothing for 3.3 anyway -- see below).

> I use gcc3.3 on freebsd 5.2.

The good news is that 3.4 is much better at this on many testcases.
(Un)luckily, it is also much more ISO/ANSI C++ standard compliant, so
upgrading from 3.3 to 3.4 for a large C++ applications could be non-trivial.

I suggest you to try it anyway. You can consult
http://gcc.gnu.org/gcc-3.4/change.html, which contains the most common
problems found when upgrading to 3.4, with examples. After you upgraded, get
back to us and tell us how it behaves. Another good point in upgrading is
that if the problem is still reproducible with 3.4, you can submit a bug
report and we'll look into it. 3.3 is near to dead at this point, so major
work to improve compile time or memory occupaiton is very unlikely on that
branch.
-- 
Giovanni Bajo

Re: compiler memory use optimization

[Joe Buck]

On Thu, Nov 18, 2004 at 07:45:16PM +0100, Giovanni Bajo wrote:
> The good news is that 3.4 is much better [than 3.3] on many testcases.
> (Un)luckily, it is also much more ISO/ANSI C++ standard compliant, so
> upgrading from 3.3 to 3.4 for a large C++ applications could be non-trivial.

This is mainly the case for those who have never used compilers other than
g++, and who learn the language by throwing code at the compiler and
seeing what works.

Re: compiler memory use optimization

[Mike Stump]

On Nov 18, 2004, at 10:33 AM, naje wrote:
> my program use C++ templates vary hard, so i've got much memory spent 
> for
> compilation, and sometimes i've got "virtual memory exhaust" error.
> Is there any way to find out which part of my program is hard to
> compile to optimize it

Compile with -Q, and watch what is slow...  Also, the { 20M -> 10M } 
type numbers indicate how much memory was used by the compiler during 
compilation of the corresponding function.  The first is before GC, the 
second is post GC.

Also, you might try a 4.0 snapshot with your code, so that you can see 
the general trends, with some luck, it might be faster to compile and 
require less memory.

Also, you can try things like -O2/-O0 and see if it is optimization 
related, or not.