Different C++ compiler exec. sizes

[Chris Mantoulidis]

Out of curiosity, I wanted to test executable file sizes of the same
program from different compilers...

The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
and DJGPP 2.03...

The program was nothing but a simple hello world program using the
iostream header file...

I compiled and linked (both copies) with those 2 different
compilers... The Borland c++ 3.1 compiler gave me an executable with
size like 20-30KB (i don't remember) and DJGPP gave me an executable
with size like 220-240KB...

I can assume 2 things here... Either DJGPP produces WAY more
compicated executables (kind of odd though) or DJGPP's header files
contain kinda different info....

Anyone seen anything like that? Anyone know why?

[Ron Natalie]

"Chris Mantoulidis" <cm****@yahoo.com> wrote in message news:a8**************************@posting.google.c om...

I can assume 2 things here... Either DJGPP produces WAY more
compicated executables (kind of odd though) or DJGPP's header files
contain kinda different info....

Nope, most likely the different has nothing to do with the executable code
nor the header files. I suspect in one case you have the library code included
in the executable and in another they are in seperate runtime file (DLL or shared library).

On little trivial programs the size of the runtime libraries dwarf the user code.

[Peter van Merkerk]

> Out of curiosity, I wanted to test executable file sizes of the same

program from different compilers...

The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
and DJGPP 2.03...

The program was nothing but a simple hello world program using the
iostream header file...

I compiled and linked (both copies) with those 2 different
compilers... The Borland c++ 3.1 compiler gave me an executable with
size like 20-30KB (i don't remember) and DJGPP gave me an executable
with size like 220-240KB...

I can assume 2 things here... Either DJGPP produces WAY more
compicated executables (kind of odd though) or DJGPP's header files
contain kinda different info....

Anyone seen anything like that? Anyone know why?

One thing that may explain the difference you are seeing is that one
compiler stores the debug information in the executable itself while the
other stores the debug information in a separate file. You are more
likely to get more sensible numbers if you do an optimized build without
debug information with both compilers.

For small and even medium sized programs the runtime library often
accounts for a large part of the executable size. With small programs
your own code accounts for only a very small fraction of the total
executable size (I would be surpriced if it would be more than 200
bytes). Because you only tested with a small program, it is important to
realize that the executable sizes you find are not necessarilly
representative for larger programs. If you do the same test with a large
(non-trivial) program, it is likely that the difference between the two
compilers has become smaller. Whether the runtime library is linked
statically or dynamically can make a big difference. Using a different
runtime library can dramatically reduce the executable size of small
programs. I have been able to produce executables with MSVC as small as
2.5 KB using the libtinyc runtime library (compared to 28KB with the
standard runtime library).

The quality of the linker and the linker settings may have some impact
on the executable size as well. Finally optimization settings of the
compiler may make a (small) difference too.

If you really are interested in making your executables as small as
possible, you may find this page an interesting read:
http://freespace.virgin.net/james.br...als/minexe.htm

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl

[Jerry Coffin]

In article <a8**************************@posting.google.com >,
cm****@yahoo.com says...

Out of curiosity, I wanted to test executable file sizes of the same
program from different compilers...

The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
and DJGPP 2.03...

BC++ 3.1 produces native DOS executables. DJGPP produces executables
for a DOS extender, which is basically a small, simple OS that gets
linked into your executable. Most of what you're seeing in the DJGPP
executable is the DOS extender code.

The DOS extender primarily allows your program to access large amounts
of memory directly, compared to the BC++ 3.1 program, which is limited
to 640K, even if your machine has hundreds of megabytes of RAM.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Alex Vinokur]

"Chris Mantoulidis" <cm****@yahoo.com> wrote in message news:a8**************************@posting.google.c om...

Out of curiosity, I wanted to test executable file sizes of the same
program from different compilers...

The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
and DJGPP 2.03...

The program was nothing but a simple hello world program using the
iostream header file...

I compiled and linked (both copies) with those 2 different
compilers... The Borland c++ 3.1 compiler gave me an executable with
size like 20-30KB (i don't remember) and DJGPP gave me an executable
with size like 220-240KB...

I can assume 2 things here... Either DJGPP produces WAY more
compicated executables (kind of odd though) or DJGPP's header files
contain kinda different info....

Anyone seen anything like that? Anyone know why?

Here are sizes of actual executables which were used
to measure comparative performance
of different compilers
* http://article.gmane.org/gmane.comp.....perfometer/19

Compiler Size DLLs
-------- ---- -----
gcc, Cygwin 478971 cygwin1.dll, KERNEL32.dll, NTDLL.DLL
gcc, Cygwin, STLport 712195 cygwin1.dll, KERNEL32.dll, NTDLL.DLL
gcc, Cygwin, Mingw32 interface 503820 msvcrt.dll, KERNEL32.dll, NTDLL.DLL
gpp, DJGPP 648443 DJGPP doesn't support dynamic linking
dmc, DigitalMars, STLport 381468 KERNEL32.dll, NTDLL.DLL, USER32.DLL, GDI32.DLL

We can see that dynamic linking usually reduces size of the executable.

Note about <gcc, Cygwin, STLport>.
This executable contains supplementary library libstlport_cygwin.a;
its size = 2406816.

--
=====================================
Alex Vinokur
mailto:al****@connect.to
http://mathforum.org/library/view/10978.html
news://news.gmane.org/gmane.comp.lang.c++.perfometer
=====================================

[Marc Ferry]

Did you strip the executables before comparison ?
FYI: strip = remove debug info, symbol table, etc

Also, be sure to have the same level of compiler optimization in your
Makefile.

Marc

Chris Mantoulidis wrote:

Out of curiosity, I wanted to test executable file sizes of the same
program from different compilers...

The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
and DJGPP 2.03...

The program was nothing but a simple hello world program using the
iostream header file...

I compiled and linked (both copies) with those 2 different
compilers... The Borland c++ 3.1 compiler gave me an executable with
size like 20-30KB (i don't remember) and DJGPP gave me an executable
with size like 220-240KB...

I can assume 2 things here... Either DJGPP produces WAY more
compicated executables (kind of odd though) or DJGPP's header files
contain kinda different info....

Anyone seen anything like that? Anyone know why?

[Alex Vinokur]

"Marc Ferry" <mf********@rd.francetelecom.com> wrote in message news:bo*********@news.rd.francetelecom.fr...

Did you strip the executables before comparison ?
FYI: strip = remove debug info, symbol table, etc

[snip]

Very efficient.

Here are executable sizes before and after stripping.
Executables are from my first posting in this thread.

Compiler Before After
strip strip
-------- ------ -----
g++, Cygwin 478971 237568
g++, Cygwin, STLport 712195 335360
g++, Cygwin, Mingw32 interface 503820 251904
gpp, DJGPP 648443 330240
--
=====================================
Alex Vinokur
mailto:al****@connect.to
http://mathforum.org/library/view/10978.html
news://news.gmane.org/gmane.comp.lang.c++.perfometer
=====================================

[Jerry Coffin]

In article <bo*************@ID-79865.news.uni-berlin.de>,
al****@bigfoot.com says...

"Marc Ferry" <mf********@rd.francetelecom.com> wrote in message news:bo*********@news.rd.francetelecom.fr...

Did you strip the executables before comparison ?
FYI: strip = remove debug info, symbol table, etc

[snip]

Very efficient.

Here are executable sizes before and after stripping.
Executables are from my first posting in this thread.

Compiler Before After
strip strip
-------- ------ -----
g++, Cygwin 478971 237568
g++, Cygwin, STLport 712195 335360
g++, Cygwin, Mingw32 interface 503820 251904
gpp, DJGPP 648443 330240

Hmmm...not very impressive, really. Just for comparison, consider that
compiling your code with VC++ 7.1 using:

cl -Oxb2 -G6ry

produces an executable of 106,496 bytes.

Compiling with Borland 5.5 produces an executable of 179,712, but
produces an executable that doesn't work correctly -- I haven't tried to
figure out whether it's a problem with the compiler or with your code
though.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Alex Vinokur]

"Jerry Coffin" <jc*****@taeus.com> wrote in message news:MP************************@news.clspco.adelph ia.net...

In article <bo*************@ID-79865.news.uni-berlin.de>,
al****@bigfoot.com says...

"Marc Ferry" <mf********@rd.francetelecom.com> wrote in message news:bo*********@news.rd.francetelecom.fr...

Did you strip the executables before comparison ?
FYI: strip = remove debug info, symbol table, etc
[snip]

Very efficient.

Here are executable sizes before and after stripping.
Executables are from my first posting in this thread.

Compiler Before After
strip strip
-------- ------ -----
g++, Cygwin 478971 237568
g++, Cygwin, STLport 712195 335360
g++, Cygwin, Mingw32 interface 503820 251904
gpp, DJGPP 648443 330240

Hmmm...not very impressive, really. Just for comparison, consider that
compiling your code with VC++ 7.1 using:

cl -Oxb2 -G6ry

produces an executable of 106,496 bytes.

Indeed, considerable distinction.

What DLLs does this executable depend on?
What are their sizes?

Compiling with Borland 5.5 produces an executable of 179,712, but
produces an executable that doesn't work correctly --

We are talking about the algorithm at
http://groups.google.com/groups?selm....uni-berlin.de

I have compiled the algorithm with
* GNU gcc (Cygwin, Cygwin with STLport, Mingw, DJGPP) and
* Digital Mars C++ compiler
and computed Fibonacci [50,000].
All results are identical.

What Fibonacci number does Borland 5.5 produce incorrectly?
I haven't tried to
figure out whether it's a problem with the compiler or with your code
though.

[snip]

--
=====================================
Alex Vinokur
mailto:al****@connect.to
http://mathforum.org/library/view/10978.html
news://news.gmane.org/gmane.comp.lang.c++.perfometer
=====================================

[Jerry Coffin]

In article <bo*************@ID-79865.news.uni-berlin.de>,
al****@bigfoot.com says...

[ ... ]

Hmmm...not very impressive, really. Just for comparison, consider that
compiling your code with VC++ 7.1 using:

cl -Oxb2 -G6ry

produces an executable of 106,496 bytes.
Indeed, considerable distinction.

What DLLs does this executable depend on?

None other than kernel32.dll, which is part of the OS, so presumably
you're not trying to count it. If you're actually interested primarily
in small size, using:

cl /O1 /G6ry fibo.cpp

reduces the executable to 98,304 bytes, with the same (lack of)
dependencies. If you're willing to depend on some DLLs to get a smaller
executable, you can use:

cl /Oxb2 /G6ry /MD fibo.cpp /link /align:16

and get an executable of 15,488 bytes that depends on msvcp71.dll and
msvcr71.dll (and, of course, kernel32.dll, ntdll.dll, etc.). If you
want to be able to use the executable under Windows 95/98/SE/Me, you
have to remove the "align:16", which inflates the executable to 16KB.
What are their sizes?
MSVCR71.dll is 348,160 bytes
MSVCP71.dll is 499,712 bytes
What Fibonacci number does Borland 5.5 produce incorrectly?

It starts to go wrong at fib(46). Here's a cut-n-paste of output:

Fib [44] = 701408733
Fib [45] = 1134903170
Fib [46] = 1244061836311903
Fib [47] = 1244062971215073
Fib [48] = 2488124807526976
Fib [49] = 3732187778742049
Fib [50] = 6220312586269025
CPU time used : 0 sec

Anytime it gains more than one digit in an iteration, something's
clearly wrong...

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Alex Vinokur]

"Jerry Coffin" <jc*****@taeus.com> wrote in message news:MP************************@news.clspco.adelph ia.net...
[snip]

It starts to go wrong at fib(46). Here's a cut-n-paste of output:

Fib [44] = 701408733
Fib [45] = 1134903170
Fib [46] = 1244061836311903
Fib [47] = 1244062971215073
Fib [48] = 2488124807526976
Fib [49] = 3732187778742049
Fib [50] = 6220312586269025
CPU time used : 0 sec

Anytime it gains more than one digit in an iteration, something's
clearly wrong...

[snip]

Weird output.

http://groups.google.com/groups?selm....uni-berlin.de

* GNU gcc (Cygwin, Cygwin with STLport, Mingw, DJGPP : Optimization 0-3) and
* Digital Mars C++ compiler (No optimization, Space, Speed) .

All those executables generate the same (valid) output

---------
$ fib.exe all 50
[---omitted---]
Fib [40] = 102334155
Fib [41] = 165580141
Fib [42] = 267914296
Fib [43] = 433494437
Fib [44] = 701408733
Fib [45] = 1134903170
Fib [46] = 1836311903
Fib [47] = 2971215073
Fib [48] = 4807526976
Fib [49] = 7778742049
Fib [50] = 12586269025
CPU time used : 0 sec
---------
Unfortunaly I don't have Borland compiler. So, I am unable to analyze what is reason for that.
Regards,

--
=====================================
Alex Vinokur
mailto:al****@connect.to
http://mathforum.org/library/view/10978.html
news://news.gmane.org/gmane.comp.lang.c++.perfometer
=====================================

[Jerry Coffin]

In article <bo*************@ID-79865.news.uni-berlin.de>,
al****@bigfoot.com says...

[ ... ]

Weird output.
Yes, to put it mildly.
http://groups.google.com/groups?selm....uni-berlin.de

* GNU gcc (Cygwin, Cygwin with STLport, Mingw, DJGPP : Optimization 0-3) and
* Digital Mars C++ compiler (No optimization, Space, Speed) .

All those executables generate the same (valid) output

In case you care, so do VC++ and Comeau (Ver. 7.1 and 4.3 respectively).

--
Later,
Jerry.

The universe is a figment of its own imagination.