public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Code Bloat using GCC 3.2 on Linux
@ 2004-12-15 11:45 Gaurav Jain
  2004-12-15 12:45 ` jlh
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Gaurav Jain @ 2004-12-15 11:45 UTC (permalink / raw)
  To: gcc-help

Hi,

I have an application which is compiled using gcc 3.2 on linux.  The
problem is that the same application compiled on Windows using MS
VC.net is much smaller in size (about 1/2) than that on linux.  The
application uses mainly C++ code, has lots of exception handling and
templates.

I'm currently using the following options to compile my source files:
gcc -x c++ -O2 -fno-omit-frame-pointer -ffloat-store -fno-inline
-Wno-multichar -fexceptions -mcpu=pentium

and the following for linking:
gcc -rdynamic -lm  -ldl -lpthread

I wish to know whether there are any gcc options that can be used to
combat the excessive code bloat using gcc on linux?  Why should the
same code have 1/2 the size on Windows?  What's the way to get the
MINIMUM possible size of an application using gcc 3.2 (even if it is
at the cost of some run-time performance)?

Any help would be highly useful.

TIA,
-Gaurav

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Code Bloat using GCC 3.2 on Linux
  2004-12-15 11:45 Code Bloat using GCC 3.2 on Linux Gaurav Jain
@ 2004-12-15 12:45 ` jlh
       [not found] ` <20041215132426.78ca7b5e@zeta.comsys.se>
  2004-12-20  6:18 ` Joe Steeve
  2 siblings, 0 replies; 11+ messages in thread
From: jlh @ 2004-12-15 12:45 UTC (permalink / raw)
  To: gcc-help

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]


> What's the way to get the
> MINIMUM possible size of an application using gcc 3.2 (even if it is
> at the cost of some run-time performance)?

Try the optimization option -Os instead of -O2, though I don't know
if this option was present in 3.2 already.

jlh

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Code Bloat using GCC 3.2 on Linux
       [not found] ` <20041215132426.78ca7b5e@zeta.comsys.se>
@ 2004-12-15 14:11   ` Gaurav Jain
       [not found]     ` <6.2.0.14.2.20041215081802.0207dbd8@iplan-mn.corp.adobe.com>
  0 siblings, 1 reply; 11+ messages in thread
From: Gaurav Jain @ 2004-12-15 14:11 UTC (permalink / raw)
  To: gcc-help

Thanks for that tip.  I tried using -Os, but it dosn't help much.

The "bloat" is in all the object files, and the final executable.  In
fact all binaries seem to be larger on Linux than on Windows.

I read the following document on templates:
http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Template-Instantiation.html#Template%20Instantiation

From this, is it correct to assume that since I'm using gcc 3.2 and ld
2.13, and since I'm working on an ELF system such as Linux, I don't
need to use any of the options that are specified (such as -frepo or
-fno-implicit-templates) because this version of ld would follow the
"Borland Model", and would automatically take care of "each template
instance occurs exactly once in the executable if it is needed, and
not at all otherwise" requirement?

Also, are there any "tools" that can be used to analyze generated code on Linux?

Thanks so much,
-Gaurav

On Wed, 15 Dec 2004 13:24:26 +0100, Lars Segerlund
<lars.segerlund@comsys.se> wrote:
> 
> If the 'bloat' is not in libraries, try -OS ( optimise small ).
> You have also some options like -fno-unrolling ( or something like that ).
> 
> I don't know if you can use -OS with -O2 but try and se if it makes any difference.
> 
> Also it would be nice to knoow where the 'bloat' is, perhaps you can have a look at the generated code with _S ( generates assembly for gcc ) and the corresponding flag for win.
> 
> / regards, Lars Segerlund.
> 
> On Wed, 15 Dec 2004 17:14:54 +0530
> Gaurav Jain <gaurav.anywhere@gmail.com> wrote:
> 
> > Hi,
> >
> > I have an application which is compiled using gcc 3.2 on linux.  The
> > problem is that the same application compiled on Windows using MS
> > VC.net is much smaller in size (about 1/2) than that on linux.  The
> > application uses mainly C++ code, has lots of exception handling and
> > templates.
> >
> > I'm currently using the following options to compile my source files:
> > gcc -x c++ -O2 -fno-omit-frame-pointer -ffloat-store -fno-inline
> > -Wno-multichar -fexceptions -mcpu=pentium
> >
> > and the following for linking:
> > gcc -rdynamic -lm  -ldl -lpthread
> >
> > I wish to know whether there are any gcc options that can be used to
> > combat the excessive code bloat using gcc on linux?  Why should the
> > same code have 1/2 the size on Windows?  What's the way to get the
> > MINIMUM possible size of an application using gcc 3.2 (even if it is
> > at the cost of some run-time performance)?
> >
> > Any help would be highly useful.
> >
> > TIA,
> > -Gaurav
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Code Bloat using GCC 3.2 on Linux
       [not found]     ` <6.2.0.14.2.20041215081802.0207dbd8@iplan-mn.corp.adobe.com>
