Re: Adventures with gcc: code vs object-code size
On Sun, Mar 21, 2004 at 02:20:13AM -0500, Matt Emmerton wrote: - Original Message - From: Garance A Drosihn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 20, 2004 5:45 PM Subject: Adventures with gcc: code vs object-code size if (strcmp(elemcopy, :) == 0) ... I don't know why the code bloats so much on i386, but I do question the use of strcmp() for a single-character compare. Something like the following would probably be better (and would avoid your problem): if (elemcopy[0] == ':') inf-count = 0; else inf-addelem(inf, elemcopy); That code isn't equivalent in general. Your code just checks that the first character is ':'. It doesn't verify that the string is exactly one character long. It's possible that in this particular context, elemcopy may be constrained such that it must be : if the first character is ':' but this isn't clear from Garances posting. The equivalent code would be: if (elemcopy[0] == ':' elemcopy[1] == '\0') inf-count = 0; else inf-addelem(inf, elemcopy); But (IMHO) this is a lot less clear than the former code (thought I admit I'm guilty of doing this quite a lot in my code). Note that a modern C compiler is free to convert strcpy(elemcopy, :) == 0 into elemcopy[0] == ':' elemcopy[1] == '\0' assuming the relevant header (string.h) is in scope. (I was under the impression that gcc did this). Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
On Sat, 20 Mar 2004, Garance A Drosihn wrote: I am not a compilier guru, so I suspect it would take me hours to pin this down. I don't want to do that, so I'm wondering if anyone understands how such a minor code-change can POSSIBLY cause such a huge change in resulting object file... I also wonder if this same issue pops up in other programs, too. I'm not a guru either, but I've seen a case where adding code (mostly switch clauses) caused a size reduction (on i386 anyway)... Depending on the optimisation level, it might be that the added code is affecting the heuristics gcc is using for inlined functions etc. -- Andrew I MacIntyre These thoughts are mine alone... E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
On Sun, Mar 21, 2004 at 07:45:43PM +1100, Peter Jeremy wrote: But (IMHO) this is a lot less clear than the former code (thought I admit I'm guilty of doing this quite a lot in my code). Note that a modern C compiler is free to convert strcpy(elemcopy, :) == 0 into elemcopy[0] == ':' elemcopy[1] == '\0' assuming the relevant header (string.h) is in scope. (I was under the impression that gcc did this). You're mixing up strcpy() with strcmp(), but you are right, unless -fno-builtin is specified. Marc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
Date: Sat, 20 Mar 2004 17:45:04 -0500 From: Garance A Drosihn
[EMAIL PROTECTED] Subject: Adventures with gcc: code vs object-code
size To: [EMAIL PROTECTED] Message-ID:
[EMAIL PROTECTED] Content-Type: text/plain;
charset=us-ascii ; format=flowed
I have written a fairly major set of changes to the `ps' command,
which is available as:
http://people.freebsd.org/~gad/ps-susv3.diff
Debate/discussion about the changes themselves actual changes should
be going on in the freebsd-standards mailing list. So for purposes
of this mailing list, please ignore most of that.
But while doing it, I was somewhat obsessed about making sure that
my changes wouldn't cause a dramatic increase in the size of the
executable for `ps'. Due to that, I tripped over one example of
code vs object-code produced which makes no sense to me. So,
consider just this section of the update (with some reformatting
so it is easy to see the code):
char elemcopy[PATH_MAX];
...do stuff...
#if !defined(ADD_PS_LISTRESET)
inf-addelem(inf, elemcopy);
#else
/*
* We now have a single element. Add it to the
* list, unless the element is :. In that case,
* reset the list so previous entries are ignored.
*/
if (strcmp(elemcopy, :) == 0)
inf-count = 0;
else
inf-addelem(inf, elemcopy);
#endif
Now, here is what I noticed:
* XXX - Adding this check increases the total size of `ps' by
* 3940 bytes on i386! That's 12% of the entire program!
* { using gcc (GCC) 3.3.3 [FreeBSD] 20031106 }
*
* When compiling for sparc, adding this option causes NO
* change in the size of the `ps' executable. And on alpha,
* adding this option adds only 8 bytes to the executable.
So, by adding one call to strcmp() to check for a : string, I end
up with /bin/ps (the stripped-object-file) which has grown by 12.6% !!
This is for a program which is almost 2500 lines spread out over
5 '.c'-files. How is that possible? What am I missing here?
In my coding experience (especially back in embedded-land when I
cared a *lot* about code size) when this happens, the reason is usually
nothing to do with the compiler per se, but with the packaging of
library functions into modules.
If it happens that strcmp was not previously being referenced at all,
absent this one line, then of course this change will pull in the
strcmp routine. Now while strcmp itself is not likely to be 3940
bytes, if it is packed together in the library with a number of other
routines (e.g. a collection of hand-optimized assembler string
routines, or of other routines which it's assumed are likely to be used
in the same program) then the one module being pulled in can suddenly
bloat the source surprisingly. This would be easy to test - extract
the program's symbol table before stripping, with and without this one
line, diff it, and see whether other new symbols are showing up along
with strcmp.
This may also be true even if gcc is partially inlining it - gcc may
be pulling in a big clump of its own internal support routines in that
case, on the assumption that when inlining you care only about speed
and not about code size. Again, differencing the symbol table should
give you some idea.
-- Clifton
--
Clifton Royston -- [EMAIL PROTECTED]
Tiki Technologies Lead Programmer/Software Architect
Did you ever fly a kite in bed? Did you ever walk with ten cats on your head?
Did you ever milk this kind of cow? Well we can do it. We know how.
If you never did, you should. These things are fun, and fun is good.
-- Dr. Seuss
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
At 10:22 AM -1000 3/21/04, Clifton Royston wrote: Date: Sat, 20 Mar 2004 From: Garance A Drosihn So, by adding one call to strcmp() to check for a : string, I end up with /bin/ps (the stripped-object-file) which has grown by 12.6% !! This is for a program which is almost 2500 lines spread out over 5 '.c'-files. How is that possible? What am I missing here? If it happens that strcmp was not previously being referenced at all, absent this one line, then of course this change will pull in the strcmp routine. Now while strcmp itself is not ... I forgot to include a significant part of this puzzle. The same ps.c file already had two calls to strcmp() in it: ps.c: if (strcmp(elem, co) == 0) ps.c: if (strcmp(elemcopy, :) == 0) ps.c: if (strcmp(vent-var-name, v-name) == 0) There was no strcmp() in the subroutine that I added it to, but I would assume that those other references would have already pulled in the routine. This may also be true even if gcc is partially inlining it. gcc may be pulling in a big clump of its own internal support routines in that case, ... but would it inline it's own routines multiple times in the same source file? Again, differencing the symbol table should give you some idea. Well, I was hoping someone would have already seen this before, but I guess I will need to do some more checking if I'm going to get a better idea of what is going on. I'll put it on my list of things to look at when I have some spare time... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
The heuristics vary from platform to platform - what does objdump -d show? -Kip Well, I was hoping someone would have already seen this before, but I guess I will need to do some more checking if I'm going to get a better idea of what is going on. I'll put it on my list of things to look at when I have some spare time... -- If I have not seen as far as others, it is because I have been standing in the footprints of giants. -- from Usenet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
At 2:52 PM -0800 3/21/04, Kip Macy wrote: The heuristics vary from platform to platform - what does objdump -d show? Based on what I see from that, the 'ps.o' which has the extra strcmp is about 40 bytes larger than the one without it. And now that you mention it, doing a plain 'ls -l' of ps.o shows that it is only 40 bytes larger. It's when you combine that file with the other *.o files, and strip it, that the final result ends up 3940 bytes larger. So maybe this has something to do with how linking is done for ELF modules. Unfortunately, I need to be concentrating on something else right now... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Adventures with gcc: code vs object-code size
From: Garance A Drosihn [mailto:[EMAIL PROTECTED] At 2:52 PM -0800 3/21/04, Kip Macy wrote: The heuristics vary from platform to platform - what does objdump -d show? Based on what I see from that, the 'ps.o' which has the extra strcmp is about 40 bytes larger than the one without it. And now that you mention it, doing a plain 'ls -l' of ps.o shows that it is only 40 bytes larger. It's when you combine that file with the other *.o files, and strip it, that the final result ends up 3940 bytes larger. So maybe this has something to do with how linking is done for ELF modules. Unfortunately, I need to be concentrating on something else right now... Its not just bumping you up another module 4K pages? The linker aligns text, data, bss, rodata, etc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Adventures with gcc: code vs object-code size
At 7:35 PM -0500 3/21/04, Don Bowman wrote: From: Garance A Drosihn [mailto:[EMAIL PROTECTED] So maybe this has something to do with how linking is done for ELF modules. Unfortunately, I need to be concentrating on something else right now... It's not just bumping you up another module 4K pages? The linker aligns text, data, bss, rodata, etc. (65) ls -l /bin/ps* -r-xr-xr-x 1 root wheel 27100 Mar 20 14:29 /bin/ps -r-xr-xr-x 1 root wheel 27296 Mar 21 18:21 /bin/ps-sanscmp -r-xr-xr-x 1 root wheel 31204 Mar 21 19:46 /bin/ps-withcmp The first one is the `ps' before all of my recent changes, the second is all of the changes except for that strcmp(), and the third adds the strcmp. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Adventures with gcc: code vs object-code size
From: Garance A Drosihn [mailto:[EMAIL PROTECTED] At 7:35 PM -0500 3/21/04, Don Bowman wrote: From: Garance A Drosihn [mailto:[EMAIL PROTECTED] So maybe this has something to do with how linking is done for ELF modules. Unfortunately, I need to be concentrating on something else right now... It's not just bumping you up another module 4K pages? The linker aligns text, data, bss, rodata, etc. (65) ls -l /bin/ps* -r-xr-xr-x 1 root wheel 27100 Mar 20 14:29 /bin/ps -r-xr-xr-x 1 root wheel 27296 Mar 21 18:21 /bin/ps-sanscmp -r-xr-xr-x 1 root wheel 31204 Mar 21 19:46 /bin/ps-withcmp The first one is the `ps' before all of my recent changes, the second is all of the changes except for that strcmp(), and the third adds the strcmp. and objdump --headers shows? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
On Sun, Mar 21, 2004 at 05:39:58PM -0500, Garance A Drosihn wrote: At 10:22 AM -1000 3/21/04, Clifton Royston wrote: Date: Sat, 20 Mar 2004 From: Garance A Drosihn So, by adding one call to strcmp() to check for a : string, I end up with /bin/ps (the stripped-object-file) which has grown by 12.6% !! This is for a program which is almost 2500 lines spread out over 5 '.c'-files. How is that possible? What am I missing here? If it happens that strcmp was not previously being referenced at all, absent this one line, then of course this change will pull in the strcmp routine. Now while strcmp itself is not ... I forgot to include a significant part of this puzzle. The same ps.c file already had two calls to strcmp() in it: ps.c: if (strcmp(elem, co) == 0) ps.c: if (strcmp(elemcopy, :) == 0) ps.c: if (strcmp(vent-var-name, v-name) == 0) There was no strcmp() in the subroutine that I added it to, but I would assume that those other references would have already pulled in the routine. Ah, totally different story then. OK, I'm baffled too. This may also be true even if gcc is partially inlining it. gcc may be pulling in a big clump of its own internal support routines in that case, ... but would it inline it's own routines multiple times in the same source file? No, it definitely shouldn't. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
- Original Message -
From: Garance A Drosihn [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, March 20, 2004 5:45 PM
Subject: Adventures with gcc: code vs object-code size
I have written a fairly major set of changes to the `ps' command,
which is available as:
http://people.freebsd.org/~gad/ps-susv3.diff
Debate/discussion about the changes themselves actual changes should
be going on in the freebsd-standards mailing list. So for purposes
of this mailing list, please ignore most of that.
But while doing it, I was somewhat obsessed about making sure that
my changes wouldn't cause a dramatic increase in the size of the
executable for `ps'. Due to that, I tripped over one example of
code vs object-code produced which makes no sense to me. So,
consider just this section of the update (with some reformatting
so it is easy to see the code):
char elemcopy[PATH_MAX];
...do stuff...
#if !defined(ADD_PS_LISTRESET)
inf-addelem(inf, elemcopy);
#else
/*
* We now have a single element. Add it to the
* list, unless the element is :. In that case,
* reset the list so previous entries are ignored.
*/
if (strcmp(elemcopy, :) == 0)
inf-count = 0;
else
inf-addelem(inf, elemcopy);
#endif
Now, here is what I noticed:
* XXX - Adding this check increases the total size of `ps' by
* 3940 bytes on i386! That's 12% of the entire program!
* { using gcc (GCC) 3.3.3 [FreeBSD] 20031106 }
*
* When compiling for sparc, adding this option causes NO
* change in the size of the `ps' executable. And on alpha,
* adding this option adds only 8 bytes to the executable.
So, by adding one call to strcmp() to check for a : string, I end
up with /bin/ps (the stripped-object-file) which has grown by 12.6% !!
This is for a program which is almost 2500 lines spread out over
5 '.c'-files. How is that possible? What am I missing here?
I am not a compilier guru, so I suspect it would take me hours to
pin this down. I don't want to do that, so I'm wondering if anyone
understands how such a minor code-change can POSSIBLY cause such a
huge change in resulting object file... I also wonder if this same
issue pops up in other programs, too.
I don't know why the code bloats so much on i386, but I do question the use
of strcmp() for a single-character compare.
Something like the following would probably be better (and would avoid your
problem):
if (elemcopy[0] == ':')
inf-count = 0;
else
inf-addelem(inf, elemcopy);
--
Matt Emmerton
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
