GCC speed

GCC speed

[Andy Rysin]

Hello All!

I am compiling large C++ project  (about 40K lines)
using Qt under Linux with GCC (egcs-1.1.2) and under
Win95 with Borland C++ Builder 4.
The point is compile time with GCC is about 2.5 time
of BCC one. (MSVC is about as slow as G++ also on this
hardware)
I tried gcc-2.95.x but compile time is mostly the
same.
Would you please tell me what is the bottleneck of G++
for today?

Besides QT I am using templates but is restricted to
one *.h and one *.cpp files and stl::string class.

Config is RH6.1/2.3.29 and Win95 on Compaq Armada with
P200MMX/96M

TIA,
Andy.
__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

Re: GCC speed

[Martin v. Loewis]

> Would you please tell me what is the bottleneck of G++
> for today?

AFAIK, there are two major consumers of compile time in g++ today:
overload resolution, and template instantiation.

When you have lots of functions with the same name, g++ will need some
time for each call, in overload resolution. This is what makes a C
compiler faster: You don't have overload resolution in C. Things get
more tricky due to conversion sequences, which all have to be
computed.

For templates, every instantiation is time-consuming, as it involves
creating a deep copy of the template. This nicely combines with
overload resolution: If lookup finds a template function, the
following things must happen:
- deduction of template arguments from the function call arguments
- instantiation of the selected template
- computation of conversion sequences for the instantiated parameters
- participation of the instance in overload resolution.

Please note that the standard library defines a number of template
functions on its own, so you might see more templates than you are
aware of. Template operators are particularly bad, since you need to
look at them every time an operator is used. For example, for strings,
there is an operator

template <class charT, class traits, class Allocator>
inline bool
operator>= (const basic_string <charT, traits, Allocator>& lhs,
	    const basic_string <charT, traits, Allocator>& rhs)
{
  return (lhs.compare (rhs) >= 0);
}

This is considered every time you have >= in your program, and so on.

You may want to check out the development snapshot of gcc and see how
it works, it should have a number of improvements in the area of
compilation speed; although nobody has analysed this in detail, so far.

Hope this helps,
Martin

Re: GCC speed

[Gerald Pfeifer]

On Thu, 23 Dec 1999, Martin v. Loewis wrote:
> You may want to check out the development snapshot of gcc and see how
> it works, it should have a number of improvements in the area of
> compilation speed; although nobody has analysed this in detail, so far.

For my (template heavy) code development snapshots are quite a bit slower
and need twice as much memory as GCC 2.95.x, and there have been similiar
reports by others, so I'd recommended carefully checking which version if
better for your need.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

GCC speed

[Andy Rysin]

Hello All!

I am compiling large C++ project  (about 40K lines)
using Qt under Linux with GCC (egcs-1.1.2) and under
Win95 with Borland C++ Builder 4.
The point is compile time with GCC is about 2.5 time
of BCC one. (MSVC is about as slow as G++ also on this
hardware)
I tried gcc-2.95.x but compile time is mostly the
same.
Would you please tell me what is the bottleneck of G++
for today?

Besides QT I am using templates but is restricted to
one *.h and one *.cpp files and stl::string class.

Config is RH6.1/2.3.29 and Win95 on Compaq Armada with
P200MMX/96M

TIA,
Andy.
__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

Re: GCC speed

[Gerald Pfeifer]

On Thu, 23 Dec 1999, Martin v. Loewis wrote:
> You may want to check out the development snapshot of gcc and see how
> it works, it should have a number of improvements in the area of
> compilation speed; although nobody has analysed this in detail, so far.

For my (template heavy) code development snapshots are quite a bit slower
and need twice as much memory as GCC 2.95.x, and there have been similiar
reports by others, so I'd recommended carefully checking which version if
better for your need.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: GCC speed

[Martin v. Loewis]

> Would you please tell me what is the bottleneck of G++
> for today?

AFAIK, there are two major consumers of compile time in g++ today:
overload resolution, and template instantiation.

When you have lots of functions with the same name, g++ will need some
time for each call, in overload resolution. This is what makes a C
compiler faster: You don't have overload resolution in C. Things get
more tricky due to conversion sequences, which all have to be
computed.

For templates, every instantiation is time-consuming, as it involves
creating a deep copy of the template. This nicely combines with
overload resolution: If lookup finds a template function, the
following things must happen:
- deduction of template arguments from the function call arguments
- instantiation of the selected template
- computation of conversion sequences for the instantiated parameters
- participation of the instance in overload resolution.

