Size Weirdness in Snapshots

Size Weirdness in Snapshots

[David Starner]

I compiled a program with both EGCS 1.1.1 and a recent snapshot, and noticed
a couple things. First, the snapshot give much more indepth error information.
Thanks, guys. Second, and the reason for this message follows.

$ g++ -Wall -o Solution Solution.cpp
$ ls -l Solution
-rwxrwxr-x   1 dvdeug   dvdeug   5105 Feb 13 21:06 Solution
$ g++-ss -Wall -o Solution Solution.cpp
$ ls -l Solution
-rwxrwxr-x   1 dvdeug   dvdeug  33271 Feb 13 21:06 Solution
$ g++ -v
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/specs
gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)
$ g++-ss -v
Reading specs from /usr/local/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.04/specs
gcc version ecs-2.93.04 19990131 (gcc2 ss-980929 experimental)

As you can see, the snapshot produced a much larger executable file than 
the old version. I don't know if it's relevant - making EGCS an efficent
optimizer of empty programs isn't very useful. It was weird, however, and
may be indictive of something. Is further study warrented?

The program:
#include <cassert>
typedef unsigned int NumOfPieces; // 0 .. 48
const unsigned int MinNumOfPieces = 0;
const unsigned int MaxNumOfPieces = 48;
const unsigned int PiecesEachHole = 4;

class Board {
	private:
		// 14 holes, including both ends
		NumOfPieces Holes[14];
	public:
		Board() {
			// Start with both ends = 0
			Holes[0] = Holes[14] = 0;
			// Put 4 pieces in each other hole
			Holes[1] = Holes[2] = Holes[3] = Holes[4] = Holes[5]
			         = Holes[6] = Holes[8] = Holes[9] = Holes[10]
				 = Holes[11] = Holes[12] = Holes[13] 
				 = PiecesEachHole;
		}
			
		void Invariant() {
			NumOfPieces Sum = 0;
			for (int I = 0; I < 14; I++) {
				Sum += Holes[I];
				assert (Holes[I] <= 48);
			};
			assert (Sum == MaxNumOfPieces);
		}

		NumOfPieces Hole(unsigned int HoleNum) {
			return Holes[HoleNum];
		}

		void MovePiece(unsigned int StartHN, unsigned int EndHN) {
			assert ((Invariant(), true));
			Holes[StartHN]--;
			Holes[EndHN]++;
			assert ((Invariant(), true));
		}	
};

int main () {
}
-- 
The irony is, there ARE drugs that ENHANCE it. This says something profound about either science or medicine or people or muppets or all four. - S. John Ross

Re: Size Weirdness in Snapshots

[Marc Espie]

In article < 36C64458.CAA0F88@aasaa.ofe.org > you write:
>I compiled a program with both EGCS 1.1.1 and a recent snapshot, and noticed
>a couple things. First, the snapshot give much more indepth error information.
>Thanks, guys. Second, and the reason for this message follows.

>$ g++ -Wall -o Solution Solution.cpp
>$ ls -l Solution
>-rwxrwxr-x   1 dvdeug   dvdeug   5105 Feb 13 21:06 Solution
>$ g++-ss -Wall -o Solution Solution.cpp
>$ ls -l Solution
>-rwxrwxr-x   1 dvdeug   dvdeug  33271 Feb 13 21:06 Solution
>$ g++ -v
>Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/specs
>gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)
>$ g++-ss -v
>Reading specs from
>/usr/local/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.04/specs
>gcc version ecs-2.93.04 19990131 (gcc2 ss-980929 experimental)

One plausible explanation for the size difference would be exception
region information...  the size is vastly different with DWARF2_UNWIND_INFO,
and without.  Look at the assembler file g++ -S yield and compare.
If the exception regions look different, that's probably it...
Now, to know what triggered the change is anothere qeustion.

Re: Size Weirdness in Snapshots

[Jeffrey A Law]

  In message <36C87AF4.BD748583@aasaa.ofe.org>you write:
  > Marc Espie wrote:
  > > One plausible explanation for the size difference would be exception
  > > region information...  the size is vastly different with DWARF2_UNWIND_IN
  > FO,
  > > and without.  Look at the assembler file g++ -S yield and compare.
  > > If the exception regions look different, that's probably it...
  > > Now, to know what triggered the change is anothere qeustion.
  > 
  > I don't quite know what I'm looking for, but the two assembler files
  > were very similar. (If it matters, this is from a later version of the
  > same file, and the most recent snapshot. It displays the same behavior.)
When you see this kind of size increase, look to the libraries and debug
symbols.