@ 2004-12-15 15:28       ` Gaurav Jain
  2004-12-15 16:09         ` Andras Tantos
       [not found]         ` <6.2.0.14.2.20041215094647.020cf100@iplan-mn.corp.adobe.com>
  0 siblings, 2 replies; 11+ messages in thread
From: Gaurav Jain @ 2004-12-15 15:28 UTC (permalink / raw)
  To: gcc-help

Hi Eljay,

What's more important for me is the size on disk.  I want a small file
that can be easy to download.

I have already tried the "strip" command, and the relative figures I
gave were after stripping the binaries.

-Gaurav


On Wed, 15 Dec 2004 08:22:02 -0600, Eljay Love-Jensen <eljay@adobe.com> wrote:
> Hi Guarav,
> 
> Did you do the "strip" command on the output binary?
> 
> strip myexecutable
> 
> That might cut out 10%.
> 
> When you are talking about the "bloat", are you speaking about the file, or
> of the memory footprint of the program when running?
> 
> If you are speaking of the file, that does not necessarily correspond to
> "bloat" in memory.  The Linux executable file may be 100 KB, and the memory
> footprint (code + data) may be 200 KB.  The Windows executable file may be
> 50 KB and the memory footprint (code + data) may be 10 MB.
> 
> I'm just trying to understand what you consider "bloat".  Is it important
> that the file be small, or that the running memory footprint be small?
> 
> --Eljay
> 
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Code Bloat using GCC 3.2 on Linux
  2004-12-15 15:28       ` Gaurav Jain
@ 2004-12-15 16:09         ` Andras Tantos
  2004-12-16  5:09           ` Gaurav Jain
       [not found]         ` <6.2.0.14.2.20041215094647.020cf100@iplan-mn.corp.adobe.com>
  1 sibling, 1 reply; 11+ messages in thread
From: Andras Tantos @ 2004-12-15 16:09 UTC (permalink / raw)
  To: Gaurav Jain, gcc-help

Hi!

Try adding this to the compiler 
switches: -fdata-sections -ffunction-sections
And this to the linker: --gc-sections

This turns on garbage-collection on sections which is off by default in GCC 
(AFIK) and on by default in VC.

Regards,
Andras Tantos

----- Original Message ----- 
From: "Gaurav Jain" <gaurav.anywhere@gmail.com>
To: <gcc-help@gcc.gnu.org>
Sent: Wednesday, December 15, 2004 7:28 AM
Subject: Re: Code Bloat using GCC 3.2 on Linux


> Hi Eljay,
>
> What's more important for me is the size on disk.  I want a small file
> that can be easy to download.
>
> I have already tried the "strip" command, and the relative figures I
> gave were after stripping the binaries.
>
> -Gaurav
>
>
> On Wed, 15 Dec 2004 08:22:02 -0600, Eljay Love-Jensen <eljay@adobe.com> 
> wrote:
>> Hi Guarav,
>>
>> Did you do the "strip" command on the output binary?
>>
>> strip myexecutable
>>
>> That might cut out 10%.
>>
>> When you are talking about the "bloat", are you speaking about the file, 
>> or
>> of the memory footprint of the program when running?
>>
>> If you are speaking of the file, that does not necessarily correspond to
>> "bloat" in memory.  The Linux executable file may be 100 KB, and the 
>> memory
>> footprint (code + data) may be 200 KB.  The Windows executable file may 
>> be
>> 50 KB and the memory footprint (code + data) may be 10 MB.
>>
>> I'm just trying to understand what you consider "bloat".  Is it important
>> that the file be small, or that the running memory footprint be small?
>>
>> --Eljay
>>
>>
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Code Bloat using GCC 3.2 on Linux
       [not found]         ` <6.2.0.14.2.20041215094647.020cf100@iplan-mn.corp.adobe.com>