Please note that the standard library defines a number of template
functions on its own, so you might see more templates than you are
aware of. Template operators are particularly bad, since you need to
look at them every time an operator is used. For example, for strings,
there is an operator

template <class charT, class traits, class Allocator>
inline bool
operator>= (const basic_string <charT, traits, Allocator>& lhs,
	    const basic_string <charT, traits, Allocator>& rhs)
{
  return (lhs.compare (rhs) >= 0);
}

This is considered every time you have >= in your program, and so on.

You may want to check out the development snapshot of gcc and see how
it works, it should have a number of improvements in the area of
compilation speed; although nobody has analysed this in detail, so far.

Hope this helps,
Martin

Re: GCC speed

[Mike Stump]

> Date: Wed, 22 Dec 1999 17:14:56 -0800 (PST)
> From: Andy Rysin <arysin@yahoo.com>

> The point is compile time with GCC is about 2.5 time of BCC one.

Sure, compile with -O0 and see if that makes a difference.  Next, you
can try -fno-inlines -fno-inline-functions and see if that help.
After that, you might try -frepo.  In this last case, compare times
with the second compile, not the first compile.

Some or all of these might make your compile go faster.  The expense
will be in generated code quality.  Feel free to compare code quality
between the two compilers as well.

Re: GCC speed

[Mike Stump]

> Date: Wed, 22 Dec 1999 17:14:56 -0800 (PST)
> From: Andy Rysin <arysin@yahoo.com>

> The point is compile time with GCC is about 2.5 time of BCC one.

Sure, compile with -O0 and see if that makes a difference.  Next, you
can try -fno-inlines -fno-inline-functions and see if that help.
After that, you might try -frepo.  In this last case, compare times
with the second compile, not the first compile.

Some or all of these might make your compile go faster.  The expense
will be in generated code quality.  Feel free to compare code quality
between the two compilers as well.

gcc speed

[Jochen Kuepper]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

Citing from http://www.cs.utk.edu/~rwhaley/ATLAS/errata.html:

  Dec ALPHA compilers

  If you are using a DEC Alpha, it is extremely important to use gnu gcc,
  rather than egcs gcc. On my 533Mhz Dec ALPHA, using egcs 1.1.1 and gnu gcc
  2.8.1, gcc provides roughly 590 Mflop DGEMM, whereas egcs results in 520 or
  so. User's of DEC unix should be aware that cc should not be used to compile
  the generated code. The compiler does not allow the turning off of
  optimizations that cause optimal code to run slower, so you should compile
  these routines with gcc. 
  [snip]

What do you think about that. Has anybody else some numbers to compare ?

Greetings,
Jochen
-----------------------------------------------------------------------
  Jochen Küpper

  Heinrich-Heine-Universität Düsseldorf     jochen@uni-duesseldorf.de
  Institut für Physikalische Chemie I
  Universitätsstr. 1, Geb 26.43 Raum 02.29     phone ++49-211-8113681
  40225 Düsseldorf                             fax   ++49-211-8115195
  Germany             http://www-public.rz.uni-duesseldorf.de/~jochen
-----------------------------------------------------------------------

gcc speed

[Jochen Kuepper]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

Citing from http://www.cs.utk.edu/~rwhaley/ATLAS/errata.html:

  Dec ALPHA compilers

  If you are using a DEC Alpha, it is extremely important to use gnu gcc,
  rather than egcs gcc. On my 533Mhz Dec ALPHA, using egcs 1.1.1 and gnu gcc
  2.8.1, gcc provides roughly 590 Mflop DGEMM, whereas egcs results in 520 or
  so. User's of DEC unix should be aware that cc should not be used to compile
  the generated code. The compiler does not allow the turning off of
  optimizations that cause optimal code to run slower, so you should compile
  these routines with gcc. 
  [snip]

What do you think about that. Has anybody else some numbers to compare ?

Greetings,
Jochen
-----------------------------------------------------------------------
  Jochen Küpper

  Heinrich-Heine-Universität Düsseldorf     jochen@uni-duesseldorf.de
  Institut für Physikalische Chemie I
  Universitätsstr. 1, Geb 26.43 Raum 02.29     phone ++49-211-8113681
  40225 Düsseldorf                             fax   ++49-211-8115195
  Germany             http://www-public.rz.uni-duesseldorf.de/~jochen
-----------------------------------------------------------------------