jeff

Re: Size Weirdness in Snapshots

[David Starner]

Jeffrey A Law wrote:
> When you see this kind of size increase, look to the libraries and debug
> symbols.
> 
> jeff

Okay. I looked at all the libraries I could find that would be linked
into my program, and they were all much larger than my program. As it
appears that no one else really cares about this, and I'm not
knowledgable enough to study it, I'll let it drop.

-- 
The irony is, there ARE drugs that ENHANCE it. This says something
profound about either science or medicine or people or muppets or all
four. - S. John Ross

Re: Size Weirdness in Snapshots

[Jeffrey A Law]

  In message < 36C9F119.B3FEED52@aasaa.ofe.org >you write:
  > Okay. I looked at all the libraries I could find that would be linked
  > into my program, and they were all much larger than my program. As it
  > appears that no one else really cares about this, and I'm not
  > knowledgable enough to study it, I'll let it drop.
What makes you think people don't care.  They certainly do.  However, you
haven't really provided us with anything which would allow us to help you.

As I mentioned, when you see a size increase like this, it typically comes
from debugging symbols, eh overhead or linking statically or dynamically.

Check those things.  Note that the increases may come from the libraries
you link against, not necessarily the code you compile for your application.
  

jeff

Re: Size Weirdness in Snapshots

[David Starner]

Jeffrey A Law wrote:
> 
>   In message < 36C9F119.B3FEED52@aasaa.ofe.org >you write:
>   > Okay. I looked at all the libraries I could find that would be linked
>   > into my program, and they were all much larger than my program. As it
>   > appears that no one else really cares about this, and I'm not
>   > knowledgable enough to study it, I'll let it drop.
> What makes you think people don't care.  They certainly do.  However, you
> haven't really provided us with anything which would allow us to help you.

What more do you need than g++ -v, the command line used, and the
program? (Not trying to be sarcastic, but I don't know what you're
looking for.)
> 
> As I mentioned, when you see a size increase like this, it typically comes
> from debugging symbols, eh overhead or linking statically or dynamically.
> 
> Check those things.  Note that the increases may come from the libraries
> you link against, not necessarily the code you compile for your application.
Which libraries? The code didn't explicitly link against any libraries,
so I would assume it would only link against libgcc, libc and libstdc++.
It should link against the same libc, so...

Well, I downloaded egcs 1.1.1 and installed that as an alternate
compiler. It produced about the same size program as the most recent
snapshot. Investigating further, the egcs 1.1.1 that came with Debian is
heavily hacked, including H.J. Lu's Linux patches, and a number of other
patches. Since the difference is not between straight Egcs 1.1.1 and a
snapshot, it's too much work for me to bother with. 

-- 
The irony is, there ARE drugs that ENHANCE it. This says something
profound about either science or medicine or people or muppets or all
four. - S. John Ross

Re: Size Weirdness in Snapshots

[Jeffrey A Law]

  In message < 36CA56A2.97B17C5B@aasaa.ofe.org >you write:
  > What more do you need than g++ -v, the command line used, and the
  > program? (Not trying to be sarcastic, but I don't know what you're
  > looking for.)
Well, you're assuming that I can either guess from your command lines why
something is larger, or that I have some magical program which can read a
binary you give me.  Depending on your system I may or may not have such
a magic utility.

Far better for you to look at these things yourself since you have the binary,
and utilities which can look at the size of the various sections within the
binary.

  > Well, I downloaded egcs 1.1.1 and installed that as an alternate
  > compiler. It produced about the same size program as the most recent
  > snapshot. Investigating further, the egcs 1.1.1 that came with Debian is
  > heavily hacked, including H.J. Lu's Linux patches, and a number of other
  > patches. Since the difference is not between straight Egcs 1.1.1 and a
  > snapshot, it's too much work for me to bother with. 
EH, debugging & shared libraries again.  

run objdump -h on the big and small versions of your program.  Then look
at the output for sections which are much better in one than the other.

Also verify that each version is linked in the same manner (either statically 
or dynamically).



jeff

Re: Size Weirdness in Snapshots

[David Starner]

Jeffrey A Law wrote:
> 
>   In message < 36C9F119.B3FEED52@aasaa.ofe.org >you write:
>   > Okay. I looked at all the libraries I could find that would be linked
>   > into my program, and they were all much larger than my program. As it
>   > appears that no one else really cares about this, and I'm not
>   > knowledgable enough to study it, I'll let it drop.
> What makes you think people don't care.  They certainly do.  However, you
> haven't really provided us with anything which would allow us to help you.