@ 2004-12-16  5:03           ` Gaurav Jain
  0 siblings, 0 replies; 11+ messages in thread
From: Gaurav Jain @ 2004-12-16  5:03 UTC (permalink / raw)
  To: gcc-help

Hi,

I have used bzip2 for the Linux version and zip for the Windows
version, and *after* compression, the relative sizes are still almost
2::1.

I have already tried using compression methods, but I can't go for
anything than bzip2 at most, as it's freely available.  What I really
wanted to resolve was the core problem, which seems to be the larger
C++ binaries, rather than the compression method.

Thanks,
-Gaurav


On Wed, 15 Dec 2004 09:47:43 -0600, Eljay Love-Jensen <eljay@adobe.com> wrote:
> Hi Guarav,
> 
> >What's more important for me is the size on disk.  I want a small file
> that can be easy to download.
> 
> What are the sizes of the Windows versus Linux files after running them
> through zip or bzip2?
> 
> --Eljay
> 
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Code Bloat using GCC 3.2 on Linux
  2004-12-15 16:09         ` Andras Tantos
@ 2004-12-16  5:09           ` Gaurav Jain
  2004-12-16  5:33             ` Ramana Radhakrishnan
  0 siblings, 1 reply; 11+ messages in thread
From: Gaurav Jain @ 2004-12-16  5:09 UTC (permalink / raw)
  To: gcc-help

Hello,

The help on the options that you suggest indicates "When you specify
these options, the assembler and linker will create larger object and
executable files and will also be slower".

That's exactly what I *don't* want!  Wonder how VC.net is able to
generate smaller files despite these options enabled!

-Gaurav


On Wed, 15 Dec 2004 08:09:40 -0800, Andras Tantos
<andras_tantos@yahoo.com> wrote:
> Hi!
> 
> Try adding this to the compiler
> switches: -fdata-sections -ffunction-sections
> And this to the linker: --gc-sections
> 
> This turns on garbage-collection on sections which is off by default in GCC
> (AFIK) and on by default in VC.
> 
> Regards,
> Andras Tantos
> 
> ----- Original Message -----
> From: "Gaurav Jain" <gaurav.anywhere@gmail.com>
> To: <gcc-help@gcc.gnu.org>
> Sent: Wednesday, December 15, 2004 7:28 AM
> Subject: Re: Code Bloat using GCC 3.2 on Linux
> 
> > Hi Eljay,
> >
> > What's more important for me is the size on disk.  I want a small file
> > that can be easy to download.
> >
> > I have already tried the "strip" command, and the relative figures I
> > gave were after stripping the binaries.
> >
> > -Gaurav
> >
> >
> > On Wed, 15 Dec 2004 08:22:02 -0600, Eljay Love-Jensen <eljay@adobe.com>
> > wrote:
> >> Hi Guarav,
> >>
> >> Did you do the "strip" command on the output binary?
> >>
> >> strip myexecutable
> >>
> >> That might cut out 10%.
> >>
> >> When you are talking about the "bloat", are you speaking about the file,
> >> or
> >> of the memory footprint of the program when running?
> >>
> >> If you are speaking of the file, that does not necessarily correspond to
> >> "bloat" in memory.  The Linux executable file may be 100 KB, and the
> >> memory
> >> footprint (code + data) may be 200 KB.  The Windows executable file may
> >> be
> >> 50 KB and the memory footprint (code + data) may be 10 MB.
> >>
> >> I'm just trying to understand what you consider "bloat".  Is it important
> >> that the file be small, or that the running memory footprint be small?
> >>
> >> --Eljay
> >>
> >>
> >
> 
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Code Bloat using GCC 3.2 on Linux
  2004-12-16  5:09           ` Gaurav Jain
@ 2004-12-16  5:33             ` Ramana Radhakrishnan
  2004-12-16  9:15               ` Gaurav Jain
  0 siblings, 1 reply; 11+ messages in thread
From: Ramana Radhakrishnan @ 2004-12-16  5:33 UTC (permalink / raw)
  To: Gaurav Jain; +Cc: gcc-help

Hi Gaurav,

> Hello,
> 
> The help on the options that you suggest indicates "When you specify
> these options, the assembler and linker will create larger object and
> executable files and will also be slower".

-fdata-sections and -ffunction-sections puts the code in different 
sections and with the linker flag --gc-sections you can remove code that 
is never called or data which is never used.  This does reduce code size 
provided the --gc-sections is implemented in the linker. Could you try 
it on your case and see what happens ?

The reason the object files might be slightly larger is that the 
encodings chosen for the instructions might be larger because of 
addressing mode issues, but with --gc-sections and linker relaxations 
enabled the overall code size would typically be smaller because of 
possible removal of, code that is never called or data that is never used.

Also 3.2 is no longer supported by the community, so you might not see 
too much interest in looking at a 3.2 problem. The versions that are 
supported today are 3.3 and 3.4 . You could try either and see if there 
are any improvements or they help solve your problem.



Do you have a number of inline functions in your code ? You could try 
tuning that with -finline-limit-X, where X may be reasonably set to a 
value between 100 and 5000.

Can you provide a sample testcase where the size difference appears to 
be huge ?

cheers
Ramana





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Code Bloat using GCC 3.2 on Linux
  2004-12-16  5:33             ` Ramana Radhakrishnan
