I compiled a program and standard library using clang/LLVM and found the results interesting: text data bss dec hex filename 141312 4076 16668 162056 27908 bzip2.arm 131764 4076 16668 152508 253bc bzip2.armv7 134748 4048 16624 155420 25f1c bzip2.i386 259112 4028 16732 279872 44540 bzip2.microblaze 168044 4040 16816 188900 2e1e4 bzip2.mips 167860 4040 16816 188716 2e12c bzip2.mips32r2 179032 4040 16816 199888 30cd0 bzip2.mips32r2elsf 179008 4040 16816 199864 30cb8 bzip2.mips32r2sf 168060 4040 16816 188916 2e1f4 bzip2.mipsel 156312 4028 16784 177124 2b3e4 bzip2.ppc 163572 10896 19280 193748 2f4d4 bzip2.ppc64 145443 4696 19368 169507 29623 bzip2.x86_64 The libraries were compiled with -O1 and the program was compiled with -O2. The whole thing was statically linked. I verified that each executable was correct by running the bzip2 test cases under QEMU. It is interesting to see how the architecture (and maybe maturity of the code generator) affects code size. -Rich
On Wed, Dec 7, 2011 at 9:43 PM, Richard Pennington wrote:> I compiled a program and standard library using clang/LLVM and found the > results interesting: > > text data bss dec hex filename > 141312 4076 16668 162056 27908 bzip2.arm > 131764 4076 16668 152508 253bc bzip2.armv7 > 134748 4048 16624 155420 25f1c bzip2.i386 > 259112 4028 16732 279872 44540 bzip2.microblaze > 168044 4040 16816 188900 2e1e4 bzip2.mips > 167860 4040 16816 188716 2e12c bzip2.mips32r2 > 179032 4040 16816 199888 30cd0 bzip2.mips32r2elsf > 179008 4040 16816 199864 30cb8 bzip2.mips32r2sf > 168060 4040 16816 188916 2e1f4 bzip2.mipsel > 156312 4028 16784 177124 2b3e4 bzip2.ppc > 163572 10896 19280 193748 2f4d4 bzip2.ppc64 > 145443 4696 19368 169507 29623 bzip2.x86_64 > > The libraries were compiled with -O1 and the program was compiled with -O2. > The whole thing was statically linked. I verified that each executable was > correct by running the bzip2 test cases under QEMU. > > It is interesting to see how the architecture (and maybe maturity of the code > generator) affects code size.What could be so different in ppc64 that causes "data" to be more than twice the size than on any other platform? Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds
On Thursday, December 08, 2011 02:46:39 AM Csaba Raduly wrote:> On Wed, Dec 7, 2011 at 9:43 PM, Richard Pennington wrote: > > I compiled a program and standard library using clang/LLVM and found the > > results interesting: > > > > text data bss dec hex filename > > 141312 4076 16668 162056 27908 bzip2.arm > > 131764 4076 16668 152508 253bc bzip2.armv7 > > 134748 4048 16624 155420 25f1c bzip2.i386 > > 259112 4028 16732 279872 44540 bzip2.microblaze > > 168044 4040 16816 188900 2e1e4 bzip2.mips > > 167860 4040 16816 188716 2e12c bzip2.mips32r2 > > 179032 4040 16816 199888 30cd0 bzip2.mips32r2elsf > > 179008 4040 16816 199864 30cb8 bzip2.mips32r2sf > > 168060 4040 16816 188916 2e1f4 bzip2.mipsel > > 156312 4028 16784 177124 2b3e4 bzip2.ppc > > 163572 10896 19280 193748 2f4d4 bzip2.ppc64 > > 145443 4696 19368 169507 29623 bzip2.x86_64 > > > > The libraries were compiled with -O1 and the program was compiled with > > -O2. The whole thing was statically linked. I verified that each > > executable was correct by running the bzip2 test cases under QEMU. > > > > It is interesting to see how the architecture (and maybe maturity of the > > code generator) affects code size. > > What could be so different in ppc64 that causes "data" to be more than > twice the size than on any other platform? > > CsabaCsaba, It turns out that most of the data space used by the ppc64 is for a little table created for each function defined in the program. The table has two 64 bit pointers in it, one is the address of the function. This is how Linux ppc64 executables are built: the table is used to indirectly call functions. There are many of these little tables in the program because it is statically linked with the standard library. -Rich