What more do you need than g++ -v, the command line used, and the
program? (Not trying to be sarcastic, but I don't know what you're
looking for.)
> 
> As I mentioned, when you see a size increase like this, it typically comes
> from debugging symbols, eh overhead or linking statically or dynamically.
> 
> Check those things.  Note that the increases may come from the libraries
> you link against, not necessarily the code you compile for your application.
Which libraries? The code didn't explicitly link against any libraries,
so I would assume it would only link against libgcc, libc and libstdc++.
It should link against the same libc, so...

Well, I downloaded egcs 1.1.1 and installed that as an alternate
compiler. It produced about the same size program as the most recent
snapshot. Investigating further, the egcs 1.1.1 that came with Debian is
heavily hacked, including H.J. Lu's Linux patches, and a number of other
patches. Since the difference is not between straight Egcs 1.1.1 and a
snapshot, it's too much work for me to bother with. 

-- 
The irony is, there ARE drugs that ENHANCE it. This says something
profound about either science or medicine or people or muppets or all
four. - S. John Ross

Re: Size Weirdness in Snapshots

[David Starner]

Marc Espie wrote:
> One plausible explanation for the size difference would be exception
> region information...  the size is vastly different with DWARF2_UNWIND_INFO,
> and without.  Look at the assembler file g++ -S yield and compare.
> If the exception regions look different, that's probably it...
> Now, to know what triggered the change is anothere qeustion.

I don't quite know what I'm looking for, but the two assembler files
were very similar. (If it matters, this is from a later version of the
same file, and the most recent snapshot. It displays the same behavior.)

19c19
< 	.align 16
---
> 	.align 4
29c29
< 	jmp .L18
---
> 	jmp .L19
31c31
< .L18:
---
> .L19:
91c91
< 	.ident	"GCC: (GNU) egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)"
---
> 	.ident	"GCC: (GNU) egcs-2.93.08 19990214 (gcc2 ss-980929 experimental)"

That is the complete diff. The only thing I can see that changes is the
align statement.
-- 
The irony is, there ARE drugs that ENHANCE it. This says something
profound about either science or medicine or people or muppets or all
four. - S. John Ross

Re: Size Weirdness in Snapshots

[Jeffrey A Law]

  In message < 36CA56A2.97B17C5B@aasaa.ofe.org >you write:
  > What more do you need than g++ -v, the command line used, and the
  > program? (Not trying to be sarcastic, but I don't know what you're
  > looking for.)
Well, you're assuming that I can either guess from your command lines why
something is larger, or that I have some magical program which can read a
binary you give me.  Depending on your system I may or may not have such
a magic utility.

Far better for you to look at these things yourself since you have the binary,
and utilities which can look at the size of the various sections within the
binary.

  > Well, I downloaded egcs 1.1.1 and installed that as an alternate
  > compiler. It produced about the same size program as the most recent
  > snapshot. Investigating further, the egcs 1.1.1 that came with Debian is
  > heavily hacked, including H.J. Lu's Linux patches, and a number of other
  > patches. Since the difference is not between straight Egcs 1.1.1 and a
  > snapshot, it's too much work for me to bother with. 
EH, debugging & shared libraries again.  

run objdump -h on the big and small versions of your program.  Then look
at the output for sections which are much better in one than the other.

Also verify that each version is linked in the same manner (either statically 
or dynamically).



jeff

Re: Size Weirdness in Snapshots

[David Starner]

Jeffrey A Law wrote:
> When you see this kind of size increase, look to the libraries and debug
> symbols.
> 
> jeff

Okay. I looked at all the libraries I could find that would be linked
into my program, and they were all much larger than my program. As it
appears that no one else really cares about this, and I'm not
knowledgable enough to study it, I'll let it drop.

-- 
The irony is, there ARE drugs that ENHANCE it. This says something
profound about either science or medicine or people or muppets or all
four. - S. John Ross

Re: Size Weirdness in Snapshots

[Marc Espie]

In article < 36C64458.CAA0F88@aasaa.ofe.org > you write:
>I compiled a program with both EGCS 1.1.1 and a recent snapshot, and noticed
>a couple things. First, the snapshot give much more indepth error information.
>Thanks, guys. Second, and the reason for this message follows.

>$ g++ -Wall -o Solution Solution.cpp
>$ ls -l Solution
>-rwxrwxr-x   1 dvdeug   dvdeug   5105 Feb 13 21:06 Solution
>$ g++-ss -Wall -o Solution Solution.cpp
>$ ls -l Solution
>-rwxrwxr-x   1 dvdeug   dvdeug  33271 Feb 13 21:06 Solution
>$ g++ -v
>Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/specs
>gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)
>$ g++-ss -v
>Reading specs from
>/usr/local/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.04/specs
>gcc version ecs-2.93.04 19990131 (gcc2 ss-980929 experimental)