@ 2004-12-16  9:15               ` Gaurav Jain
  2004-12-17  3:37                 ` Ramana Radhakrishnan
  0 siblings, 1 reply; 11+ messages in thread
From: Gaurav Jain @ 2004-12-16  9:15 UTC (permalink / raw)
  To: Ramana Radhakrishnan; +Cc: gcc-help

> -fdata-sections and -ffunction-sections puts the code in different
> sections and with the linker flag --gc-sections you can remove code that
> is never called or data which is never used.  This does reduce code size
> provided the --gc-sections is implemented in the linker. Could you try
> it on your case and see what happens ?

That makes me more comfortable - I'll sure give this one a try and see
how it goes.
 
> Also 3.2 is no longer supported by the community, so you might not see
> too much interest in looking at a 3.2 problem. The versions that are
> supported today are 3.3 and 3.4 . You could try either and see if there
> are any improvements or they help solve your problem.

That's not an option for me - I *have* to go with 3.2

> Do you have a number of inline functions in your code ? You could try
> tuning that with -finline-limit-X, where X may be reasonably set to a
> value between 100 and 5000.

Yes I do, but I'm already using -fno-inline. I guess that should do
away with it?

Thanks,
-Gaurav

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Code Bloat using GCC 3.2 on Linux
  2004-12-16  9:15               ` Gaurav Jain
@ 2004-12-17  3:37                 ` Ramana Radhakrishnan
  0 siblings, 0 replies; 11+ messages in thread
From: Ramana Radhakrishnan @ 2004-12-17  3:37 UTC (permalink / raw)
  To: Gaurav Jain; +Cc: gcc-help

Hi Gaurav,

<snip>
> 
> 
>>Do you have a number of inline functions in your code ? You could try
>>tuning that with -finline-limit-X, where X may be reasonably set to a
>>value between 100 and 5000.
> 
> 
> Yes I do, but I'm already using -fno-inline. I guess that should do
> away with it?


Yup .

cheers
Ramana

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Code Bloat using GCC 3.2 on Linux
  2004-12-15 11:45 Code Bloat using GCC 3.2 on Linux Gaurav Jain
  2004-12-15 12:45 ` jlh
       [not found] ` <20041215132426.78ca7b5e@zeta.comsys.se>
@ 2004-12-20  6:18 ` Joe Steeve
  2 siblings, 0 replies; 11+ messages in thread
From: Joe Steeve @ 2004-12-20  6:18 UTC (permalink / raw)
  To: Gaurav Jain; +Cc: gcc-help

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

Gaurav Jain <gaurav.anywhere@gmail.com> writes:

> I have an application which is compiled using gcc 3.2 on linux.
> The problem is that the same application compiled on Windows
> using MS VC.net is much smaller in size (about 1/2) than that on

Is the compiled binary (using VC.net) managed code on a DotNET
clr?

> I wish to know whether there are any gcc options that can be
> used to combat the excessive code bloat using gcc on linux?  Why

Use objdump to dump the program & section headers of the ELF and
compare that with the section dump of the PE executable (I've no
clue how you'll get the section dump of the PE., are there any
tools available?? will objdump on w32 do it?? ). They should show
comparitively where the bloat is.

-- 
.O. A proud GNU user
..O http://www.joesteeve.tk/
OOO http://gnukid.shyper.com/

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2004-12-20  6:18 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-15 11:45 Code Bloat using GCC 3.2 on Linux Gaurav Jain
2004-12-15 12:45 ` jlh
     [not found] ` <20041215132426.78ca7b5e@zeta.comsys.se>
2004-12-15 14:11   ` Gaurav Jain
     [not found]     ` <6.2.0.14.2.20041215081802.0207dbd8@iplan-mn.corp.adobe.com>
2004-12-15 15:28       ` Gaurav Jain
2004-12-15 16:09         ` Andras Tantos
2004-12-16  5:09           ` Gaurav Jain
2004-12-16  5:33             ` Ramana Radhakrishnan
2004-12-16  9:15               ` Gaurav Jain
2004-12-17  3:37                 ` Ramana Radhakrishnan
     [not found]         ` <6.2.0.14.2.20041215094647.020cf100@iplan-mn.corp.adobe.com>
2004-12-16  5:03           ` Gaurav Jain
2004-12-20  6:18 ` Joe Steeve

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).