One plausible explanation for the size difference would be exception
region information...  the size is vastly different with DWARF2_UNWIND_INFO,
and without.  Look at the assembler file g++ -S yield and compare.
If the exception regions look different, that's probably it...
Now, to know what triggered the change is anothere qeustion.

Size Weirdness in Snapshots

[David Starner]

I compiled a program with both EGCS 1.1.1 and a recent snapshot, and noticed
a couple things. First, the snapshot give much more indepth error information.
Thanks, guys. Second, and the reason for this message follows.

$ g++ -Wall -o Solution Solution.cpp
$ ls -l Solution
-rwxrwxr-x   1 dvdeug   dvdeug   5105 Feb 13 21:06 Solution
$ g++-ss -Wall -o Solution Solution.cpp
$ ls -l Solution
-rwxrwxr-x   1 dvdeug   dvdeug  33271 Feb 13 21:06 Solution
$ g++ -v
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/specs
gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)
$ g++-ss -v
Reading specs from /usr/local/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.04/specs
gcc version ecs-2.93.04 19990131 (gcc2 ss-980929 experimental)

As you can see, the snapshot produced a much larger executable file than 
the old version. I don't know if it's relevant - making EGCS an efficent
optimizer of empty programs isn't very useful. It was weird, however, and
may be indictive of something. Is further study warrented?

The program:
#include <cassert>
typedef unsigned int NumOfPieces; // 0 .. 48
const unsigned int MinNumOfPieces = 0;
const unsigned int MaxNumOfPieces = 48;
const unsigned int PiecesEachHole = 4;

class Board {
	private:
		// 14 holes, including both ends
		NumOfPieces Holes[14];
	public:
		Board() {
			// Start with both ends = 0
			Holes[0] = Holes[14] = 0;
			// Put 4 pieces in each other hole
			Holes[1] = Holes[2] = Holes[3] = Holes[4] = Holes[5]
			         = Holes[6] = Holes[8] = Holes[9] = Holes[10]
				 = Holes[11] = Holes[12] = Holes[13] 
				 = PiecesEachHole;
		}
			
		void Invariant() {
			NumOfPieces Sum = 0;
			for (int I = 0; I < 14; I++) {
				Sum += Holes[I];
				assert (Holes[I] <= 48);
			};
			assert (Sum == MaxNumOfPieces);
		}

		NumOfPieces Hole(unsigned int HoleNum) {
			return Holes[HoleNum];
		}

		void MovePiece(unsigned int StartHN, unsigned int EndHN) {
			assert ((Invariant(), true));
			Holes[StartHN]--;
			Holes[EndHN]++;
			assert ((Invariant(), true));
		}	
};

int main () {
}
-- 
The irony is, there ARE drugs that ENHANCE it. This says something profound about either science or medicine or people or muppets or all four. - S. John Ross

Re: Size Weirdness in Snapshots

[Jeffrey A Law]

  In message < 36C9F119.B3FEED52@aasaa.ofe.org >you write:
  > Okay. I looked at all the libraries I could find that would be linked
  > into my program, and they were all much larger than my program. As it
  > appears that no one else really cares about this, and I'm not
  > knowledgable enough to study it, I'll let it drop.
What makes you think people don't care.  They certainly do.  However, you
haven't really provided us with anything which would allow us to help you.

As I mentioned, when you see a size increase like this, it typically comes
from debugging symbols, eh overhead or linking statically or dynamically.

Check those things.  Note that the increases may come from the libraries
you link against, not necessarily the code you compile for your application.
  

jeff

Re: Size Weirdness in Snapshots

[Jeffrey A Law]

  In message < 36C87AF4.BD748583@aasaa.ofe.org >you write:
  > Marc Espie wrote:
  > > One plausible explanation for the size difference would be exception
  > > region information...  the size is vastly different with DWARF2_UNWIND_IN
  > FO,
  > > and without.  Look at the assembler file g++ -S yield and compare.
  > > If the exception regions look different, that's probably it...
  > > Now, to know what triggered the change is anothere qeustion.
  > 
  > I don't quite know what I'm looking for, but the two assembler files
  > were very similar. (If it matters, this is from a later version of the
  > same file, and the most recent snapshot. It displays the same behavior.)
When you see this kind of size increase, look to the libraries and debug
symbols.


jeff